IBM Mainframe Forum

Billy,

Below are the msgs from Dump

DMW001I No listing found for ProgB.

Failing Instruction in Context:
00000000_160870AC -10 4040 4040 STH R4,64(,R4)
00000000_160870B0 -C 4040 4040 STH R4,64(,R4)
00000000_160870B4 -8 4040 4040 STH R4,64(,R4)
00000000_160870B8 -4 4040 4040 STH R4,64(,R4)
00000000_160870BC 0 4040 0000 STH R4,0
00000000_160870C0 4 0000 Invalid Opcode
00000000_160870C2 6 FFFF Invalid Opcode
00000000_160870C4 8 FFB2 Invalid Opcode


Storage around Failing Instruction
Address Offset Hex Data
1608709C -20 40404040 40404040 40404040 40404040
160870AC -10 40404040 40404040 40404040 40404040
160870BC 0 40400000 0000FFFF FFB21608 70001608
160870CC 10 70380000 00080000 00061608 7038160A

We identified the offset from this addresses and in the module map it looks like C-SECT impacted
4 V-CON | CEEBXITA $UNRESOLVED(W)

But it is the same in development also.

When looked for address 1608 in ProgB there was a move statement which is appearing in the middle of the code which is no way related to the linkage section.
Can you please advice?

e




All of this is showing you that your program has been overwritten, or that your program has branched to somewhere it shouldn't. The "Storage around Failing Instruction" would normally be showing you the other instructions. You have spaces, some low-values, some high-values and some things which look a bit like addresses.

Either your code has been overwritten with storage, or, you have branched into storage.

You may recognise from what Steve Myers said earlier. I have stated that the overwriting is more likely because it is a Cobol program. However, the x'BC' for your location from the start of the module Progb is absurdly small for a Cobol program. That displacement is probably in the intitialisation of the program.

When you can, see if you can compile the Progb with the generated pseudo-assembler.

Please don't send the information in a PM. Post it for everyone.

Just saw the listing and found the below as a warning msg in ProgB as below. Guess this would be the problem
IGYPA3013-W Data items "WS-TOKEN-TEXT-TEMP (ALPHANUMERIC REFERENCE MODIFIED ITEM)" and "WS-TOKEN-TEXT-TEMP (ALPHANUMERIC)"
had overlapping storage. An overlapping move will occur at execution time.
Any idea??

Well, that is interesting, but shouldn't be the problem.

Can you post code doing the MOVE and the code which sets up any fields used for the values of the reference modification. Plus the DATA DIVISION definitions of all the fields.

The SSRANGE should prevent reference modification stretching outside the field it is being applied to, so this shouldn't be able to garble anything else.

Above is for the MOVE statement on the warning message that was displayed in the listing

The address 160870BC in dump matches with the below MOVE stmt
MOVE WS-DATE-OUT-LEN TO
WS-TOKEN-TEXT-LEN(WS-INDEX1)
WS-TOKEN-TEXT-LEN ===> is the variable that is in the above definition of array. So I thought that the warning message is related to it.

Can you show the definition of WS-INDEX1, please? Is it an index on a table (if so show the table)?

01 WS-INDEX1 PIC S9(4) COMP. It is just as a declaration in ProgB

Yoy, that's no INDEX, it is a subscript. Name should change later, can only cause confusion.