Shadow sets merge after system reboot

[Andrew Rycroft]

Hi,

I am using Volume Shadowing on my OpenVMS system. I find that after a system reboot the shadowsets go into a shadowset merge state. This takes a long time to complete.

Are there any ways this can be avoided ?

Thanks
Andrew

[Bojan Nemec]

Hi,

I remember that there was a work arround about merging shadowsets. The work arround says that you must open a dummy file on each shadow set before rebooting. So you put an open/close in your SYSHUTDWN.COM. But I dont remember where I read this. I never try, because reboots are so rare on VMS ;)

Bojan

[Volker Halle]

Andrew,

a shadowset only enters a merge state, if it has not been cleanly dismounted. During shutdown, this can happen due to open files preventing the dismount (look for appropriate %DISM-W- messages during shutdown). If this is the case, add SHOW DEV/FILES DSAx: commands into SYSHUTDWN.COM and make sure you close all open files.

Volker.

[labadie_1]

Hello Volker !

Happy to see you here.

:-)

Gerard

[Ian Miller.]

as has already been said its due to disk not being properly dismounted due to open files. The suggestion of doing SHOW DEV/FILES for each disk in SYSHUTDWN is a good one as it allows you to discover what is still open and then yu can add commands to close the files. This will minimise the occurance of this problem.

[Martin P.J. Zinser]

Hi Andrew,

one reason for this can be installed images residing on the disk or server processes (e.g. HTTP) having files open. As others pointed out,
a show dev/files in the shutdown procedure should give you some clues.

Greetings, Martin

[Wim Van den Wyngaert]

Stop all users, batch jobs and applications properly (e.g. stop/id).

Also check for spool files and other system things. As long as reference count in show dev/full is not zero, something is open (non system disk).

Also, if some station/server is doing MSCP IO to the disk you may have a shadow merge.

Wim

[Volker Halle]

Wim,

if another node in the cluster does have this shadowset mounted (required to do MSCP IO), the same principles apply to that node: if it leaves the cluster without properly dismounting that shadowset, it will cause a merge on that shadow set (on one of the remaining nodes in the cluster, if SHADOW_MAX_COPY allows)

Volker.

[Richard W Hunt]

If the reason for the reboot was predictable, you can do most of what you need by remembering to include the REBOOT and REMOVE options in your answers to the last question of the SHUTDOWN script.

But if the reboot was spontaneous, I don't think there is a way to prevent the merge. Nor do I think you WANT to, despite what you might think you want to do. That merge is going to prevent your systems from having inconsistent disk data on the two members of the shadow set. Which is, after all, the whole point of having a shadow set anyway. If they ain't consistent, they ain't shadows, either.