IEBCOPY does not overlay your ESTAE. It creates its own ESTAE, which gets control before yours. IEBCOPY's ESTAE does a Retry, and RTM releases the RTM2WA before giving control to the retry routine. Since IEBCOPY's ESTAE retried, processing of the Abend is completed, so your ESTAE does not get control.
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Steff Gladstone Sent: Tuesday, March 8, 2022 10:03 AM To: [email protected] Subject: ESTAE and IEBCOPY In one of our REXX procedures we execute IEBCOPY to copy a member from one PDS to another. Sometimes IEBCOPY fails (e.g., for lack of space either in the directory or the library). It intercepts the abend through its ESTAE routine and returns a CC=8 with a text message to SYSPRINT. We would like to be able to receive more specific information as to the abend code and reason code of the IEBCOPY fail so we wrote a front-end which creates our own ESTAE before calling IEBCOPY so we can capture the information from the SDWA at abend time. But it appears that IEBCOPY overlays our ESTAE with its own so we don't get control. So we decided that when IEBCOPY returns to our front-end we would locate the RTM2WA and glean the information from it. But the pointer to the RTM2WA (TCBRTWA) is zero at that point (we suppose that IEBCOPY cancels its ESTAE before returning to us and the RTM2WA is released). Does anybody have any ideas how we might capture the abend and reason codes in spite of all this? Thanks, Steff Gladstone ---------------------------------------------------------------------- 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
