IBM Mainframe Forum

I took an existing program, which has run fine since 2008 and expanded a packed field in an occurs clause and now the program is abending and I just can't see what the problem is.

I took the existing program and added displays - here are snapshots of the code and the results of the production version. Below WS-TEST1 and DDICAPT-VOL(WS-SUB3) is a display of the values in hex.

WS-TEST1 = /
CHAR /
ZONE 006144444
NUMR 011C00000
1...5...1
PROCTBL-VOL(WS-SUB2) = 2635
DDICAPT-VOL(WS-SUB3) =
CHAR
ZONE 0000
NUMR 000C
1...
WS-SUB2 = 02
WS-SUB3 = 05
2DICAPT-VOL(WS-SUB3) = 1611 IN THE TEST CODE, IT ABENDS BEFORE THIS DISPLAY
CHAR /
ZONE 0061
NUMR 011C
1...

DDICAPT-DATA 40 143 A
DDICAPT-DATA-TABLE DDICAPT-DATA 13 A OCCURS 11
DDICAPT-PROCESS-DATE DDICAPT-DATA-TABLE 04 P
DDICAPT-NBRAMT DDICAPT-DATA-TABLE +4 01 A
DDICAPT-REC-COUNT DDICAPT-DATA-TABLE +5 04 P
DDICAPT-VOLUME DDICAPT-DATA-TABLE +9 04 P
DDICAPT-NO-DATA-RECEIVED-DAYS 183 02 N
DDICAPT-FILLER 185 16 A

WS-PROCESS-TABLE W 162 A
WS-PROCTBL WS-PROCESS-TABLE 27 A OCCURS 6
WS-PROCTBL-DATEC WS-PROCTBL 8 N VALUE 0 -
MASK('99/99/9999')
WS-PROCTBL-DATEJ WS-PROCTBL +8 4 P VALUE 0
WS-PROCTBL-RECS WS-PROCTBL +12 4 P VALUE 0 -
MASK('ZZZZZZ9')
WS-PROCTBL-VOL WS-PROCTBL +16 4 P VALUE 0 -
MASK('ZZZZZZ9')
WS-PROCTBL-AMT WS-PROCTBL +20 4 P 2 VALUE 0 -
MASK('ZZZZ9.99')
WS-PROCTBL-AMT-VAR WS-PROCTBL +24 1 A VALUE ' '
WS-PROCTBL-REC-VAR WS-PROCTBL +25 1 A VALUE ' '
WS-PROCTBL-VOL-VAR WS-PROCTBL +26 1 A VALUE ' '

WS-TEST1 W 9 A

IF DDICAPT-VOLUME(WS-SUB3) NE 0
MOVE DDICAPT-VOLUME(WS-SUB3) TO WS-TEST1
END-IF
DISPLAYS WERE PLACED HERE
WS-ACTUAL-VARIANCE = 0
IF WS-TEST1 NE ' ' AND +
WS-PROCTBL-VOL(WS-SUB2) NE 0
MOVE WS-TEST1 TO DDICAPT-VOLUME(WS-SUB3) THIS IS THE STATEMENT THAT FAILS IN THE TEST CODE
DISPLAY WAS PLACED HERE
WS-ACTUAL-VARIANCE = +
WS-PROCTBL-VOL(WS-SUB2) / DDICAPT-VOLUME(WS-SUB3)
END-IF

Here is the changed code:
I've changed WS-TEST1 to various sizes (11,7) but there is no difference, still abends. None of the IF logic was changed, just the additional byte to the packed field.

DDICAPT-DATA 40 154 A
DDICAPT-DATA-TABLE DDICAPT-DATA 14 A OCCURS 11
DDICAPT-PROCESS-DATE DDICAPT-DATA-TABLE 04 P
DDICAPT-NBRAMT DDICAPT-DATA-TABLE +4 01 A
DDICAPT-REC-COUNT DDICAPT-DATA-TABLE +5 04 P
DDICAPT-VOLUME DDICAPT-DATA-TABLE +9 05 P
DDICAPT-NO-DATA-RECEIVED-DAYS 194 02 N
DDICAPT-FILLER 196 05 A

