topic Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha in Operating System - OpenVMS

Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

Edward Alekxandr — Thu, 31 Aug 2006 20:23:11 GMT

One of my colleagues has been testing OpenVMS 8.3 and as the following problem, can anyone shed any light on this?

During part of our testing with OpenVMS 8.3, we installed a clean copy
of the Operating System.
After adding a couple of entries to MODPARAMS.DAT (see below)
the OS will not boot, with an error message of:

EXECINIT-F-NOMEM, insufficient physical memory for minimum working set

The AUTOGEN.COM seems to have an error as it refers to the symbol
WSMAX_MAX which causes an unknown symbol DCL error,
which I assume should be WSMAX_MX.

The contents of MODPARAMS.DAT have not changed since OpenVMS 8.3. Any
ideas?

The host is a DS10 with 1GB RAM and the MODPARAMS entries are below:

MIN_PQL_DFILLM = 200
RJOBLIM=64
MIN_PQL_MASTLM=250
MIN_PQL_MBYTLM=750000
MIN_PQL_MENQLM=2000
MIN_PQL_MFILLM=250
MIN_CHANNELCNT=2048
MIN_PROCSECTCNT=40
ADD_GBLPAGES=1308357
MIN_WSMAX=12437
ADD_NPAGEDYN=17616
ADD_PAGEDYN=231264
ADD_GBLPAGES=1000000
MIN_MAXPROCESSCNT=32000
MIN_GBLSECTIONS=2000

Any help would be most appreciated.

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

Steven Schweda — Thu, 31 Aug 2006 21:01:21 GMT

