topic Re: Preventing CONFIGURE startup in Operating System - OpenVMS

Preventing CONFIGURE startup

Bart Zorn_1 — Tue, 09 Oct 2007 05:08:13 GMT

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

Re: Preventing CONFIGURE startup

Steven Schweda — Tue, 09 Oct 2007 06:35:00 GMT

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

Re: Preventing CONFIGURE startup

Bart Zorn_1 — Tue, 09 Oct 2007 06:40:13 GMT

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

Re: Preventing CONFIGURE startup

Steven Schweda — Tue, 09 Oct 2007 06:46:49 GMT

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

Re: Preventing CONFIGURE startup

Bart Zorn_1 — Tue, 09 Oct 2007 06:51:58 GMT

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

Re: Preventing CONFIGURE startup

Steven Schweda — Tue, 09 Oct 2007 07:00:15 GMT

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

Re: Preventing CONFIGURE startup

Bart Zorn_1 — Tue, 09 Oct 2007 07:06:24 GMT

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!

Re: Preventing CONFIGURE startup

Steven Schweda — Tue, 09 Oct 2007 07:17:58 GMT

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

Re: Preventing CONFIGURE startup

Robert Gezelter — Tue, 09 Oct 2007 07:54:17 GMT

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

Re: Preventing CONFIGURE startup

Bart Zorn_1 — Tue, 09 Oct 2007 09:20:13 GMT

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

Re: Preventing CONFIGURE startup

EdgarZamora — Tue, 09 Oct 2007 09:51:43 GMT

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

Re: Preventing CONFIGURE startup

EdgarZamora — Tue, 09 Oct 2007 09:56:08 GMT

> using sysman io auto /exclude

make that io set exclude

the io auto /exclude would be too late.

Re: Preventing CONFIGURE startup

Wim Van den Wyngaert — Tue, 09 Oct 2007 10:45:10 GMT

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

Re: Preventing CONFIGURE startup

Robert Gezelter — Tue, 09 Oct 2007 11:06:27 GMT

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

Re: Preventing CONFIGURE startup

John Gillings — Tue, 09 Oct 2007 18:31:11 GMT

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.

Re: Preventing CONFIGURE startup

Bart Zorn_1 — Wed, 10 Oct 2007 01:49:51 GMT

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

Re: Preventing CONFIGURE startup

The Brit — Wed, 10 Oct 2007 06:31:27 GMT

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

Re: Preventing CONFIGURE startup

Bart Zorn_1 — Wed, 10 Oct 2007 07:59:46 GMT

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

Re: Preventing CONFIGURE startup

John Travell — Wed, 10 Oct 2007 10:03:41 GMT

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:

Re: Preventing CONFIGURE startup

EdgarZamora — Wed, 10 Oct 2007 10:41:23 GMT

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.