No. The FRR is associated with the SRB/TCB that set it alone and can only be
deleted by that SRB/TCB.

When there is a switch to another unit of work on that CPU, the FRR stack is
saved.

What are you trying to do or avoid?

On Thu, 28 Jul 2016 20:53:20 -0400 Joseph Reichman <[email protected]>
wrote:

:>Can I delete from another work unit e.g TASK  before the SRB 
:>Returns to dispatcher 
:>
:>
:>
:>> On Jul 28, 2016, at 8:29 PM, Greg Dyck <[email protected]> wrote:
:>> 
:>>> On 7/28/2016 1:00 PM, Joe Reichman wrote:
:>>> I have a FRR covering a SRB it not a parameter on the SCHEDULE or IEAMSCHD
:>>> but rather invoked inside the SRB. The documentation says to delete it just
:>>> code SETFRR D,WORKREGS However I am guessing it has to be in the context of
:>>> the SRB or in the FRR on the SETRP REMREC=YES
:>>> 
:>>> But that's only in the retry routine ?
:>> 
:>> If you don't enter recovery then explicitly delete the FRR prior to 
returning to the dispatcher.
:>> 
:>> If you do enter recovery and percolate the error then RTM will implicitly 
delete the FRR for you.
:>> 
:>> If you do enter recovery and retry, it depends.  If you retry to a point 
where the FRR does not get explicitly deleted then you should use SETRP 
REMREC=YES.  If you retry to a point where the FRR does get explicitly deleted 
then do nothing in recovery.
:>> 
:>> Greg
:>> 
:>> ----------------------------------------------------------------------
:>> For IBM-MAIN subscribe / signoff / archive access instructions,
:>> send email to [email protected] with the message: INFO IBM-MAIN
:>
:>----------------------------------------------------------------------
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to [email protected] with the message: INFO IBM-MAIN

--
Binyamin Dissen <[email protected]>
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 [email protected] with the message: INFO IBM-MAIN

Reply via email to