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
