Re: ALERSERV delete from stimerm exit
the extended addressability guide and it shows a DU-AL only for SRB and TCB, not for individual RBs. I don't know what to clarify. A work unit (Task or SRB), AKA dispatchable unit, has an access list (that is the DU-AL). That is an architectural construct. When an IRB is given control the system switches the DU-AL to an empty one. The work unit still has a DU-AL. So, yes, due to IRBs the work unit could be thought of as having multiple access lists, only one of which is active at a time. In the Auth Assembler guide, it is stated that IRBs (created by CIRB) get control with an empty DU-AL : “Upon entry, the exit routine runs with an empty dispatchable unit access list (DU-AL). To establish addressability to a data space created by the mainline routine, the exit routine can use the ALESERV macro with the ADD parameter, and specify the STOKEN of the data space.” All fully true. ALESERV AL=WORKUNIT does not allow the ALET to be used for an IRB under the same TCB. Thus WORKUNIT means something else. I view that conclusion as incorrect. Workunit means workunit, the task. Within the processing for that work unit, there are restrictions/exceptions. Having restrictions/exceptions should not be much of a surprise. 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: ALERSERV delete from stimerm exit
On Mon, 12 Oct 2020 07:53:28 -0400 Peter Relson wrote: :>A "workunit" (AKA "dispatchable unit") to z/OS is a task or SRB. :>Therefore a workunit is created when a task is created (ATTACH/ATTACHX) or :>an SRB is scheduled (SCHEDULE, IEAMSCHD). ALESERV AL=WORKUNIT does not allow the ALET to be used for an IRB under the same TCB. Thus WORKUNIT means something else. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ALERSERV delete from stimerm exit
Then what's special about a timer exit or an IRB in general? And why does MVS Programming: Authorized Assembler Services Guide say "Upon entry, the exit routine runs with an empty dispatchable unit access list (DU-AL). " -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Monday, October 12, 2020 7:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ALERSERV delete from stimerm exit A "workunit" (AKA "dispatchable unit") to z/OS is a task or SRB. Therefore a workunit is created when a task is created (ATTACH/ATTACHX) or an SRB is scheduled (SCHEDULE, IEAMSCHD). 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ALERSERV delete from stimerm exit
A "workunit" (AKA "dispatchable unit") to z/OS is a task or SRB. Therefore a workunit is created when a task is created (ATTACH/ATTACHX) or an SRB is scheduled (SCHEDULE, IEAMSCHD). 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: ALERSERV delete from stimerm exit
Thanks: it's RCF time. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Rob Scott Sent: Monday, October 12, 2020 4:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ALERSERV delete from stimerm exit In the Auth Assembler guide, it is stated that IRBs (created by CIRB) get control with an empty DU-AL : “Upon entry, the exit routine runs with an empty dispatchable unit access list (DU-AL). To establish addressability to a data space created by the mainline routine, the exit routine can use the ALESERV macro with the ADD parameter, and specify the STOKEN of the data space.” Rob Scott Rocket Software From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 12 October 2020 09:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ALERSERV delete from stimerm exit EXTERNAL EMAIL I was relying on what Peter Relson wrote, but I checked the extended addressability guide and it shows a DU-AL only for SRB and TCB, not for individual RBs. Peter, if you see this, please clarify. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3<http://mason.gmu.edu/~smetz3> From: IBM Mainframe Discussion List mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of Joseph Reichman mailto:reichman...@gmail.com>> Sent: Sunday, October 11, 2020 9:03 PM To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: ALERSERV delete from stimerm exit Seymour mentioned it was the same TCB But different RB or more specifically IRB > On Oct 11, 2020, at 2:19 PM, Binyamin Dissen > mailto:bdis...@dissensoftware.com>> wrote: > > On Fri, 9 Oct 2020 09:08:54 -0400 Peter Relson > mailto:rel...@us.ibm.com>> wrote: > > :>>if there is any restriction on deleting an ALET entry > :>>(ALESERV DELETE) from a STIMERM exit > > :>It is not a "restriction", it is a "does not make sense" situation. It > :>goes well beyond "delete". > > :>IRBs (STIMERM exits being one such) do not get control with the access > :>list that their "mainline" (the STIMERM issuing code) had. > :>You cannot use an ALET not on your access list. You cannot delete an ALET > :>not on your access list. > > :>If you had tried to reference storage using that ALET while within the > :>STIMERM exit you would have gotten a program interrupt. > > Peter, > > I have looked in various manuals and did not find a clear definition of when a > new "workunit" is created. My assumption from this thread was that an IRB > created one, but I wonder if there are other occasions. It would not have been > obvious to me that an IRB would not inherit the workunit of the TCB. > > -- > Binyamin Dissen > mailto:bdis...@dissensoftware.com>> > http://secure-web.cisco.com/1R5JinyI_89BoT3Z3QmyLNfl5N7ghUXmHkjRjp1fOIq_6W-TFxTlM6rYjDVJ5IIZqFwBH0yS6IaSavG-griK1FdoRqymg1wVAYg_GWsuK_SDER9TAsHbj2ORIYbH9B3mhhoi_6pc-XQxwf8yvCwihk7ih_aML22HZWzNSaO1P4eV_xWz7bbzpq97WU1NcuzKQqa2IW7d_LZIo3DUVmpiyT-C7cfwxKrartZc2lthjBCp-eVLg6f3u0eKz8gakmIgZ-lXtkNzuGXtUyCv2KOxDyPzElWR1UIkBH02zBtZuL7pGFGB8oq4mUz1Y3RiuZMjkxNZuInVYHENxpwx2_hKhUwAL2VY6F771uVZb9ojJIqdAzbRPJjNU9YZPDuhm6G2u0B42tdVZWG9yu3TvoGUcCJ7Hp3u2vz72qQMipbdIYkZPX_QGZuyYkiPXzdhcHEVt/http://www.dissensoftware.com<http://secure-web.cisco.com/1R5JinyI_89BoT3Z3QmyLNfl5N7ghUXmHkjRjp1fOIq_6W-TFxTlM6rYjDVJ5IIZqFwBH0yS6IaSavG-griK1FdoRqymg1wVAYg_GWsuK_SDER9TAsHbj2ORIYbH9B3mhhoi_6pc-XQxwf8yvCwihk7ih_aML22HZWzNSaO1P4eV_xWz7bbzpq97WU1NcuzKQqa2IW7d_LZIo3DUVmpiyT-C7cfwxKrartZc2lthjBCp-eVLg6f3u0eKz8gakmIgZ-lXtkNzuGXtUyCv2KOxDyPzElWR1UIkBH02zBtZuL7pGFGB8oq4mUz1Y3RiuZMjkxNZuInVYHENxpwx2_hKhUwAL2VY6F771uVZb9ojJIqdAzbRPJjNU9YZPDuhm6G2u0B42tdVZWG9yu3TvoGUcCJ7Hp3u2vz72qQMipbdIYkZPX_QGZuyYkiPXzdhcHEVt/http://www.dissensoftware.com> > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu<mailto: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<mailto:lists...@listserv.ua.edu> with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructi
Re: ALERSERV delete from stimerm exit
In the Auth Assembler guide, it is stated that IRBs (created by CIRB) get control with an empty DU-AL : “Upon entry, the exit routine runs with an empty dispatchable unit access list (DU-AL). To establish addressability to a data space created by the mainline routine, the exit routine can use the ALESERV macro with the ADD parameter, and specify the STOKEN of the data space.” Rob Scott Rocket Software From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 12 October 2020 09:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ALERSERV delete from stimerm exit EXTERNAL EMAIL I was relying on what Peter Relson wrote, but I checked the extended addressability guide and it shows a DU-AL only for SRB and TCB, not for individual RBs. Peter, if you see this, please clarify. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3<http://mason.gmu.edu/~smetz3> From: IBM Mainframe Discussion List mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of Joseph Reichman mailto:reichman...@gmail.com>> Sent: Sunday, October 11, 2020 9:03 PM To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: ALERSERV delete from stimerm exit Seymour mentioned it was the same TCB But different RB or more specifically IRB > On Oct 11, 2020, at 2:19 PM, Binyamin Dissen > mailto:bdis...@dissensoftware.com>> wrote: > > On Fri, 9 Oct 2020 09:08:54 -0400 Peter Relson > mailto:rel...@us.ibm.com>> wrote: > > :>>if there is any restriction on deleting an ALET entry > :>>(ALESERV DELETE) from a STIMERM exit > > :>It is not a "restriction", it is a "does not make sense" situation. It > :>goes well beyond "delete". > > :>IRBs (STIMERM exits being one such) do not get control with the access > :>list that their "mainline" (the STIMERM issuing code) had. > :>You cannot use an ALET not on your access list. You cannot delete an ALET > :>not on your access list. > > :>If you had tried to reference storage using that ALET while within the > :>STIMERM exit you would have gotten a program interrupt. > > Peter, > > I have looked in various manuals and did not find a clear definition of when a > new "workunit" is created. My assumption from this thread was that an IRB > created one, but I wonder if there are other occasions. It would not have been > obvious to me that an IRB would not inherit the workunit of the TCB. > > -- > Binyamin Dissen > mailto:bdis...@dissensoftware.com>> > http://secure-web.cisco.com/1R5JinyI_89BoT3Z3QmyLNfl5N7ghUXmHkjRjp1fOIq_6W-TFxTlM6rYjDVJ5IIZqFwBH0yS6IaSavG-griK1FdoRqymg1wVAYg_GWsuK_SDER9TAsHbj2ORIYbH9B3mhhoi_6pc-XQxwf8yvCwihk7ih_aML22HZWzNSaO1P4eV_xWz7bbzpq97WU1NcuzKQqa2IW7d_LZIo3DUVmpiyT-C7cfwxKrartZc2lthjBCp-eVLg6f3u0eKz8gakmIgZ-lXtkNzuGXtUyCv2KOxDyPzElWR1UIkBH02zBtZuL7pGFGB8oq4mUz1Y3RiuZMjkxNZuInVYHENxpwx2_hKhUwAL2VY6F771uVZb9ojJIqdAzbRPJjNU9YZPDuhm6G2u0B42tdVZWG9yu3TvoGUcCJ7Hp3u2vz72qQMipbdIYkZPX_QGZuyYkiPXzdhcHEVt/http://www.dissensoftware.com<http://secure-web.cisco.com/1R5JinyI_89BoT3Z3QmyLNfl5N7ghUXmHkjRjp1fOIq_6W-TFxTlM6rYjDVJ5IIZqFwBH0yS6IaSavG-griK1FdoRqymg1wVAYg_GWsuK_SDER9TAsHbj2ORIYbH9B3mhhoi_6pc-XQxwf8yvCwihk7ih_aML22HZWzNSaO1P4eV_xWz7bbzpq97WU1NcuzKQqa2IW7d_LZIo3DUVmpiyT-C7cfwxKrartZc2lthjBCp-eVLg6f3u0eKz8gakmIgZ-lXtkNzuGXtUyCv2KOxDyPzElWR1UIkBH02zBtZuL7pGFGB8oq4mUz1Y3RiuZMjkxNZuInVYHENxpwx2_hKhUwAL2VY6F771uVZb9ojJIqdAzbRPJjNU9YZPDuhm6G2u0B42tdVZWG9yu3TvoGUcCJ7Hp3u2vz72qQMipbdIYkZPX_QGZuyYkiPXzdhcHEVt/http://www.dissensoftware.com> > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu<mailto: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<mailto: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<mailto:lists...@listserv.ua.edu> with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact
Re: ALERSERV delete from stimerm exit
I was relying on what Peter Relson wrote, but I checked the extended addressability guide and it shows a DU-AL only for SRB and TCB, not for individual RBs. Peter, if you see this, please clarify. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Joseph Reichman Sent: Sunday, October 11, 2020 9:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ALERSERV delete from stimerm exit Seymour mentioned it was the same TCB But different RB or more specifically IRB > On Oct 11, 2020, at 2:19 PM, Binyamin Dissen > wrote: > > On Fri, 9 Oct 2020 09:08:54 -0400 Peter Relson wrote: > > :>>if there is any restriction on deleting an ALET entry > :>>(ALESERV DELETE) from a STIMERM exit > > :>It is not a "restriction", it is a "does not make sense" situation. It > :>goes well beyond "delete". > > :>IRBs (STIMERM exits being one such) do not get control with the access > :>list that their "mainline" (the STIMERM issuing code) had. > :>You cannot use an ALET not on your access list. You cannot delete an ALET > :>not on your access list. > > :>If you had tried to reference storage using that ALET while within the > :>STIMERM exit you would have gotten a program interrupt. > > Peter, > > I have looked in various manuals and did not find a clear definition of when a > new "workunit" is created. My assumption from this thread was that an IRB > created one, but I wonder if there are other occasions. It would not have been > obvious to me that an IRB would not inherit the workunit of the TCB. > > -- > Binyamin Dissen > http://secure-web.cisco.com/1R5JinyI_89BoT3Z3QmyLNfl5N7ghUXmHkjRjp1fOIq_6W-TFxTlM6rYjDVJ5IIZqFwBH0yS6IaSavG-griK1FdoRqymg1wVAYg_GWsuK_SDER9TAsHbj2ORIYbH9B3mhhoi_6pc-XQxwf8yvCwihk7ih_aML22HZWzNSaO1P4eV_xWz7bbzpq97WU1NcuzKQqa2IW7d_LZIo3DUVmpiyT-C7cfwxKrartZc2lthjBCp-eVLg6f3u0eKz8gakmIgZ-lXtkNzuGXtUyCv2KOxDyPzElWR1UIkBH02zBtZuL7pGFGB8oq4mUz1Y3RiuZMjkxNZuInVYHENxpwx2_hKhUwAL2VY6F771uVZb9ojJIqdAzbRPJjNU9YZPDuhm6G2u0B42tdVZWG9yu3TvoGUcCJ7Hp3u2vz72qQMipbdIYkZPX_QGZuyYkiPXzdhcHEVt/http%3A%2F%2Fwww.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > > -- > 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 IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ALERSERV delete from stimerm exit
Seymour mentioned it was the same TCB But different RB or more specifically IRB > On Oct 11, 2020, at 2:19 PM, Binyamin Dissen > wrote: > > On Fri, 9 Oct 2020 09:08:54 -0400 Peter Relson wrote: > > :>>if there is any restriction on deleting an ALET entry > :>>(ALESERV DELETE) from a STIMERM exit > > :>It is not a "restriction", it is a "does not make sense" situation. It > :>goes well beyond "delete". > > :>IRBs (STIMERM exits being one such) do not get control with the access > :>list that their "mainline" (the STIMERM issuing code) had. > :>You cannot use an ALET not on your access list. You cannot delete an ALET > :>not on your access list. > > :>If you had tried to reference storage using that ALET while within the > :>STIMERM exit you would have gotten a program interrupt. > > Peter, > > I have looked in various manuals and did not find a clear definition of when a > new "workunit" is created. My assumption from this thread was that an IRB > created one, but I wonder if there are other occasions. It would not have been > obvious to me that an IRB would not inherit the workunit of the TCB. > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > > -- > 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: ALERSERV delete from stimerm exit
On Fri, 9 Oct 2020 09:08:54 -0400 Peter Relson wrote: :>>if there is any restriction on deleting an ALET entry :>>(ALESERV DELETE) from a STIMERM exit :>It is not a "restriction", it is a "does not make sense" situation. It :>goes well beyond "delete". :>IRBs (STIMERM exits being one such) do not get control with the access :>list that their "mainline" (the STIMERM issuing code) had. :>You cannot use an ALET not on your access list. You cannot delete an ALET :>not on your access list. :>If you had tried to reference storage using that ALET while within the :>STIMERM exit you would have gotten a program interrupt. Peter, I have looked in various manuals and did not find a clear definition of when a new "workunit" is created. My assumption from this thread was that an IRB created one, but I wonder if there are other occasions. It would not have been obvious to me that an IRB would not inherit the workunit of the TCB. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ALERSERV delete from stimerm exit
The timer exit runs in the same TCB; it's the RB that is different. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Rob Scott Sent: Friday, October 9, 2020 4:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ALERSERV delete from stimerm exit If the ALET is not invalid, the most likely reason is that the TCB of the DELETE does not match the TCB of the ADD. You have two options : (1) Change the ALESERV ADD/DELETE to use AL=PASN (2) Do not attempt to ALESERV from the STIMERM exit and indicate (maybe via rc/rsn or a request added to a queue) that the TCB that performed the ALESERV ADD should perform the DELETE. I would suggest (2), but also if this is new code perhaps use memory objects instead of dataspaces? Personally I like to keep timer exits (and recovery/retry routines) as simple as possible and to abdicate complex logic responsibility back to the establishing routine. Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: 09 October 2020 03:37 To: IBM-MAIN@LISTSERV.UA.EDU Subject: ALERSERV delete from stimerm exit EXTERNAL EMAIL Hi Would any one know if there is any restriction on deleting an ALET entry (ALESERV DELETE) from a STIMERM exit I am getting a RC X'14' in R15 I ran the program under test and it's the same ALET I ALERSERV ADD AL=WORKUNIT thanks -- 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 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences 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: ALERSERV delete from stimerm exit
Thanks I’ll do it in the mainline > On Oct 9, 2020, at 9:09 AM, Peter Relson wrote: > > >> >> if there is any restriction on deleting an ALET entry >> (ALESERV DELETE) from a STIMERM exit > > It is not a "restriction", it is a "does not make sense" situation. It > goes well beyond "delete". > > IRBs (STIMERM exits being one such) do not get control with the access > list that their "mainline" (the STIMERM issuing code) had. > You cannot use an ALET not on your access list. You cannot delete an ALET > not on your access list. > > If you had tried to reference storage using that ALET while within the > STIMERM exit you would have gotten a program interrupt. > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ALERSERV delete from stimerm exit
>if there is any restriction on deleting an ALET entry >(ALESERV DELETE) from a STIMERM exit It is not a "restriction", it is a "does not make sense" situation. It goes well beyond "delete". IRBs (STIMERM exits being one such) do not get control with the access list that their "mainline" (the STIMERM issuing code) had. You cannot use an ALET not on your access list. You cannot delete an ALET not on your access list. If you had tried to reference storage using that ALET while within the STIMERM exit you would have gotten a program interrupt. 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: ALERSERV delete from stimerm exit
Thanks > On Oct 9, 2020, at 4:27 AM, Rob Scott wrote: > > If the ALET is not invalid, the most likely reason is that the TCB of the > DELETE does not match the TCB of the ADD. > > You have two options : > > (1) Change the ALESERV ADD/DELETE to use AL=PASN > (2) Do not attempt to ALESERV from the STIMERM exit and indicate (maybe via > rc/rsn or a request added to a queue) that the TCB that performed the ALESERV > ADD should perform the DELETE. > > I would suggest (2), but also if this is new code perhaps use memory objects > instead of dataspaces? > > Personally I like to keep timer exits (and recovery/retry routines) as simple > as possible and to abdicate complex logic responsibility back to the > establishing routine. > > > Rob Scott > Rocket Software > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Joseph Reichman > Sent: 09 October 2020 03:37 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: ALERSERV delete from stimerm exit > > EXTERNAL EMAIL > > > > > > Hi > > > > Would any one know if there is any restriction on deleting an ALET entry > (ALESERV DELETE) from a STIMERM exit I am getting a RC X'14' in R15 > > > > I ran the program under test and it's the same ALET I ALERSERV ADD AL=WORKUNIT > > > > thanks > > > > > -- > 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 ■ > Main Office Toll Free Number: +1 855.577.4323 > Contact Customer Support: > https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport > Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - > http://www.rocketsoftware.com/manage-your-email-preferences > 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: ALERSERV delete from stimerm exit
If the ALET is not invalid, the most likely reason is that the TCB of the DELETE does not match the TCB of the ADD. You have two options : (1) Change the ALESERV ADD/DELETE to use AL=PASN (2) Do not attempt to ALESERV from the STIMERM exit and indicate (maybe via rc/rsn or a request added to a queue) that the TCB that performed the ALESERV ADD should perform the DELETE. I would suggest (2), but also if this is new code perhaps use memory objects instead of dataspaces? Personally I like to keep timer exits (and recovery/retry routines) as simple as possible and to abdicate complex logic responsibility back to the establishing routine. Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: 09 October 2020 03:37 To: IBM-MAIN@LISTSERV.UA.EDU Subject: ALERSERV delete from stimerm exit EXTERNAL EMAIL Hi Would any one know if there is any restriction on deleting an ALET entry (ALESERV DELETE) from a STIMERM exit I am getting a RC X'14' in R15 I ran the program under test and it's the same ALET I ALERSERV ADD AL=WORKUNIT thanks -- 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 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences 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: ALERSERV delete from stimerm exit
I don’t see a TTOKEN parameter under ALESERV Thanks > On Oct 9, 2020, at 2:50 AM, Robin Atwood wrote: > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ALERSERV delete from stimerm exit
I am guessing you need a job step TTOKEN if you delete the ALET not under the owning TCB. Robin > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Joseph Reichman > Sent: 09 October 2020 09:37 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: ALERSERV delete from stimerm exit > > Hi > > > > Would any one know if there is any restriction on deleting an ALET entry > (ALESERV DELETE) from a STIMERM exit I am getting a RC X'14' in R15 > > > > I ran the program under test and it's the same ALET I ALERSERV ADD > AL=WORKUNIT > > > > thanks > > > > > -- > 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
ALERSERV delete from stimerm exit
Hi Would any one know if there is any restriction on deleting an ALET entry (ALESERV DELETE) from a STIMERM exit I am getting a RC X'14' in R15 I ran the program under test and it's the same ALET I ALERSERV ADD AL=WORKUNIT thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
