VMS & HSG80 powerup/boot

[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.