Autogen

[Peter Clarke]

Basically i would just like to know how you all run Autogen and what are the best qualifiers to use???

Also does anyone know when i am likely to receive my copy of VMS 8.2??

Thanks

Peter

[Ian Miller.]

@SYS$UPDATE:AUTOGEN HELP
gives a brief list. The usual would be to
save feedback during peak hours

@SYS$UPDATE:AUTOGEN SAVPARAMS SAVPARAMS

(some data saved is a snapshot hence peak time)
then to run a report of suggested changes

@SYS$UPDATE:AUTOGEN GETDATA TESTFILES

Then see SYS$SYSTEM:AGEN$PARAMS.REPORT

When happy with the report

@SYS$UPDATE:AUTOGEN GETDATA SETPARAMS

and reboot if non-dynamic parameters have changed.

[Ian Miller.]

RE V8.2 kit I recieved mine at the start of this week.

[Karl Rohwedder]

We received our kit ca. 2 weeks ago (Germany).

Regarding Autogen:
When the system is up for more than N days, we run an AUTOGEN SAVPARAMS during peek working hour and our nightly job performs a GETDATA TESTFILES phase.

mfg Kalle

[Jan van den Ende]

Peter,

8.2 (AXP): received early this week (NL)

AUTOGEN:

once a week peaktime for SAVPARAMS,

then at quiet hours GETPARAMS TESTFILES.

If the reports so indicate, SETPARAMS,
so any reboot will use the new params.

If serious reasons, then reboot just for that, but normally that can wait for things like patches etc.

Every single node in our cluster typically runs for (well) over half a year before any reboot. The cluster has not been down for 8 years.

Proost.

Have one on me.

Jan

[Kris Clippeleyr]

Peter,

Received V8.2 (Alpha & Itanium) last week (Flanders).

As for AUTOGEN, since most of our applications put a fairly stable load on the systems, we run AUTOGEN from SAVPARAMS to TESTFILES once in a while (each month or so). We then interpret visually the reports, and if necessary, modify MODPARAMS.DAT, and run AUTOGEN again to SETPARAMS. If static parameters change, we have to plea for a reboot.

Kris (aka Qkcl)

[Robert Gezelter]

Peter,

Just my US$ 0.02.

I often run AUTOGEN from GETDATA forward. I also often stop it BEFORE the reboot. This allows me to correct any errors and warnings that I detect BEFORE they actually take effect. Depending on what you are changing, you may want to stop AUTOGEN earlier (or even go one phase at a time).

Feedback data can be saved, used, ignored, or manually integrated into MODPARAMS.DAT. Which is appropriate in a particular situation depends on your workload. Often, I see dramatically different workloads over time, so I end up manually integrating the data, rather than end up with an inappropriate set of automatic values. This is particularly true in production systems, where load on any particular machine may vary widely depending upon how many of its colleague cluster members are online at particular points in time.

I am also an advocate of a set of tree-structured MODPARAMS.DAT files, so that cluster and site (in a multisite cluster) wide parameters only appear in a single place. This avoids the classic "failed to update the file" problem. In many cases, the only parameters that will be in a node-specific MODPARAMS.DAT will be the SCS identification parameters.

