Restoring Original System Parameter Settings

[Niall Godwin]

Hi,

An Alpha/OpenVMS V7.1-2 system recently crashed. The system didn't go through the normal crash recovery so I don't have any diagnostic data to examine.
However I suspect that it may have been the result of changes that I had made to system parameter values.

I can restore the system disk from a recent image backup, but can I simply 'undo' the parameter changes using the previous versions of PARAMS.DAT and SETPARAMS.DAT that are still on the system.

Niall Godwin.

[Robert Gezelter]

Niall,

How did you make the changes?

If you used MODPARAMS.DAT and AUTOGEN, you can certainly rename the latest MODPARAMS.DAT (in this type of situation, I never recommend deleting anything, it may be of use in understanding, recovering, or reproducing the problem).

If you made other changes, it is different. Please let us know how you effected the change in system parameters.

- Bob Gezelter, http://www.rlgsc.com

[Allan Bowman]

Yes - you should be able to restore the previous version. Delete or rename the top versions of the two files and then run Autogen - I am not at a system at the moment, but I believe you want both the start and end phases to be SETPARAMS (and of course, NOFEEDBACK). You can check what the various phases are with "@sys$update:autogen help".

Allan in Atlanta

[Arch_Muthiah]

Niall,

If you want to examine the system crash, you can do that using system crash dump analyzer (SDA).
I have to look into the help to see how to recover system paramaters you have changed manually.
But better you can run MCR SYSGEN, which will tune your system for better performance.


Archunan

[Niall Godwin]

Bob,
I made the changes in MODPARAMS.DAT and ran AUTOGEN with FEEDBACK.
I have the previous version of MODPARAMS.DAT.
Niall.

[Arch_Muthiah]

whoops, too many answers, before I complete typing my response. Yes, Niall, you can follow the suggestion Mr.Bob suggested. AUTOGEN.


Archunan

[Robert Gezelter]

Niall,

Good. Since you made the changes in MODPARAMS.DAT, you can rename the newest version of MODPARAMS.DAT to something else, and then, as Allan noted, use AUTOGEN to rebuild the parameters based upon the earlier MODPARMS.DAT.

The key to recovering this type of situation is to never delete anything until you are ABSOLUTELY POSITIVE BEYOND ANY (REPEAT -- ANY) DOUBT that the problem file will NEVER be needed (apologies for the UPPER CASE emphasis, but I have seen too many client situations where that advice was not followed, it is all too often an expensive mis-step).

I hope that the above is helpful.

- Bob Gezelter, http://www.rlgsc.com

[Niall Godwin]

Bob,

Thanks for the advice and it is one of the options that I had considered. But I am unsure about one issue.

When I modified MODPARAMS, I ran AUTOGEN with FEEDBACK which may or may not have been a wise move.

Given this, will running AUTOGEN again with the previous version of MODPARAMS (and without FEEDBACK) restore the system to EXACTLY what it was before the changes. This is the reason why I posed the question on whether I could use the previous versions of PARAMS.DAT & SETPARAMS.DAT.

Hope my question makes sense.

Niall.

[Robert Gezelter]

Niall,

I would not recommend FEEDBACK in this situation. FEEDBACK may have introduced changes in the settings.

The advantage of this approach is that you can delete the identifiable updated files from TODAY, and do things again.

I would generally recommend rerunning AUTOGEN without FEEDBACK. It is possible to get into some peculiar situations when you reset files that are generated/modified by AUTOGEN.

In effect, MODPARAMS.DAT will be out of synch with the running system. If this situation persists, the next person to attempt changes will be pole-axed by the assumption that MODPARAMS.DAT reflects the current state of the system. It is not pleasant to untangle that situation.

It should go without saying that if you are the least bit unsure of this situation, a BACKUP or ZIP of the affected files BEFORE attempting the changes is a good safety netm against accidents.

- Bob Gezelter, http://www.rlgsc.com

[Niall Godwin]

Bob,
Having unwisely used FEEDBACK when making the changes, would it be better to use the previous version of SETPARAMS.DAT (as Allan believes I can).

i.e rename the latest version of SETPARAMS.DAT and run AUTOGEN as follows
$ @sys$update:autogen setparams reboot nofeedback

Alternatively:
Since AUTOGEN saved the original system parameters in the file SYS$SYSTEM:ALPHAVMSSYS.OLD before updating the parameters in SYS$SYSTEM:ALPHAVMSSYS.PAR,
can I simply restore the OLD file (to the PAR file) and reboot the system ?

Niall

[Robert Gezelter]

Naill,

To get back a running system in a flash, Allan is correct. HOWEVER, I have seen so many catastrophes caused by out of synch MODPARAMS and other files that I prefer to go back to the pre-FEEDBACK MODPARAMS.DAT and re-run AUTOGEN (this should produce the same file as the pre-FEEDBACK and pre-bad Change file). It also guarantees that you are in a stable situation.

In an emergency, yes. However, you are not finished with resolving the problem until MODPARAMS.DAT is valid. Otherwise, you are merely increasing the potential for catastrophic damage from out of synch files (for example, more than a few update and installation procedures presume that MODPARAMS.DAT is valid and run AUTOGEN automatically). If it is not valid, and you install a patch, you will be in a "land of mirrors" (or if you fancy ZORK or ADVENTURE, "twisty little passages") with no easy way out.

- Bob Gezelter, http://www.rlgsc.com

[David Jones_21]

"Since AUTOGEN saved the original system parameters in the file SYS$SYSTEM:ALPHAVMSSYS.OLD before updating the parameters in SYS$SYSTEM:ALPHAVMSSYS.PAR,
can I simply restore the OLD file (to the PAR file) and reboot the system ?"

Yes, you should be able to do that, but the autogen will likely hose you again if some setting in modparams.dat is screwing things up.

When we had a couple dozen identical workstations in a student lab, I would tune one machine and then copy the alphavmssy.par file to each root (changing the systemID appropriately).

[comarow]

Neil,

Generally using feedback and running autogen
is a good thing to do. Highly recommended.
The first question that comes to mind,
which no one asked was: Was the feedback
good? Meaning, was it for at least 24 hours
and did the system have a full load? If so,
that is unlikely the problem.

The easiest way to see what changed is
$set default sys$system
$set term/width =132
$differences/parr setparams.dat

If you'ver run autogen more than once
$diff/paf setparams.dat;newversion - setparams.dat;oldversion


It will compare the old and the new
setparams.dat
It will highlight the changes. I suggest
always doing that after running an autogen
as a sanity (or in my case, insanity) check.

If it lowers any parameter that you wonder about, or change say a cluster or shadow parameter that someone did just in sysgen,
add them to modparams.dat and rerun autogen.

Always know you agen$feedback.dat. Make sure it is a good, file that reflects a peak load on your system.

At boot, you can always do a
sysboot>use alphavmssys.old
and it will use the old parameters.

A little trick, especially if you are going to potentially run a lot of autogens.. and want a easy "backout recovery option".

Prior to doing anything at sysgen type
sysgen>write INCASE
that will save a copy of the current parameters you can always go back to.

at that point you can type
sysgen> use INCASE.PAR
and you'll be back to a known set of parameters.


Before doing anything

[Niall Godwin]

Thanks to all for your contributions.

Bob,
In the end, I took the safe route and ran AUTOGEN again using the previous version of MODPARAMS.DAT and with NOFEEDBACK on this occasion.

comarow,
Feedback was valid - system was up for over 100 days old.
Thanks for the very useful tips.

Niall