Mark, Tom Ross has already responded that what you are trying to do is not the right way to do it. To paraphrase, you are trying to use a screw-driver as a hammer. It MIGHT work (in some cases) but it certainly is NOT the right way to do this. What you need (or should do) is read up on LE condition handling. I received the following information from one person that MIGHT provide useful guidance,
"... he should try the LE Programming Guide [Chapters 15-19] for information about how to 'use' LE rather than 'fight' it by issuing his own ESTAE and creating chaos out of order. [This would be a reasonable response to his claim of not having documentation.] If he is a SHARE member, there is an excellent session on "Diagnosing Application Problems Under LE" that would clearly explain the sequence of things when there are problems in an LE application. He might even consider attending SHARE to get educated on LE. He might also find out about some run-time options that could be the reason he is not seeing messages or dumps. Of course, his ESTAE may have disrupted things so much that LE is no longer able to deal with it. But, of course, Janice's award winning session on Condition Handlers would be valuable should he be willing to back away from his ESTAEs and wants to actually use a handler. The LE Programming Reference would provide info on the specific services he'll need." *** You can find copies of these presentations at: (Open to non-SHARE members) http://www-03.ibm.com/servers/eserver/zseries/zos/le/conference/pdf/swa8208. pdf and (for SHARE members) http://shareew.prod.web.sba.com/proceedingmod/abstract.cfm?abstract_id=12611 &conference_id=13 "Mark" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Mark wrote: > > I have an ASM main task that establishes an ESTAE. > > > > It then calls a COBOL subroutine (establishing an estae trap(on,nospie)) > > where it abends with an 0C4/11 > > > > LE calls the CEEBXITA routine and appears to process its recovery. > > > > My asm ESTAE takes control and eventually returns back to the OS. > > > > Then a minute later I get a dump for 0C4/11 in CEEBINIT. The program > > appears to have issued the SVC 13 to trigger this. > > > > I don't seem to have access to the LE internals docs. But I'm guessing that > > the CEEBINIT routine is doing nothing more than "re-issue" the original > > abend so that the task abends with the original abend codes. > > > > Does anyone have a clue whether or not I'm right? > > > > Or is there something else going on that I need to look into? > > > > There isn't a CEEDUMP file created. I do have the DD card in the batch region. > > > > There are no LE return codes or messages that I can find. > > > > Anyone care to wade into this and clear this up for me? > > > > -Mark > More clarification. > > The SVC 13 really means 0A0D. > > The ASM ESTAE routine cleans up files, and percolates the abend up the > chain. > > I've created the CEEDUMP using the UADUMP option. It seems to know all > about the original abend but doesn't shed any light on why the CEEBINIT > program would issue the SVC Abend using what appears to be the original > abend codes. > > My google search isn't turning up any useful information. > > Alternatively, anyone know how I might get access (temporary or > whatever) to the license LE manuals? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html