The private area size can be displayed by this TSO TEST command: L 224.%+30?+40 7FF16E50. 007FA000
The result, hex 007FA000, varies of course from system to system. This is the same field, LDASIZA, shown by the IPLINFO exec. I assembled variations of a 24-bit program with different sizes and attempted to run them, and the largest program that would load on this system and not get the S106-C abend had a size of 00726000 (hex), or about 848K less than the private area size of 007FA000. If I increased the program size by 4K, to 00727000, it got the S106-C abend. A below-the-line program having the size of 00752958 (hex), like the DFHEISUP program shown in an earlier post by John Chase, would definitely get the S106-C abend on the system I use. There would be no way around it except to find a way to increase the private area size. Bill On Thu, 20 Feb 2014 16:29:38 -0600, Shane Ginnane wrote: >Some find ploughing through dumps intimidating - a little "Diagnosis 101" >first might shed some light: > >- has this task run successfully previously ?. If so, what changed. (no, >"nothing" should not be accepted) >- what size *private* area is available (search for Mark Zelden IPLINFO exec) >- what's the size of the module (thanks John) >- what was the available storage ?. From here on you're going to need that >dump. > >Shane ... > >On Thu, 20 Feb 2014 10:19:17 -0800, Ed Jaffe wrote: > >>By inspecting the SVC dump, you should be able to see the failing >>STORAGE OBTAIN or GETMAIN in the system trace. That will give you >>length, subpool, etc. You should also be able to use VSMLIST to see >>where all of the storage went. > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
