Hi The below one worked : Smitty HACMP Extended Configuration Extended Verification and Synchronization Verify first for

errors Emulate or Actual [Emulate} Verify changes only? [No] Logging [Standard] ==================================================== If no errors above do the Actual Emulate or Actual [Actual] Verify changes only? [No] Logging [Standard] Thanks and Regards, samsung ******************************************************************************** ***** Lets make things a little bit more easier: - HACMP 5.4.1 => No timestamp file => timestamp is compared to the value in the ODM - No enhanced Concuurent Mode VG => Terms active/passive do not apply To determine the real state, execute the following command on both nodes: lsattr -El <vgname> The output contains a value named timestamp => this is the value which HACMP wil l compare to the actual value on the VG. Now, on the node where the VG is currently varied on, execute the following comm and an any disk contained in this VG, e.g. hdisk4: lqueryvg -p hdisk4 -T This command will read the timestamp directly from the disk. The value should be the same as given by the lsattr command. If HACMP warns you about a timestamp Problem. the lsattr Command will show a dif ferent value on at least one of the nodes. To correct this problem, you need to use a command which reads the timestamp from the disk and writes it to the ODM = > this is what synclvodm odm does. importvg -L should work as well as it will ca ll synclvodm (this would be the better choice anyway as importvg is high level c ommand). In order to be able to call importvg -L, the disks of the VG need to be accessib le. In non-concurremt environments, access is usually blocked through SCSI3 disk reservation.

Assuming node 1 has currently the VG online, and node 2 needs to execute importv g -L doe the follwoing: on node 1: varyonvg -b -u -n <vgname> # this will break the reservation on node 2: importvg -L <vgname> # this should update the time stamp in your ODM on node 2: lsattr -El <vgname> # verify if the value has really changed one node 1: restore the reservation with the following command: varyonvg -n <vgn ame> What C-SPOC calls are some pretty complicated functions - not so easy to track i f you are not really familiar to it. The easiest way to check what C-SPOC finall y did, is to look in the logfile /tmp/cspoc.log or /var/hacmp/log/cspoc.log on t he initiating node. A final word: As long as no mount is issued, no consistency problem can appear.