Hi Steve,

You're close! I'll go through your points in order:

1. Correct. CEEPIPI is called with request code 3 (init_sub). The PIPI table is set up correctly. For the demonstration case (IBM's sample to keep things simple) I took a working program and added an intentional ABENDS0C3.

For your supplementary questions, I decided to create this demonstration case when I saw LE presenting user abends for system abends that occurred outside of the LE environment. We are in the process of developing an application that is making use of CEEPIPI, and on the "happy path" everything works fine. As for the treatment of abends outside the LE environment, this is not changed behavior. However, that does not automatically mean it is correct behavior.

2. Correct. CEEPIPI is called with request 4 (call_sub), and the called subroutine runs OK.

3. Correct. The abend occurs between two calls to CEEPIPI.

Note, however, that it is not necessary to call any subroutines to get this situation. If the driver program abends after receiving control back from CEEPIPI after the init_sub call, the abend information will still be altered by LE's recovery routines.

Regards, Gord Tomlin

Steve Comstock wrote:
Gord Tomlin wrote:
Just looking for input as to whether this is "working as designed" before I report it as a defect...

If a program that uses CEEPIPI to call HLL subroutines abends while *not* in any of the HLL subroutines, LE recovery processes the abend and transforms a system abend into a LE user abend. Meanwhile, the associated dump is written to SYSUDUMP rather than CEEDUMP.

Let me understand a little better:

1. Your driver initializes an LE environment for running
   subroutines by calling CEEPIPI with a request code of
   3 (init_sub)

   So I assume, for the moment, your PIPI table is set
   up correctly.

   [BTW, is this new behavior for you? Was it working before
    and now it acts differently? Or is this your first time
    through the PIPI process?]


2. You call your subroutine by calling CEEPIPI with a
   request code of 4 (run_sub) and it presumably runs OK

3. You call one or more additional subroutines (or your
   first subroutine again)

   at some time during this process, between two calls
   of subroutines from your PIPI table, your driver
   abends and gets an LE UCC

Is that about right?





This situation can be recreated by using the samples "ASMPIPI" and "HLLPIPI" from the LE Programming Guide", and adding the abend of your choice (I used EX 0,*) after the label TSUB in ASMPIPI. Instead of seeing a ABENDS0C3 in ASMPIPI, you will see a ABENDU4036-2 associated with CEEPLPKA. The only sign of the original abend is in the system trace table. Needless to say, LE's recovery routines have not made a positive contribution to locating the original problem.

One of the requirements for a program that uses CEEPIPI to call LE-conforming HLL routines is that the calling routine *not* be a LE-conforming program, so it seems nonsensical on the surface that LE's recovery routines would try to interpret the abend.

The LE Programming Guide says:
- init_sub creates a LE environment and "sets the environment dormant so that exceptions are percolated out of it. - for call_sub, CEEPIPI activates the LE environment before the called routine is invoked, and after the called routine returns, the environment is dormant.

It appears to me that LE is doing an incomplete job of ignoring/percolating abends that occur while outside of the LE environment. Does anyone know anything to the contrary?

Thanks!



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to