Operating System - OpenVMS
1748261 Members
3607 Online
108760 Solutions
New Discussion юеВ

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

 
SOLVED
Go to solution
Edward Alekxandr
Occasional Advisor

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

Closed as per above.

Many thanks to all those that replied.
Volker Halle
Honored Contributor

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

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.
Len Holt
New Member

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

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.


Hoff
Honored Contributor

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

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
The Brit
Honored Contributor

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

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
Hoff
Honored Contributor

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

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.
Len Holt
New Member

Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha

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.