- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- AUTOGEN: How would I revert to orig configs is som...
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
тАО08-02-2004 07:31 AM
тАО08-02-2004 07:31 AM
Both Nodes are ES40s
Exp level=novice.
I have a 2-Node production cluster that is currently having some issues with quorum time-outs. HP has recommended that I increase the QDSKINTERVAL to 10, (I'm going to increase to 5. The current setting is two) and autogen the system. System needs to be rebooted for this.
I can see where the setting needs to be changed in each modparams.dat file on both nodes and can edit the file no problem.
Could you tell me?:
1. Is there any "best" way to run autogen? Meaning, are there any additional qualifiers that should be used that maybe the mgr's manual isn't giving examples to. What syntax would you use?
2. I'm from the HP-UX world, where the "procedure" to rebuild a kernel includes the creation of a backup kernel file. So, if there is a major malfunction I have confidence in knowing I can revert to the prior file/working config and at least get back to where I started.
How do I save the current settings in memory on VMS, so I can get back if something goes wrong?? Let's say some admin changed a setting in modparams.dat didn't tell me, now I can't boot the system nor do I know what the problem is. What is the normal practice?
3. If I have a problem, how would I re-gen the system to get my old/working settings back into place.
Any other advice would be appreciated.
Thanks
Kirk
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-02-2004 08:32 AM
тАО08-02-2004 08:32 AM
Re: AUTOGEN: How would I revert to orig configs is something went wrong with autogenning the system
http://h71000.www7.hp.com/DOC/732FINAL/6048/6048pro_001.html#agp
You can also get some excellent basic instructions by doing
$ @sys$update:autogen help
You should also familiarize yourself with doing a minimum boot, which is what you'll need to do if for any reason the changes cause problems upon rebooting. Documentation is here:
http://h71000.www7.hp.com/DOC/731FINAL/6017/6017pro_010.html#booting_min
I believe the tried and true method for getting back to where you were after a failed autogen/reboot sequence is to recover the old parameter file which is automatically saved for you. To do this you'll need to do a minimum boot and
SYSBOOT> set QDSKINTERVAL
SYSBOOT> continue
The system will complete the boot sequence using the reset (but not permanently restored) value for the parameter, whereupon you can get in and either have another whack with MODPARAMS.DAT and AUTOGEN or execute the following commands to get the old, generated parameter file back:
$ set default sys$system
$ rename alphavmssys.old alphavmssys.par
and then reboot.
This is a hasty summary from memory -- you should really read the docs and/or have the support center walk you through this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-02-2004 09:05 AM
тАО08-02-2004 09:05 AM
Re: AUTOGEN: How would I revert to orig configs is something went wrong with autogenning the system
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-02-2004 10:14 AM
тАО08-02-2004 10:14 AM
SolutionWhen you edit MODPARAMS.DAT to change parameter values, when you exit the editor, you don't overwrite the old file -- you create the next-higher version number under that filename. If the new version is bad, you can rename this new highest-numbered version to a different name or even delete it, thus "exposing" the previous version for re-use.
There are a number of other files associated with AUTOGEN, which are also located in the same SYS$SYSTEM area as MODPARAMS.DAT.
During the WRITEPARAMS phase, AUTOGEN puts the system parameters in binary form into the file ALPHAVMSSYS.PAR (VMSVMSSYS.PAR on VAX). But before overwriting the old file, it writes the old values into a file with the next-highest version number under name ALPHAVMSSYS.OLD. Each subsequent run of AUTOGEN just adds another version of this file. So unless you purge away or delete these old versions, they remain around, preserving history and providing recovery potential.
So if you had problems booting after an AUTOGEN run gone awry, you could boot "conversationally" (do
>>> SET BOOT_OSFLAGS n,1
at the SRM prompt, where "n" is the number of the system root you're booting from (nothing to do with UNIX root) -- the default is zero, and boot:
>>> BOOT
then at the SYSBOOT> prompt:
SYSBOOT> USE ALPHAVMSSYS.OLD
SYSBOOT> CONTINUE
This causes VMS to use the parameter values from where they were saved in the ALPHAVMSSYS.OLD file in place of the values from ALPHAVMSSYS.PAR. As VMS continues, it will eventually write these values into ALPHAVMSSYS.PAR, so this will write the old values over the current ones and you're back to where you were.
Other files which AUTOGEN creates are: AGEN$HISTORY.DAT with feedback data gathered during the SAVPARAMS phase, PARAMS.DAT with a list of input values resulting from the GETDATA phase, and from the GENPARAMS phase the file SETPARAMS.DAT with the entire list of SYSGEN commands it will use to set the parameters during the SETPARAMS phase. Each run of a given AUTOGEN phase generates a new higher-numbered version of the associated file, and you can use the $DIFFERENCES utility to compare the values if you wish.
What I like to do is run
$@SYS$UPDATE:AUTOGEN SAVPARAMS SETPARAMS FEEDBACK
and look at the AUTOGEN report in file SYS$SYSTEM:AGEN$PARAMS.REPORT, and if that looks OK then I compare the actual values that AUTOGEN is changing with what I expected it to change. Only if things look OK do I actually do the reboot.
If things don't look right then I would play with MODPARAMS.DAT and re-running AUTOGEN until they do (or if I gave up, I could rename to different names all the files AUTOGEN just created, leaving the previous versions exposed as the highest versions; the command
$ DIRECTORY/DATE/CREATED/SINCE=TODAY SYS$SYSTEM:
would help you identify the files AUTOGEN just created).
I've attached the short DCL command procedure I run after AUTOGEN to see what it changed. I call it SHOWPARAMS.COM.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-02-2004 10:27 AM
тАО08-02-2004 10:27 AM
Re: AUTOGEN: How would I revert to orig configs is something went wrong with autogenning the system
QDSKINTERVAL controls the number of seconds between checks of the quorum disk. After a node leaves the cluster unexpectedly, the VMS Cluster code re-validates the contents of the quorum file, and not until the contents have been re-validated does the cluster start counting the quorum disk's votes (QDSKVOTES) toward quorum. In some cases, the quorum disk could be validated in only 2 QDSKINTERVAL periods (but I'm not sure if this is still the case today), but in general it can take up to 4 scans (4 times QDSKINTERVAL in seconds) to re-validate the quorum disk's votes.
A related paramter is RECNXINTERVAL. This tells how long we wait during a communications interruption, hoping that communications will be restored, before giving up and kicking one or more nodes out of the cluster so it can once again meet the Rule of Total Connectivity (the ability for each and every system in the cluster to talk directly to each and every other node in the cluster).
In older version of VMS, QDSKINTERVAL had the default value of 10. RECNXINTERVAL has a default value of 20. One downside of this 10-second value for QDSKINTERVAL was that it could take up to 40 seconds to re-validate the quorum disk's votes after an unexpected node failure. But with these values, it was never possible for a node to validate the quorum disk's votes before deciding on the fate of other cluster nodes based on RECNXINTERVAL.
In a more-recent version of VMS just a few years ago, the default value of QDSKINTERVAL was lowered to 3 seconds. This change meant the quorum disk could be re-validated in at most 12 seconds, which was much faster than the previous maximum of 40 seconds. But this also meant it might be possible for one of the nodes connected to the quorum disk to validate it and "grab" ownership of it before the RECNXINTERVAL timer had expired.
I'm guessing this is why support is suggesting a value of 5 seconds (RECNXINTERVAL divided by 4, assuming it's set at the default value of 20 seconds).
There is much more detail on these concepts in the book "VAXcluster Principles" by Roy G. Davis.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-02-2004 09:11 PM
тАО08-02-2004 09:11 PM
Re: AUTOGEN: How would I revert to orig configs is something went wrong with autogenning the system
in your (as usually, excellent) explanation I found two procedural aspects, which IMHO allow for some 'slicker' way of action.
>>> SET BOOT_OSFLAGS n,1
at the SRM prompt, where "n" is the number of the system root you're booting from (nothing to do with UNIX root) -- the default is zero, and boot:
>>> BOOT
this MODIFIES your bootstrap flags, permanently until the next SET BOOT_OSFLAGS.
I much prefer
>>> BOOT -FL n,1
this leaves the default boot settings intact, and only uses the alternate flags for this one boot action.
What I like to do is run
$@SYS$UPDATE:AUTOGEN SAVPARAMS SETPARAMS FEEDBACK
and look at the AUTOGEN report in file SYS$SYSTEM:AGEN$PARAMS.REPORT,
The SETPARAMS generates a new
If you replace SETPARAMS by GENPARAMS, everything will be the same, except for the creation of the .SYS file. Of course it does have a little drawback: if you got a set that satisfies you, you now have to rerun autogen with SETPARAMS. Then again, to might postpone that until you run it with REBOOT.
And again, that also does have a drawback: now, IF you get an unplanned reboot (un-hoped for, but hardware malfunctions DO occasionally occur!), then you come back up again without your new params.
All in all, WE generate the new param file when, and only if, we are satisfied with the .REPORT reports.
ymmv of course.
Jan