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.

[Jan van den Ende]

John, Volker,

you are giving VMS workarounds, which means, assuming VMS is sufficiently available to use those.
I might be wrong in this, but the way I read the question, the trouble is that there is no BOOT device yet!
_IF_ the boot device is also on the HSG, _THAT_ is the problem, and the other devices will probably appear sufficiently close together that they are also acvailable by the time VMS has reached the need to start using them.
OTOH, if local drives are used as SYSTEM disks, then your solutions are perfectly valid.

Craig, could you indicate which of those situations applies in your case?

Proost.

Have one on me (maybe at the Bootcamp in Nashua>)

jpe

[Volker Halle]

Jan,

my first reference is to a power-up script stored in the SRM console. This could help in the system-disk-on-HSG-not-yet-available situation, if some SRM commands could be found, which would cause sufficient delay in the power-up script.

Craig then talked about changes in SYSTARTUP_VMS.COM, so the discussion shifted towards solutions in OpenVMS itself.

Volker.

[Robert Atkinson]

Craig, a boot reset might give you enough time for the HSG's to initialise.

From the console :-

>>> set boot_reset on

Rob.

[Wim Van den Wyngaert]

I checked console log of 3 years of 4 GS160 nodes.

The mount of the common disk is most of the time succeeding after 20 seconds but I found 1 case where it took more than 30 seconds (failed after 32 seconds, succeeded after 46 seconds, no trials in between).

So I would give it at least a minute.

BUT the disks that were unavailable for up to 46 seconds were not served by the HSG80 but by MSCP (interbuilding disk via FDDI).

fwiw

Wim

[Stephen Daddona]

Thanks for all the responses!

1) The system disk is a locally-connected disk, so that's not the problem.

2) I was making the changes to my 'mount disks' DCL procedure to look for the DGA disks, and I was wondering if doing it in SYSTARTUP_VMS.COM was 'too late', like Volker said. The reason that I was wondering was that even after the ES40 was up for a few hours, the DGA disks never showed up. And using SYSMAN IO AUTOCONFIGURE didn't help. I had to restart the HSGs to have the ES40 'see' the DGA disks.

3. I'll look into the SRM module idea.

[Volker Halle]

Craig,

SYSMAN IO AUTO should have worked. If it didn't, then probably something was wrong with the HSG80s or the SAN path to them (did the FC switches come up correctly ?), so just rebooting the HSG80s might have cured the problem.

You could use ANAL/SYS and SDA> FC NAME and SDA> FC ADDR to look at the SAN-related data structures.

I wouldn't suggest to think about the SRM power-up script, if you boot from a local system disk and can do whatever workaround/wait in OpenVMS.

Volker.

[Stephen Daddona]

Now that you mention it, one thing I didn't consider was the possibility of the ES40 booting before the SAN switch does, so the ES40 doesn't get to see the HSG80s.

It still points to a need to figure out a way to 'pause' the ES40.

[Volker Halle]

Craig,

again, OpenVMS should be able to establish connections to the HSG80, even if the SAN switch comes up later than OpenVMS. A forced crash - instead of a plain reboot -of the ES40 in that state could have answered some of the questions...

Volker.

[Wim Van den Wyngaert]

Don't you have a console log of the HSG80 to find out what it was doing during the problem ?

Wim

[Stephen Daddona]

I don't have a console log of the HSG80.