WEBES & sys$manager:shutdwn.com

[Kevin Carter_3]

Hardware: DS20E running OpenVMS 8.2
WEBES is installed on an ODS 5 shadow set.

Question: will sys$manager:shutdwn.com wait for WEBES to shutdown if shutdown.com contains $ desta stop? (from the command line it takes a while for WEBES to stop)

Issuing a $ wcc stop from the command line fails to shutdown the wccproxy process, even from a privileged account. Since the wccproxy process does not stop the dismount dsa30: fails and the shadow set has to be rebuilt after a reboot even with mini merge enabled.

Question: how to shutdown wcc proxy process for a reboot? (so the shadow set can be dismounted properly)

[John Gillings · Accepted solution]

Kevin,

It sounds to me like the DESTA STOP and or WCC STOP commands are asynchronous.

Therefore SYSHUTDWN.COM will NOT wait for them to complete because it has no way of knowing it's supposed to. Maybe there's a /WAIT qualifier to make it synchronous?

The "simple" solution is to write your own WEBES_SHUTDOWN.COM which is synchronous and call it from the system shutdown. The rough structure would look something like:

$ DESTA STOP
$ c=1
$ loop:
$ ! code to see if it's stopped
$ IF stopped THEN GOTO STOPWCC
$ WAIT 00:00:05 ! 5 seconds?
$ c=c+1
$ IF c.LT.sanity_threshold THEN GOTO loop
$ WRITE SYS$OUTPUT "WEBES SHUTDOWN FAILED"
$ STOPWCC: WCC STOP



The test code could use F$CONTEXT and F$PID to see if WEBES process(es) exist, or look for some other condition you know to be true when the shutdown has completed.

Alternatively, you could widen your scope to the more general issue of dismounting the shadow set and instead look at SHOW DEVICE/FILES DSA30, looking for open files.

Waiting for WEBES to finish is a waste of time if there's some other process holding a file open. You'll still have the shadow rebuild problem after the reboot.

Perhaps issue STOP or SHUTDOWN commands for anything you expect to be using the disk, then give it time to settle. Check for any other open files and STOP/EXIT/ID any remaining processes.

Another possibility which has its own risks but might be worth thinking about... if you have MINICOPY enabled, perhaps you could diskmount all but one member of the shadowset with /POLICY=MINICOPY. When you reboot, MOUNT/POLICY=REQUIRE_MEMBERS . I'm not certain, but maybe that will reform the shadowset with a MINICOPY? I don't know if the minicopy bitmap survives a reboot (on the other hand, it breaks by usual rule of never reducing a shadowset below two members)

[Karl Rohwedder]

Attached is a snippet from our shutdown procedure as a starter...

regards Kalle

[John Gillings]

Karl,

You could use F$CONTEXT to search for specific processes, rather than scanning all processes and performing your own match tests. For example, this:

$ Context = ""
$ Cmd_Stop_1:
$ thePid = F$PID(CONTEXT)
$ If (thePid.nes."")
$ Then
$ prcnam = F$Getjpi(thePid,"PRCNAM")
$ If (Prcnam.eqs."DESTA Director") .or. (Prcnam.eqs."WCCProxy")
$ Then
$ Stop /Ident='thePID'
$ Endif
$ Goto Cmd_Stop_1
$ Endif

becomes:

$ Context = ""
$ tmp=F$CONTEXT("PROCESS",ctx,"PRCNAM","DESTA Director,WCCProxy","EQL")
$ Cmd_Stop_1:
$ thePid = F$CONTEXT(Context)
$ If (thePid.nes."")
$ Then
$ Stop /Ident='thePID'
$ Goto Cmd_Stop_1
$ Endif

In this specific case there may not be much difference, but if you look at the rich set of attributes you can search for, including using wildcards, and compounding multiple context items, even across cluster nodes, it's well worth learning.

[Karl Rohwedder]

John,

I know, but some code is quite old and if it runs, it runs...

regards Kalle