[Info-vax] Reconfiguring VMS 6.2 - Shadow set question

[Paul Sture]

In article <k64k7u$s9f$1 at dont-email.me>,
 Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:

> On 2012-10-22 21:43:45 +0000, Jan-Erik Soderholm said:
> 
> > In no case do you need a MOUNT of the system disk in any command file.
> 
> In no case?  In any command file?  Careful with those absolutes...  
> While I understand your intent (and your statement is correct for what 
> you intend), it's quite possible to mount system disks additional times 
> for specific requirements, and there are constructs where mounting the 
> disk (shared) is handy to state (and enforce) an interest in a 
> particular disk.  Mounting a disk (shared) in a batch job means that 
> the disk won't drop offline due to an operator request, a state which 
> can be handy for data disks and for remote-mount system disks.  
> Mounting a disk a second time (during the bootstrap) can also be common 
> to bring that disk online in a cluster, too.  Now does everybody do 
> this?  No.  (A number of folks probably don't know about mounting disks 
> shared to maintain interest, but it's documented.)  And does the system 
> manager generally need to deal with mounting the local system disk in a 
> standalone configuration?  No.  But sites can choose to...

I believe Jan-Erik was referring to mount system disk shadow set members 
in the startup files.

>From the Volume Shadowing Manual:

http://h71000.www7.hp.com/doc/73final/5423/5423pro_003.html



--- start quote ---

CAUTION

Do not add members to a system disk shadow set in startup procedures. 
Doing so can result in loss of data under the following circumstances:

1. A system is operating normally with a multiple member system disk 
shadow set.
2. The original boot device is removed from the shadow set but remains 
as a functioning disk.
3. The system continues with the remaining members.
4. The system is shut down or it fails.
5. The system is rebooted using the original boot device (which is now 
out of date).
6. The boot process determines that the boot device is not consistent 
with the other shadow set members and, therefore, does not add them into 
the shadow set. This behavior preserves the up-to-date data on the other 
members.
7. A MOUNT command in the startup procedure adds the other shadow set 
members to the system disk shadow set.
8. A copy operation from the boot device to the other shadow set members 
is initiated, thereby overwriting them.

--- end quote ---

-- 
Paul Sture