Operating System - OpenVMS
1748274 Members
4200 Online
108760 Solutions
New Discussion юеВ

Re: Shadowing on a system disk.

 
TKelly_1
Occasional Advisor

Shadowing on a system disk.

Hello all,

I've recently been made responsible for a DS25 running openvms 7.3. The system disk in this machine 'was' shadowed.

Originally, two disks (DKA0 and DKA100) were in the shadowset DSA0:. Now, DKA100 is the only member of the DSA0 shadowset. It turns out the phsyical disk DKA0 was dead and has been for some time. I'd like to restore that shadowset.

I've replaced the physical disk with an identical disk (i.e. exact same disk, plugged into the spot from which the old DKA0 was removed). I can mount the new DKA0, copy files to it, verify it's working etc.. However when i try to re-add it to the DSA0 shadowset using:

mount/system dsa0: /shadow=($1$dka0:) alphasys

The shadow set attempted to merge but clocked up a large number of errors. I've been using the "Volume Shadowing for OpenVMS" manual as a reference, but have yet to spot what I'm doing wrong.

It appears to me that shadowing the system disks is a 'special case' (as the systartup_vms.com does not explicitly mount the system shadowset on startup, rather OpenVMS just knows to do this). Is there a particular sequence of actions required to rebuild this system shadowset with a new disk?

Thanks and regards.
19 REPLIES 19
Karl Rohwedder
Honored Contributor

Re: Shadowing on a system disk.

I am wondering about the merge, I would assume a shadow copy, perhaps you may tell us the real error messages.
The systemdisk is a special case during booting, but when the system us up and running adding and removing members from the shadowset is done as with data disks.

regards Kalle
Volker Halle
Honored Contributor

Re: Shadowing on a system disk.

TKelly,

welcome to the OpenVMS ITRC forum.

OpenVMS shadowed system disks do NOT need to be mounted in SYSTARTUP_VMS.COM, because OpenVMS will form the system disk shadowset with the same members as existed prior to the boot.

Your mount command is correct. I prefer to always use /CONFIRM when doing manual MOUNTs. This will tell you the label of the disk to be added - and overwritten - and still allows you to say NO, if you had specified the wrong disk.


The shadow set attempted to merge ...


The operation you've described is called a SHADOW COPY, not a MERGE. During a shadow-copy all blocks from the existing members are copied to the new member. A MERGE compares all blocks of all members and only updates blocks, which were different by copying it from the 'master member'.

Did you look at the errors being reported ? You will need DECevent (DIAGNOSE) or WEBES (SEA) to do this.

Try an INIT/ERASE DKA0: SCRATCH first, this will write to all blocks of the new disk and should report any problems at that time. This operation will take a while.

Volker.
The Brit
Honored Contributor

Re: Shadowing on a system disk.

Did you initialize the disk before you attempted to mount it into the shadowset??

$ Init/Sys $1$DKA0: ALPHASYS

(label is actually irrelevant). It is possible that the new disk is not actually "New". However, the fact that the disk is accepted into the shadowset and begins to copy, suggests that you used the correct commands, and that the problem is more likely with the new disk.

Anyway, as requested by Kalle, it would be best to cut and paste the actual error messages.

Dave
Dave.
TKelly_1
Occasional Advisor

Re: Shadowing on a system disk.

Hello and thanks for the quick replies. Ditto the welcome, I've been reading the posts on here for quite a while. It's an invaluable knowledgebase.

First off, yep, I'm 100% clear that "OpenVMS shadowed system disks do NOT need to be mounted in SYSTARTUP_VMS.COM". That's as per what I've read and my/your comments above.

:) Thanks for the note on /CONFIRM - I had actually used that myself. I too like the assurance of getting the target of the copy confirmed.

Apologies if I was loose with my terminology ('use of merge instead of copy'). You are correct, I am referring to the initial copy when adding a new member to the DSA0: shadowset.

Yup - I initialised the disk (a couple of times!) while playing with it.

I'll go and use DIA to dig out the exact errors from day I first tried this and then post them in short order.
Volker Halle
Honored Contributor

Re: Shadowing on a system disk.

TKelly,

did you do just an INIT DKA0: label or did you also use /ERASE - that makes a big difference here...

Volker.
Jim_McKinney
Honored Contributor

Re: Shadowing on a system disk.

> shadow set attempted to merge but clocked up a large number of errors

Copy, not merge, right? Errors on the source or destination disk? If the source disk has forced error flags set on any blocks those will need to be remedied prior to any shadow copy. In any case, you'll probably want to use one of the error log translation tools (DECEvent, WEBES, etc) to decode the event.
TKelly_1
Occasional Advisor

Re: Shadowing on a system disk.

I did not use /ERASE. So I'll add that to my to-do list too. Many thanks for highlighting the difference!
Robert Gezelter
Honored Contributor

Re: Shadowing on a system disk.

TKelly,

Just a small note of clarification. SYSTARTUP_VMS.COM is not the only possible place where a MOUNT can be placed.

The case of the system residence volume is indeed special, and all of the command files invoked during the startup are indeed not germane, however in other cases, it does make a great difference.

- Bob Gezelter, http://www.rlgsc.com
Jim_McKinney
Honored Contributor

Re: Shadowing on a system disk.

> use /ERASE

I actually find it preferable to use BACKUP and make a /PHYSICAL copy of the source disk onto the target, follow that with an INITIALIZE or MOUNT/OVERRIDE=SHADOW to destroy the SCB, and then initiate the shadow copy. Shadow copies then are much faster as the majority of the data on the target disk will not have to be updated and the initial copy was performed with no decision making code involved.