Re: Regarding RBINTCOD
, January 30, 2024 3:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Regarding RBINTCOD On Tue, 30 Jan 2024 20:05:50 +0200, Binyamin Dissen wrote: >:>Jon P did write what I meant. Answer: no, it just makes it a lot more likely >that the storage obtain for the SDWA will succeed. > >Sad. I believe abend recovery R0=12 is virtually unheard of when SDWA is above the line. Realize that REGION=2048M is not valid and 2047M is the max. I suspect that IBM reserves this last 1M for situations like this. Additionally, running out of 2GB of storage is very rarely from <1K storage obtains. SDWA is small and enough storage should be available. Far more concerning would be S878 abend recovery. Does abend recovery automatically bypass storage limits during S878 abend recovery? If not, is there a mechanism to bypass it temporarily? I've used STORAGE OBTAIN,COND=YES and when it fails, percolate it to IBM recovery. For common recovery in product environments, this is not the best solution but it works most of the time. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Regarding RBINTCOD
On Tue, 30 Jan 2024 20:05:50 +0200, Binyamin Dissen wrote: >:>Jon P did write what I meant. Answer: no, it just makes it a lot more likely >that the storage obtain for the SDWA will succeed. > >Sad. I believe abend recovery R0=12 is virtually unheard of when SDWA is above the line. Realize that REGION=2048M is not valid and 2047M is the max. I suspect that IBM reserves this last 1M for situations like this. Additionally, running out of 2GB of storage is very rarely from <1K storage obtains. SDWA is small and enough storage should be available. Far more concerning would be S878 abend recovery. Does abend recovery automatically bypass storage limits during S878 abend recovery? If not, is there a mechanism to bypass it temporarily? I've used STORAGE OBTAIN,COND=YES and when it fails, percolate it to IBM recovery. For common recovery in product environments, this is not the best solution but it works most of the time. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Regarding RBINTCOD
On Tue, 30 Jan 2024 13:17:15 + Peter Relson wrote: :> :>Are you implying that an ESTAE(X) routine with SDWALOC=31 is guaranteed an :>SDWA and there is no reason to check R0 for 12 and alternate code paths? :> :>Jon P did write what I meant. Answer: no, it just makes it a lot more likely that the storage obtain for the SDWA will succeed. Sad. -- 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: Regarding RBINTCOD
Are you implying that an ESTAE(X) routine with SDWALOC=31 is guaranteed an SDWA and there is no reason to check R0 for 12 and alternate code paths? Jon P did write what I meant. Answer: no, it just makes it a lot more likely that the storage obtain for the SDWA will succeed. 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: Regarding RBINTCOD
REGION=(24,31,64) memory limits is available On Mon, Jan 29, 2024 at 12:27 PM Jon Perryman wrote: > On Mon, 29 Jan 2024 15:40:04 +0200, Binyamin Dissen < > bdis...@dissensoftware.com> wrote: > > >Are you implying that an ESTAE(X) routine with SSWALOC=31 is guaranteed an > >SDWA and there is no reason to check R0 for 12 and alternate code paths? > > Obviously Peter is not making that guarantee but how many jobs run with > REGION=0M or 0K. If I remember correctly, SDWA allocation ignores REGION > limits, which essentially ensures SDWA will always exist unless you have > serious system problems. Above the line storage may not be guaranteed but > the odds would be astronomical. > > Coding REGION= >16M is far more common. With all the advancements, filling > below the line storage should never happen but it is conceivable. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Regarding RBINTCOD
REGIONX=(24,31,53) memory limits is available. On Mon, Jan 29, 2024 at 12:27 PM Jon Perryman wrote: > On Mon, 29 Jan 2024 15:40:04 +0200, Binyamin Dissen < > bdis...@dissensoftware.com> wrote: > > >Are you implying that an ESTAE(X) routine with SSWALOC=31 is guaranteed an > >SDWA and there is no reason to check R0 for 12 and alternate code paths? > > Obviously Peter is not making that guarantee but how many jobs run with > REGION=0M or 0K. If I remember correctly, SDWA allocation ignores REGION > limits, which essentially ensures SDWA will always exist unless you have > serious system problems. Above the line storage may not be guaranteed but > the odds would be astronomical. > > Coding REGION= >16M is far more common. With all the advancements, filling > below the line storage should never happen but it is conceivable. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Regarding RBINTCOD
On Mon, 29 Jan 2024 15:40:04 +0200, Binyamin Dissen wrote: >Are you implying that an ESTAE(X) routine with SSWALOC=31 is guaranteed an >SDWA and there is no reason to check R0 for 12 and alternate code paths? Obviously Peter is not making that guarantee but how many jobs run with REGION=0M or 0K. If I remember correctly, SDWA allocation ignores REGION limits, which essentially ensures SDWA will always exist unless you have serious system problems. Above the line storage may not be guaranteed but the odds would be astronomical. Coding REGION= >16M is far more common. With all the advancements, filling below the line storage should never happen but it is conceivable. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Regarding RBINTCOD
On Mon, 29 Jan 2024 12:57:53 + Peter Relson wrote: :>But none of this is appropriate to do within a recovery routine. That is why there is an SDWA. :>And if the system was unable to provide the ESTAE-type recovery routine with an SDWA, then too bad (and encourage the creator to use SDWALOC31=YES (as is the case always for such recovery as ESTAEX and ARR). Are you implying that an ESTAE(X) routine with SSWALOC=31 is guaranteed an SDWA and there is no reason to check R0 for 12 and alternate code paths? -- 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: Regarding RBINTCOD
Thanks > On Jan 29, 2024, at 7:58 AM, Peter Relson wrote: > > > Is there any way to know whether this is an SVC or abend > > I mean I know for SVC the length must be 2 but that doesn't mean it cannot > be a abend > > > Abend is an SVC. So you could conceivably look at RBINTCOD for x'000D'. > A different question would be whether you can tell that the error was not > initiated by the abend SVC but by CALLRTM TYPE=ABTERM or was a program check > or an SVC error. In general the answer might be "no" because there is > auxiliary information passed by RTM1 (think of an FRR environment, whether or > not there are FRRs) to RTM2 via SVC x'D'. That auxiliary information is not > part of the programming interface. > > But none of this is appropriate to do within a recovery routine. That is why > there is an SDWA. > And if the system was unable to provide the ESTAE-type recovery routine with > an SDWA, then too bad (and encourage the creator to use SDWALOC31=YES (as is > the case always for such recovery as ESTAEX and ARR). > > 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: Regarding RBINTCOD
Is there any way to know whether this is an SVC or abend I mean I know for SVC the length must be 2 but that doesn't mean it cannot be a abend Abend is an SVC. So you could conceivably look at RBINTCOD for x'000D'. A different question would be whether you can tell that the error was not initiated by the abend SVC but by CALLRTM TYPE=ABTERM or was a program check or an SVC error. In general the answer might be "no" because there is auxiliary information passed by RTM1 (think of an FRR environment, whether or not there are FRRs) to RTM2 via SVC x'D'. That auxiliary information is not part of the programming interface. But none of this is appropriate to do within a recovery routine. That is why there is an SDWA. And if the system was unable to provide the ESTAE-type recovery routine with an SDWA, then too bad (and encourage the creator to use SDWALOC31=YES (as is the case always for such recovery as ESTAEX and ARR). 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