I don't know anything, but
MIN_MAXPROCESSCNT=32000
looks pretty large to me, and
MIN_WSMAX=12437
looks pretty small (but if you really have
that many processes, I suppose that each one
can't expect very much memory).

Assuming that you fixed the problem(s) in
AUTOGEN.COM, did
SYS$SYSTEM:AGEN$PARAMS.REPORT say anything
interesting?

> After adding a couple of entries to
> MODPARAMS.DAT (see below) the OS will
> not boot, [...]

"Doctor, it hurts when I do this."
"Don't do that."

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

Edward Alekxandr — Thu, 31 Aug 2006 21:10:23 GMT

Most of the entries from MIN_xxx are from an installation of Advanced Server.

From what Luke said about the AGEN report, there were no entries relating to any warnings or errors.
He said he couldn't see any reason that VMS 8.3 would refuse to boot after running AUTOGEN with the same parameters VMS 8.2 was happy with.

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

Steven Schweda — Thu, 31 Aug 2006 21:16:55 GMT

> He said he couldn't see any reason that
> VMS 8.3 would refuse to boot after running
> AUTOGEN with the same parameters VMS 8.2
> was happy with.

Of course, AUTOGEN probably worked right in
V8.2, too.

Is your Advanced server version supported
under this VMS version?

I'll admit that it's not very satisfying, but
selectively removing the items which caused
the trouble may be the fastest way to see
which one(s) did it.

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

Edward Alekxandr — Thu, 31 Aug 2006 21:23:37 GMT

This install of VMS 8.3 is totally fresh, no Advanced Server nothing except the MODPARAMS entries and an AUTOGEN and reboot.

The only thing that worries me is the DCL error in AUTOGEN where is refers to wsmax_max (by doing a if wsmax .gt. wsmax_max then wsmax = wsmax_max)
which causes an error because wsmax_max is not actually defined, however wsmax_mx (and wsmax_mn) is.

I think Luke has tried to edit the autogen.com to correct this, after it nuked the params in order to boot.

I think we might have to do a trial and error approach, its just the coding error that makes me wonder if autogen is safe to run.

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

Thomas Ritter — Thu, 31 Aug 2006 21:49:33 GMT

Edward, there is more to running autogen than just running, rebooting and hoping all is well. Over the years there have been some problems.
You should always compare in text format the old parameters with the new parameters.

Consider something like this

$ node = f$getsyi("NODENAME")
$ mc sysgen
use sys$system:alphavmssys.par !Real Version
set/output=sys_users:[user.autogen]prod_new_params.txt
show/all
show/special
!!!use sys$system:alphavmssys.old !Previous version
use sys_users:[user.autogen]prod_PARAMS_CURRENT.PAR
set/output=sys_users:[user.autogen]prod_old_params.txt
show/all
show/special
exit
$
$differences/parallel/out=differences.lis prod_new_params.txt prod_old_params.txt
$type/p differences.lis

A difference file is very easy to examine.
I work in a environment where if you screw up and systems are not available, then you will pay compensation as agreed to in contract.

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

Karl Rohwedder — Thu, 31 Aug 2006 23:49:47 GMT

You didn't tell us about your system, but may be 32000 processes with minimum working set is too much for system, how much memory in there?

regards Kalle

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

Steven Schweda — Fri, 01 Sep 2006 00:04:18 GMT

> The host is a DS10 with 1GB RAM [...]

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

Volker Halle — Fri, 01 Sep 2006 01:14:37 GMT

Edward,

there is a definite bug in AUTOGEN.COM for OpenVMS Alpha V8.3. Please manually fix that bug (change references from WSMAX_MAX to WSMAX_MX) and make sure this gets officially reported to HP ! This code was not there in V8.2 - so it's new code and as we all know, new code can have bugs ;-(

Does AUTOGEN produce correct results after fixing the WSMAX_MAX reference ?

I'm just guessing: what's AUTOGEN calculating for BALSETCNT ? If you multiply that with WSMAX, do you exceed physical memory ?

Try reducing MAXPROCESSCNT or add a limit for MAX_BALSETCNT first.

Volker.

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

Edward Alekxandr — Fri, 01 Sep 2006 08:45:04 GMT

Firstly, thanks to everyone that posted, you've been really helpful.

I don't think Luke's had his call returned from our distributor,
let alone HP yet.

After editing autogen.com for wsmax_max symbols and removing the
MIN_MAXPROCESSCNT=32000, autogen works ok.

I understand that Luke has reported the bug, but I wouldn't
hold much hope in HP receiving it anytime soon due to the
distributor's 'way'.
Luke had a really odd bugcheck with a production system last week
and our distributor's comments were mostly 'computers crash, its a known problem'
I think they agreed to take it further with HP but you never know.

Regarding just running autogen and rebooting....
All of the Banks production systems are part of the Critical Online Zone
which means no changes to anything anytime when daylight trading (CHAPS and RTGS)
are operating. Also every change goes through InfoMAN on MVS.

This is a dev box that was wiped and a fresh copy of VMS 8.3 installed on it
by one of my colleagues so that he could get a feel for any differences to 8.2

I'm an MVS guy myself but they won't let me have my own zBox to play with,
I get a z/VM instance (admittedly a zBox costs around Â£200k)

Looking in InfoMAN I can see that the MAXPROCESSCNT entry causing the error
was implemented by our software vendor. Whilst I'll try and find out why,
anybody know any reasons why this might be? Its a CachÃ© DB.

Anyway thanks again to all (especially Volker)

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

Edward Alekxandr — Fri, 01 Sep 2006 08:47:35 GMT

Closed as per above.

Many thanks to all those that replied.

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

Volker Halle — Fri, 01 Sep 2006 08:56:41 GMT

Edward,

the maximum possible value for MAXPROCESSCNT changed from 16384 to 32767 just recently (from V7.3-2 to V8.2).

If the MODPARAMS.DAT file was from a pre-V8.2 system, this parameter could not have done much harm there (due to the absolute limit in SYSGEN), but now with the SYSGEN limit as high as 32767, if could have really 'worked'.

Volker.

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

Len Holt — Fri, 27 Jul 2007 16:21:39 GMT

Hello,

Well history repeats itself with a twist. I'm setting up a test cluster in a SAN environment.
I have a DS10 1GB of memory. I've cloned the system disk of an ES45. The DS10 and ES45 are both running VMS 7.3-2 Both have been recently patched up to V1200 and firmware on both is up to date. The DS10 has a local system disk that boots up just fine. This problem only occurs when trying to boot the cloned system disk. I set the bootdef_dev to point to the cloned system disk on the SAN.

When booting I get the same message described in this thread.

%EXECINIT-F-NOMEM, insufficient physical memory for minimum working set

I have booted with b -fl 0,1 and adjusted

balsectcnt = 8 min
wsmax = 64 min

Also I adjusted the scsnode name and the scssystemid during the conversational boot.

The goal is to make the test cluster appear on a smaller scale as the production cluster. I'm trying to get this one node to boot up to run autogen and continue with the real testing for the cluster.

I've taken undocumented steps when booted on the DS10 local system disk. I've copied the MODPARAMS.DAT and the AGEN$INCLUDE_PARAMS.DAT from the local system to the mounted clone of the system disk, shutdown and set a MIN boot getting the same results. I may have to resort to the old fashion way of image copying the system disk...(a few steps)

Am I really going at this all wrong? I've read a few other threads that describe upgrading systems by using the SAN copying the system disk and booting the new system, autogen, etc.

The difference in this whole scenario is this one DS10 whose local system disk was not set up similar to other nodes in the shop. I'm trying to bring it to standard(with minnimal work)for a standard test cluster.

Thanks for any help you can provide.

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

Hoff — Fri, 27 Jul 2007 23:31:23 GMT

Get the box booted on the FC SAN disk, and -- if you have to -- you can boot conversationally and USE DEFAULT to get parameters set and the system limping far enough to allow some access from the console terminal.

If I read what the sequence used here correctly, the value of balsectcnt was set to 8, and wsmax to 64. What is listed as minimal values aren't necessarily bootable values. SYSBOOT is very unforgiving, and SYSGEN/SYSMAN access is only slightly less unforgiving.

Making direct changes at SYSBOOT or SYSGEN/SYSMAN are approaches where I've gotten myself into this sort of predicament; it's best to use MODPARAMS.DAT and AUTOGEN to make parameter changes.

Clean the cruft out of the MODPARAMS.DAT -- anything that cannot be explicitly and currently justified. (My rule of thumb here: anything in MODPARAMS that doesn't also have a comment explaining what version, what product or component, and why the setting is needed goes "bye-bye"; gets deleted. Stuff added into the file gets these details as a comment.) While you are working in the file, any explicit parameter assignment statement that can be altered to a MIN_param, MAX_param or ADD_param construct should also be adjusted; locking a specific value might provide enough for some cases, but too little for other cases.

AUTOGEN and reboot.

Call us back with the results.

Stephen Hoffman
HoffmanLabs LLC

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

The Brit — Sat, 28 Jul 2007 07:12:19 GMT

Throughout this thread I see references to "WSMAX_MX". I am unfamiliar with this parameter.
It is obviously not from MODPARAMS.DAT, based on the OP.

Googling it only returns references in this thread.

I am curious, can anyone explain where the parameter comes from and where/how it is set (relating to this issue).

Dave

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

Hoff — Sat, 28 Jul 2007 08:54:53 GMT

Dave (the brit): the wsmax_max (or _mx) stuff was (is?) a dcl symbol used as part of calculations within autogen itself; the discussion is of localized version of the code to correct an error. iIt's not something within modparams.

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

Len Holt — Sun, 29 Jul 2007 20:01:36 GMT

Hello,

With the help of a colleague, we finally figured out what was happening. The ALPHAVMSSYS.PAR was the trick for getting the system to boot. I copied this over to the mounted system disk clone form the booted DS10 local system disk. In a conversational boot I kept noticing setting all the parameters would not change and continued getting the Insufficient memory message. Well you learn something new every day... I'm able to make the necessary changes on this "New" system disk and proceed on with testing. I know this is probably not the most recommended way of doing things, It does work and saves a few steps. I will have to make various changes to startup files, Autogen and get on with business. There are suprisingly few changes that need to be made. I appreciate all the insight on what steps to take. Thanks again for all the input.