Steve, Thanks, for the extensive answers. The picture is clear now.
Kees. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Steve > Sent: 18 August, 2017 15:35 > To: [email protected] > Subject: Re: SMFLIMxx sample? > > Hello, > > Kees, sorry for the delay in answering: > > >You say: "Note that SMFLIMxx REGIONBELOW/REGIONABOVE are *not* related > to the IEFUSI's "region size" parameter" > >Am I correct to state that SMFLIMxx REGIONBELOW/REGIONABOVE are equal > to IEFUSI setting a Regionsize=Regionlimit both below and above? > > sbj: As the function exists now, VSM sets the job step's limit and size > values using a myriad of fields passed into it: > - JCL Region= or REGIONX= values > - SMFLIMxx REGIONxxxxx values (which will override the above JCL REGION > values) > - IEFUSI RegionLimit and RegionSize values > - SMFLIMxx SYSRESVxxxxx values, which will essentially be used in place > of the IEFUSI REGIONLIMIT value. > > VSM will factor these values together and come up with a regionlimit and > a regionsize. > > Since there is no regionsize keyword, when SYSRESVxxxx is used, the > regionsize should match the regionlimit. > > If the JCL REGION or the SMFLIMxx REGIONxxxxx values are non-zero and > lower than the determined regionlimit, that means the user (or SMFLIMxx > coder) has a specific amount in mind and the regionsize will be set to > that amount. And as we know, if you request more region via JCL than is > available, an abend will result. IIRC, if SYSRESVxxxxx is not used and > IEFUSI doesn't set any values, VSM will add a default value to the > regionsize to set the regionlimit. > > This is why people are simply coding REGIONBELOW(NOLIMIT) > REGIONABOVE(NOLIMIT) to simply override whatever the user requested and > giving them REGION=0M. I'm not sure why they aren't using SYSRESVxxxxx > to protect private for system use, unless they still have their IEFUSI > in place. > > >IEFUSI doc explains the value of difference between regionsize and > regionlimit with regard to VL Getmains. Is this no important anymore, > because SMFLIMxx does not provide control of a different regionlimit > anymore? > SBJ: I won't say it's not important, just that it was not in the > function provided on day 1. And that the nuance about VL Getmains is > often missed. > > >Region=0M implies Memlimit=0M. Does the SMFLIMxx Memlimit parameter > overrule Memlimit=0M for Region=0M tasks? > sbj: REGION=0M implies Memlimit=0M, but only when coded on the JCL. > Using REGIONxxxxx(NOLIMIT) does not specifically alter the MEMLIMIT. The > SMFLIMxx memlimit parameter will overrule the MEMLIMIT coded and the > implied memlimit from region=0M. Since IEFUSI and SMFLIMxx have the > ability to set any MEMLIMIT, there is no reason to imply a memlimit. > > > > >If so, a filter on REGION= would be helpful or I need IEFUSI to ignore > SMFLIMxx for Region=0M steps. > sbj: Please open an RFE in DeveloperWorks. I think you'll get a lot of > votes for the idea. > > > >Does NOHONORIEFUSIREGION in SCHEDxx also apply to SMFLIMxx, i.o.w. is > SMFLIMxx also ignored like IEFUSI is? If so, will SCHEDxx docs be > updated? > sbj: NOHONORIEFUSIREGION does override SMFLIMxx. I'll make a note to > get the doc updated. > > Thanks, > Kees. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