WS-PROCESS-TABLE W 168 A
WS-PROCTBL WS-PROCESS-TABLE 28 A OCCURS 6
WS-PROCTBL-DATEC WS-PROCTBL 8 N VALUE 0 -
MASK('99/99/9999')
WS-PROCTBL-DATEJ WS-PROCTBL +8 4 P VALUE 0
WS-PROCTBL-RECS WS-PROCTBL +12 4 P VALUE 0 -
MASK('ZZZZZZ9')
WS-PROCTBL-VOL WS-PROCTBL +16 5 P VALUE 0 -
MASK('ZZZZZZZZ9')
WS-PROCTBL-AMT WS-PROCTBL +21 4 P 2 VALUE 0 -
MASK('ZZZZ9.99')
WS-PROCTBL-AMT-VAR WS-PROCTBL +25 1 A VALUE ' '
WS-PROCTBL-REC-VAR WS-PROCTBL +26 1 A VALUE ' '
WS-PROCTBL-VOL-VAR WS-PROCTBL +27 1 A VALUE ' '

WS-TEST1 = /
CHAR /
ZONE 00614444444
NUMR 011C0000000
1...5...10.
PROCTBL-VOL(WS-SUB2) = 2635
DDICAPT-VOL(WS-SUB3) =
CHAR
ZONE 00000
NUMR 0000C
1...5
WS-SUB2 = 02
WS-SUB3 = 05
12/29/10 12.42.14 CA-EASYTRIEVE PLUS-6.4 0311 PAGE 1

PROGRAMS AND ALL SUPPORTING MATERIALS COPYRIGHT (C) 1982, 1996 BY COMPUTER ASSOCIATES INTL. INC.
280 *******A006 PROGRAM INTERRUPT - CODE 7 (DATA EXCP)
INTERRUPT OCCURRED AT 085A BLOCK 1 FROM EP CA-EASYTRIEVE PLUS 6.4 0311-12/29/10-12.41-JSN00228
INSTRUCTION AT 0000C88A IS F89431262022
FIRST OPERAND ADDRESS 0000B166 CONTENTS 0000000000000000005F
SECOND OPERAND ADDRESS 0007D1F8 CONTENTS 0001611C40
PSW+4 AT INTERRUPT 8000C890
REGISTERS AT INTERRUPT
R0 00008D40 R1 00008508 R2 0007D1D6 R3 0000B040 R4 000084D0 R5 0000A040 R6 0007D190 R7 000094A8
R8 0007D1D6 R9 0000A2A8 R10 A8507626 R11 0000C030 R12 00040B78 R13 000127EC R14 8000C81E R15 00000000
FILE ID/NAME RECORD ADDRESS RECORD LENGTH STATUS
0001 SYSPRINT 00006BF4 62 OPEN
0002 SYSIN 00000000 80 CLOSED
0003 WORK 00000000 0 CLOSED
0004 EZTPRE 00000000 512 CLOSED
0005 DDICAPT 0007D190 200 ACTIVE
0006 FVSCVAR 00000000 0 CLOSED
0007 RPTAMT 00017C14 151 ACTIVE
0008 RPTVOL 00017B74 126 ACTIVE
0009 EZTS001 00000000 104 CLOSED
000A EZTS002 00017B0C 34 CLOSED
WORKING STORAGE
BLOCK ADDRESS
0001 000084D0
0002 000094A8
0003 0000A040
0004 0000B030
*******A014 PREMATURE TERMINATION DUE TO PREVIOUS ERROR(S)

Your error indicates that one of these is not a valid packed decimal field:

Yes, I see that and I don't understand in the first place how the original code is even working, I just know it does as can be seen by the displays and that the job finishes with code code 0.

I don't see how this
WS-TEST1 = /
CHAR /
ZONE 006144444
NUMR 011C00000
1...5...1

moves into this
BEFORE
DDICAPT-VOL(WS-SUB3) =
CHAR
ZONE 0000
NUMR 000C
1...


AFTER
2DICAPT-VOL(WS-SUB3) = 1611
CHAR /
ZONE 0061
NUMR 011C
1...

but it fails when there is one extra byte like this
DDICAPT-VOL(WS-SUB3) =
CHAR
ZONE 00000
NUMR 0000C
1...5
I don't understand why it is getting the x'40' at the end of the second operand instead of just ending with the 1611C. Why is expanding the field 1 byte causing this to happen?

I have not worked with Easytrieve for many, many years. However, it appears that you are moving a 4-byte packed decimal value into WS-TEST1 and attempting to move a 5-byte packed decimal value out of WS-TEST1. Since the fifth byte is a space, this causes the S0C7 abend. I recommend either creating another holding variable that is packed decimal instead of alphanumeric, or finding out why only 4 packed decimal bytes are being moved into WS-TEST1.

Have you sorted this out needhelp?

I don't think we got the full story. If you have extended a field on your input file, presumably there are also changes to the program which creates the file. Possible clue, you record is 200 characters long, yet your definition is 201 characters long. Maybe the file-creater "corrected" this by removing something and didn't let you know.

