VMS & HSG80 powerup/boot

[Stephen Daddona]

We have an ES40 running VMS 8.2 that is connected to two HSG80's via a StorageWorks SAN Switch 8. We recently had a power failure in our computer room, and when the power came back, the ES40 booted faster than HSG80's. The result was that the ES40 couldn't 'see' the disks that are connected to the HSG80s. I had to restart the HSG80s and then reboot the ES40.
Is there a way to make the ES40 pause during startup to allow the HSG80s time to complete their startup?

Thanks in advance!

[Volker Halle · Accepted solution]

Craig,

there is no easy solution to your problem.

It may be possible to modify the power-up script to include e.g. some TEST commands to delay execution of the script enough, so that the HSG80s finish their power-up initialization first.

See chapter 2.23 in the ES40 User Interface Guide:

http://h18002.www1.hp.com/alphaserver/download/es40fg_revb.pdf

Be careful when modifying the power-up script.

Volker.

[Wim Van den Wyngaert]

Even when the HSG80 is booted, you can have the case that all disk are not yet visible (configure process is discovering them) when trying to mount them. We wait some time if we don't see them (maximum a few minutes).

Wim

[Ian Miller.]

If the ES40 system disk is not on the HSG80 the you could have the VMS startup DCL check for the disks and wait if they are not available.

[Stephen Daddona]

That's what I was thinking of trying - having the SYSTARTUP_VMS.COM procedure look for the DGA disks and waiting for them to become visible.
I don't think that I'll want to mess with STARTUP.COM!

[Thomas Ritter]

Following on from Ian, we do just that in all our system startups, but we do not wait. If the disks are not available, then the startup of the remaining Software products is aborted. It is quite straight forward, when the disks become available,to logon into the system account and resume the system startups or simply reboot. Experience has taught us to handle any disk problems well before starting other software or the application.

[John Gillings]

Craig,

I've attached a simple procedure which attempts to mount a disk. It will wait a maximum of 30 seconds for the device to appear. Obviously this can be modified to suit. Should be self explanatory.

My preference is to abstract the "storage objects" from the physical devices. You need a kind of data base which can associate "nick names" for storage objects to devices and logical names. During startup, you then ask a procedure to make sure the storage is available, perhaps with an importance flag (ie: "REQUIRED - means wait forever until it's available, or "OPTIONAL" - means wait some timeout period, then give up and return a failure status). The procedure will check if the device exists and is mounted. If not, it will do whatever is needed.

Implemented correctly, this allows you to specify multiple logical objects that may map to the same physcial device, and you're free to move them around as required. You don't need to code an explicit sequence of mounts during the startup, it will be derived automatically. Your startup looks something like this:

$ @GETDISK APPLICATION_1 DISK$APP1 REQUIRED
$ @APP1_STARTUP
$ @GETDISK APPLICATION_2 DISK$APP2 REQUIRED
$ @APP2_STARTUP
$ @GETDISK APPLICATION_3 DISK$APP3 OPTIONAL
$ IF $STATUS.EQS.DISK_OK THEN @APP3_STARTUP

(or you can write the GETDISK call at the start of the APP_STARTUP.COM proceddure)

All the gory details of mounts, shadow sets, policies and other stuff are hidden in GETDISK.

[John Gillings]

Craig,

I've attached a simple procedure which attempts to mount a disk. It will wait a maximum of 30 seconds for the device to appear. Obviously this can be modified to suit. Should be self explanatory.

My preference is to abstract the "storage objects" from the physical devices. You need a kind of data base which can associate "nick names" for storage objects to devices and logical names. During startup, you then ask a procedure to make sure the storage is available, perhaps with an importance flag (ie: "REQUIRED - means wait forever until it's available, or "OPTIONAL" - means wait some timeout period, then give up and return a failure status). The procedure will check if the device exists and is mounted. If not, it will do whatever is needed.

Implemented correctly, this allows you to specify multiple logical objects that may map to the same physcial device, and you're free to move them around as required. You don't need to code an explicit sequence of mounts during the startup, it will be derived automatically. Your startup looks something like this:

$ @GETDISK APPLICATION_1 DISK$APP1 REQUIRED
$ @APP1_STARTUP
$ @GETDISK APPLICATION_2 DISK$APP2 REQUIRED
$ @APP2_STARTUP
$ @GETDISK APPLICATION_3 DISK$APP3 OPTIONAL
$ IF $STATUS.EQS.DISK_OK THEN @APP3_STARTUP

(or you can write the GETDISK call at the start of the APP_STARTUP.COM proceddure)

All the gory details of mounts, shadow sets, policies and other stuff are hidden in GETDISK.

[John Gillings]

Sorry, for the duplicate - first post said it has failed. Interesting that the attachment was dropped in the retry.

[Volker Halle]

Craig,

we are talking about HSG80 (e.g. DGA) disks here, which will NOT be configured by CONFIGURE, but need to be configured by explicitly running SYSMAN IO AUTOCONFIGURE.

The 'logical' place to wait for the disks to appear (in a loop starting with $ MCR SYSMAN IO AUTO), would be either in SYLOGICALS.COM or SYCONFIG.COM.

SYSTARTUP_VMS.COM would be too 'late', if you have common files on the HSG disks (e.g. queue manager db).

Also take into considertion, that you might want to skip the autoconfiguration, if booting with STARTUP_P1 = "MIN".

Volker.