IBM Mainframe Forum

Hi,

I have an issue that I am struggling with at the moment.

The compile listing offset supplied by the CEEDUMP, CEE3845I module is not correct when I look at the program listing.
It shows a number greater than where the actual abend occurs.

Does anyone know why this might occur? Is there some compile option that I am specifying incorrectly.
At the moment I use the following.
//COB EXEC PGM=IGYCRCTL,REGION=2M,
// PARM=('TEST(ALL,SYM)',
// 'NORENT,SOURCE,SSRANGE',
// 'OPT,MAP,DATA(31),RMODE(ANY)',
// 'EXIT(INEXIT(RW),PRTEXIT(RW))')

and the Linkage is

//LNK EXEC PGM=IEWL,
// PARM='NOLIST,MAP,XREF,LET,AMODE(31),RMODE(ANY),SIZE=(192K,96K)',
// COND=(4,LT,COB)
//*

Appreciate the help!

The compile listing offset supplied by the CEEDUMP, CEE3845I module is not correct when I look at the program listing.
It shows a number greater than where the actual abend occurs.

You are writing complete and utter garbage here. The computer does not lie to you. The offset of the abend is what the computer tells you it is. If you believe, for whatever reasons, that the abend occurred at a different point in the program -- YOU ARE WRONG! You may be wrong because the compile / linkage edit JCL is not putting the load module in the load library you think it is, you may be wrong because you "know" -- CONTRARY TO THE FACTS GIVEN YOU BY THE COMPUTER -- where the abend supposedly occurs, or any number of other reasons.

But you need to go back to the abend, discard all preconceived notions that you know anything about the abend, and use what the computer tells you to debug the abend properly.

You might think so, but I have been working in COBOL for 7 years now, and this is the first shop where I find this happening. I am using the SYSPRINT STEP1 COB for the listing and the abend is showing be as below. So explain that!

Condition Information for Active Routines
Condition Information for CEEHSGLT (DSA address 000288A0)
CIB Address: 00029330
Current Condition:
CEE0198S The termination of a thread was signaled due to an unhandled cond
Original Condition:
IGZ0006S The reference to table WS-DV-MON by verb number 01 on line 002429



002423C 018000 EXIT.
002424C 018100*
002425C 018200 CCSI-FD-EXIT.
002426C 018300*
002427C 018400 EXIT.
002428C 018500*********************************************************
002429C 018600* END OF SOURCE STATEMENT
002430C 018700*********************************************************
002431 ** GREG TO JULIAN DATE ROUTINE **
002432 COPY Y2CCS507.
002433C *********************************************************

Check the NUM and AUTONUM settings of the editor.

With seven years' experience, why pick the Beginners and Students Forum?

At your new site, what do others make of this?

You mention "wrong offset" but then you show line-numbers. Line-numbers are not the offset.

What is the first piece of code inside "Y2CCS507"? What, when you use the actual OFFSET, for real, not a line-number, do you come up with? Offset from the abend, offset in the compile listing, what line-number does that lead you to?

Your other possibility is you are looking at the "wrong" listing. Did you check the compile date/time of the abending program against that of the one you are looking at?

Hello,

Is the offset close to what you believe it should be (i.e. only a few bytes off)? Keep in mind that many of the COBOL statements generate multiple actual instructions.

What method did you use to determine the problem instruction in the code (the system has given exactly where the problem is)?

Which abend was raised? Sometimes the abend that the system catches is caused by something earlier (i.e. walked on storage).

Suspect that you need to detemine what was the last thing the program did successfully - before the abend.

Hi,

If I use the offset to find the statement, it is close. But if I use the statement number supplied by the CEEDUMP, it is way off.

I am forcing the error by performing a move on a out of range subscript field and compiling with SSRANGE on. It gives a SOC4 at the moment.

Thanks..

A bad subscript with SSRANGE does not give a S0C4.

It may be your intention, but the bad subscript with SSRANGE is not why your program is failing. Without SSRANGE, a bad subscript may get a S0C4.

Are you making the connection between the OFFSET of the abend and the offset in the compile listing, or do you just "know" that it is the code which you put in which is causing the abend (which it isn't)?

If you are selective about the questions that you answer, you are less likely to get good answers.

Any chance at all that your message is truncated? like 2429 should be 24290? I know that's a large number, but just checking.

Hello,

Maybe i misunderstand, but if i do understand, the ssrange is to diagnose the 0c4 . . .