JCL frequently is constructed in ignorance, endowed with inertia, or both. REGION=600K worked and perhaps had a purpose in 1978 but no longer, REGION=200M won't make your job run faster. We use IEFUSI, Thruput Manager, SMS, and DTS ACC/SRS to dynamically update or override as needed incorrect or inefficient specifications in JCL. The goal is generally to inform through messages if appropriate but to execute the work efficiently without interruption and resubmission unless a site standard has been violated we cannot automagically correct such as account code.
I consider that REGION= is mostly decoration at this point. My IEFUSI (not yet updated for storage above the bar reasonably large defaults are provided through SMFPRM00) makes REGION a binary switch. You either get my generous defaults or you code REGION=0M and we give you everything can less a buffer for recovery. REGION ABEND's are a waste of human resources to resolve and REGION won't protect me from most of the (authorized) animals that have every actually caused me problems overallocating real or virtual storage. Too frequently poor performance or ABENDs result from insufficient below the bar or below the line virtual storage. Why allow it? REGION is not there to protect you the systems programmer from real storage use or page data set use. The systems programmer needs to insure that a sufficiently robust paging configuration exists and that ample real storage and virtual storage are provided to run workloads efficiently. Bad JCL need not be honored fix it dynamically and get on with business. Do you really think the typical application programmer today understand virtual storage management or has time to revamp all the batch JCL they use personally or are responsible for in your job scheduler? I don't think so. What we do is not arbitrary. For the overall benefit to the business deep technical expertise and management of some resources is done by the system staff. Our application developers don't expect me to fix their COBOL programs and I don't expect them to correctly and carefully set just the "right" REGION= specification on every job step. It is better for the business that they focus on building or updating feature and function needed and if I can eliminate one small platform specific technical consideration. Here is an IEFUSI approach that made sense to me *********************************************************************** * * * Module Name = IEFUSI * * * * Descriptive Name = SMF Step Initiation Exit * * * * Function = * * Exit allows installation to control job step * * region size. * * * * PVT: * * We provide all tasks with the maximum available below the * * line less a safety allowance for RTM to prevent programs * * from using every last byte of storage and being terminated * * at END OF MEMORY (S0F9,S40D) by MVS if the MVS Recovery * * Termination Manager cannot obtain enough high private to * * do task level termination. * * * * EPVT: * * For REGION=0K users we provide the maximum above all others * * are given a very generous 1G EPVT allocation. * * * * * * The value of the increment used in this exit is the * * difference between the region limit and the region * * size (below the line) and is set to 512K, i.e. the * * region limit = the region size + 512K Above the * * line the same logic is applied only the cushion * * is set to 10M * * * Best Regards, Sam Knutson, GEICO System z Team Leader mailto:[email protected] (office) 301.986.3574 (cell) 301.996.1318 "Think big, act bold, start simple, grow fast..." -----Original Message----- On Wed, 29 Sep 2010 00:35:18 +0000, Ted MacNEIL <[email protected]> wrote: >>REGION is one of those things that should not be left to application JCL to manager properly. > >I disagree (strongly) with that statement! >Tech Support is there to help, not control! > >Yes. The config is a technical issue; the reason it's there is to support the business, ie, appdev. > >They know better than tech supp what is needed. > ==================== This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
