Re: Ancient IEFUSI
Elardus, The initial question was about the TIME= Parameter on the JOB card. I am trying to understand why you mentioned the REGION= parameter? And, if a site has a standard that TIME is not allowed on a JOB card, then the solution is to remove it and/or flag it and then remove it with a JCL management tool such as J-Man. This can be done for any JCL statement parameter, keyword, sub-parameter, value, positional character, entire statements, automatically. And, it can be done any time a JCL object is moved into production. Mitch -Original Message- From: Elardus Engelbrecht elardus.engelbre...@sita.co.za To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Mon, Dec 8, 2014 5:30 am Subject: Re: Ancient IEFUSI Mitch wrote: This is all fine a good, but why check when a job is submitted? Why not check efore and eliminate the problem (and potential delay in batch)? Simply - USI is used to check memory and enforce limits at every job step(s) espite stated REGION=value. IEFUSI exit routines receive control before the initiator checks to determine hether the job step will actually execute. You cannot enforce storage limits before job execution - Only WHILE the thing is unning. Groete / Greetings lardus Engelbrecht -- or IBM-MAIN subscribe / signoff / archive access instructions, end email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
On Tue, 9 Dec 2014 03:47:49 -0500, Mitch mitc...@aol.com wrote: The initial question was about the TIME= Parameter on the JOB card. I am trying to understand why you mentioned the REGION= parameter? Original post in this thread by Andrew Metcalfe contains this I am finally getting around to modifying our IEFUSI exit to do something sensible with MEMLIMIT as more tasks exploit 64-bit storage. So Andrew is talking about memory. Subsequent posts in this thread drifted to TIME= parameter. That can be managed BEFORE you submit your job as per your explanation. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
Well I, for one, am jolly glad people are examining their IEFUSI exits, particularly in the area of MEMLIMIT. It's something I've been advising for quite a while... Cheers, Martin From: Elardus Engelbrecht elardus.engelbre...@sita.co.za To: IBM-MAIN@LISTSERV.UA.EDU Date: 09/12/2014 11:15 Subject:Re: Ancient IEFUSI Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Tue, 9 Dec 2014 03:47:49 -0500, Mitch mitc...@aol.com wrote: The initial question was about the TIME= Parameter on the JOB card. I am trying to understand why you mentioned the REGION= parameter? Original post in this thread by Andrew Metcalfe contains this I am finally getting around to modifying our IEFUSI exit to do something sensible with MEMLIMIT as more tasks exploit 64-bit storage. So Andrew is talking about memory. Subsequent posts in this thread drifted to TIME= parameter. That can be managed BEFORE you submit your job as per your explanation. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
Folks Just to clarify what my requirement is to save any off-track debate The ancient IEFUSI exit in addition to policing region size, (rightly or wrongly) uses the undocumented R10 LCT pointer to thread through to the SCTX which identifies whether there is a TIME=parameter on the EXEC card for the STEP and sets a bit in the CEPUCOM which is later interrogated by IEFUTL. We want to allow users to specify TIME= on the EXEC card. If a job drives IEFUTL for exceeding the STEP CPU time, IEFUTL grants a CPU extension of 1 minute *unless* CEPUCOM indicates that the step has TIME= specified, in which case the job is terminated. Andrew This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority (Financial Services Register No. 122702). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
If a site wants to enforce a rule for TIME= or REGION= for all jobs, the only way is an exit. Production JCL usually is well controlled, individual users' JCL is not (at least not here). Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mitch Sent: 09 December, 2014 9:48 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ancient IEFUSI snip And, if a site has a standard that TIME is not allowed on a JOB card, then the solution is to remove it and/or flag it and then remove it with a JCL management tool such as J-Man. This can be done for any JCL statement parameter, keyword, sub-parameter, value, positional character, entire statements, automatically. And, it can be done any time a JCL object is moved into production. Mitch -Original Message- From: Elardus Engelbrecht elardus.engelbre...@sita.co.za To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Mon, Dec 8, 2014 5:30 am Subject: Re: Ancient IEFUSI Mitch wrote: This is all fine a good, but why check when a job is submitted? Why not check efore and eliminate the problem (and potential delay in batch)? Simply - USI is used to check memory and enforce limits at every job step(s) espite stated REGION=value. IEFUSI exit routines receive control before the initiator checks to determine hether the job step will actually execute. You cannot enforce storage limits before job execution - Only WHILE the thing is unning. Groete / Greetings lardus Engelbrecht -- or IBM-MAIN subscribe / signoff / archive access instructions, end email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
I believe that the JMR (mapped by IEFJMR) is available to JES2 exits - if so, you can use JES2 exit 6 to easily extract any TIME parameter specified in the JCL (using XINTKEY) and set your bit the user comm area for IEFUTL. Another alternative is to use IEFUJV to scan the JCL card images in the clear. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Metcalfe Sent: 09 December 2014 11:24 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ancient IEFUSI Folks Just to clarify what my requirement is to save any off-track debate The ancient IEFUSI exit in addition to policing region size, (rightly or wrongly) uses the undocumented R10 LCT pointer to thread through to the SCTX which identifies whether there is a TIME=parameter on the EXEC card for the STEP and sets a bit in the CEPUCOM which is later interrogated by IEFUTL. We want to allow users to specify TIME= on the EXEC card. If a job drives IEFUTL for exceeding the STEP CPU time, IEFUTL grants a CPU extension of 1 minute *unless* CEPUCOM indicates that the step has TIME= specified, in which case the job is terminated. Andrew This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority (Financial Services Register No. 122702). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Shane Ginnane Sent: Monday, December 08, 2014 6:54 PM On Mon, 8 Dec 2014 06:03:50 -0500, Mitch wrote: ... but why check when a job is submitted? Why not check before ... Wheww - tuff requirements. I've done some exits in my time, but none that get inside users head(s) - not real sure I want to go there. Does this mean you're giving up on the DWIM macro? :-) -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
Rob Scott wrote:
... and set your bit the user comm area for IEFUTL.
CEPAUCOM in CEPA ('common exit parameter area')?
Another alternative is to use IEFUJV to scan the JCL card images in the clear.
Good idea, and this is what I see in SYS1.SAMPLIB(SMFEXITS):
User communication field. Intended for communication between exits of a job.
Could that work (passing CEPAUCOM from one exit to other) for the OP?
Groete / Greetings
Elardus Engelbrecht
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
Why not get rid of most exits, and use a tool that does this function for you? Or is someone teach the new folks how to modify and maintain Assembler code after we all retire? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP (ITOPT1) - KLM Sent: Tuesday, December 9, 2014 3:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ancient IEFUSI If a site wants to enforce a rule for TIME= or REGION= for all jobs, the only way is an exit. Production JCL usually is well controlled, individual users' JCL is not (at least not here). Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mitch Sent: 09 December, 2014 9:48 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ancient IEFUSI snip And, if a site has a standard that TIME is not allowed on a JOB card, then the solution is to remove it and/or flag it and then remove it with a JCL management tool such as J-Man. This can be done for any JCL statement parameter, keyword, sub-parameter, value, positional character, entire statements, automatically. And, it can be done any time a JCL object is moved into production. Mitch -Original Message- From: Elardus Engelbrecht elardus.engelbre...@sita.co.za To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Mon, Dec 8, 2014 5:30 am Subject: Re: Ancient IEFUSI Mitch wrote: This is all fine a good, but why check when a job is submitted? Why not check efore and eliminate the problem (and potential delay in batch)? Simply - USI is used to check memory and enforce limits at every job step(s) espite stated REGION=value. IEFUSI exit routines receive control before the initiator checks to determine hether the job step will actually execute. You cannot enforce storage limits before job execution - Only WHILE the thing is unning. Groete / Greetings lardus Engelbrecht -- or IBM-MAIN subscribe / signoff / archive access instructions, end email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
Because tools cost money? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Norman.Hollander Sent: 10 December, 2014 2:20 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ancient IEFUSI Why not get rid of most exits, and use a tool that does this function for you? Or is someone teach the new folks how to modify and maintain Assembler code after we all retire? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP (ITOPT1) - KLM Sent: Tuesday, December 9, 2014 3:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ancient IEFUSI If a site wants to enforce a rule for TIME= or REGION= for all jobs, the only way is an exit. Production JCL usually is well controlled, individual users' JCL is not (at least not here). Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mitch Sent: 09 December, 2014 9:48 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ancient IEFUSI snip And, if a site has a standard that TIME is not allowed on a JOB card, then the solution is to remove it and/or flag it and then remove it with a JCL management tool such as J-Man. This can be done for any JCL statement parameter, keyword, sub-parameter, value, positional character, entire statements, automatically. And, it can be done any time a JCL object is moved into production. Mitch -Original Message- From: Elardus Engelbrecht elardus.engelbre...@sita.co.za To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Mon, Dec 8, 2014 5:30 am Subject: Re: Ancient IEFUSI Mitch wrote: This is all fine a good, but why check when a job is submitted? Why not check efore and eliminate the problem (and potential delay in batch)? Simply - USI is used to check memory and enforce limits at every job step(s) espite stated REGION=value. IEFUSI exit routines receive control before the initiator checks to determine hether the job step will actually execute. You cannot enforce storage limits before job execution - Only WHILE the thing is unning. Groete / Greetings lardus Engelbrecht -- or IBM-MAIN subscribe / signoff / archive access instructions, end email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu 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
Re: Ancient IEFUSI
In the past I have used JES2 exit 6 to fail jobs that specify the TIME keyword - there is a supplied and supported routine XINTKEY that you can $CALL to extract specific JCL parameters. Other methods include using JES2 exit 2/3 or IEFUJV to unconditionally strip any TIME keyword from JCL statements therefore allowing the jobclass defaults to be enforced. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Metcalfe Sent: 07 December 2014 15:07 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ancient IEFUSI One of the reasons our IEFUSI examines the SCTX is to determine whether the step time (SCTXSTL) differs from the JES2 JOBCLASS setting. If so the assertion is that the user has coded TIME= on the EXEC card. IEFUSI sets a bit in the CEPUCOM area which is interrogated by IEFUTL when deciding whether to grant CPU time extension. If the user coded TIME= on the EXEC card he gets the bullet rather than an extension. How might I best determine (in IEFUTL) whether the user coded TIME=, so that I can maintain the same behaviour. Thanks Andrew This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority (Financial Services Register No. 122702). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
Everyone: So, use a tool like J-Man from RES and it will eliminate any job like this from ever getting to production. No more JES exits, and, you can enforce EVERY standard AND naming convention for production from ever being a problem. Issue resolved! Mitch -Original Message- From: Rob Scott rsc...@rocketsoftware.com To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Mon, Dec 8, 2014 8:33 pm Subject: Re: Ancient IEFUSI In the past I have used JES2 exit 6 to fail jobs that specify the TIME keyword - there is a supplied and supported routine XINTKEY that you can $CALL to extract specific JCL parameters. Other methods include using JES2 exit 2/3 or IEFUJV to unconditionally strip any TIME keyword from JCL statements therefore allowing the jobclass defaults to be enforced. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Metcalfe Sent: 07 December 2014 15:07 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ancient IEFUSI One of the reasons our IEFUSI examines the SCTX is to determine whether the step time (SCTXSTL) differs from the JES2 JOBCLASS setting. If so the assertion is that the user has coded TIME= on the EXEC card. IEFUSI sets a bit in the CEPUCOM area which is interrogated by IEFUTL when deciding whether to grant CPU time extension. If the user coded TIME= on the EXEC card he gets the bullet rather than an extension. How might I best determine (in IEFUTL) whether the user coded TIME=, so that I can maintain the same behaviour. Thanks Andrew This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority (Financial Services Register No. 122702). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
At 09:32 + on 12/08/2014, Rob Scott wrote about Re: Ancient IEFUSI: In the past I have used JES2 exit 6 to fail jobs that specify the TIME keyword - there is a supplied and supported routine XINTKEY that you can $CALL to extract specific JCL parameters. Other methods include using JES2 exit 2/3 or IEFUJV to unconditionally strip any TIME keyword from JCL statements therefore allowing the jobclass defaults to be enforced. These methods show how to detect the use of a TIME parameter in the JCL. Based on the way that IEFUSI and IEFUTL are used (as described in the quote below) what you can do is set the CEPUCOM flag if you see a TIME Parm in IEFUJV. Since you can detect and remove TIME= there you can just detect it (leaving it there) and set the flag for later checking. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Metcalfe Sent: 07 December 2014 15:07 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ancient IEFUSI One of the reasons our IEFUSI examines the SCTX is to determine whether the step time (SCTXSTL) differs from the JES2 JOBCLASS setting. If so the assertion is that the user has coded TIME= on the EXEC card. IEFUSI sets a bit in the CEPUCOM area which is interrogated by IEFUTL when deciding whether to grant CPU time extension. If the user coded TIME= on the EXEC card he gets the bullet rather than an extension. How might I best determine (in IEFUTL) whether the user coded TIME=, so that I can maintain the same behaviour. Thanks Andrew -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
Gentlemen, This is all fine a good, but why check when a job is submitted? Why not check before and eliminate the problem (and potential delay in batch)? Mitch McCluhan, Modernization Analyst IBM GBS/AMS/BAM Consultant -Original Message- From: Robert A. Rosenberg hal9...@panix.com To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Mon, Dec 8, 2014 9:51 pm Subject: Re: Ancient IEFUSI At 09:32 + on 12/08/2014, Rob Scott wrote about Re: Ancient IEFUSI: In the past I have used JES2 exit 6 to fail jobs that specify the TIME keyword - there is a supplied and supported routine XINTKEY that you can $CALL to extract specific JCL parameters. Other methods include using JES2 exit 2/3 or IEFUJV to unconditionally strip any TIME keyword from JCL statements therefore allowing the jobclass defaults to be enforced. These methods show how to detect the use of a TIME parameter in the JCL. Based on the way that IEFUSI and IEFUTL are used (as described in the quote below) what you can do is set the CEPUCOM flag if you see a TIME Parm in IEFUJV. Since you can detect and remove TIME= there you can just detect it (leaving it there) and set the flag for later checking. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Metcalfe Sent: 07 December 2014 15:07 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ancient IEFUSI One of the reasons our IEFUSI examines the SCTX is to determine whether the step time (SCTXSTL) differs from the JES2 JOBCLASS setting. If so the assertion is that the user has coded TIME= on the EXEC card. IEFUSI sets a bit in the CEPUCOM area which is interrogated by IEFUTL when deciding whether to grant CPU time extension. If the user coded TIME= on the EXEC card he gets the bullet rather than an extension. How might I best determine (in IEFUTL) whether the user coded TIME=, so that I can maintain the same behaviour. Thanks Andrew -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
Mitch wrote: This is all fine a good, but why check when a job is submitted? Why not check before and eliminate the problem (and potential delay in batch)? Simply - USI is used to check memory and enforce limits at every job step(s) despite stated REGION=value. IEFUSI exit routines receive control before the initiator checks to determine whether the job step will actually execute. You cannot enforce storage limits before job execution - Only WHILE the thing is running. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
On Mon, 8 Dec 2014 06:03:50 -0500, Mitch wrote: ... but why check when a job is submitted? Why not check before ... Wheww - tuff requirements. I've done some exits in my time, but none that get inside users head(s) - not real sure I want to go there. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
One of the reasons our IEFUSI examines the SCTX is to determine whether the step time (SCTXSTL) differs from the JES2 JOBCLASS setting. If so the assertion is that the user has coded TIME= on the EXEC card. IEFUSI sets a bit in the CEPUCOM area which is interrogated by IEFUTL when deciding whether to grant CPU time extension. If the user coded TIME= on the EXEC card he gets the bullet rather than an extension. How might I best determine (in IEFUTL) whether the user coded TIME=, so that I can maintain the same behaviour. Thanks Andrew This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority (Financial Services Register No. 122702). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
To the best of my knowledge, whether rightly or wrongly, neither the LCT nor the SCTX has ever been considered a programming interface. GUPI and PSPI are no longer differentiated (although they're still valid and you'll see them in many macros); PI is the new term. DMTI has morphed into NOTPI. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
In ofdab2603e.ec1e6e90-on85257da6.0052641c-85257da6.0052c...@us.ibm.com, on 12/06/2014 at 10:03 AM, Peter Relson rel...@us.ibm.com said: To the best of my knowledge, whether rightly or wrongly, neither the LCT nor the SCTX has ever been considered a programming interface. That matches my recollection. However, some undocumented behaviors have been more stable than some documented features. I know of one features that was announced in V1R1.2 and taken away in V1R1.3 of MVS/SP, while R10-LCT has been (mostly) stable from the OS/360 days on. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
In 5763756791911978.wa.andrew.metcalfebarclays@listserv.ua.edu, on 12/05/2014 at 10:35 AM, Andrew Metcalfe andrew.metca...@barclays.com said: The first of these is the alarming comment: * ON ENTRY R10 POINTS TO THE LCT. While that could certainly change without notice, it's been stable[1] since OS/360 and you should catch any hypothetical changes during your regression testing. [1] But read Jim Mulder's meesage. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Ancient IEFUSI
Folks I am finally getting around to modifying our IEFUSI exit to do something sensible with MEMLIMIT as more tasks exploit 64-bit storage. This exit has lain untouched for many many years, although it still functions correctly for the things it is supposed to do with region size. However, now I come to look at it, it becomes my responsibility to fix any anomalies I find. The first of these is the alarming comment: * ON ENTRY R10 POINTS TO THE LCT. * SEE MICROFICHE OF IEFSMFIE AT CURRENT PTF LEVEL COS IT'S * POSSIBLE FOR THIS TO CHANGE The documentation for IEFUSI makes no reference to R10 pointing to the LCT, indeed it states that R2-R12 are not applicable. My investigations have determined that R10 does indeed point to the LCT, but how long this will remain the case is not for me to gamble on, so I have to find another way. The exit uses LCTSCTVA as input to SWAREQ to get to the SCTX via the SCT. It then takes a copy of the SCTX using IEFQMREQ and updates (in certain circumstances) the SCTXSTL value and re-writes the SCTX using IEFQMREQ. Given that I can’t rely on R10 pointing to the LCT, should I be using JSCSCTP from the JSCB to get the SCT SVA token for SWAREQ (even though it is not part of GUPI)? Any enlightenment appreciated! Thanks Andrew -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
Just a thought. Is there a sample of this exit in your sys1.sample dataset? It might have more current info. Lizette -Original Message- From: Andrew Metcalfe andrew.metca...@barclays.com Sent: Dec 5, 2014 9:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Ancient IEFUSI Folks I am finally getting around to modifying our IEFUSI exit to do something sensible with MEMLIMIT as more tasks exploit 64-bit storage. This exit has lain untouched for many many years, although it still functions correctly for the things it is supposed to do with region size. However, now I come to look at it, it becomes my responsibility to fix any anomalies I find. The first of these is the alarming comment: * ON ENTRY R10 POINTS TO THE LCT. * SEE MICROFICHE OF IEFSMFIE AT CURRENT PTF LEVEL COS IT'S * POSSIBLE FOR THIS TO CHANGE The documentation for IEFUSI makes no reference to R10 pointing to the LCT, indeed it states that R2-R12 are not applicable. My investigations have determined that R10 does indeed point to the LCT, but how long this will remain the case is not for me to gamble on, so I have to find another way. The exit uses LCTSCTVA as input to SWAREQ to get to the SCTX via the SCT. It then takes a copy of the SCTX using IEFQMREQ and updates (in certain circumstances) the SCTXSTL value and re-writes the SCTX using IEFQMREQ. Given that I can’t rely on R10 pointing to the LCT, should I be using JSCSCTP from the JSCB to get the SCT SVA token for SWAREQ (even though it is not part of GUPI)? Any enlightenment appreciated! Thanks Andrew -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
Andrew Normally IEFUSI is used to control or audit region related constraints rather that execution time. I would consider taking the logic used to determine when the existing IEFUSI changes SCTXSTL and put it into IEFUTL, which is logically the right place. You can also drop the calls to IEFQMREQ as IEFUTL provides a way to indicate via R15 and R1 if the exit is to extend or cancel a jobstep. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Metcalfe Sent: 05 December 2014 16:36 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Ancient IEFUSI Folks I am finally getting around to modifying our IEFUSI exit to do something sensible with MEMLIMIT as more tasks exploit 64-bit storage. This exit has lain untouched for many many years, although it still functions correctly for the things it is supposed to do with region size. However, now I come to look at it, it becomes my responsibility to fix any anomalies I find. The first of these is the alarming comment: * ON ENTRY R10 POINTS TO THE LCT. * SEE MICROFICHE OF IEFSMFIE AT CURRENT PTF LEVEL COS IT'S * POSSIBLE FOR THIS TO CHANGE The documentation for IEFUSI makes no reference to R10 pointing to the LCT, indeed it states that R2-R12 are not applicable. My investigations have determined that R10 does indeed point to the LCT, but how long this will remain the case is not for me to gamble on, so I have to find another way. The exit uses LCTSCTVA as input to SWAREQ to get to the SCTX via the SCT. It then takes a copy of the SCTX using IEFQMREQ and updates (in certain circumstances) the SCTXSTL value and re-writes the SCTX using IEFQMREQ. Given that I can’t rely on R10 pointing to the LCT, should I be using JSCSCTP from the JSCB to get the SCT SVA token for SWAREQ (even though it is not part of GUPI)? Any enlightenment appreciated! Thanks Andrew -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
Rob Setting the SCTX step time in IEFUSI has been used here historically to *prevent* IEFUTL being taken for certain categories of job/stc. I am trying to avoid my MEMLIMIT changes driving changes to the other SMF exits!! Thanks Andrew This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority (Financial Services Register No. 122702). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
Responding to the original post...I think that setting time limit(s) in IEFUSI is highly unorthodox. Having to depend on an undocumented--essentially coincidental--pointer to the LCT is begging for trouble. Two possible solutions. 1. Find a documented, independent way to reach the LCT. I poked around a bit found some possible paths starting from TCBOLD. Detailed solution left to the Andrew. ;-) 2. Bite the bullet and move all time-limit code to IEFUTL where it belongs. That means changing two exits rather than one, but the result should be more comprehensible and long-term maintainable. Fortunately a crisis is only looming, not impending. Fix this now before disaster comes tapping on the window. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Metcalfe Sent: Friday, December 05, 2014 8:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Ancient IEFUSI Folks I am finally getting around to modifying our IEFUSI exit to do something sensible with MEMLIMIT as more tasks exploit 64-bit storage. This exit has lain untouched for many many years, although it still functions correctly for the things it is supposed to do with region size. However, now I come to look at it, it becomes my responsibility to fix any anomalies I find. The first of these is the alarming comment: * ON ENTRY R10 POINTS TO THE LCT. * SEE MICROFICHE OF IEFSMFIE AT CURRENT PTF LEVEL COS IT'S * POSSIBLE FOR THIS TO CHANGE The documentation for IEFUSI makes no reference to R10 pointing to the LCT, indeed it states that R2-R12 are not applicable. My investigations have determined that R10 does indeed point to the LCT, but how long this will remain the case is not for me to gamble on, so I have to find another way. The exit uses LCTSCTVA as input to SWAREQ to get to the SCTX via the SCT. It then takes a copy of the SCTX using IEFQMREQ and updates (in certain circumstances) the SCTXSTL value and re-writes the SCTX using IEFQMREQ. Given that I can’t rely on R10 pointing to the LCT, should I be using JSCSCTP from the JSCB to get the SCT SVA token for SWAREQ (even though it is not part of GUPI)? Any enlightenment appreciated! Thanks Andrew -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
I am finally getting around to modifying our IEFUSI exit to do something sensible with MEMLIMIT as more tasks exploit 64-bit storage. This exit has lain untouched for many many years, although it still functions correctly for the things it is supposed to do with region size. However, now I come to look at it, it becomes my responsibility to fix any anomalies I find. The first of these is the alarming comment: * ON ENTRY R10 POINTS TO THE LCT. * SEE MICROFICHE OF IEFSMFIE AT CURRENT PTF LEVEL COS IT'S * POSSIBLE FOR THIS TO CHANGE The documentation for IEFUSI makes no reference to R10 pointing to the LCT, indeed it states that R2-R12 are not applicable. My investigations have determined that R10 does indeed point to the LCT, but how long this will remain the case is not for me to gamble on, so I have to find another way. The exit uses LCTSCTVA as input to SWAREQ to get to the SCTX via the SCT. It then takes a copy of the SCTX using IEFQMREQ and updates (in certain circumstances) the SCTXSTL value and re-writes the SCTX using IEFQMREQ. Given that I can?t rely on R10 pointing to the LCT, should I be using JSCSCTP from the JSCB to get the SCT SVA token for SWAREQ (even though it is not part of GUPI)? I remember what happened in 1991 in SP4.2.0 when a code change and recompile of IEFSMFIE resulted in R10 no longer containing the address of the LCT when IEFUSE was invoked. But, rather than rely on my memory, I dug up the problem record in the old development PTM database. (PTM was Program Trouble Memorandum, for those who enjoy obscure IBM acronyms.) quote EXTERNAL DESCRIPTION TEXT: PH32142 * Top of Data ** External users of SMF exits IEFUSI and IEFUJI require access to the Scheduler Linkage Control Table (LCT). This access has been through the UNDOCUMENTED dependency that Reg 10 Point to the LCT upon entry to these exits. These users include the system test tool JMON, some tools used by Santa Teresa Lab (similar to or actual copies of JMON), and the OP/CA Product (AND IF OP/CA uses this pointer then OTHER products do too which means that this pointer MUST be documented). ...(Skip's notes)... Opening this problem per conversation w/Bill R. 4.2.0 eio accounts South Road Lab and Santa Teresa Lab are currently experiencing (or have experienced) problems in these exits. Bill has agreed to make the necessary changes to change these exits back the way they used to be regarding register contents. Documentation for the exits will also be changed. Need usermod for this to support drivers 19 and 20 for eio's. PTM SOLUTION ENTRY: PH32142 Enter up to 50 lines of Solution only. Press END key (PF3) to save Solution or CANCEL to return to previous * Top of Data *** The module that invokes both these exits (IEFSMFIE) included changes in DCR 163 that required that module to get access to Register 10 for 'other' reasons (besides addressing the LCT). It was later determined that EXTERNAL users of these exits are dependent upon the address of the Scheduler LCT being in Reg 10 upon entry (even though this is NOT documented as a part of the interface to these exits). SO, the module was changed to set Reg 10 to the address of the LCT prior to invoking the exits (copying the value from a local variable) AND arrangements are being made to update the interface documentation in the User Exits books to include this information. end quote So that's what happened, although it looks like the documentation either didn't happen, or subsequently got lost. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ancient IEFUSI
On 5 December 2014 at 16:34, Jim Mulder d10j...@us.ibm.com wrote: I remember what happened in 1991 in SP4.2.0 when a code change and recompile of IEFSMFIE resulted in R10 no longer containing the address of the LCT when IEFUSE was invoked. [...] SO, the module was changed to set Reg 10 to the address of the LCT prior to invoking the exits (copying the value from a local variable) AND arrangements are being made to update the interface documentation in the User Exits books to include this information. end quote So that's what happened, although it looks like the documentation either didn't happen, or subsequently got lost. I observe that in 2011 (not sure what release that would be), the external classification of the LCT itself was changed from DMTI to NOTPI. The comment says 8 char jobclass Feature ME22289, which seems hard to relate to a classification change. Was the change announced or documented? The DMTI itself was put in only as part of SHOWHDR Compliance in 1993, i.e. after the reversal you describe. I don't even remember what DMTI is or was; there used to be GUPI and PSPI (General Use- and Product Sensitive- Programming Interface, respectively), then simplified to just PI or NOTPI. Was DMTI just an older way of saying NOTPI? It seems not, since all the above strings still occur in a current MACLIB. Are these classifications documented somewhere? Regardless, it seems that any non-IBM use of any LCT fields may be suspect. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
