An FRR always gets deactivated at the WU
level SRB or Task correct ?

Joe Reichman
8045 Newell St Apt 403
Silver Spring MD 20910
Home (240) 863-3965
Cell (917) 748 -9693

> On Aug 31, 2016, at 3:38 PM, Binyamin Dissen <[email protected]> 
> wrote:
> 
> From:  MVS Programming: Assembler Services Guide
> 
> Deactivating an ESTAE-type recovery routine
> 
> A program may deactivate an ESTAE-type recovery routine only under the same
> linkage stack level as the level that existed when the program activated the
> recovery routine. This rule affects programs that add entries to the linkage
> stack either through the BAKR or PC instruction. Failure to follow this rule
> results in an error return code of 36 from the ESTAE or ESTAEX macro.
> 
> When you issue a PR, the system automatically deactivates all ESTAE-type
> recovery routines that were previously activated under that current linkage
> stack entry.
> 
> 
> On Wed, 31 Aug 2016 19:18:32 +0000 "Blaicher, Christopher Y."
> <[email protected]> wrote:
> 
> :>Here is the code; mainline code calls RECOVERY subroutine then does an 0C1
> :>
> :>
> :>         WTO   'CALLING RECOVERY'
> :>         JASL  R14,RECOVERY           SET UP RECOVERY
> :>         LTR   R15,R15                DID IT GO OK
> :>         JNZ   AUXP9020               NO, EXIT
> :>
> :>         WTO   'BACK FROM RECOVERY'
> :>         DC    H'0'                   PSW in dump points to next 
> instruction after this
> :>
> :>Here is the subroutine.
> :>
> :>RECOVERY CSTART ,               FYI, this does a BAKR/LARL/USING
> :>         ST    R11,ESTAPARM+0          STORE CB IN PARM LIST
> :>         ST    R10,ESTAPARM+4          STORE MODEL IN LIST
> :>         ST    R12,ESTAPARM+8          STORE BASE REG IN PARM LIST
> :>         ST    R13,ESTAPARM+12         STORE DATA REG IN PARM LIST
> :>         XC    ESTAEV(24),ESTAEV       CLEAR ESTAE PARAMETER LIST
> :>         LAY   R3,ESTAEXIT             GET ADDRESS OF ESTAE EXIT RTN
> :>         LAY   R4,ESTAPARM             GET ADDRESS OF ESTAE PARMS
> :>
> :>         ESTAE (R3),CT,PURGE=HALT,ASYNCH=NO,TERM=YES,RECORD=YES,       +
> :>               TOKEN=ESTAETKN,PARAM=(R4),CANCEL=NO,                    +
> :>               MF=(E,ESTAEV)
> :>
> :>         LTR   R15,R15
> :>         JZ    GOOD
> :>         DC    H'5'                    0C1 IF NOT RC=0
> :>GOOD     DS    0H
> :>         ST    R15,RETURNCDE           SAVE IT FOR MESSAGE
> :>         ST    R0,REASONCDE            SAVE IT FOR MESSAGE
> :>
> :>         PR    ,                       RETURN
> :>
> :>
> :>Here is the start of the ESTAE
> :>
> :>ESTAEXIT DS    0H
> :>         DROP  ,                       DROP ALL DSECTS
> :>         BAKR  R14,0                   SAVE EVERYTHING
> :>         CHI   R0,12                   IS SDWA PRESENT?
> :>         JE    ESTAE100                NO, -->
> :>
> :>         L     R2,0(,R1)               LOAD PARAM LIST ADDR FROM SDWA
> :>         LR    R4,R1                   SAVE POINTER TO SDWA
> :>         USING SDWA,R4
> :>
> :>***********************************************************************
> :>*  NO SDWA PRESENT, R2 POINTS TO PARM LIST                            *
> :>***********************************************************************
> :>ESTAE100 DS    0H                      ENTER HERE IF SDWA PRESENT
> :>         LARL  R12,ESTAEXIT            LOAD PROGRAM BASE REGISTER
> :>         USING ESTAEXIT,R12            <<< SET AS APPROPRIATE
> :>         L     R13,12(,R2)             LOAD SAVEWORK AREA ADDRESS
> :>         USING SAVEWORK,R13
> :>
> :>         L     R11,0(,R2)              LOAD LOCAL CB ADDR
> :>         USING CB,R11
> :>
> :>         L     R9,4(,R2)               LOAD MODEL ADDRESS
> :>         USING MODEL,R9
> :>
> :>         ESTAE 0,TOKEN=ESTAETKN        PREVENT RECURSION IN THE CODE
> :>
> :>         WTO   'SSDFAUXP ESTAE ENTERED',DESC=(7),ROUTCDE=(11)
> :>
> :>Output from the job.  Started with a /S procname rather than using ASCR.  
> Both give the same result.
> :>
> :>15.09.56 STC76052  CALLING RECOVERY
> :>15.09.56 STC76052  BACK FROM RECOVERY
> :>15.09.58 STC76052  IEA995I SYMPTOM DUMP OUTPUT  130
> :>   130             SYSTEM COMPLETION CODE=0C1  REASON CODE=00000001
> :>   130              TIME=15.09.56  SEQ=00363  CPU=0000  ASID=00E6
> :>   130              PSW AT TIME OF ERROR  078D0000   9AC00116  ILC 2  INTC 
> 01
> :>   130                ACTIVE LOAD MODULE           ADDRESS=1AC00000  
> OFFSET=00000116
> :>
> :>
> :>Chris Blaicher
> :>Technical Architect
> :>Mainframe Development
> :>Syncsort Incorporated
> :>50 Tice Boulevard, Woodcliff Lake, NJ 07677
> :>P: 201-930-8234  |  M: 512-627-3803
> :>E: [email protected]
> :>
> :>www.syncsort.com
> :>
> :>
> :>
> :>
> :>
> :>-----Original Message-----
> :>From: IBM Mainframe Discussion List [mailto:[email protected]] On 
> Behalf Of Charles Mills
> :>Sent: Wednesday, August 31, 2016 2:45 PM
> :>To: [email protected]
> :>Subject: Re: ESTAE exit not being entered on abend
> :>
> :>Is there an [E]SPIE in the picture/ [E]SPIE gets control ahead of ESTAE, 
> right, and can choose not to percolate? (From memory ...)
> :>
> :>Charles
> :>
> :>-----Original Message-----
> :>From: IBM Mainframe Discussion List [mailto:[email protected]] On 
> Behalf Of Blaicher, Christopher Y.
> :>Sent: Wednesday, August 31, 2016 8:55 AM
> :>To: [email protected]
> :>Subject: ESTAE exit not being entered on abend
> :>
> :>I have a job that does an address space create.
> :>The program in the new address space sets an ESTAE and I know it gave back a
> :>RC=0 as I print the return code.
> :>Note, the ESTAE exit does a WTO that it has been entered as the first thing.
> :>Right after I set the ESTAE I force an 0C1.
> :>I get the 0C1, but the ESATE exit is never entered.
> :>Any hints?  Anybody seen this behavior before?
> :>
> :>----------------------------------------------------------------------
> :>For IBM-MAIN subscribe / signoff / archive access instructions, send email 
> to [email protected] with the message: INFO IBM-MAIN
> :>
> :>________________________________
> :>
> :>
> :>
> :>ATTENTION: -----
> :>
> :>The information contained in this message (including any files transmitted 
> with this message) may contain proprietary, trade secret or other 
> confidential and/or legally privileged information. Any pricing information 
> contained in this message or in any files transmitted with this message is 
> always confidential and cannot be shared with any third parties without prior 
> written approval from Syncsort. This message is intended to be read only by 
> the individual or entity to whom it is addressed or by their designee. If the 
> reader of this message is not the intended recipient, you are on notice that 
> any use, disclosure, copying or distribution of this message, in any form, is 
> strictly prohibited. If you have received this message in error, please 
> immediately notify the sender and/or Syncsort and destroy all copies of this 
> message in your possession, custody or control.
> :>
> :>----------------------------------------------------------------------
> :>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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to