CICS HANDLE ABEND
Frank Swarbrick
I have a specific question, which I'll state below, but perhaps a little background is in order.
I've worked in this shop for 14 years, and it was here where I learned CICS programming (along with the CICS for the COBOL Programmer books and a one week training course from Protech). I say this just so you know I've never worked on CICS systems anywhere but here.
When I started here (1996) we were on CICS/VSE 2.3 and we had Abend-Aid for CICS/VSE as our CICS dump analyzer tool. We are now on z/OS with CICS TS for z/OS 4.1. We have ASG-SmartScope installed, but we've not yet actually configured it for use. This is not all that relevant, but I thought I'd mention it. We actually use the LE dumps that are triggered by an abend (we have TERMTHDACT(DUMP) set).
For the most part our CICS application programs do not use CICS HANDLE ABEND. I was just talking to our most senior applications person (almost 30 years here, plus another ten or so elsewhere prior to that) and asked him why in general we did not use CICS HANDLE ABEND to do cleanup and send back graceful error messages to the end user. He said that when we got Abend-Aid lo those many years ago if we did a HANDLE ABEND it would supress the dump, and so Abend-Aid would have nothing to analyze. So a standard was put in place that HANDLE ABEND not be used.
With CICS TS z/OS 4.1, at least, this appears to not be true. Whether the abend is an S0C7, something caused by an unhandled condition, or (most?) any other abend I have observed that the CICS transaction dump is, in fact, created. (The LE dump, on the other hand, is not!)
My question for you CICS historians is, is my co-worker's assertion that using HANDLE ABEND used to suppress the transaction dump in fact the case? If so, when did it change. And why? Don't get me wrong, I think it should do the dump. I'm just curious about the change, if there was one.
Thanks!
Frank
--
Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO USA
P: 303-235-1403
>>>
The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you.
Frank Swarbrick
Thanks!
--
Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO USA
P: 303-235-1403
On 11/9/2010 at 5:25 PM, in message
<OFF4DC12EE.08C847A3-ON882577...@ux2b.pcb>, Irwin
Deutsch <ideu...@PRINCESSCRUISES.COM> wrote:
> It didn't necessarily suppress the dump, Frank. It depended on what you
> did in your abend routine. You could either continue the abend, in which
> case you would probably get the dump, or you could end the transaction
> normally, in which case there would be no dump, no backout, etc.
>
>
> Irwin
>
>
> The information contained in this email and any attachment may be
> confidential and/or legally privileged and has been sent for the sole use
> of the intended recipient. If you are not an intended recipient, you are
> not authorized to review, use, disclose or copy any of its contents. If
> you have received this email in error please reply to the sender and
> destroy all copies of the message. Thank you.
Frank M. Ramaekers
typically, have HANDLE ABEND to allow for the DTB to do it's work
(rather than programming the backout).
Frank M. Ramaekers Jr.
Thanks!
Frank
--
>>>
_____________________________________________________
This message contains information which is privileged and confidential and is solely for the use of the
intended recipient. If you are not the intended recipient, be aware that any review, disclosure,
copying, distribution, or use of the contents of this message is strictly prohibited. If you have
received this in error, please destroy it immediately and notify us at Priva...@ailife.com.
indust...@winwholesale.com
> ... we do not, typically, have HANDLE ABEND to allow for the
Sincerely,
Dave Clark
WinWholesale Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
(937) 294-5331
*********************************************************************************************
This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission.
*********************************************************************************************
Frank Swarbrick
As I mentioned in a followup, my original test case had been
- Program 1 has EXEC CICS HANDLE ABEND LABEL(abend-procedure)
- Program 2 is executed via EXEC CICS LINK from Program 1
- Program 2 causes an abend condition
The results were:
- Program 2 abends and does a transaction dump with it's original abend code (ASRA or whatever). No LE dump is created.
- Control is given back to Program 1 at label "abend-procedure".
- Program does some stuff and terminates
If, however, I put the HANDLE ABEND statement in the *same* program as the program that abends there is *no* transaction dump. So basically, my co-worker was correct, and things function now as they did back then. We just didn't realize that having a HANDLE ABEND on a "lower-level" program acts differently with regard to the transaction dump (in that it is not suppressed). I have yet to find where this is documented, but...
Let me tell you what brought all of this up. I've been playing around with the CICS Web Support (having transactions started via an HTTP request to a TCPIPSERVICE). I had noticed that even though I did not have a HANDLE ABEND in my application code I was not getting the LE dump that I expected, even though it was creating the CICS transaction dump
DFHDU0203I 11/10/2010 15:56:25 CICSDEVJ A transaction dump was taken for dumpcode: ASRA, Dumpid: 2/0027.
DFHWB0125 11/10/2010 15:56:25 CICSDEVJ EDF3 The CICS Web Interface program DFHWBBLI has detected an abend issued by the program
CICSEDF3. TCPIPSERVICE: FJSHTTP
DFHWB0101 11/10/2010 15:56:25 CICSDEVJ EDF3 The CICS Web Interface alias program DFHWBA detected a failure in program DFHWBBLI.
Host IP address: 10.0.200.250. Client IP address: 10.1.166.11. TCPIPSERVICE: FJSHTTP
DFHDU0203I 11/10/2010 15:56:25 CICSDEVJ A transaction dump was taken for dumpcode: AWBM, Dumpid: 2/0028.
I opened a PMR with IBM and they said it's because of the following (essentially) (sorry for going in to more detail than might be necessary, but that's how I do things):
CICS does not execute the user application directly but instead it executes DFHWBA under the user specified tran ID (EDF3 in this case). DFHWBA does a HANDLE ABEND and some other stuff and then links to CICS program DFHWBBLI.
DFHWBBLI also does a CICS HANDLE ABEND. DFHWBBLI optionally links to the user specified converter program. After the converter program returns DFHWBBLI then links to the user application (CICSEDF3 in this case).
User program abends and does a dump for that abend. In the above case, user program CICSEDF3, abend code ASRA.
The abend is percolated back one level to DFHWBBLI. DFHWBBLI writes the DFHWB0125 message above, does some other stuff and then returns back to DFHWBA.
DFHWBA writes the DFHWB0101 message above and invokes the URM DFHWBEP.
DFHWBEP does, optionally, some stuff (like specifying a message other than the CICS supplied HTTP 500 "Internal Server Error" message) and returns back to DFHWBA.
DFHWBA then sends the HTTP error response message back to the client. It then does EXEC ABEND ABCODE('AWBM') CANCEL (unless you customized DFHWBEP to suppress it).
>From there the normal abend process is done, with DFHTFP being invoked and then the DFHPEP URM, etc. Transaction backout is done, et al.
ANYWAY, the point is that it's the program that links to the user's program (namely DFHWBBLI) that "catches" the abend. This is why I did the test the way I did it, having one program (with a HANDLE ABEND) link to a second program (which abends).
...
Addressing other things:
I can see, and possibly agree, why one would not want to have a HANDLE ABEND. But in this case I have no choice, because it's an internal CICS module that is doing the HANDLE ABEND. I've reasoned that it *must* behave this way in order to send the HTTP response back to the HTTP client. If it just allowed the abend to terminate the task there would be no way (I assume) to do this, so the client application would just hang out there, waiting for a response, until it times out (assuming it has a timeout!).
Interestingly, this is exactly what happens for a CICS TCP/IP listener/server application I wrote. Since I do not have HANDLE ABEND in it the task terminates and never responds to the client. Has always been an issue, and I think I can now solve it by using HANDLE ABEND. And since we have a "driver" program, kind of like what the combination of DFHWBA/DFHWBBLI are, I can place my HANDLE ABEND in there and still get a transaction dump when one of our business logic programs abend. So this is pretty cool. Still won't get the LE dump, though I'm considering asking IBM to remedy that.
Of course I'm actually testing using a TCPIPSERVICE to replace my inhouse written listener/server, so I don't really need to fix that program, but anyway.
Some good points were made about Dynamic Transaction Backout. CICS does the right thing in that after it handles the abend (sends the response to the client) it creates the AWBM abend which in turn invokes DTB.
Seems to me that it would be useful to have EXEC CICS HANDLE ABEND enhanced so there would be an option to the following:
1) Do a transaction dump for the abend
2) Give control to the user abend handler label/program
3) When the program returns to CICS, continue with abend processing; ie DTB et al.
No idea if that's feasible, but it seems to me to be ideal. We'd get the best(?) of both words. A dump and DTB, but also the ability to terminate gracefully from the end user's point of view.
Maybe I'm just crazy.
--
Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO USA
P: 303-235-1403
>>>
The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you.
Tony Thigpen
enhanced so there would be an option to the following:
> 1) Do a transaction dump for the abend
> 2) Give control to the user abend handler label/program
> 3) When the program returns to CICS, continue with abend processing;
ie DTB et al.
You can always put a EXEC CICS DUMP command in your abend routine.
Tony Thigpen
indust...@winwholesale.com
> Maybe I'm just crazy.
Frank Swarbrick
<F255EFE0ECF08C4A9C1D...@ch2wpmail1.na.ds.ussco.com>, "Chase,
John" <jch...@USSCO.COM> wrote:
>> -----Original Message-----
>> From: CICS List On Behalf Of Frank Swarbrick
>>
>> [ snip ]
>>
>> Seems to me that it would be useful to have EXEC CICS HANDLE ABEND
> enhanced so there would be an
>> option to the following:
>> 1) Do a transaction dump for the abend
>> 2) Give control to the user abend handler label/program
>> 3) When the program returns to CICS, continue with abend processing;
> ie DTB et al.
>>
>> No idea if that's feasible, but it seems to me to be ideal. We'd get
> the best(?) of both words. A
>> dump and DTB, but also the ability to terminate gracefully from the
> end user's point of view.
>
> specify, in case of an abend. That label or program is, effectively, an
> "exit routine" in which you can already do the things you ask (and more,
> if desired).
>
> For example:
>
> ABEND-HANDLE-ROUTINE.
> . . .
> EXEC CICS DUMP
> TRANSACTION
> DUMPCODE(whatever)
> <other options>
> END-EXEC.
> . . .
> CALL 'CEE3DMP' USING <title, options, fc>.
> . . .
> EXEC CICS SYNCPOINT
> ROLLBACK
> END-EXEC.
> . . .
> ABEND-HANDLE-ROUTINE-EXIT.
> EXIT.
>
> Now, I "speak" just enough COBOL to embarrass myself (and others), but I
> believe this code fragment does everything you specified:
>
> 1. Produces a transaction dump (and optionally a SYSDUMP, depending on
> your dump table options for the dumpcode you specify);
>
> 2. Produces an LE dump, according to the options you specify;
>
> 3. Instructs CICS to back-out everything in "this" LUW that has not
> already been committed.
>
>
>> Maybe I'm just crazy.
>
Not exactly. I realized that these things could be done. But the state of the data in the dump is not what it was at the time of the actual abend, but what it was at the time the dump request was issued after the abend has been handled. See the following:
CEEMSG (LE) output when no HANDLE ABEND:
CEE3250C The system or user abend AEIP was issued.
From compile unit CICSWIRE at entry point CICSWIRE at statement 5053 at compile unit offset +00005ED4 at entry offset
+00005ED4 at address 1071FED4.
CEE3DMP V1 R10.0: Condition processing resulted in the unhandled condition. 11/12/10 9:42:13 AM Page: 1
Task Number: 1564 Transaction ID: WIRE
CEE3845I CEEDUMP Processing started.
--------------------------
CEEMSG (LE) output when HANDLE ABEND is specified, and the "exit code" does an EXEC CICS DUMP and a call to CEE3DMP:
CEE3DMP V1 R10.0: Frank's Dump 11/12/10 9:40:39 AM Page: 1
Task Number: 1436 Transaction ID: WIRE
CEE3845I CEEDUMP Processing started.
CEE3DMP called by program unit CICSWIRE at statement 14686 (offset +0001B4C2).
-------------------------
CEEMSG (LE) output when HANDLE ABEND is specified, and the "exit code" does EXEC CICS ABEND ABCODE (abcode) where abcode is retrieved from EXEC CICS ASSIGN ABCODE (abcode):
CEE3250C The system or user abend AEIP was issued.
From compile unit CICSWIRE at entry point CICSWIRE at statement 14682 at compile unit offset +0001B47C at entry offset
+0001B47C at address 1073547C.
CEE3DMP V1 R10.0: Condition processing resulted in the unhandled condition. 11/12/10 10:23:11 AM Page: 1
Task Number: 1804 Transaction ID: WIRE
CEE3845I CEEDUMP Processing started.
-------------------------
So the original abend occured at statement 5053, (offset 5ED4), but neither method of using HANDLE ABEND reflects this.
We've also lost the values of some of the EIB fields (particularly EIBRESP, EIBRESP2, EIBFN and EIBRCODE).
I've never tried to make use of an actual CICS transaction dump, but it appears that it has the same issues as the LE dump.
Perhaps there are some tricks that can be done to restore these fields to how they looked at the time of the original abend, but I do not know what they are.
Frank