Discussion:
FRR Clarification
(too old to reply)
Joe Reichman
2017-02-12 00:15:12 UTC
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Binyamin Dissen
2017-02-12 08:21:12 UTC
Permalink
Raw Message
On Sat, 11 Feb 2017 19:15:51 -0500 Joe Reichman <***@GMAIL.COM> 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 <***@dissensoftware.com>
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Leonardo Vaz
2017-07-28 18:36:13 UTC
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen
Sent: Sunday, February 12, 2017 3:22 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: FRR Clarification

On Sat, 11 Feb 2017 19:15:51 -0500 Joe Reichman <***@GMAIL.COM> 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 <***@dissensoftware.com> 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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jim Mulder
2017-07-29 17:28:22 UTC
Permalink
Raw Message
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
Post by Leonardo Vaz
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Leonardo Vaz
2017-07-31 15:10:52 UTC
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On Behalf Of Jim Mulder
Sent: Saturday, July 29, 2017 1:29 PM
To: IBM-***@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
Post by Leonardo Vaz
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
invalid
2017-09-19 16:53:11 UTC
Permalink
Raw Message
Post by Jim Mulder
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.
Is that correct? Won't it get control as a restricted FRR if the cross
memory environment can't be established?
Greg Dyck
2017-09-20 20:04:56 UTC
Permalink
Raw Message
Post by invalid
Post by Jim Mulder
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.
Is that correct? Won't it get control as a restricted FRR if the cross
memory environment can't be established?
Only if the SETFRR *explicitly* asked for it with the MODE=(xxxxx,LOCAL)
specification. Doing so also requires that the FRR routine be loaded in
common storage so that it can be executed in any address space. It also
requires that the FRR be written with the possibility of being entered
in restricted local mode (i.e., SDWALCL is on) and perform appropriate
recovery actions if it is. Very few FRRs are coded (or need to be
coded) to execute in a restricted local mode environment.

Regards,
Greg
invalid
2017-09-23 18:30:51 UTC
Permalink
Raw Message
Post by Greg Dyck
Post by invalid
Post by Jim Mulder
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.
Is that correct? Won't it get control as a restricted FRR if the cross
memory environment can't be established?
Only if the SETFRR *explicitly* asked for it with the MODE=(xxxxx,LOCAL)
specification.
Thank you.

Binyamin Dissen
2017-07-29 18:43:33 UTC
Permalink
Raw Message
Perhaps you forgot EUT=YES in an EUT environment?

On Fri, 28 Jul 2017 18:37:11 +0000 Leonardo Vaz <***@CN.CA> 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-***@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen
:>Sent: Sunday, February 12, 2017 3:22 AM
:>To: IBM-***@LISTSERV.UA.EDU
:>Subject: Re: FRR Clarification
:>
:>On Sat, 11 Feb 2017 19:15:51 -0500 Joe Reichman <***@GMAIL.COM> 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 <***@dissensoftware.com>
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...