>The IEA705I message shows that NETMENU is failing on an unconditional GETMAIN >fixed request for 20K in LSQA (subpool 229) below the line in both the first >and second occurrence. > >The Private Area is maxed out at 10M. It should be no more than 2M. So it >looks like the Private Area is the culprit as Tom thought was more likely. If >so, I suppose LSQA had no room to grow. > >I guess it is time to look at the source code of NETMENU. It should not be >asking for so much below the line.
NO. It is time to look at the DUMP, as was suggested several times before. Everything else is pure speculation. Also, keep in mind that the culprit may very well be that storage *above* the line is exhausted. If 31bit storage (region) is not available anymore, then VSM will go below the line (if there is space there in the region). The end result is that you'll see a request failing *below* the line because storage *above* is exhausted. I have seen abend80A (indicating a storage below problem), but the problem was above the line. The *only* way to debug this is to look at a dump and look at the storage allocated (search SIS for 'abend878 debug' - gives a very old, very good info apar that tells exactly how to do it). Even if you have a generic abend878 action=nodump slip trap active, set another slip trap on 878 with an action other than nodump. It will override the generic slip trap. Barbara Nitz ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html