AUTOGEN: How would I revert to orig configs is something went wrong with autogenning the system

[Kirk Reindl]

2-node VMS cluster running 7.3-1
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

[Craig A Berry]

You'll really want to read through ch. 6 of the System Management Utilities Reference:

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.

[Wim Van den Wyngaert]

Small tip : the autogen files are not cleaned up. If after a year you reboot while others have done several autogens you can do dir/dat alphavmssys.old to find when autogens where done. Just rename a date that whas valid ...

Wim

[Keith Parris · Accepted solution]

The file versioning built into VMS is a great asset, and this is one of the cases where that beneficial feature becomes evident.

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

[Keith Parris]

Now, with regard to the QDSKINTERVAL setting:

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.

[Jan van den Ende]

Keith,

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 VMSSYS.PAR file, which, if NOT satisfactory, COULD become a nuisance.
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