>I have a question about error recovery and here is the situation. > >1. Cobol STC calls an assembler module which passes >a RACF command using IRRSEQ00 >2. The customer has a large profile, over 32K >3. We are seeing a S80A in 'IRRSEQ00' > >Now the question, I know I can write a Cobol Condition Handler, but since >the abend is occurring in an assembler module, can i change the Assembler >called to do a ESTAE ..? I want to be able to note the S80A abend but still >recovery. I am being realistic ? > >What I am not sure of is that the S80A will percolate down where a Cobol >condition handler will catch it. I am in a void in this area and need some >help.
Generally speaking, no, you should not use ESTAE (and ESPIE) in code that is part of an LE application. LE documents the MVS services that are deprecated to be used in that context, because they *may* interfere with LE processing. Now, LE cannot make sure those services are not used because you can CALL other (standalone) programs to help you perform the task at hand. Those (standalone) programs may well protect themselves via ESTAE or other MVS recovery services. Such programs will register error handlers upon entry and deregister again before return. ESTAE type recovery routines are invoked upon ABENDs in the reverse order of their registration. When a recovery routine decides to retry, not other recover routine will get control for this error. (There is more to this, read in z/OS MVS Assembler Services Guide.) When a recovery routine decides not to retry, i.e. it decides to percolate, then the next recovery routine (if any) will get control. This is MVS recovery management, an LE is part of this game, so your assembler routine's ESTAE will get control, and when it percolates, LE's ESTAE routine will be given control. Besides the ESTAE interface, there is also the ESPIE interface. LE registers an ESPIE recovery routine, if TRAP(ON,SPIE) is in effect, to gain control for program check interrupts long before they are turned into an S0Cx type ABEND. We just learned in the course of a PMR, there are cases where LE's ESPIE routine decides to percolate a program check into an ABEND, *but* is does so in an unexpected way: LE deregisters its ESTAE routine before turning the program check into an ABEND. This works fine as long as not ESTAE routine has been registered *after" LE's. If so, LE thinks it deregisters its own ESTAE routine, but since ESTAE routines are chained LIFO, it deregisters some other code's ESTAE routine. This behaviour probably does not hurt your case, because you probably are not interested in program checks anyway. And for non-program-check ABENDs, the latest ESTAE should get control first (I write "should" because I cannot say for sure lack of access to internal LE documentation). If you want to be sure, you could register your own ESTAE *and* ESPIE upon entry, and deregister both before return. *Note*, you must take care to re-register LE's ESPIE routine, since there can only ever be a single ESPIE routine at one point in time (ESPIE documents how to do this). With your own ESTAE and ESPIE in place, there is no way LE would be notified of an error before your code. Not sure why you want to get control in the assembler code, since I understand it is tightly bound to the Cobol code calling it. What do you want to do when you get notified of an ABEND? -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
