Data not getting passed from sub pgm to main pgm

Bill Woodger · Posted: Tue Mar 05, 2013 6:17 am

Are you showing the PROCEDURE DIVISION USING ... from the source programs or the compile listings? Can you check the listings please?

vinu78 · Active User Joined: 02 Oct 2008 Posts: 179 Location: India

Bill,

Please see the PROCEDURE DIVISION USING that is used in the modules

PROGRAM A

Jose Mateo · Posted: Tue Mar 05, 2013 7:49 pm

Good day to all!

Vinu78, make your WS-TEST-DATA a LINKAGE SECTION variable in PROG A. Remember that WORKING-STORAGE variable could be pass to PROG B but if PROG B manipulate those variable it is done in B and not in A. I am confuse why are you using WS-DUMMY-DFHCOMMAREA I some cases then DFHCOMMAREA in others.

Bill Woodger · Posted: Tue Mar 05, 2013 8:49 pm

Jose,

If the PROGA field is in Linkage, where does the storage for it come from?

What do you mean if the manipulations are done in PROGB it only affects PROGB, not PROGA?

The "name" of something does not matter. It is that USINGS "line up" with the data that is being expected.

Vinu78,

How do you get ????? for the DISPLAY of the packed-decimal? Is this output from a DISPLAY, or from a debugger or something?

vinu78 · Active User Joined: 02 Oct 2008 Posts: 179 Location: India

Bill,

I got ???? from Expeditor (online debugger since it is executed online).

I am getting the values to WS-TEST-DATA through MQ queue in PROG A and once these variables has the value, we are calling PROG B for re-formatting and writing to online VSAM file. So WS-TEST-DATA is declared in Working storage section in PROG A (and not in Linkage section as we don't have to). However it is declared in Linkage section (as LS-) as well as in Work storage section in PROG B, since the values are passed from PROG A.

Interesting thing is, if I am passing the Sequence number separately as WS-SEQ-NO as one one of the calling parameter (apart from WS-TEST-DATA) from PROG A to PROG B, and then increment the Seq number value in PROG B, this new Seq value stays intact even if the control comes back to PROG A.
I am not sure what is happening behind the scenes.

Thanks
Vinu

Thanks
Chidam

Robert Sample · Posted: Tue Mar 05, 2013 9:13 pm

To expand upon Bill's comment, the USING phrases must line up, and the type of call (BY REFERENCE, BY CONTENT, BY VALUE) can impact the results especially when passing data back from the calling program.

Jose Mateo · Posted: Tue Mar 05, 2013 9:39 pm

Bill,
From what I see is that WS-TEST-DATA is defined as a WORKING-STORAGE variable in PROG A which is been pass to PROG B by a call and it is defined in a LINKAGE SECTION in PROG B. In PROG B it calculates a sequence number which is part of WS-TEST-DATA but because there's no linkage storage between PROG A and PROG B, PROG A doesn't have the modified sequence number from PROG B.

Akatsukami · Posted: Tue Mar 05, 2013 10:07 pm

But the linkage section does not include those variables that are defined (and for which storage is allocated) in the module, correct? So no linkage section ought to be included in program A, only the variable definitions; if the arguments are passed by reference, the variables will be updated by activity in program B.

Bill Woodger · Posted: Tue Mar 05, 2013 10:25 pm

Vinu,

Can you post the compile options of the modules, separately if they are different.

What is the actual output from the DISPLAY in PROGA after the CALL to PROGB (regardless of what you get from the debugger).

Can you also include your CICS version, MQ version.

vinu78 · Active User Joined: 02 Oct 2008 Posts: 179 Location: India

I am thinking whether DFHCOMMAREA and DFHEIBLK plays the role here.
Whether we need to have DFHCOMMAREA and DFHEIBLK to be declared in PROG-B ? Because if we declare something like this in PROG-A, we are not losing the value from WS-SEQ-NO once the control comes back from PROG B to A

Binop B · Posted: Tue Mar 05, 2013 10:43 pm

vinu78 · Active User Joined: 02 Oct 2008 Posts: 179 Location: India

Thanks everybody for the inputs and suggestions.