needhelp wrote:MOVE WS-TEST1 TO DDICAPT-VOLUME(WS-SUB3) THIS IS THE STATEMENT THAT FAILS IN THE TEST CODE

I don't see that this can be true. Check your Easytrieve Plus manual on the MOVE statement. If you don't have one, download it. The MOVE does a byte-by-byte left-to-right copy of the data. OP-code would be MVC. No S0C7 from MVC's. The failing piece of assembler code, OP-code F8, is a ZAP - which means Zero-and-Add-Packed. It is going to take the really long 0000000000000000005F, make it zero (so in this case probably ending in 0F) and then ADD the part which ends in a space. It is not the MOVE which is failing, it is the assignment:

needhelp wrote:WS-ACTUAL-VARIANCE = +
WS-PROCTBL-VOL(WS-SUB2) / DDICAPT-VOLUME(WS-SUB3)

The production program is reading a different file than your test program (if not, then that is your first problem). I'd say that your record layout in the test program does not match the physical data on the file. When the data is moved to WS-TEST1, five bytes are moved, because that is how long the field you are moving from is defined as (the rest of WS-TEST1 will be padded with space, but the first space has come from your input field). The move five bytes back to where it came from, still with a space in the last byte, and try to do a calculation with it. S0C7.

Check you file and record layouts. I don't know what the WS-TEST1 was trying to do in the first place, but I guess you inherited that.

It was late, and I forgot a couple of things I meant to mention

Firstly, there is a lot of information Easytrieve Plus can provide when it abends, but only if you have told it to do so earlier, on the PARM statement. Here would be my suggestion:



I always found that ETP's Abend output (the ABEXIT SNAP bit) provided all the information needed as regards to the data that was hanging around at the time, including recently used records on the files. If you think it too big an output, you can always ignore it until you need it, or put ABEXIT NOSNAP which gives some ETP stuff that your dump-handler software probably doesn't know about (if it doesn't know about ETP).

The "DEBUG" isn't what you youngsters might think it is. It is not going to drop you into an interative debug session, or do anything especially useful as far as your program running with your data unless your program crashes.

Then, as coded above, it will tell you what program line number (STATE - on the output listing, not your text source) it crashed on and it will show you the previous FLOW and FLOWSIZ n (where n is a max of 4096) line numbers (again on the output) that were executed.

XREF, PMAP/CLIST and DMAP will control the format of the output listing of your program.

XREF will produce an alpha-order list of datanames, job/sort names, procedure names and anything else you'd need, with line numbers showing where defined and referenced. XREF SHORT will only include names actually referenced in the program (which is good if you have macros for record-layouts).

If you really want to see the Assmemble code (and get a spot-on reference for when there is an abend) code PMAP (which will "map" the program for you). When you don't need it, put CLIST instead (Condensed Listing), which is probably what you are currently getting from the installation default.

DMAP will "map" the data.

LIST (which is not part of DEBUG) is a useful thing, as it will give you files used/records per file, per JOB/SORT. It is also useful to list the PARM statement out, if not installation default, this is how to do it (LIST PARM).

Finally, VFM, ETPs "virtual file manage". Exceptionally useful. You can create a file which only exists with the program. You can create it in one JOB, then read it in another (or in a SORT). By default, it takes its space from memory. That means tis quick. It gets tossed away when no longer needed. Great fun, easy to use. You are using it akread, perhaps without knowing, if you have multiple reports, or a sequenced report. A bonus is, when a VIRTUAL file is sorted, ETP starts off SYNSORT, or DFSORT, or whatever you have installed, with a perfect count of the number of records. Apparently, makes the sort more efficient.

Enough about the PARM.

The other thing I noticed was that your input file contains "signed" decimal data for fields which have no decimal places, but you are defining them in your program as "unsigned".

needhelp wrote:DDICAPT-VOLUME ... 05 P

When you do your little calculation, DDICAPT-VOLUME will end up as an "unsigned" field. You file will end up with a mixture of "C" and "F" (positive, and unsigned-treated-as-positive) numbers on it. Might not cause a problem. Might cause some confusion when someone else looks at your file. Might cause a problem if you manage to turn a "D" into an "F", a negative number into unsigned-treated-as-positive. If you want the equivalent of Cobol's COMP-3 PIC S9(9), then you need to code DDICAPT-VOLUME ... 05 0 . In ETP, all fields with decimal places are signed, all those without are unsigned. So you have to tell it zero decimal places to keep the definition matching the data!