Re:

> Could someone point me to a source where I can get the "skinny" on the
> setting of NMHEAP?

> What are the gotchas in setting it too high? etc.

Wasting system resources, particularly if a process "goes wild" and
allocates all of its potential stack and/or heap, and then hangs.

Also, on older releases of MPE/iX, the first touch of a heap or a stack
allocated about 1/30th of the limit as secondary disk storage.
This meant that if you had a large limit (the default of 80 MB for the heap),
you could quickly eat up a disk drive with useless transient space.
That has been fixed for some time, however.

The downside to limiting the heap is that if the value chosen is too small,
you might have a problem ... as you saw:


> QUERY on our system has a MAX HEAP SIZE of 81,920,000

I suspect it doesn't.  In fact, despite several bug reports and
repeated reminders over the years, I suspect that the vast majority of
HP provided programs (including QUERY) still are linked without specifying
NMHEAP.  This means that they get the system default NMHEAP, which is
under your control (via SYSGEN MISC).

Here's how to tell:

   :linkedit
   LinkEd> listprog query.pub.sys

   PROGRAM        : QUERY.PUB.SYS
   XL LIST        :
   CAPABILITIES   : BA, IA, MR, PH
   NMHEAP SIZE    :
   NMSTACK SIZE   :
   ...

The lack of a value after "NMHEAP SIZE" means that it will get the system
default NMHEAP when run (unless overridden on the RUN command).

Similarly for NMSTACK.


> as do in-house programs. We had

Again, I suspect they don't have 80 MB NMheaps, but that they are *getting*
your system default nmheap of 80 MB.

Why does the distinction matter?  Because you might someday change your
default NMHEAP...then those programs will still get the default, which
may or may not be enough.

I originally submitted my bug report against @.PUB.SYS NMPRGs because I'd run
into a site that had set the default NMHEAP quite low ... so low that some
HP programs were aborting because they hadn't been linked with a
specific (and large enough) NMHEAP value.


> the offending program succeed with a run-time NMHEAP of 10,000,000. Now we
> want to alter the program file itself with a different NMHEAP, but are not

Great... use 10 MB.


> really comfortable using 10,000,000 (which was a number picked out of the
> air because it was double the out-of-the-box value for the program file
> itself).

Sounds like a good number for now.

In the older days, when the NMSTACK and NMHEAP had more of a negative affect
on tranisent disk space, some programmers/vendors took the time to think
about what NMSTACK/NMHEAP they needed, and linked their programs with that
info.  In the case of SUPRTOOL, apparently 5 MB was plenty for years ...
and should probably now be increased.

Hope this helps,

--
Stan Sieler
[log in to unmask]
www.allegro.com/sieler/wanted/index.html

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *