- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alph...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-31-2006 01:23 PM
тАО08-31-2006 01:23 PM
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.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-31-2006 02:01 PM
тАО08-31-2006 02:01 PM
Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha
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."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-31-2006 02:10 PM
тАО08-31-2006 02:10 PM
Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-31-2006 02:16 PM
тАО08-31-2006 02:16 PM
Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha
> 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-31-2006 02:23 PM
тАО08-31-2006 02:23 PM
Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-31-2006 02:49 PM
тАО08-31-2006 02:49 PM
Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-31-2006 04:49 PM
тАО08-31-2006 04:49 PM
Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha
regards Kalle
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-31-2006 05:04 PM
тАО08-31-2006 05:04 PM
Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-31-2006 06:14 PM
тАО08-31-2006 06:14 PM
Solutionthere 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-01-2006 01:45 AM
тАО09-01-2006 01:45 AM
Re: Boot failure after AUTOGEN in OpenVMS 8.3 Alpha
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)