Preventing CONFIGURE startup

[Bart Zorn_1]

Hello,

I want to prevent the automatic startup of the CONFIGURE process until all members of the cluster have rebooted. Is there a supported way to NOT start CONFIGURE during system startup?

The reason for this is that we are removing a lot of DGA devices from our configuration and I do not want the removed devices to show up after a reboot because some other cluster member is still MSCP serving them.

Once all members have rebooted (and nobody is MSCP serving the non-existing devices anymore), I want to start the CONFIGURE process on all members.

Setting STARTUP$AUTOCONFIGURE_ALL to zero, or setting the SYSGEN parameter NOAUTOCONFIG to 1 will prevent the startup of CONFIGURE. However, both these settings do much more than just this.

Has anyone any other ideas?

Thanks in advance!

Bart Zorn

[Steven Schweda]

Set STARTUP$AUTOCONFIGURE_ALL == 0 in
SYS$MANAGER:SYCONFIG.COM/.TEMPLATE, and then
add in all the stuff you actually want from
SYS$STARTUP:VMS$DEVICE_STARTUP.COM.

I'd've been happier, too, if there had been
more variables to control the various tasks
than just that one. (Especially when the
name sounds so harmless, but it wrecks so
much. Like, in my case, prevent the starting
of CONFIGURE.)

[Bart Zorn_1]

Steven,

Thank you for the idea. However, this is not precisely what one could call "supported".

An easier way to accomplish what I want is adding an "exit" at the beginning of SYS$STARTUP:VMS$INITIAL-050_CONFIGURE.COM. But that is also unsupported.

Regards,

Bart

[Steven Schweda]

> [...] this is not precisely what one could
> call "supported".

What's unsupported? SYCONFIG.COM wasn't
_my_ idea, and it's more likely to survive
an OS upgrade than an altered
VMS$INITIAL-050_CONFIGURE.COM is. Ugly as it
may be, I'd say the the one nice thing that
one might say about it is precisely that it
_is_ supported.

[Bart Zorn_1]

I have no problem adding something to SYCONFIG.COM. Indeed, that *IS* supported.

But you mentioned adding all the stuff to SYS$STARTUP:VMS$DEVICE_STARTUP.COM. I guess that is somewhat less supported.

Bart

[Steven Schweda]

> But you mentioned adding all the stuff to
> SYS$STARTUP:VMS$DEVICE_STARTUP.COM. I guess
> that is somewhat less supported.

No, unless someone has hacked into the ITRC
forums Web system, what I mentioned was
adding all the stuff you actually wanted
_from_ SYS$STARTUP:VMS$DEVICE_STARTUP.COM
[_to_ SYS$MANAGER:SYCONFIG.COM].

Now, it's possible that the critical parts of
VMS$DEVICE_STARTUP.COM could change someday,
but I wouldn't hold my breath waiting.

[Bart Zorn_1]

Indeed! Although I have my doubts about the proper operation of the ITRC website, I did misread your post. Sorry about that.

I think it is not a very "clean" solution, but I will think about it.

Thanks and regards,

Bart

P.S. the website returns errors when I submit something, but in the mean time it has accepted my submission none the less!

[Steven Schweda]

> P.S. the website returns errors when I
> submit something, but in the mean time it
> has accepted my submission none the less!

Get used to it. The ITRC forum software
shares many of the properties of complete
garbage.

The spurious "Error while posting the reply"
is only one of its many colorful defects.
There's a whole collection of 404 error
pages, too. Gullible newcomers often
multi-post because they believe these
helpful messages.

[Robert Gezelter]

Bart,

I would not recommend adding some special processing to an existing command file.

What I would recommend is using the STARTUP database to run an auxiliary file during the correct phase of startup processing. This file can check the setting of SYSGEN paramneters, and take appropriate action.

When the transition has completed (e.g., the extra DGA devices have all been removed), you can then disable the auxiliary processing, and remove the files entry in the STARTUP database.

Personally, I would prefer to add things to the SYS$COMMOM:VMS$LAYERED.DAT database.

Note that adding a file to the startup sequence in this fashion avoids the hazard of making modifications to a core startup command file and getting difficulties as a result.

- Bob Gezelter, http://www.rlgsc.com

