Re: Region Size - Step or Jobcard
re: http://www.garlic.com/~lynn/2010m.html#16 Region Size - Step or Jobcard i.e. MVS was still mostly the same address space ... or every MVS virtual address space was mostly the same (some installations, 13mbytes threatening to become 14mbytes, of every 16mbyte virtual address space) ... in large part because of the engrained, pervasive pointer-passing API paradigm. -- virtualization experience starting Jan1968, online at home since Mar1970 -- 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
Re: Region Size - Step or Jobcard
In days of yore, long, long ago, and far, far, away, it made sense to code at the step level. OS/MVT used a contiguous storage algorithm and reserved that storage for the life of a job step.. If STEPB required more storage that STEPA, the possibility existed for significant execution delays until a contiguous block of real storage large enough for STEPB to execute became available. Great amounts of time and effort were spent determining actual real storage requirements and maintaining cascading region parameters to ensure that there was always enough contiguous real storage for the next job step. Potentially large amounts of real storage were wasted on small (real storage) steps executing before the large (real storage) step. All of the above went the way of the dodo when OS/MVS (specifically, virtual storage) became available. IMO, it no longer makes any sense to even worry about it. I do not believe any benefit (or not) would even be measureable. HTH, snip If there is a job with 200+ steps. Is it better to have region coded at the JOBCARD level or the STEP Level? /snip -- 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
Re: Region Size - Step or Jobcard
IMHO, whatever is, leave it. There would not be enough potential benefit to justify the risks and cost. My $0.02 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Wednesday, August 04, 2010 1:07 PM To: IBM-MAIN@bama.ua.edu Subject: Region Size - Step or Jobcard Someone asked me the question, and since we are having a good discussion, I thought I would throw this out to the collective wisdom here. If there is a job with 200+ steps. Is it better to have region coded at the JOBCARD level or the STEP Level? I have heard various thoughts on this over the years and I am hoping for some better clarification other than I think I remember that Lizette NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
Re: Region Size - Step or Jobcard
W dniu 2010-08-04 20:07, Lizette Koehler pisze: Someone asked me the question, and since we are having a good discussion, I thought I would throw this out to the collective wisdom here. If there is a job with 200+ steps. Is it better to have region coded at the JOBCARD level or the STEP Level? I have heard various thoughts on this over the years and I am hoping for some better clarification other than I think I remember that 1. I think, it really doesn't matter *in practice*. 2. Without knowledge of the job steps it's impossible to answer. Example: 199 steps with IEFBR14 and 1 with MYPROG. Or the opposite... -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- 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
Re: Region Size - Step or Jobcard
On Wed, 4 Aug 2010 13:24:02 -0500, Staller, Allan wrote: In days of yore, long, long ago, and far, far, away, it made sense to code at the step level. OS/MVT used a contiguous storage algorithm More precisely, MVT had a single address space and reserved that storage for the life of a job step.. If STEPB required more storage that STEPA, the possibility existed for significant execution delays until a contiguous block of real storage large enough for STEPB to execute became available. At the shop where I started in 1970, we did just the opposite. All regions were coded on the JOB card and there was a standard for what the region would be. IIRC, Class A always used 110K. This was to avoid storage fragmentation. Today it is much less important. I usually code region on the JOB statement, but that's a personal preference. I don't believe in changing existing JCL without a good reason. -- Tom Marchant -- 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
Re: Region Size - Step or Jobcard
On Wed, 4 Aug 2010 14:07:20 -0400, Lizette Koehler stars...@mindspring.com wrote: Someone asked me the question, and since we are having a good discussion, I thought I would throw this out to the collective wisdom here. If there is a job with 200+ steps. Is it better to have region coded at the JOBCARD level or the STEP Level? I have heard various thoughts on this over the years and I am hoping for some better clarification other than I think I remember that Lizette The less JCL coding, the better. And if you have system-exits that force such limits, coding a value may have no impact. Or if you have such small default-value defined for jobs, that could also have in impact -- for example, the minimum REGION required for a particular SAS conversion required a JCL change, however instead the JCL parameter was removed altogether. However, do consider that 'assigned JOB-level REGION, sets the max limit for any subordinate job-step, unless an exit gets involved. Scott Barry SBBWorks, Inc. -- 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
Re: Region Size - Step or Jobcard
For new JCL I always recommend just putting an ample region size on the job card and be done with it. But I would certainly not change running JCL for no reason. I always say if it ain't broke don't break it. C. Todd Burrell PMP, MCSE 2003:Security Security+, Network+ Lead z/OS Systems Programmer ITSO (404) 723-2017 (Cell) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Wednesday, August 04, 2010 2:07 PM To: IBM-MAIN@bama.ua.edu Subject: Region Size - Step or Jobcard Someone asked me the question, and since we are having a good discussion, I thought I would throw this out to the collective wisdom here. If there is a job with 200+ steps. Is it better to have region coded at the JOBCARD level or the STEP Level? I have heard various thoughts on this over the years and I am hoping for some better clarification other than I think I remember that Lizette -- 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 -- 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
Re: Region Size - Step or Jobcard
If you have a problem with the region size, add a REGION parameter to the jobcard that is equal to or larger than any step, and overrides all the steps. No need to remove the REGION from the steps or procs, and any changes to the values could result in typo abends. On Wed, Aug 4, 2010 at 2:43 PM, Burrell, C. Todd (CDC/OCOO/ITSO) (CTR) z...@cdc.gov wrote: For new JCL I always recommend just putting an ample region size on the job card and be done with it. But I would certainly not change running JCL for no reason. I always say if it ain't broke don't break it. C. Todd Burrell PMP, MCSE 2003:Security Security+, Network+ Lead z/OS Systems Programmer ITSO (404) 723-2017 (Cell) -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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
Re: Region Size - Step or Jobcard
m42tom-ibmm...@yahoo.com (Tom Marchant) writes: More precisely, MVT had a single address space aka VS2/SVS was minimally modified MVT in a single (16mbyte) virtual address space; biggest change was borrowing ccwtrans from cp67 for EXCP ... to take the application-passed channel program and make a copy of it ... substituting real addresses for virtual addresses. there was a specially modified MVT os/360 relase 13 done at boeing huntsville. MVT storage/memory management became heavily fragmented with long running jobs. boeing huntsville had a pair of 360/67s for long running cad/cam jobs with 2250 vector graphics under MVT OS/360 release 13. MVT release 13 was modified to use the 360/67 virtual memory hardware to reoganize storage/memory locations (compensating for enormous storage fragmentation). there was no paging going on ... just address translation. the os/360 single address space contributed heavily to pervasive pointer-passing paradigm (also efficiency in limited storage/memory environments). this caused all sorts of problems attempting to deploy MVS with multiple virtual address spaces. MVS kernel image was made half of each 16mbyte application virtual address space (to simplify pervasive use of pointer-passing APIs). The problem manifested itself when all the subsystems were also moved into their own separate address space ... now the pointer-passing API between applications and subsystems started to break down. The solution was the common segment ... a part of every virtual address space that could have dedicated areas for moving parameters into so as to not breack the pointer passing API paradigm. The problem was that the demand for common segment area grew as the size of systems and number of subsystems grew. Some large MVS shops were even facing the possibility of moving from 5mbyte common segment to 6mbyte common segment ... reducing maximum application area to 2mbytes. Burlington ... internal chip foundary and big internal MVS shop had an enormous problem ... with major fortran applications that were constantly threatening to exceed 7mbytes and lots of carefully crafted MVS systems that maintained the common segment at 1mbyte. Move off MVS to CMS would have eliminated a whole lot of effort that was constantly going into keeping their applications working in the MVS environment ... but that would have been an enormous blow to MVS prestige and image. -- virtualization experience starting Jan1968, online at home since Mar1970 -- 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
Re: Region Size - Step or Jobcard
For new JCL I always recommend just putting an ample region size on the job card and be done with it. But I would certainly not change running JCL for no reason. I always say if it ain't broke don't break it. I say implement an IEFUSI exit that isn't from the dark ages and not worry about (or ignore) what users code for (at least most) JCL. I shouldn't talk too much because I still haven't changed the default from 256M above. The below default is 7M and I'm sure 8M or even 9M wouldn't be a problem and would leave plenty of room for LSQA below the line (which I reserve 512K anyway). None of the LPARs I work with have less than 10M private below the line. Typically STCs code REGION=0M which I only allow (don't ignore) for STCs and that gives them everything they need anyway. BATCH that codes REGION=0M is penalized by getting the default, but I haven't found a batch job that ever needed more than 256M. If it did need more, I allow whatever is specified except for 0M (throw back to the old days - even the smallest LPAR I support has 1.5G real and a robust paging subsystem). Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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
Re: Region Size - Step or Jobcard
If there is a job with 200+ steps. Is it better to have region coded at the JOBCARD level or the STEP Level? Actually, while I still recommend using region at the job card level, in your particular case it will narrow the step that caused the fragmentation. Assuming you use checkregionloss and did NOT have a fragmented init when the job started. (Also assuming that the 822 is reproducible for *this* job.) I also strongly urge you to investigate the 822 *before* giving the job a region of 0M and removing individual region sizes. You might end up with abend878 -10 or -C or abend80A in steps after the IEFBR14 step. Unequivocally setting region=0M is covering up a problem that might hit you very hard when you can least afford it. 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
