FRR Clarification
Hi, When trying to cover my code I always choose an FRR If I am in Supervisor State * Always get an SDWA * Would get control before an ESTAE So If I'm In SRB mode I have no choice in task mode I can code EUT=YES. However now looking over the Doc "Once a program activates an EUT FRR it cannot issue an SVC's" So while SETFRR is providing coverage the program cant issue any SVC's? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FRR Clarification
On Sat, 11 Feb 2017 19:15:51 -0500 Joe Reichman wrote: :>When trying to cover my code I always choose an FRR If I am in Supervisor :>State :>* Always get an SDWA If no storage available for the SDWA, the FRR does not get control. An ESTAE will. :>* Would get control before an ESTAE The latest ESTAE always get control first. :>So If I'm In SRB mode I have no choice in task mode I can code EUT=YES. :>However now looking over the Doc "Once a program activates an EUT FRR it :>cannot issue an SVC's" :>So while SETFRR is providing coverage the program cant issue any SVC's? Correct. FRR is faster, but it has constraints. -- 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: FRR Clarification
Old thread, but I am curious based on a recent issue I had; it seems the ESTAE got control before the FRR, documentation seems to state that FRR gets control before the estae, is that right? So if my FRR never got control it must be that there was no space for an SDWA, or "the latest ESTAE always get control first", before even the FRRs? Thanks, Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: Sunday, February 12, 2017 3:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: FRR Clarification On Sat, 11 Feb 2017 19:15:51 -0500 Joe Reichman wrote: :>When trying to cover my code I always choose an FRR If I am in Supervisor :>State :>* Always get an SDWA If no storage available for the SDWA, the FRR does not get control. An ESTAE will. :>* Would get control before an ESTAE The latest ESTAE always get control first. :>So If I'm In SRB mode I have no choice in task mode I can code EUT=YES. :>However now looking over the Doc "Once a program activates an EUT FRR it :>cannot issue an SVC's" :>So while SETFRR is providing coverage the program cant issue any SVC's? Correct. FRR is faster, but it has constraints. -- 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: FRR Clarification
FRRs always get control before ESTAEs/ARRs. FRRs always get an SDWA. Just about the only reason for an FRR to not get control is that the cross memory environment that was request on SETFRR cannot be established. In that case, a logrec record is written to say that the FRR was skipped. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > Old thread, but I am curious based on a recent issue I had; it seems > the ESTAE got control before the FRR, documentation seems to state > that FRR gets control before the estae, is that right? So if my FRR > never got control it must be that there was no space for an SDWA, or > "the latest ESTAE always get control first", before even the FRRs? > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FRR Clarification
Perhaps you forgot EUT=YES in an EUT environment? On Fri, 28 Jul 2017 18:37:11 + Leonardo Vaz wrote: :>Old thread, but I am curious based on a recent issue I had; it seems the ESTAE got control before the FRR, documentation seems to state that FRR gets control before the estae, is that right? So if my FRR never got control it must be that there was no space for an SDWA, or "the latest ESTAE always get control first", before even the FRRs? :> :>Thanks, :>Leo :> :>-Original Message- :>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen :>Sent: Sunday, February 12, 2017 3:22 AM :>To: IBM-MAIN@LISTSERV.UA.EDU :>Subject: Re: FRR Clarification :> :>On Sat, 11 Feb 2017 19:15:51 -0500 Joe Reichman wrote: :> :>:>When trying to cover my code I always choose an FRR If I am in Supervisor :>State :> :>:>* Always get an SDWA :> :>If no storage available for the SDWA, the FRR does not get control. An ESTAE will. :> :>:>* Would get control before an ESTAE :> :>The latest ESTAE always get control first. :> :>:>So If I'm In SRB mode I have no choice in task mode I can code EUT=YES. :>:>However now looking over the Doc "Once a program activates an EUT FRR it :>cannot issue an SVC's" :> :>:>So while SETFRR is providing coverage the program cant issue any SVC's? :> :>Correct. :> :>FRR is faster, but it has constraints. -- 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: FRR clarification
>it seems the ESTAE got control before the FRR wanna bet? As the earlier posts mentioned, it is possible that an FRR will never get control (for example if an SDWA could not be obtained, which typically would happen only if the system was already in deep trouble). But an ESTAE will never get control before an FRR (where such a statement implies that both do get control). One might argue that if an FRR was skipped because of inability to get an SDWA that the address space should be memterm'd because the recovery routine would not have gotten a chance to clean up. An FRR (also true for ESTAE) would also be skipped if the cross-memory environment that it requires cannot be established. I'd suggest that if you think this is happening, you get a dump and examine the system trace, specifically for RCVY entries. A RCVY FRR entry is provided whether the FRR is skipped or not, with an indication in the data if it was skipped. Peter Relson z/OS Core Technologoy Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FRR Clarification
Thank you very much for the clarification Jim Mulder! It's very good to know about the logrec record. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Saturday, July 29, 2017 1:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: FRR Clarification FRRs always get control before ESTAEs/ARRs. FRRs always get an SDWA. Just about the only reason for an FRR to not get control is that the cross memory environment that was request on SETFRR cannot be established. In that case, a logrec record is written to say that the FRR was skipped. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > Old thread, but I am curious based on a recent issue I had; it seems > the ESTAE got control before the FRR, documentation seems to state > that FRR gets control before the estae, is that right? So if my FRR > never got control it must be that there was no space for an SDWA, or > "the latest ESTAE always get control first", before even the FRRs? > -- 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
FW: FRR Clarification One More Thing I forgot
From: Joe Reichman [mailto:reichman...@gmail.com] Sent: Saturday, February 11, 2017 7:16 PM To: 'IBM Mainframe Discussion List' Subject: FRR Clarification Hi, When trying to cover my code I always choose an FRR If I am in Supervisor State * Always get an SDWA * Would get control before an ESTAE * Also a ESATE only covers an RB while a FRR cover a TCB So If I'm In SRB mode I have no choice in task mode I can code EUT=YES. However now looking over the Doc "Once a program activates an EUT FRR it cannot issue an SVC's" So while SETFRR is providing coverage the program cant issue any SVC's? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FRR Clarification One More Thing I forgot
FRB ? Do you mean FRR also dies that mean an FRR to provides protection in the context of the current RB Thing is I also Read the a PR instruction de-activates the FRR that's even worse Seems there are lots Joe Reichman 8045 Newell St Apt 403 Silver Spring MD 20910 Home (240) 863-3965 Cell (917) 748 -9693 > On Feb 12, 2017, at 3:23 AM, Binyamin Dissen > wrote: > > On Sat, 11 Feb 2017 19:19:24 -0500 Joe Reichman wrote: > > :>*Also a ESATE only covers an RB while a FRR cover a TCB > > What does that mean? > > The RB cannot change while the FRB is providing protection as that requires an > SVC. > > -- > 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: FRR Clarification One More Thing I forgot
What I mean to say seems there a lots of way that an recovery routine becomes de-activated > On Feb 12, 2017, at 4:36 AM, Joseph Reichman wrote: > > FRB ? Do you mean FRR also dies that mean an FRR to provides protection in > the context of the current RB > > Thing is I also Read the a PR instruction de-activates the FRR that's even > worse > > Seems there are lots > > Joe Reichman > 8045 Newell St Apt 403 > Silver Spring MD 20910 > Home (240) 863-3965 > Cell (917) 748 -9693 > >> On Feb 12, 2017, at 3:23 AM, Binyamin Dissen >> wrote: >> >> On Sat, 11 Feb 2017 19:19:24 -0500 Joe Reichman >> wrote: >> >> :>*Also a ESATE only covers an RB while a FRR cover a TCB >> >> What does that mean? >> >> The RB cannot change while the FRB is providing protection as that requires >> an >> SVC. >> >> -- >> 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: FRR Clarification One More Thing I forgot
On Sun, 12 Feb 2017 04:36:59 -0500 Joseph Reichman wrote: :>FRB ? Do you mean FRR also dies that mean an FRR to provides protection in the context of the current RB The FRR would probably be driven with an 0F8 :>Thing is I also Read the a PR instruction de-activates the FRR that's even worse The MVS support for PR drops the FRR? Didn't know that. :>> On Feb 12, 2017, at 3:23 AM, Binyamin Dissen wrote: :>> :>> On Sat, 11 Feb 2017 19:19:24 -0500 Joe Reichman wrote: :>> :>> :>*Also a ESATE only covers an RB while a FRR cover a TCB :>> :>> What does that mean? :>> :>> The RB cannot change while the FRB is providing protection as that requires an :>> SVC. -- 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: FRR Clarification One More Thing I forgot
What I meant was a PR instruction de-activates the recovery routines > On Feb 12, 2017, at 4:54 AM, Binyamin Dissen > wrote: > > On Sun, 12 Feb 2017 04:36:59 -0500 Joseph Reichman > wrote: > > :>FRB ? Do you mean FRR also dies that mean an FRR to provides protection in > the context of the current RB > > The FRR would probably be driven with an 0F8 > > :>Thing is I also Read the a PR instruction de-activates the FRR that's even > worse > > The MVS support for PR drops the FRR? Didn't know that. > > :>> On Feb 12, 2017, at 3:23 AM, Binyamin Dissen > wrote: > :>> > :>> On Sat, 11 Feb 2017 19:19:24 -0500 Joe Reichman > wrote: > :>> > :>> :>*Also a ESATE only covers an RB while a FRR cover a TCB > :>> > :>> What does that mean? > :>> > :>> The RB cannot change while the FRB is providing protection as that > requires an > :>> SVC. > > -- > 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: FRR Clarification One More Thing I forgot
if you have the ability to read look at MVS Programming: Authorized Assembler Services Guide and MVS Programming: Assembler Services Guide chapters on recovery problem solved -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FW: FRR Clarification One More Thing I forgot
On Sat, 11 Feb 2017 19:19:24 -0500 Joe Reichman wrote: :>* Also a ESATE only covers an RB while a FRR cover a TCB What does that mean? The RB cannot change while the FRB is providing protection as that requires an SVC. -- 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
