- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Preventing CONFIGURE startup
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-10-2007 04:02 AM
тАО10-10-2007 04:02 AM
Re: Preventing CONFIGURE startup
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-10-2007 04:05 AM
тАО10-10-2007 04:05 AM
Re: Preventing CONFIGURE startup
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-10-2007 04:19 AM
тАО10-10-2007 04:19 AM
Re: Preventing CONFIGURE startup
> 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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-10-2007 05:33 AM
тАО10-10-2007 05:33 AM
Re: Preventing CONFIGURE startup
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-10-2007 05:55 AM
тАО10-10-2007 05:55 AM
Re: Preventing CONFIGURE startup
> 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-10-2007 06:24 AM
тАО10-10-2007 06:24 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-10-2007 07:06 AM
тАО10-10-2007 07:06 AM
Re: Preventing CONFIGURE startup
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-10-2007 08:50 AM
тАО10-10-2007 08:50 AM
Re: Preventing CONFIGURE startup
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-10-2007 01:08 PM
тАО10-10-2007 01:08 PM
Re: Preventing CONFIGURE startup
$ 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-10-2007 06:49 PM
тАО10-10-2007 06:49 PM
Re: Preventing CONFIGURE startup
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