Re: Abend S052-104
On Sun, 28 Mar 2021 00:58:22 -0400 Gary Weinhold wrote: :>It was set up this way when we decided we had to add a PC to our product :>20 years ago. I believe the programmer was afraid that a customer could :>accidentally cancel the server started task and cause all running :>instances of our product to abend (which could include CICS and IMS/TM :>regions, batch jobs and a shared dataspace). He figured this technique :>would only prevent new instances of our product from starting and :>wouldn't be as big a problem for the customer to recover from. Set up a RESMGR in the server that sets a bit indicating not available. It is possible to get an 0D6 (or is it 0D7) should a thread be in the middle of the PC and get interrupted and then resume after the cancel completes but that would be extremely rare, -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend S052-104
It was set up this way when we decided we had to add a PC to our product 20 years ago. I believe the programmer was afraid that a customer could accidentally cancel the server started task and cause all running instances of our product to abend (which could include CICS and IMS/TM regions, batch jobs and a shared dataspace). He figured this technique would only prevent new instances of our product from starting and wouldn't be as big a problem for the customer to recover from. What specifically is the "technique"? Using LXRES within a batch job is simply a bad idea. Apparently you want a separate LXRES for each user. That's OK (if likely very wasteful). But then you can have multiple started tasks. "The" server started task does not need to be the implementation. "A" server started task" could be (and each user connects to its own server). And of course the server task could be made non-cancelable. Further, canceling a server causes no abend in and of itself. Only when a client attempts to access would there be the expected problem, leaving opportunity for "waiting until restart" or whatever. 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: Abend S052-104
Gary If you update the PPT entry for your server jobstep program to NOCANCEL, then you can consider moving the ownership of that PC-cp to the server. Rob From: IBM Mainframe Discussion List On Behalf Of Gary Weinhold Sent: 28 March 2021 05:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Abend S052-104 EXTERNAL EMAIL Rob Scott wrote (snipped): > From the description of the abend, if your user code runs as a jobstep in > something like a JES initiator, you will always be at risk from a prior batch > job performing an LXRES for PC-ss (without an initiator restart). ... > Is there any reason why your user-ASID owned PC-cp cannot be owned by your > server-ASID ? > > The load module would have to be in LPA/common but could probably execute > exactly the same code as it does today. and Peter Relson wrote (snipped): > One case would be a multi-step started task (or initiated job) where the > first step did so, and there is a second step. > Don't do that. Thanks, Peter and Rob. This was a batch job and we do not know all the preceding job steps (we only know the prior step was IDCAMS). We know our product can be run in multiple steps in the same job. Your responses will enable us to help the customer research the preceding steps to the abend in the address space. The resolution may be as simple as changing the job class for this job (or the cross-memory job step). According to the customer, this happens once in a while and rerunning the job works. It was set up this way when we decided we had to add a PC to our product 20 years ago. I believe the programmer was afraid that a customer could accidentally cancel the server started task and cause all running instances of our product to abend (which could include CICS and IMS/TM regions, batch jobs and a shared dataspace). He figured this technique would only prevent new instances of our product from starting and wouldn't be as big a problem for the customer to recover from. Gary Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com<mailto:weinh...@dkl.com> Visit us online at www.DKL.com<http://www.DKL.com> E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -- 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 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: Abend S052-104
On Sun, 28 Mar 2021, at 05:58, Gary Weinhold wrote: > ... According to > the customer, this happens once in a while and rerunning the job works. Does the customer have more than one initiator servicing whatever job class the job required? That is, how likely is it that the rerun jobs run in a different address space from the earlier job? -- Jeremy Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend S052-104
Rob Scott wrote (snipped): From the description of the abend, if your user code runs as a jobstep in something like a JES initiator, you will always be at risk from a prior batch job performing an LXRES for PC-ss (without an initiator restart). ... Is there any reason why your user-ASID owned PC-cp cannot be owned by your server-ASID ? The load module would have to be in LPA/common but could probably execute exactly the same code as it does today. and Peter Relson wrote (snipped): One case would be a multi-step started task (or initiated job) where the first step did so, and there is a second step. Don't do that. Thanks, Peter and Rob. This was a batch job and we do not know all the preceding job steps (we only know the prior step was IDCAMS). We know our product can be run in multiple steps in the same job. Your responses will enable us to help the customer research the preceding steps to the abend in the address space. The resolution may be as simple as changing the job class for this job (or the cross-memory job step). According to the customer, this happens once in a while and rerunning the job works. It was set up this way when we decided we had to add a PC to our product 20 years ago. I believe the programmer was afraid that a customer could accidentally cancel the server started task and cause all running instances of our product to abend (which could include CICS and IMS/TM regions, batch jobs and a shared dataspace). He figured this technique would only prevent new instances of our product from starting and wouldn't be as big a problem for the customer to recover from. Gary Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend S052-104
This abend is not about a separate started task that uses LXRES in its creation of an XM environment, and then subsequent jobs or started tasks "connect". The description for this abend is this: LXRES is issued but a cross-memory-resource-owning jobstep task has already terminated in the home address space One case would be a multi-step started task (or initiated job) where the first step did so, and there is a second step. Don't do that. 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: Abend S052-104
Gary From the description of the abend, if your user code runs as a jobstep in something like a JES initiator, you will always be at risk from a prior batch job performing an LXRES for PC-ss (without an initiator restart). Admittedly this is rare as LXRES-issuing code normally runs as a started task. One possibility that could explain the situation : (1) A prior batch job established a non-resuable System-LX PC-ss and then terminated cleanly (including a successful LXFRE) (2) At this point PCAUTH still has the initiator ASID in the “memory delete queue” and has marked the ASID as non-reusable. (3) Your code is then scheduled to run in this initiator (same ASID as the init has not restarted) (4) When you issue the LXRES you will get the S052-104 (5) If the initiator was stopped prior to your code executing, I would expect a IEF352I message (due to (1) and (2)) Without testing, I am unsure if the prior code was changed to use REUSABLE=YES if this would prevent the problem you are seeing, however this is moot as the prior job code is not under your control. Is there any reason why your user-ASID owned PC-cp cannot be owned by your server-ASID ? The load module would have to be in LPA/common but could probably execute exactly the same code as it does today. Rob Scott Rocket Software From: IBM Mainframe Discussion List On Behalf Of Gary Weinhold Sent: 25 March 2021 18:05 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Abend S052-104 EXTERNAL EMAIL We have a situation in a customer environment where they intermittently get this abend when our product initializes in a jobstep. The S052 abend explanation: A program incorrectly issued a macro to request processing by Program Call/authorization (PC/AUTH) service routines. Register 15 contains a hexadecimal reason code in the form xxyy, where x identifies the macro that was issued, and yy identifies the error. See the system programmer response for an explanation of these reason codes. *Code** Explanation* 01yy The program issued an LXRES macro. 0104 A job step attempted to issue the LXRES macro, but a prior job step owned space-switch entry tables. (Subsequent job steps are not permitted to issue PC/AUTH macros.) Before applications using our product are started, our product initializes an non-terminating address space in which we set up a system non-space-switching PC. This PC is executed when our product is initialized in a job step. The function of the PC is to create a non-space-switching non-system PC in our address-space with our "user" PC for several supervisor state routines we need to invoke. We also set up an MVS RESMGR exit to allow us to cleanup at termination (which includes an LXFRE). So there is no doubt that we executed an LXRES. But to me this abend indicates that some prior step (could it perhaps not even be in this job, but in some job that previously ran in this address space?) created a space-switching PC and the address space is still is supporting it and will not allow another LXRES. So to prevent this error from occurring, is there something we can do in our code, or should the submitter of the job ensure that it runs in a different address space or should whatever created the space-switching PC clean it up? Or do I entirely misunderstand the meaning of this abend code? Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com<mailto:weinh...@dkl.com> Visit us online at www.DKL.com<http://www.DKL.com> E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -- 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 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
Abend S052-104
We have a situation in a customer environment where they intermittently get this abend when our product initializes in a jobstep. The S052 abend explanation: A program incorrectly issued a macro to request processing by Program Call/authorization (PC/AUTH) service routines. Register 15 contains a hexadecimal reason code in the form xxyy, where x identifies the macro that was issued, and yy identifies the error. See the system programmer response for an explanation of these reason codes. *Code** Explanation* 01yy The program issued an LXRES macro. 0104 A job step attempted to issue the LXRES macro, but a prior job step owned space-switch entry tables. (Subsequent job steps are not permitted to issue PC/AUTH macros.) Before applications using our product are started, our product initializes an non-terminating address space in which we set up a system non-space-switching PC. This PC is executed when our product is initialized in a job step. The function of the PC is to create a non-space-switching non-system PC in our address-space with our "user" PC for several supervisor state routines we need to invoke. We also set up an MVS RESMGR exit to allow us to cleanup at termination (which includes an LXFRE). So there is no doubt that we executed an LXRES. But to me this abend indicates that some prior step (could it perhaps not even be in this job, but in some job that previously ran in this address space?) created a space-switching PC and the address space is still is supporting it and will not allow another LXRES. So to prevent this error from occurring, is there something we can do in our code, or should the submitter of the job ensure that it runs in a different address space or should whatever created the space-switching PC clean it up? Or do I entirely misunderstand the meaning of this abend code? Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
