Home > Archive > Cobol > May 2004 > LE Condition Handling - Code/JCL Samples
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
LE Condition Handling - Code/JCL Samples
|
|
| docdwarf@panix.com 2004-05-14, 11:30 am |
|
All right, then... time to give back a bit of what was given me.
Thanks to Mr Klein for directing me to
http://ew.share.org/callpapers/atta...e/s8234jmwa.pdf
as it is an invaluable resource.
Thanks also to Google for directing me to
http://www-1.ibm.com/servers/eserve...df/sna8234b.pdf
which contains a slightly stripped-down version of the TOPHDLR program
found in Mr Klein's URL... but since Google allows for 'View as HTML' I
could copy-n-paste into a text-editor and save a bit o' keying.
To the guts, then. I coded and compiled:
IDENTIFICATION DIVISION.
PROGRAM-ID. SKELPROG.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 STUFF.
05 FILLER PIC XX VALUE SPACE.
01 FILLER REDEFINES STUFF.
05 FLD1 PIC 9.
05 FLD2 PIC 9.
*
PROCEDURE DIVISION.
*
DISPLAY ' !! BEFORE DIVIDE '.
COMPUTE FLD1 = FLD1 / FLD2.
DISPLAY ' !! MADE IT BACK AFTER S0C7'.
GOBACK.
.... which, when run, blew up as expected. (This might be said of a good
deal of my work.) The SYSOUT showed:
!! BEFORE DIVIDE
CEE3207S The system detected a data exception (System Completion
Code=0C7).
From compile unit SKELPROG at entry point SKELPROG at statement 14 at
compile unit offset +00000306 at address 000075AE.
.... and the CEEDUMP began with:
CEE3DMP V2 R10.0: Condition processing resulted in the unhandled
condition.
From the second URL above I got (and modified slightly according to the
code in the first URL):
IDENTIFICATION DIVISION.
PROGRAM-ID. TOPHDLR.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
INPUT-OUTPUT SECTION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 DMP-TITLE PIC X(80)
VALUE 'CEEDUMP FROM HANDLER ROUTINE'.
01 DMP-OPTIONS PIC X(255)
VALUE 'TRACE FILE VAR STOR'.
01 FEEDBACK.
10 FB-SEV PIC S9(4) COMP.
10 FB-MSGNO PIC S9(4) COMP.
10 FB-CASE-SEV PIC X.
10 FB-FAC-ID PIC X(3).
10 FB-ISINFO PIC S9(8) COMP.
LINKAGE SECTION.
01 CURRENT-CONDITION.
10 FBCODE PIC X(8).
88 S0C7 VALUE X'00030C8759C3C5C5'.
88 S0C9 VALUE X'00030C8959C3C5C5'.
88 S0CB VALUE X'00030C8959C3C5C5'.
10 PIC X(4).
01 DATA-INFO PIC S9(8) COMP.
01 RESULT-CODE PIC S9(9) COMP.
88 RESUME VALUE +10.
88 PERCOLATE VALUE +20.
01 NEW-CONDITION PIC X(12).
PROCEDURE DIVISION USING CURRENT-CONDITION, DATA-INFO,
RESULT-CODE, NEW-CONDITION.
100-PROGRAM-BEGIN.
****************************************
*****************
* CALL CEE3DMP TO PRODUCE THE DUMP, AND THEN
* SET RESUME TO TRUE SO THE PROGRAM KEEPS RUNING
****************************************
*****************
IF S0C9 OR S0C7 OR S0CB
CALL 'CEE3DMP' USING DMP-TITLE, DMP-OPTIONS, FEEDBACK
IF FB-SEV NOT = 0
DISPLAY 'ERROR IN CEE3DMP CALL', FB-FAC-ID, FB-MSGNO
DISPLAY 'NO DUMP HAS BEEN PRODUCED'
END-IF
SET RESUME TO TRUE
ELSE
SET PERCOLATE TO TRUE
END-IF.
999-EXIT-PROGRAM.
GOBACK.
.... which I compiled to the same library as SKELPROG.
I then changed the JCL from:
//STEP020 EXEC PGM=SKELPROG
.... to ...
//STEP020 EXEC PGM=SKELPROG,PARM='/USRHDLR(TOPHDLR)'
.... the '/' in the PARM indicating that what follows is an LE runtime
parameter, in this case the User Handler is TOPHDLR.
The job ran and showed a Completion Code of 0.
SYSOUT showed:
!! BEFORE DIVIDE
!! MADE IT BACK AFTER S0C7
.... and CEEDUMP began with:
CEE3DMP V2 R10.0: CEEDUMP FROM HANDLER ROUTINE
CEE3DMP called by program unit IGZCFCC at offset +000002D8.
(note that text string 'CEEDUMP FROM HANDLER ROUTINE' is the value
assigned to DMP-TITLE in TOPHDLR)
As should be obvious this TOPHDLR handles only three conditions; in order
to handle more one needs to get their values associated with the FBCODE.
These can be found in SCEESAMP PDS (in the SHARE presentation it is
CEE.SCEESAMP, on the system I'm using it is SYS1.SCEESAMP), member
CEEIGZCT... now how a sane person would go about associating these values
with their ABEND codes I do not know but according to the presentation:
88 CEE341 VALUE X'00030C8159C3C5C5'.
88 CEE342 VALUE X'00030C8259C3C5C5'.
88 CEE343 VALUE X'00030C8359C3C5C5'.
88 CEE344 VALUE X'00030C8459C3C5C5'.
88 CEE345 VALUE X'00030C8559C3C5C5'.
88 CEE346 VALUE X'00030C8659C3C5C5'.
88 CEE347 VALUE X'00030C8759C3C5C5'.
88 CEE348 VALUE X'00030C8859C3C5C5'.
88 CEE349 VALUE X'00030C8959C3C5C5'.
88 CEE34A VALUE X'00030C8A59C3C5C5'.
88 CEE34B VALUE X'00030C8B59C3C5C5'.
.... covers values S0C1 thru S0CB.
I find the implications of these capabilities to be stunning and
invaluable... but, as some might have concluded, I'se jes' easily
impressed. My thanks, once again, to Mr Klein and my apologies to the
group for presenting my experiments and findings in so muddy. obscure and
incomplete a fashion.
DD
| |
| S Comstock 2004-05-14, 4:30 pm |
| DocDwarf (aka Captain COBOL(!!??)) writes ...
[snip]
>I find the implications of these capabilities to be stunning and
>invaluable... but, as some might have concluded, I'se jes' easily
>impressed. My thanks, once again, to Mr Klein and my apologies to the
>group for presenting my experiments and findings in so muddy. obscure and
>incomplete a fashion.
Ahh, Doc, very good. But it just scratches the surface. You can, for example,
capture the statement number in your dump output, you can define your own
conditions and write handlers to catch them, and on and on.
The folks who originally designed and developed LE thought condition handling
would be the big seller. But no, it seems for COBOL folks, if they know
anything about LE, dynamic storage allocation is the hot seller. Condition
handling comes in second, though.
So how do we convince management it is a worthwhile investment to train folks
in these skills? For that matter, how do we convince programmers?
Kind regards,
-Steve Comstock
800-993-9716
303-393-8716
www.trainersfriend.com
email: steve@trainersfriend.com
256-B S. Monaco Parkway
Denver, CO 80224
USA
| |
| docdwarf@panix.com 2004-05-14, 9:30 pm |
| In article <20040514153537.10600.00000426@mb-m24.aol.com>,
S Comstock <scomstock@aol.com> wrote:
>DocDwarf (aka Captain COBOL(!!??)) writes ...
>
>
>[snip]
>
>
>
>Ahh, Doc, very good. But it just scratches the surface.
My apologies for being so superficial, Mr Comstock... the amount of time
between Mr Klein's posting the URLs and my posting of the code which I had
found, modified, compiled, modified, compiled, modified... etc. and then
posted should have allowed for more, true... but I guess I am lazy.
>You can, for example,
>capture the statement number in your dump output, you can define your own
>conditions and write handlers to catch them, and on and on.
This is something Mr Zitzelberger (sp?) was suggesting, aye.
[snip]
>So how do we convince management it is a worthwhile investment to train folks
>in these skills?
The same way one convinces management it is a worthwhile investment to
train folks in *any* skills... from what I have seen the easiest thing to
do is pass a few laws.
(For example: years on back laws regarding certain interactions between
superiors and subordinates were in such a state of existence and/or
enforcement that there was no perceived need for anti-sexual harassment
classes... and, as a result, no classes. Since then the laws have changed
and their enforcement has changed, with the result that management is
convinced that such anti-sexual harassment training is well worth the time
and money used on it.)
>For that matter, how do we convince programmers?
See above in re/ 'the same way'... but, of course, slightly different.
Some programmers are happy to have one year's experience twenty times
over, others risk their jobs by using their Internet connection to read
comp.lang.cobol. Sun T'zu, I believe, spoke of different kinds of
motivation for different people... fear of punishment for the lazy,
possibility of gain for the greedy, the opportunity to contribute for the
intelligent... but that was written a few millennia back, things *must* be
different now.
DD
|
|
|
|
|