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