The EXT value in the message for the "no region" shows a 32MB Limit was enforced, the REGION=0 execution shows no such limit.
Barry Merrilly yours, Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive technical questions: [email protected] Dallas, TX 75229 http://www.mxg.com admin questions: [email protected] tel: 214 351 1966 fax: 214 350 3694 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Farley, Peter x23353 Sent: Monday, July 24, 2017 3:58 PM To: [email protected] Subject: Re: REGION=0M leads to CPU through the roof Your installation may have an IEFUSI exit that turns REGION=0M into a much smaller value, perhaps even smaller than the default with no REGION specified at all. Less virtual storage allocated may lead to less I/O buffering and more I/O CPU time or even more LE storage use/free issues? Just guessing here. IMHO your best bet is to run the REGION=0M version with an application tuning product (Strobe, TriTune, etc., I think IBM even has one) and see where the actual CPU hot spots are. HTH Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Way, Richard Sent: Monday, July 24, 2017 4:19 PM To: [email protected] Subject: REGION=0M leads to CPU through the roof In the course of trying to duplicate a customer problem, I have run across unexpected behavior that I wonder if anyone can help to explain. I have an application program (COBOL 4.2, z/OS 2.2, AMODE 31, RENT) that exhibits the following: When run with our *default* REGION (i.e. no REGION= on the EXEC whatsoever): CPU: 0 HR 00 MIN 31.34 SEC SRB: 0 HR 00 MIN 00.06 SEC VIRT: 1056K SYS: 276K EXT: 32740K SYS: 13116K ATB- REAL: 8K SLOTS: 0K VIRT- ALLOC: 10M SHRD: 0M When run with an explicit REGION=0M: CPU: 0 HR 11 MIN 38.43 SEC SRB: 0 HR 00 MIN 00.07 SEC VIRT: 7856K SYS: 276K EXT: 1622548K SYS: 13116K ATB- REAL: 8K SLOTS: 0K VIRT- ALLOC: 10M SHRD: 0M You'll note the large increase in storage - which is of course not surprising - but more interesting (and unwelcome) to me is that the CPU time required increased by roughly a factor of 22X to do the exact same work. (The ONLY difference between the two runs is the addition of REGION=0M to the EXEC.) Can anyone suggest what I should be thinking about here in terms of possible causes? Is it possible that so much "overhead" is needed to manage the much larger memory space? Could it be something to do with LE tuning? Thanks, Richard Way -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
