Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

System Disk Shadowing

SOLVED
Go to solution
Michael LaRoche
Frequent Advisor

System Disk Shadowing

I'm trying to figure out how a system pack is shadowed here. They have dka0 and dka300 as a shadowed system pack but neither is in the mount procedure for disk drvies. I need to install a patch and would rather take the one member (dka300) offline and install the patch to dsa0 then reboot without dka300 joining in.

Can the shadowset be setup by using flags at the chevron prompt?

Thanks for any guidance.
10 REPLIES
Kris Clippeleyr
Honored Contributor
Solution

Re: System Disk Shadowing


It seems you're talking about a shadowed system disk, DSA0:, members DKA0: and DKA300:.
To safely install a product, or a patch, you simply dismount one of the members, e.g. DKA300:; then perform the installation and reboot from the member still in the shadowset. VMS will upon reboot form a single-member shadowset, unless somewhere in SYSTARTUP_VMS.COM and/or friends, the second disk (DKA300:) is mounted in.
Make sure that you boot from the correct disk, so at the chevron (>>>) specify:
>>> B DKA0

If all's well, you have to restore the shadowset 'by hand', like:
$ MOUNT/SYS DSA0: /SHAD=(DKA0:,DKA300:) -
$_
I'm gonna hit the highway like a battering ram on a silver-black phantom bike...
Michael LaRoche
Frequent Advisor

Re: System Disk Shadowing

I had checked the systartup_vms.com and others for the mounting of disks but no mention of putting dka300 into dsa0.

That is why I ask if it is setup at the chevron prompt. I cannot get to the system console to check the chevron prompt setups, so is it possible to say for the default boot to boot dka0,dka300?
Jan van den Ende
Honored Contributor

Re: System Disk Shadowing

Michael,

Is this a cluster?
Then the boot recognises that both (or 3) members are mounted, and at SystemDisk mount all mounted members are mounted.

IIRC, _IF_ the SD shadowset is dismounted _CLEANLY_ , then even after a cluster shutdown (or a standalone member shutdown) this is recognised, and the whole set is mounted clean.

This implies, that if you first dismount one member, that member will also NOT be mounted automagically.

But... you have to double-double check that there __REALLY__ is NO shadow set mount for the system disk NOWHERE in the bootstrap!!

If possible, dismount 1 member, and do a reboot.
If the member is NOT mounted, go ahead, but, if the member DOES get mounted, FIND OUT WHERE!!!

Success.

Cheers.

Have one on me.

Jan
Don't rust yours pelled jacker to fine doll missed aches.
Kris Clippeleyr
Honored Contributor

Re: System Disk Shadowing



so is it possible to say for the default boot to boot dka0,dka300?


That certainly is possible, but has nothing to do with shadowing. If more than 1 disk is specified in BOOTDEF_DEV, it simply means that the system will try to boot from the first disk in the list, and if that is ABSENT, will try to boot from the second one.

Btw, you can use the lexical function F$GETENV to find the BOOTDEF_DEV device.

Greetz,

Kris
I'm gonna hit the highway like a battering ram on a silver-black phantom bike...
Uwe Zessin
Honored Contributor

Re: System Disk Shadowing

System disk members are automatically re-mounted, cluster or not. During bootstrap the code goes over all disks and checks them for having the same volume label and shadowset generation number.

If you dismount one member, the remaining disk(s) get a new generation number. As others have already mentioned, this prevents the automatic re-mount of this member during bootstrap provided that you have no explicit mount anywhere.

You can simply try it out:
- dismount the non-boot member
- reboot the system
- check if this disk has become a shadowset member again (if it's in a shadow copying state - the must be an explicit MOUNT somehere)
.
Michael LaRoche
Frequent Advisor

Re: System Disk Shadowing

I had noticed in modparams.dat there are statements related to shadowing one being shadow_sys_disk = 1 and another being shadow_sys_unit = 0 (for dsa0). If I comment out those 2 and leave shadowing=2 and alloclass=1.

According to the above replies, dismount dka300 and reboot that should help once I change the modparams. If this is not correct please let me know.

Thanks
Lawrence Czlapinski
Trusted Contributor

Re: System Disk Shadowing

Michael, unless you are permanently disolving the shadow you do not need to change shadow_sys_disk or shadow_sys_unit for patches. For OS version upgrades, you do have to turn off shadowing.
As previously stated, do either a: $dismount/cluster dka300 ! can be use whether on a cluster or not
or:
$dismount dka300 ! if not on a cluster

Reboot the cluster or standalone node to ensure that the only dka0 is in the shadow set.
If dka300 is shown as a member of dsa0 after the reboot, then there is a explict mount into the shadow set somewhere and you will have to comment it out and reboot again.
This is one reason, we usually don't have explict mounts of the system disks except in mixed architecture clusters.
Lawrence
Daniel Fernandez Illan
Trusted Contributor

Re: System Disk Shadowing

Hi
The best option to disable shadowing on a system disk is:

perform a conversational boot
>>>b -flags 0,1 dka0

Disable volume shadowing

SYSBOOT>set shadow_sys_disk 0
SYSBOOT>continue

Install patch, reboot the machine and reform the shadow set:

$mount/confirm/system dsa0: /shadow=(dka0:,dka300:) volume_label.

Good luck.
Ian Miller.
Honored Contributor

Re: System Disk Shadowing

If you are just to install a patch then do what Kris suggested. I was doing exactly that last night and its fine. Note that you should shutdown apps, and quiese the system to ensure the system disk shadow set member you remove is a good a backup as possible.
____________________
Purely Personal Opinion
Michael LaRoche
Frequent Advisor

Re: System Disk Shadowing

Thanks to all who responded. I will have to defer the dismount of the dka300 until Dec. 4 and test it then. I'm sure it'll work as the pack is not explicitly mounted anywhere.