Some of the material related to this can be found in my OpenVMS Technical Journal article from January 2004 (a reprint of which can be downloaded from http://www.rlgsc.com/publications/vmstechjournal/inheritance.html).

I hope that the above is helpful.

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

[Jan van den Ende]

Peter,

I have to admit that I forgot to mention AGEN$INCLUDE_PARAMS
So, that credit goes to Bob, but I want to point out that it is indeed a VERY helpfull mechanism!
Take some time to determine how to optimise the modularisation, it will be time WELL spent!

Proost.

Have one on me.

Jan

[Jan van den Ende]

Peter,

OT, but from your profile:
"I have assigned points to 183 of 204 responses to my questions. "

See:

http://forums1.itrc.hp.com/service/forums/pageList.do?userId=CA1086708&listType=unassigned&forumId=1

some of those are already rather old.

-- maybe you can find some time to fixe up some loose ends? Even if you do think an answer deserves no points, then assigning 0 points will remove the "unassigned" flag.

Proost.

Have one on me.

Jan

[John Gillings]

Peter,

I recommend against ever letting AUTOGEN shutdown or reboot your system. SETPARAMS is the furthest I'll ever let it execute.

When AUTOGEN finishes, always check the report file: SYS$SYSTEM:AGEN$FEEDBACK.REPORT

If there are any problems, adjust MODPARAMS.DAT and iterate. When you're happy with the results, reboot manually.

I also recommend against allowing AUTOGEN to resize your page, swap or dump files. Place the lines:

SWAPFILE=0
PAGEFILE=0
DUMPFILE=0

in MODPARAMS.DAT to disable resizing.

After executing AUTOGEN, check the report for the recommended sizes. If you want to change the size use

$ @SYS$UPDATE:SWAPFILES.COM

The sizes AUTOGEN calculates tend to be low, attempting to minimise disk space. Allowing AUTOGEN to adjust them up and down just fragments the disk and the files. Allocate large files and leave them alone.

In a cluster, it makes sense to use AGEN$INCLUDE_PARAMS to include your cluster common parameters from a physically common file. This helps ensure there are no parameter conflicts between cluster nodes.

For example, here is a common parameter file from one of my clusters (4 nodes, V6.*):

AGEN$INCLUDE_PARAMS CLUSTER$FILES:CLUSTERPARAMS.DAT

CLUSTERPARAMS.DAT
----------------------------
VAXCLUSTER=2
VOTES=1
DISK_QUORUM="$46$DIA31 "
QDSKVOTES=4
EXPECTED_VOTES=8
QDSKINTERVAL=10

! Enable NI cluster interconnect
NISCS_LOAD_PEA0=1
NISCS_PORT_SERV=0
MIN_NISCS_MAX_PKTSZ=4468
MIN_SCSCONNCNT=40
!
! Serve everything
MSCP_LOAD=1
MSCP_SERVE_ALL=1
TMSCP_LOAD=1
TMSCP_SERVE_ALL=1
!
! disable AUTOGEN resizing
PAGEFILE=0
SWAPFILE=0
DUMPFILE=0
dumpstyle=1
!
! Security policy
LGI_BRK_TMO=720
LGI_HID_TIM=86400
MAXSYSGROUP=7
MIN_MAXBUF=4096
!
! Default terminal characteristics
TTY_DEFCHAR =%x180010B8 ! 24 lines+SCOPE+(NOWRAP)+LOWER+TTSYNC+HOSTSYNC+ESCAPE
TTY_DEFCHAR2=%x00023002 ! DISCONNECT+EDITING+INSERT+AUTOBAUD

[Jan van den Ende]

John,

You managed to surprise me again!

But this time by raising some doubt...


For example, here is a common parameter file from one of my clusters (4 nodes, V6.*):

AGEN$INCLUDE_PARAMS CLUSTER$FILES:CLUSTERPARAMS.DAT

CLUSTERPARAMS.DAT
----------------------------
VAXCLUSTER=2
VOTES=1
DISK_QUORUM="$46$DIA31 "
QDSKVOTES=4
EXPECTED_VOTES=8
QDSKINTERVAL=10


(For completeness, I _DO_ assume you do not override these params again in MODPARAMS.DAT :-( )

Firstly, I normally consider a quorum disk as a poor-man's workaround to reach the minimum of 3 voting nodes, and I like to do away with it as soon as the stable config reaches 3 active nodes.

Second, as I see it, this cluster has 4 1-vote nodes, and a 4-vote QDSK?
To me, that implies that the Qdsk is a full-fledged single-point-of-failure!!
I am sure you will have had your reasons, but I would like to see an explanation why a 4-node cluster would benefit from the extra complexity, overhead, and reaction time, just to add a SPOF?

Curiously awaiting,

Proost.

Have one on me.

Jan

[Ian Miller.]

I expect its so John can boot the cluster with only one node.

[Jan van den Ende]

Ian,

I can buy that argument, but...

in that case
QDSKVOTES = 3
EXPECTED_VOTES = 7
would get you there, but now, WITHOUT the QDSK as SPOF for the fully running cluster!
You would have to be missing at least two one node AND the QDSK to loose quorum!

So, question mark still stands.

Proost.

Have one on me.

jpe

[Robert_Boyd]

Something that I do in addition to the suggestions already mentioned is to compare the new SYS$SYSTEM:SETPARAMS.DAT file with the old one(s) with

$ DIFF/PARA SYS$SYSTEM:SETPARAMS.DAT

This allows me to see what has changed in a quick direct easy to read manner. I've been doing this for many years and it has been educational, and has occasionally saved me from big problems before doing the

$ autogen setparams

Robert

[John Gillings]

Jan,

Yes, you're correct. This used to be a 5 node cluster, and I haven't updated everything since removing a node. QDSKVOTES should be reduced to 3 and EXPECTED_VOTES should be reduced to 7.

In a production environment I agree, you're much better off eliminating the quorum disk. This particular cluster is our CSC V6 support cluster. It contains VAX and Alpha nodes V6.1 & V6.2, along with numerous different interconnects and disk technologies (SCSI, DSSI, IPI, ethernet, FDDI). It's a horrible mess of very old "scrap" systems that no sane person would use for production, but for support purposes it gives us a lot of flexibility.

The point here is to try to keep anything that needs to be common across the cluster in a single place to avoid conflicts. The required change in QDSKVOTES and EXPECTED_VOTES is a perfect example. Without the include file, those changes would need to be repeated 4 times, on each node. With the include, they're done ONCE and we can be confident that all nodes agree.