DFHCOMMAREA not picked up by called program

[awkksgovus]

In short we have this sitituation.

Main PGMA calls PGMB
PGMB (Doesn't use DFHCOMMAREA) returns to PGMA
PGMA calls PGMB (second time)
PGMB returns to PGMA
PGMA calls PGMC (uses commarea) DFHCOMMAREA (working storeage area) is correct before the call
PGMC is invoked - DFHCOMMAREA - does not contain any information that looks like it came from PGMA

The call to PGMC from PGMA looks like this:
EXEC CICS LINK
PROGRAM (PGMC)
COMMAREA (WS-PGMA-DATA)
LENGTH (WS-MAX-LENGTH)
END-EXEC.

The WS-PGMA-DATA is a total of 12000 bytes
the WS-MAX-LENGTH PIC S9(5) COMP VALUE +12000.

The EIBCALEN = 0 when it is checked in PGMC when it is called.

So... what dots am I missing or t's am I not crossing to make this work?

 

[razalas]

Please post the LINKAGE SECTION and PROCEDURE DIVISION statement for PGMC. Are you sure you are establishing addressability?

Code what you mean,
and mean what you code!
But by all means post your code!

Razalas

 

[awkksgovus]

LINKAGE SECTION.
*
01 DFHCOMMAREA.
05 FILLER PIC X(12000).

01 TWA.
05 PARMLIST PICTURE S9(8) COMP
OCCURS 6.
PROCEDURE DIVISION USING DFHEIBLK DFHCOMMAREA.
...
EXEC CICS
ADDRESS TWA(ADDRESS OF TWA)
END-EXEC.
...
IF EIBCALEN > 0
MOVE DFHCOMMAREA TO WS-COMMAREA
END-IF.

Addressability... is where I seem stuck. Using Intertest I see the transfer from one program to another.

 

[MarcLodge]

Are you able to trace programC in Intertest? Does it get into programC?

 

[awkksgovus]

It gets to PGMC... but PGMC thinks there is no DFHCOMMAREA and no LENGTH.

Using CEDF. It shows a slightly different picture than Intertest. It (PGMA) shows that it is passing nothing with a length of 0.

 

[MarcLodge]

Presumably you can see in Intertest PGMA link and when it is executed it has data and looks fine?

A couple of further questions:
Is this a new program?
Do you have other programs in the region that do similar?

 

[awkksgovus]

Correct in Intertest... it shows data for the commarea and a length.

This is an existing program. A problem that has been in one environment for more than a year that no one fixed. There are two other areas where the same code is used, including production where it works just fine.

There is one other program that seems to have the same problem that this one does (PGMC). Same conditions as the other. However we have existing programs (this drives off of a main menu program (PGMA)) that there are no such problems.

 

[MarcLodge]

OK, so we can rule out that specific CICS region as other programs that do similar work OK in it.

That leaves the program!

Have you tried re-compiling it?
Have you got the compile deck of one of the programs that works OK? If so can you compare the compile options to see if there is anything different between the options.
Can you compare the CICS definition of the tran with that program that works?
Can you compare the CICS definition of the program with that program that works?

I can't see anything wrong with your call and so am thinking that it's something slightly odd, hence my questions above.

Marc

 

[awkksgovus]

I found a solution with some help the solutions were:

The LENGTH operand of the LINK command must point to a binary HALFWORD ( i.e., a 2-byte COMP field ) NOT a FULLWORD ( i.e., a 4-byte COMP field ). Hence, your COBOL definition must be S9(4) COMP-5, not S9(5) COMP.
If you pass a 4-byte COMP field ( i.e. S9(5) COMP ), CICS only looks at the first halfword ( 2 bytes ) of the fullword, which will always be x'0000' ( zero ) for any positive value less than 65536.

The S9(4) COMP-5 worked.

As did the hard coding of;

EXEC CICS LINK
PROGRAM (PGMC)
COMMAREA (WS-PGMA-DATA)
LENGTH (+12000)
END-EXEC

Thanks for your input. It helped me to dig a littel deeper.

The follow up I will be checking is to see if object code, minus the fix (from the code that I had), compiles to the same length of what is in production. If it does not, then we are missing the source code. But that is an internal problem.

 

[MarcLodge]

Well done for sorting it out, and thanks for getting back here with the solution.

Marc