Operating System - OpenVMS
1748087 Members
5032 Online
108758 Solutions
New Discussion юеВ

Re: Preventing CONFIGURE startup

 
Robert Gezelter
Honored Contributor

Re: Preventing CONFIGURE startup

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
Honored Contributor

Re: Preventing CONFIGURE startup

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
Honored Contributor

Re: Preventing CONFIGURE startup

> 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
Honored Contributor

Re: Preventing CONFIGURE startup

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
Honored Contributor

Re: Preventing CONFIGURE startup

> 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.
EdgarZamora
Trusted Contributor

Re: Preventing CONFIGURE startup


SYCONFIG is older than that and predates SYSMAN. If I recall correctly, SYSMAN probably came out in the 5.0 timeframe.

Anyway...

Bob,

I agree with you in principle and I'm a big fan of SYSMAN STARTUP. I especially like the resiliency of SYSMAN in tolerating startup errors. If I had a brand new VMS system I wouldn't even modify the SYxxx procedures, but too many people get confused with SYSMAN startup especially if you have a cluster and start doing stuff like enabling and disabling procedures on a per node basis (which you don't see unless you do a SHOW/FULL). Most people favor the original way of using systartup and the rest of the SYxxx procedures.

This is really an old religious debate and it boils down to personal preference I think. In this case the SYCONFIG way is faster (if Bart's SYCONFIG.COM is in SYS$COMMON.) Bart could either:

1. edit SYCONFIG.COM
2. delete SYCONFIG.COM;0 afterwards

OR

1. create xxx.com containing the same commands
2. insert it into SYSMAN startup for execution during the "initial" phase.
3. remove from SYSMAN startup when done.
4. delete xxx.com

If he has multiple sys$specific syconfig files then your way wins.
Robert Gezelter
Honored Contributor

Re: Preventing CONFIGURE startup

Edgar,

Indeed. The practice of modifying the various SYS$STARTUP:SY*.COM files goes back to the beginning (okay, not quite 17 November 1858).

SYSMAN/STARTUP does appear at, if I recall correctly without reference to the manuals (or my systems as I am writing this) at 5.0, which is a bit later.

The files are activated with an implicit SYS$STARTUP prefix, so the file searching obeys the SYS$SPECIFIC/SYS$COMMON hierarchy.

Proper checking of STARTUP controlled files DOES require checking BOTH the enable/disable status and the parameters to each file. While this needs to be done, it is not particularly different that dealing with the SYS$SPECIFIC/SYS$COMMON hierarchy (where oie does need to remember WHICH SYS$SPECIFIC applies; I have had people assure me that the crashed cluster member does not have anything in SYS$SPECIFIC, when I checked, I found out that they were looking at the RUNNING NODE'S SYS$SPECIFIC).

In the end, I try to use the STARTUP database where possible. It is far safer to disable a product (using SYSMAN) than it is to edit SYSTARTUP_VMS.COM.

A side effect of using the STARTUP database is that with a modest degree of care, the time to system availability is substantially reduced.

- Bob Gezelter, http://www.rlgsc.com
Robert Gezelter
Honored Contributor

Re: Preventing CONFIGURE startup

To all,

There is a typo in my previous posting:

... (where oie does need to remember ...

should read:

... (where one does need to remember ...
^^

My apologies for any confusion.

- Bob Gezelter, http://www.rlgsc.com
Jon Pinkley
Honored Contributor

Re: Preventing CONFIGURE startup

I am not convinced that avoiding the startup of the CONFIGURE process is sufficient to prevent MSCP served devices from being seen. I did the following on a satellite node, and it did prevent the CONFIGURE process from starting, but it did NOT prevent the node from seeing all the MSCP served devices present at the time the node booted.

$ create sys$specific:[sys$startup]VMS$INITIAL-050_CONFIGURE.COM ! prevent CONFIGURE process from starting on this node
$! NOTE: this didn't prevent MSCP served devices from being seen on the next reboot!

See the previous thread:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1114738

The main problems are:

1. Once a device is set to served, it can't be set /noserved, whether as a result of mscp_serve_all or explicit set device/served. Setting the device /noavailable does not prevent it being MSCP served either.

2. Most VMS disk devices cannot be disconnected, like LD virtual devices can be.

3. There is no way I am aware of to selectively exclude MSCP served devices from CONFIGURE's point of view.

Is there a problem other than the devices showing up, but not being usable? I too wish there was a better solution than rebooting multiple times, but other than the devices showing up, and using some memory for the io database, is there a problem with having the devices in the io database?

Jon
it depends
Bart Zorn_1
Trusted Contributor

Re: Preventing CONFIGURE startup

The thread Jon refers to confirms my suspicion that you cannot exclude DGA devices. CONFIGURE will configure anything it sees.

I have here a test cluster of two nodes. One DGA device has been made invisible by the storage team. One cluster member still MSCP serves this DGA device.
When I reboot the other member, while preventing CONFIGURE to startup, this DGA device does not get configured. As soon as I start CONFIGIRE afterwards, the DGA device appears.

For a first test I prevented the CONFIGURE startup by editing SYS$STARTUP:VMS$INITIAL-050_CONFIGURE.COM. I will decide for a more sophisticated way later.

However, my first attempt to do it in a more supported way, by setting STARTUP$AUTOCONFIGURE_ALL to 0 and doing the SYSMAN IO commands in SYCONFIG, resulted in CONFIGURE not being started, but the DGA device did get configured!
I have no idea (yet) why.

Note that not starting CONFIGURE does not interfere with a correct system startup. Of course, if the accessibility of disks depend on MSCP, that is an other story.

Bart