Posted: Tue Apr 14, 2009 10:25 pm Post subject: Memory issues 24bit processing & region
So we are in the process of upgrading to a newer version of ZOS. Over many years change equaled cost and we are in the position of having may Cobol programs compiled with both 24 and 31 bit compile/link options. As ZOS grows it likes to have its below the line memory, and what I am told is the next ZOS upgrade it will want all memory below the line (not sure if true). Over the last year or so jobs run out of memory and abend, usualy due to the region parameter on the step. I figured out you can override at the job level and problem seems to vanish. In addition we do have prjects underway to go through the Cobol jobs and perform the required conversions to newer cobol, as well as change to 31 bit processing. This will be a long drawn out process. Recently a small change has caused even more jobs to fail. My question is, do we add the region=0m to the job card to all the batch production jobs, or will be causing a whole bunch of other problems by doing this? I haven't been able to a clear understanding from anyone, even know we are supported by IBM. I understand the support we have are guys and gals who were swallowed up by IBM. So I need a true tech who knows cause and effect in the current ZOS enviornment. Thanks!
Joined: 03 Dec 2002 Posts: 579 Topics: 1 Location: Iowa, USA
Posted: Wed Apr 15, 2009 8:50 am Post subject:
Bob,
It would help to know your default REGION or some old/new values you've coded to get steps to run. Usually the default is set via JES JOBCLASS initialization parameter or perhaps via system exits such as IEFUSI. Your REGION setting needs to allow sufficient amount below and above the line.
Typically each ZOS release moves more control blocks, etc. ABOVE the 16Meg line so that the REGION available to the user doesn't shrink. I am sure the next upgrade will not take all memory below the line.
However, the system code that gets loaded into your user REGION for program and file management has grown over time and can could be causing shortages. If your REGION values in JCL (or the default REGION assigned via JES) has remained the same over several releases it may need to be moderately increased.
Routinely coding REGION=0M can be dangerous if a program has a looping GETMAIN or tries to obtain all the remaining memory in the address space. The result can be no remaining memory to load needed system routines on your behalf and possibly system PAGE dataset problems. _________________ Regards,
Bill Dennis
Disclaimer: My comments on this foorum are my own and do not represent the opinions or suggestions of any other person or business entity.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum