Binary fields being corrupted in linkage

Flasharino · New User Joined: 12 Sep 2008 Posts: 8 Location: USA

I have been in the business for over 20 years and this one is new to me.

I am testing a new enhancement to our large mainframe system and everything has been going fine. We recently migrated our code to a new CICS region for the business team to do their QA testing. All of a sudden we get an 0C4 storage violation ABEND. According to the Abend-Aid dump two fields that are being passed to a called program have garbage in them. They are defined as PIC S9(4) COMP. They should have had values of 1 and 0 in them but what I see in the dump taken while in the called program is x'40414040' (the 2 fields are adjacent to one another).

So then I recompile the program with Expediter to see what is going on and it works perfectly. Just as it always has. I figure that I picked up something different when I recompiled or something, so I recompiled without XPED again. Two days later the same thing happens. This time I call in a couple teammates to get some new eyes, but they don't see anything I don't see. Once again when the program is put back in a non-XPED state is STILL works.

I have a feeling that it is going to keep happening this way till I can work out the problem. We don't see any issues with the code. I compared the compile options between our Expediter and non-Exped jobs and the only difference is that the Exped compile has NOOPTOMIZE vs. OPTOMIZE for the regular.

Can anyone help me Thanks.

Bill O'Boyle

What's really strange is that if you "OR" either one of these halfwords with a X'F0F0' mask, you get the equivalent of X'0000' (X'F0F0') and X'0001' (X'F0F1') in display-numeric format and you're expecting X'0000' and X'0001' in these halfwords.

What's your TRUNC compiler option set to (BIN, STD or OPT) or are these halfwords defined as COMP-5 (Native Binary), which overrides any TRUNC compiler setting? Minimum COBOL version/release for COMP-5 support was OS/390 2.2.1 and any version/release of Enterprise COBOL.

Could this be a clue?

Just a SWAG....

Regards,

Bill

Flasharino · New User Joined: 12 Sep 2008 Posts: 8 Location: USA

Thanks for the reply Bill. To answer your question, the TRUNC(BIN), but as I pointed out that it true all the time - either XPED or not.

Also - IBM Enterprise COBOL for z/OS 3.4.1

CICS Guy · Posted: Fri Sep 12, 2008 10:56 pm Post subject:

Optomize does remove code that the compiler assumes will never execute.
Does the program initialize the fields to zero at some point and then later set the one to one?
Can you put a display in the code whare the fields are initialized and/or set and run it both ways?

Flasharino · New User Joined: 12 Sep 2008 Posts: 8 Location: USA

I am pretty cinfident that the fields are fine when they are initialized. A few lines after that values are moved into them from two counters. The problem seems to come in the program that is then called using these fields as part of the passed linkage data.

How can you put displays in CICS programs??

CICS Guy · Posted: Fri Sep 12, 2008 11:52 pm Post subject:

Flasharino · New User Joined: 12 Sep 2008 Posts: 8 Location: USA

I think I have tried that before and it didn't work here. Is that an option that CICS can turn on of off?

Earl Haigh · Active User Joined: 25 Jul 2006 Posts: 209

How can you put displays in CICS programs??

try EXEC CICS WRITE OPERATOR

or

write to the CEEOUT TDO <-- ask your Systems Programmer.

The problem seems to come in the program that is then called using these fields as part of the passed linkage data.

Since you indicate these are S9(4) COMP // halfword 2 bytes.

make sure the called program has storage definitions with correct
storage alignment.

Bill O'Boyle

Use of the DISPLAY VERB in CICS/COBOL comes under control of LE and message are routed to TDQ "CESE" and is perfectly legal to use in CICS.

Optionally, LE Callable Service routine "CEEMOUT" can also be used as a substitute in CICS.

Regards,

Bill

Flasharino · New User Joined: 12 Sep 2008 Posts: 8 Location: USA

Doesn't it swap out the entire TCB when you do a DISPLAY in CICS??

Robert Sample · Posted: Thu Sep 18, 2008 12:21 am Post subject:

Flasharino, I've seen a few of these subtle abends when there's a linkage section (i.e., COMMAREA) mismatch -- frequently due to a copybook problem. The storage violation occurred because the CICS trailer identity block on a chunk of memory had 6 bytes overlaid with application data due to a program not recompiled with the new copybook definition and using the old linkage section length.

Bill O'Boyle · Posted: Thu Sep 18, 2008 1:34 am Post subject:

Flasharino asked "Doesn't it swap out the entire TCB when you do a DISPLAY in CICS??"

I'm assume you're referring to the QR? If there was any giving up of control by the QR (EIP), it would mimic that of a WRITEQ TD QUEUE API.

No, LE is in control of serially operating the TDQ "PUTS" and perhaps (under the covers), DISPLAY in CICS uses CEEMOUT, but that would be a SWAG on my part

But, if you're not on OS/VS COBOL, all should be fine.

IIRC, it will even work with COBOL2 but, the key is LE is a run-environment requirement, which is true (and builtin) on all current HLL compilers.

Regards,

Bill

Flasharino · New User Joined: 12 Sep 2008 Posts: 8 Location: USA

Thanks for all the input.

One last question. How would I look at the contents of the TDQ "CESE" after writing to it? Is that using CECI?

Thanks.

Earl Haigh · Active User Joined: 25 Jul 2006 Posts: 209

One last question. How would I look at the contents of the TDQ "CESE" after writing to it? Is that using CECI?

ASK YOUR CICS SYSTEMS PROGRAMMER !

Flasharino · New User Joined: 12 Sep 2008 Posts: 8 Location: USA