Upgrading the OS

[roose]

Hi Folks,

Just a question concerning OS ugprades. Currently, we are on v7.3-1 and we are upgrading to v7.3-2. Together with the OS upgrade activity, we will also be increasing our memory from the current 4GB to 8GB. We have a two-node ES80 cluster here, DECnet Plus v7.3-1 ECO 2 and TCP/IP v5.3 ECO 4.

My question is: aside from the patches and update kits requirements, what SYSGEN parameters should we be modifying for a) the OS upgrade itself and b) the memory upgrade from 4GB to 8GB? Is it possible to do an autogen now with our current configuration and simulate an 8GB memory?

For the OS upgrade, I saw some thread regarding some previous issues with some PQL parameters causing a crash during the initial reboot, but based on HP's upgrade checklist, we should not be affected as the values of our parameters are less than 16352.

I have already checked the OS upgrade manual but I can't seem to find specific information, thus I am turning to your experiences :)

Thanks in advance for your help!

[Steven Schweda]

The OS upgrade should take care of itself, or
else tell you what you need to do. It may
run AUTOGEN if it thinks that that's a good
idea.

I would simply use AUTOGEN (again) after
installing the memory.

I see no benefit to "simulating" having more
memory than you have. That sounds to me like
a good way to cause problems.

[Volker Halle]

Roose,

on the first boot after the upgrade (in the so-called BOOTUPGRADE phase), AUTOGEN is run automatically. Make sure you have valid and recent autogen feedback data (by running shutdown with SAVE_FEEDBACK or executing a separate @AUTOGEN SAVPARAMS GENPARAMS FEEDBACK) prior to the upgrade.

Volker.

[Jan van den Ende]

Roose,

proceed as Volker suggests, BUT, AFTER the AUTOGEN on the upgrade OS & hardware, BEFORE going into production, have a REAL THOROUGH review of the generated AGEN$REPORT.
Even better: generate one BEFORE you begin, and afterwards compare them.

Expect some messages like: The calculated value was .. but a Minimum/Maximum/Hardcoded value of ... was specified.

Review those. Some may well be from explicit applic requirements. Consider scaling the specified value in rato of the calculated value.
Others have their reason in a past, (much?) more tight configuration. Please honour the calculated values for those.

And in general: be generous. AUTOGEN still tries (too much, in my and many others opinion) to conserve memory and CPU cycles, at the cost of what now usually is the most scarse resource: disk IO.

hth

Proost.

Have one on me.

jpe

[Guy Peleg]

I support earlier comments, let the O/S do
it work for the upgrade and run autogen.

Then you may want to increase WSDEF/QUOTA/EXTENT for various accounts on
your system, to grant critical processes
more physical memory. If you are using
VIOC cache (which I hope you are not), you might want to increase VCC_SIZE.

fwiw,

Guy Peleg
BRUDEN-OSSG

[Ian Miller.]

You may also find
min_quotas.com
at
http://dcl.openvms.org/stories.php?story=05/07/28/2894075

of use.

[comarow]

A few comments.

Many upgrades fail not because the uprgrade fails, but rather because during the upgrade, the run of autogen changes something that shouldn't have been changed!

Please make sure you have a system that can be autogened before the upgrade.

This most likely happens when people go into sysgen and make changes directly and not enter them in modparams.dat

The system will not check to see what changes have been made directly into sysgen. I have heard people claim that "Autogen ruined my system". It wasn't autogen. It was making the changes in sysgen without entering them into modparams.dat

That is because, as you gathered, the upgrade will run autogen. Thus, it is critical to have a good, valid feedback file. that means it must reflect your work load, be from within the last month, and be for 24 hours of uptime. Without good feedback, autogen can not make any reasonable adjustments.

Make sure you do not save feedback if the system hasn't been up for 24 hours or without a full load.

If you can test a full autogen and reboot prior to the upgrade, that would be best.

I agree with the comments about increasing working sets. However, usually the PQL_M parameters make them useless. If you check the PQL_MWSQUOTA and PQL_MWSEXTENT no UAF values below them will make any difference.

Have fun!

[roose]

Hi Folks,

Thanks for your reply on this one. Just two more things to clarify: if I do save my feedback, either through autogen or the SAVE_FEEDBACK option during shutdown, can I use it during my succeeding autogens after both the OS and memory upgrades? Will the system use this feedback during the first reboot after the OS upgrade?

Our problem here is that downtime is a very rare opportunity in this environment (as everywhere else :) ), and unfortunately, the primary application is not a cluster-aware one. Thus, once we release the system to production, that's it. We won't have the luxury of fine-tuning the system after a few days with normal loading.

[Steven Schweda]

> We won't have the luxury of fine-tuning the
> system after a few days with normal loading.

Some people would not call that a luxury.

[Volker Halle]

Roose,

just make sure you start the upgrade with valid feedback data (AGEN$FEEDBACK.DAT) present. The automatic AUTOGEN during the first boot of the upgraded system will use the existing feedback data.

Volker.