Gil, >>My IEFUSI unconditionally overrides any region smaller than 32M to give the >>full region below. ... >??? And zero above? Sounds broken to me? Rationale? >What does "full region below" mean? >o Whatever is available there? >o Exactly 8MiB (or at least that)? >o Other (specify)?
I did not talk about what my USI does above the line, did I? Why do you jump to the conclusion that it is zero above? In my case, 'full region below' means whatever is available below the line. I was NOT allowed to reserve LSQA (though I might need to bring that back on the tablet - the reasons for not allowing reserved LQSA are as arcane as believing one gets the region one coded.) Actually, I do subtract the size of the PSA. I was just sick and tired of the 878-10 dumps (that are not suppressed via slip trap) for those that still code region=1M or region=4M (all TSO users- that's hardwired in the TSO RACF segment, unfortunately). As for above - it depends. STCs coding 0M get 0M, everyone else gets 1G above. Or whatever they specified in the region parm, as long as it was more than 32M. Specifying less than 32M gets them 32M. Subsystem OMVS gets whatever they want - I have a healthy respect for the warning in the books. Which is why they are able to take over a system, storage-wise. On the other hand, I don't need to worry about 878. If there is one, it is definitely the application. And my USI forbids the use of memlimit in JCL. Just about everyone can get a may of 500M above the bar, if that is allowed in SMFPRM. There are enough address spaces around that hardcode their memlimit to values that NO paging subsystem can ever satisfy in case of a runaway application - DUMPSRV, GRS and the SMSPDSE asids being the worst offenders. Come on, which paging subsys can handle the combined amount of 16383PB (dumpsrv) + 128PB (GRS) plus 1TB each (SMSPDSE/1)? Lizette, >S822 is not one of my more favorite abends to deal with. For me it is a >time consuming process of going through storage to find the fragmentation. Do a search on 'abend822 debug' in SIS. There is a very old information apar (II5something) around that tells you where to look. It is a matter of 2 minutes to find the piece of storage that fragmented the address space. It is a different matter altogether to find out who/what getmained it and why. Usually because the 822 abend hits a completely innocent job. >There has always been a confusion at my shop as to where to code REGION=. >My history says only code it on the JOBCARD never the step. Here they code >it in both places and I am never sure if that harms the whole process which >could lead to these types of issues. The recommendation has been for some time to code region only on the job card. For hysterical reasons, most shops have coded region per step, and are (understandably) reluctant to change. Whenever I touch production JCL, I make sure that region is removed everywhere but for the job card. Steve, >Would this be related to the reason for the PARMLIB(DIAGxx) member with >VSM CHECKREGIONLOSS needing to be specified? You might have that backwards. CHECKREGIONLOSS tests if the region at the end of the job is the same size as the region was when the job started. If region size has diminished, the system automatically restarts the init getting rid of the fragmentation. A message informs you about that. That takes care of the *next* job getting the 822. Plus it narrows down which job *caused* the fragmentation. Note I did not say that the job that just ran before the restart of the init is *necessarily* the culprit. It depends on how big you make the check parms for below and above. >If so, then I think IBM needs to take another look at their handling (or >mis-handling) of LSQA. No. This has always been this way. Besides, whenever I could identify an IBM product causing fragmentation, IBM took an apar. Vendors didn't and tried to talk their way out of it to cover up for bad design that leaves an address space fragmented. Not all vendors, and not all the time, but enough of them to annoy me. >Theoretically, you should be able to use REGION=68K (like the example >given in the JCL REF) and get it to work. Yes, well, but only assuming there isn't any IEALIMIT or IEFUSI coded or the default region set in the jes deck or or or.... >So, IEFBR14 has not increased in size but the addittional functionality within >allocation may well be the culprit. Not really. Just because an IEFBR14 step got the 822, that does not mean *that* step did anything. The culprit for an 822 is *always* one of the steps in the job *before* the abend (assuming there wasn't fragmentation when the job started - then it may have been a prior job). IEFBR14 or rather, the allocation code that goes with it, may only have been the culprit when one or more *prior* steps were also IEFBR14. Regards, Barbara ---------------------------------------------------------------------- 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
