This is just a question.
Have you looked at using a LE User Handled Condition instead of an ESTAEX?
CEEHDLR-Register User-written condition handler
z/OS V1R12.0 Language Environment Programming Reference
SA22-7562-12
CEEHDLR registers a user-written condition handler for the current stack
frame. The user condition handler is invoked when:
It is registered for the current stack frame by CEEHDLR, and
The Language Environment condition manager requests the condition
handler associated with the current stack frame handle the condition.
Language Environment places the user-written condition handlers associated
with each stack frame in a queue. The queue can be empty at any given time.
The Language Environment condition manager invokes the registered condition
handlers in LIFO (last in, first out) order to handle the condition.
The opposite of CEEHDLR, which registers a user-written condition handler,
is CEEHDLU, which unregisters the handler. You do not necessarily need to
use CEEHDLU to remove user-written condition handlers you registered with
CEEHDLR. Any user-written condition handlers created through CEEHDLR and not
unregistered by CEEHDLU are unregistered automatically by Language
Environment, but only when the associated stack frame is removed from the
stack.
I have seen LE being touchy at times when a process tries to override what
it wants to do.
Lizette
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Charles Mills
Sent: Wednesday, August 28, 2013 7:49 AM
To: [email protected]
Subject: LE U4088 Reason 63 -- no back chain
I am trying to get an ESTAEX recovery routine to call an LE C routine. Why?
I want to do some diagnosis and cleanup following an ABEND. Why not use LE
conditions and/or C signals? I do, but LE's ESTAE(X) is (apparently) TERM=NO
and does not catch certain ABENDs such as operator cancel. Why cancel rather
than stop? Yes, I support stop, but on a "polling" basis, so should the
(rather complex) code get in some application loop it never checks for stop.
Customers do what they do, and sometimes what they do is cancel a program.
Okay, on to the problem at hand. I have the ESTAEX recovery routine calling
an assembler routine. The idea is that the assembler routine will become LE
conformant and then call the C code. The assembler entry point begins with
ESTAE2LE CEEENTRY PPA=CEEPPA, +
AUTO=0, +
NAB=NO, +
MAIN=NO, +
BASE=R11
It is ABENDing with a 4088/63. The doc says
Stack segment owning the next-available-byte (NAB) could not be found or a
DSA backchain pointer did not contain a valid 31-bit addressable address. A
storage overlay problem has probably occurred. DSA backchain pointers must
contain valid addresses that can be accessed as is while in 31-bit
addressing mode. For instance, a 24-bit address that was obtained by using
the BAL or BALR assembler instruction will contain the ILC, CC, and Program
Mask in the uppermost byte of this address, thus making it an invalid
address in 31-bit mode.
I doubt that a storage overlay has occurred (but anything is possible, of
course). There should be no 24/31-bit issues -- all code is and has always
been 31-bit. I tried clearing the ESTAEX-provided save area backchain to
zeros but it made no difference. I suspect the problem is that ESTAEX just
does not provide any backchain but LE needs one if MAIN=NO.
Anyone have any thoughts or clever suggestions?
Thanks,
Charles
----------------------------------------------------------------------
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