[Bart Zorn_1]

Hello Robert,

although I do agree with you that generally the mechanism of SYSMAN STARTUP is nice to do things like this, I fail to see how that could be done in this case. VMS$DEVICE_STARTUP.COM is called by the SYSMAN STARTUP mechanism. This in turn calls SYS$MANAGER:SYCONFIG.COM. AFAIK the only place to prevent CONFIGURE from starting up is SYCONFIG. Once SYCONFIG completes, VMS$DEVICE_STARTUP starts CONFIGURE, unless STARTUP$AUTOCONFIGURE_ALL has been set to zero.

So there is no hole in which you could put something else.

Regards,

Bart

[EdgarZamora]

How many devices is "a lot of DGA devices"? Maybe you should approach this another way... like using sysman io auto /exclude?

[EdgarZamora]

> using sysman io auto /exclude

make that io set exclude

the io auto /exclude would be too late.

[Wim Van den Wyngaert]

Or very simple (and untested) : put zip.exe over configure.exe. This way the configure process will never do something. And afterwards, delete the exe again (thus the original exe is active again).

Wim

[Robert Gezelter]

Bart,

This posting is in response to your comment regarding the use of SYSMAN.

First, multiple files can be executed at each Phase of STARTUP.COM (the phases are: INITIAL, DEVICES, PRECONFIG, CONFIG, BASEENVIRON, LPBEGIN, LPMAIN, and LPBETA).

VMS$DEVICE_STARTUP.COM is called from phase DEVICES (the second phase of the startup sequence).

What I was suggesting in my earlier posting is to use an additional command file in the previous phase (INITIAL) to control the context for the invocation of CONFIGURE during the DEVICES phase.

- Bob Gezelter, http://www.rlgsc.com

[John Gillings]

Bart,

I think you can do what you want in a supported manner. I'd imagine there's not a whole lot else you can do on your nodes before you have DGA devices configured, so you could put code in SYCONFIG.COM to wait until there are enough cluster nodes present to satisfy your requirements.

Something like this perhaps?

$ nodes="|NODE1,|NODE2,|NODE3,|NODE4,"
$ WaitLoop:
$ WRITE SYS$OUTPUT "Waiting for ''nodes' at ''f$time()'"
$ c=0
$ NodeLoop: nn=F$ELEMENT(c,",",nodes)-","
$ IF nn.NES.""
$ THEN
$ IF F$GETSYI("CLUSTER_MEMBER",nn-"|")
$ THEN
$ nodes=nodes-"''nn',"
$ ELSE
$ c=c+1
$ ENDIF
$ GOTO NodeLoop
$ ENDIF
$ IF nodes.NES.""
$ THEN
$ WAIT 00:00:30 ! seconds
$ GOTO WaitLoop
$ ENDIF

For a one-off case, that's probably sufficient but if this is something you're likekly to want to do frequently, you probably need a sanity counter and maybe a SYSGEN USER parameter bypass.

You also may need to be a bit wary of races, as this code will "synchronize" your nodes to the end of SYCONFIG. Startup procedures may have implicit dependencies on nodes starting up at different times and not getting in each other's way.

[Bart Zorn_1]

John,

This is not what I am looking for. I want to reboot the 4 nodes of the cluster one at a time, so it is likely that the other 3 are present at the time of each boot. What I want is that the newly booted member does not configure the MSCP served devices from the other members.

Edgar,

We need to remove about 50 DGA devices, so a solution using SYSMAN IO SET EXCLUDE does not look attractive. In addition, I have no idea if the CONFIGURE process honors the exclusions!

Thanks for your ideas!

Bart

[The Brit]

Hi Bart,
Maybe I'm missing your point here (and if I am then I apologise), but couldn't you just turn of MSCP Serving? or use some other value for MSCP_SERVE_ALL?

Dave

[Bart Zorn_1]

Hi Dave,

Turning off MSCP service is not an option, for two reasons:

- You have to reboot to turn it off. This means it would require eight reboots (of 4 nodes) to get rid of the now non-existing DGA devices. Of course, because we are running production, an entire cluster reboot is out of the question.

- I want to have MSCP service as a last resort in case there is some major SAN problem.

Regards,

Bart

[John Travell]

