I use FRRs a lot because just about every PC routine I write can be called from
an SRB. The PC routine defines a ESTAEX when called in task mode and examines
the FRR stack and adds or replaces an FRR when called in an SRB routine or when
a lock is set. I rarely use EUT=YES FRRS. Not a big fan of EUT FRRs. I know
that the documentation states the R2 points to the 24 byte parm area but I've
always retrieved it from the SDWAPARM field. In your dump R2 seems to point to
the FRR extension. And yes, the parm address is in PSA (BE) looks right for the
first entry in the stack). The FRR stack has to be specially managed by MVS and
saved and restored each time a DU is dispatched. There's a lot of details
missing from your email so I'm just going to give you the working linkage to a
well tested FRR routine. First of all, I don't save the registers. I know that
R14 points to the EXIT service call so I don't worry about the registers.
Second, I always set the first 8 bytes of the 24 byte parm area to an
eyecatcher. I always do that last in case something goes wrong before the FRR
is fully setup. Beleive me, things can go wrong. Lastly, my FRR entry point is
just a stub. After dealing with the FRR dependencies, it just jumps into the
ESTAEX recovery routine with an entered from FRR flag set. The way I have
everything setup, the processing of an abend doesn't matter once the starting
linkage is addressed.
One other thing, most of my routines are RMODE64. Therefore, the FRR exit is
loaded into 31 bit storage. So most of my code uses the 64 bit instruction set
and a 31 bit SDWA. It’s a real pain when you want to retry into 64 bit
addresses but its well tested.
*********************************************************************
* FRR ENTRY TO HANDLE RELEASING LOCK. IT TRANSFERS CONTROL TO ABEND
* RECOVERY ABOVE TO RECORD ERROR
TDFPCLNK_FRR DS 0H
LARL R12,TDFPCLNK_ESTAEX USE ESTAEX ADDRESSABILITY
USING TDFPCLNK_ESTAEX,R12
USING SDWA,R1
LLGT R8,SDWAPARM FRR Parmad address
LLGTR R7,R0 SAVE FOR JUMP INTO ABEND RECOVERY
LLGFR R5,R14 SAVE FOR JUMP INTO ABEND RECOVERY
LLGTR R6,R1 SAVE FOR JUMP INTO ABEND RECOVERY
CLC 0(8,R8),=CL8'eyecatch' GOT MY EYECATCHER?
JE TDFRECV_GOTPARMS YES - LETS RECORD
**********************************************************************
* WITHOUT PARM AREA, WE CAN STILL SET ABEND CODES FOR PERCOLATION
LLGTR R1,R6 RESET TO RETURN W/FAILURE
LARL R2,retry_address_if_no_parms
SETRP RC=4,REMREC=YES,RETADDR=(R2)
LLGTR R14,R5 RESET TO RETURN W/FAILURE
BR R14
**********************************************************************
* RESET MY PARM REGISTERS
TDFRECV_GOTPARMS DS 0H
Load parms from R8
And jump into ESTAEX RTM exit with called from FRR flag set
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Donald Likens
Sent: Wednesday, October 02, 2013 3:47 PM
To: [email protected]
Subject: FRR Recovery Routine Environment
I do not understand what I am doing wrong. I setup the following recovery
environment:
SETFRR A,FRRAD=FRRA,EUT=YES,MODE=FULLXM,WRKREGS=(R1,R2),
PARMAD=(R3)
ST R13,0(R3)
I then caused my program to abend.
When my recovery routine is entered I ABEND with an S0C4 because R2 is not as I
expected. The following is the start of my FRR recovery routine:
013723*C START FRR RECOVERY ROUTINE
013724FRR DS 0H
013725* ON ENTRY
013726* R15 ADDRESS OF THIS ROUTINE
013727* R14 RETURN ADDRESS
013728* R1 ADDRESS OF SDWA
013729* R2 ADDRESS OF PARAMETERS
013730 STM R0,R15,0(R13)
013731 USING FRR,R15
013733 L R3,0(R2)
013734 USING WKGSTG,R3
013735 LR R12,R15
013736 DROP R15
013737 USING FRR,R12
I thought perhaps R2 would be the address of the parameter list but the dump
does not support that theory.
Here is what I am seeing in the dump:
Generalpurpose register values
Lefthalves of all registers contain zeros
0-3 00FBE6C8 00FBE7F8 00000C20 1940BE28
4-7 7FFFF000 7FFFF000 7FFFF000 7FFFF000
8-11 7FFFF000 7FFFF000 7FFFF000 7FFFF000
12-15 975B0494 00FBE98C 00FE6EAC 975B0494
00000C20 00140000 01575150 026AF950 026AF950
00FBE7F8 00000BE0 140C1000
00000BE0 03452108
03452000.:03467FFF.--Storage not available
Can anyone share a working SETFRR/UET and the start of the recovery routine.
Thanks
----------------------------------------------------------------------
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
