stealth AUTOGEN

[Jess Goodman]

I have three Itanium blades running IA64 VMS 8.4.   Recently I applied the UPDATE-V0700 patch to them, along with most of the ECO kits not included in that update, per  the master  ECO list (except  I have yet to find VMS84I_MUP-V0400 anywhere, but I digress).

Each node has its own system disk.  After updating the first node I rebooted it without issue,

After updating the second node I decided to run AUTOGEN on it.  When I then rebooted it apparently hung after joining the cluster but before  getting to SYSTARTUP_VMS.   I waited 10 minutes and then reset it  and this time it booted ok.

The next day I updated the third node and ran AUTOGEN on it.  It also hung on the first boot attempt and had to be reset.

In looking into this I was surprised to find that there were two sets of new AUTOGEN files (SETPARAMS.DAT, AUTOGEN.PAR,  IA64VMSSYS.OLD, etc.) on the two system disks where I had ran AUTOGEN once.  The timestamps of the second sets of files were 15-45 seconds later than the creation times of the STARTUP.LOG files from each node's first reboot attempt.

That made me decide to look in these STARTUP.LOG files.  Directory displayed them as being zero block files so I had to manually set the EOF mark on them.  Luckily the contents of the files had been flushed to disk before I reset the systems.

Typing them out I see that on both nodes the first boot occurred with STARTUP_P1 set to "MIN" and STARTUP_P3 set to "AGEN".   That expains why AUTOGEN ran.   The last line in both files was:

%STDRV-I-EMTYPHAS, phase LPBETA has no entries in file 0.

I do not know why they hung after that step.   Even more mysterious,  I have no idea how the STARTUP_P1 and STARTUP_P3 parameters were set.  They were definitely blank strings before the updates, and there is nothing in MODPARAMS.DAT or any where else I have looked to explain it.

I just ran AUTOGEN on the first node that I updated.  STARTUP_P1 and STARTUP_P3  from USE CURRENT are both still blank strings.

Anyone have a clue?

TIA,

Jess

[Jess Goodman]

I am reopening this thread to answer my own question and then to ask a related one.

I loaded some VMS 8.4 updates on one of my IA64 blades today.  I then ran AUTOGEN with feedback and rebooted.  It did not hang this time, but before the boot process got to SYSTARTUP_VMS.COM  it shut itself down and rebooted again.  Once again I found that during the first boot STARTUP_P1 was "MIN" and STARTUP_P3 was "AGEN".

But ths time I was watching the console closely.  During the first boot I saw this:

%SYSBOOT-E-BADBAP, NPAG_BAP_* parameters do not match memory layout.
%SYSBOOT-I-SETBAP, Setting NPAG_BAP parameters to default and requesting AUTOGEN
/reboot.

%RAD-I-ENABLED, RAD Support is enabled for 3 RADs


    HP OpenVMS Industry Standard 64 Operating System, Version V8.4
    ) Copyright 1976-2012 Hewlett-Packard Development Company, L.P.


%SYSINIT-I- waiting to form or join an OpenVMS Cluster
%VMScluster-I-LOADSECDB, loading the cluster security database
%MSCPLOAD-I-CONFIGSCAN, enabled automatic disk serving
%STDRV-I-STARTUP, OpenVMS startup begun at 24-APR-2013 16:56:17.24
%STDRV-I-LOG, startup output is being written to SYS$SYSTEM:STARTUP.LOG

So SYSBOOT thought there was a problem with a SYSGEN value and changed the boot parameters on the fly in order to run AUTOGEN.

The "problem" SYSBOOT saw was with NPAG_BAP_MAX_PA.  Its old value was  2147483647 but when I ran AUTOGEN it was lowered all they way down to 4096 based on this line in AGEN$FEEDBACK.DAT

BAP_MAX_PA = 4096

The second AUTOGEN initiated by SYSBOOT used the same feedback data and would have kept NPAG_BAP_MAX_PA at 4096 if SYSBOOT had not used CHECK_FEEDBACK,  but with that option AUTOGEN instead wrote this to AGEN$PARAMS.REPORT:

** WARNING **
The feedback values for NPAG_BAP_MIN_PA and NPAG_BAP_MAX_PA are
        0 and 4096; these values conflict
        with registered Bus Addressable Pool in the range of
        0 to 2147483647.  These feedback values
        are ignored because they may not allow the system to boot.
        Hewlett-Packard recommends that new feedback data be collected
        using the SAVPARAMS phase of AUTOGEN.

Now here's the kicker:  4096 might seem way to low, but NPAG_BAP_MAX_PA  is specified n megabytes!    Prior to VMS 7.3-1 the units were bytes.  This change was documented in the V7.3-1 release notes.  So 4096 megabytes seems adequate and  2147483647 megabytes is obviously too large.

It seems apparent to me that the code in SYSBOOT and for AUTOGEN's CHECK_FEEDBACK option was never updated when the units were changed from bytes to megabytes.

I opened a case with VMS supoort back in December about this issue with AUTOGEN and CHECK_FEEDBACK.  I was not aware at the time that SYSBOOT has the same problem.  VMS Engineering closed my case after a couple of weeks stating that they were not able to reproduce the problem.

Is anyone else seeing this issue with NPAG_BAP_MAX_PA ?

Jess