Bart, I think I am missing something here.
You plan to reboot one node at a time, but intend to block CONFIGURE to effectively prevent a full startup during reboot. It will presumably also prevent the mounting of the volumes needed to permit the node to resume production activity.
Beyond preserving the cluster incarnation date, what else do you expect to achieve that a full cluster reboot will not do better ?
Methinks you are trying to create a lot of hard work and risk an extended outage just to avoid a moments downtime.
JT:

[EdgarZamora]

Bart,

I understand what you're trying to do and why you need to do a rolling reboot of the cluster. I think Steven's (Schweda) idea is your best bet. Modify SYCONFIG so you turn off the startup$autoconfigure_all. Add in the bits from VMS$DEVICE_STARTUP that you need and you're all set:

$ startup$autoconfigure_all == 0
$mcr sysman
io connect fta0/noadapter/driver=sys$ftdriver
io connect mpa0/noadapter/driver=sys$pipedriver
exit

This is temporary anyway until you can get all your nodes rebooted, right? After they are all rebooted, undo the stuff you did in SYCONFIG and start CONFIGURE on all the members.

[Robert Gezelter]

Edgar,

The one shot nature of this change is why I previously suggested a separate file entered into the VMS$LAYERED.DAT file at the appropriate phase.

This file would then be disabled and deleted when it is no longer needed.

This should accomplish the goals with the least risk. I try not to modify HP-supplied files if there is an alternative, equivalent mechanism.

- Bob Gezelter, http://www.rlgsc.com

[Robert Gezelter]

Edgar,

The one shot nature of this change is why I previously suggested a separate file entered into the VMS$LAYERED.DAT file at the appropriate phase.

This file would then be disabled and deleted when it is no longer needed.

This should accomplish the goals with the least risk. As a general practice, it is a sound idea to avoid modify HP-supplied files if there is an alternative, equivalent mechanism. I have seen far too many instances where an editing mistake caused a severe problem. Separate files executed under the STARTUP framework cannot interrupt the operation of the other files (e.g., an editing error in SYS$MANAGER:SYSTARTUP_VMS.COM will exit the file prematurely).

- Bob Gezelter, http://www.rlgsc.com

[Steven Schweda]

> I try not to modify HP-supplied files if
> there is an alternative, equivalent
> mechanism.

So, editing VMS$LAYERED.DAT/.TEMPLATE doesn't
do this, but editing SYCONFIG.COM/.TEMPLATE
does do this? Now I _am_ confused. (But
that's not unusual.)

[Robert Gezelter]

Steven,

A good question. SYS$STARTUP:VMS$LAYERED.DAT is indeed supplied as part of the HP distribution. However, it is an empty indexed file, intended to store the list of layered product (including third-party and customer products) startup files to be executed at various points in the startup sequence. The base OpenVMS startup sequence is governed by SYS$STARTUP:VMS$VMS.DAT, which is identical in format. Adding entries to the VMS$LAYERED.DAT file has been documented for many, many years, and is supported.

Both of these files are maintained using the SYSMAN STARTUP series of commands (reasonable documentation is available within SYSMAN using the HELP command).

In the past, I have given a summary description of what can be done using SYSMAN and the STARTUP database, the slides from that presentation at the Fall 1999 US DECUS Symposium can be found as "SYSMAN for Improved Restart Performance" at http://www.rlgsc.com/decus/usf99/index.html

- Bob Gezelter, http://www.rlgsc.com

[Steven Schweda]

> Adding entries to the VMS$LAYERED.DAT file
> has been documented for many, many years,
> and is supported.

ALP $ dire /date SYS$COMMON:[SYSMGR]SYCONFIG

Directory SYS$COMMON:[SYSMGR]

SYCONFIG.COM;1 3-MAR-1993 18:07:56.62
SYCONFIG.TEMPLATE;1
3-MAR-1993 18:07:56.62


2007 - 1993 = many, many years.

I quote:

$! This is an empty site-specific device configuration procedure.
$! If you have specific device configuration requirements at your
$! site, you should place the required commands in this procedure.
[...]

Sounds supported, even encouraged, to me.

As usual, there is more than one way to deal
with a problem like this, but claiming
distinct benefits for one method over another
makes more sense when those benefits are
actually distinct, not common.