|
View previous topic :: View next topic
|
| Author |
Message |
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 |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| 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. |
|
| Back to top |
|
|
Jose Mateo
Active User
Joined: 29 Oct 2010
Posts: 121
Location: Puerto Rico
|
|
|
|
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. |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL
|
|
|
|
| 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. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
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. |
|
| Back to top |
|
|
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
| Code: |
CALL PROG-B USING DFHEIBLK
WS-DUMMY-DFHCOMMAREA
WS-TEST-DATA
WS-SEQ-NUM |
In PROG B, I have declared as
| Code: |
LINKAGE SECTION.
01 DFHCOMMAREA PIC X(01).
01 LS-TEST-DATA PIC X(100).
01 LS-SEQ-NUM PIC S9(5) COMP-3.
PROCEDURE DIVISION USING DFHEIBLK
WS-DUMMY-DFHCOMMAREA
LS-TEST-DATA
LS-SEQ-NUM |
|
|
| Back to top |
|
|
Binop B
Active User
Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN
|
|
|
|
| vinu78 wrote: |
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 |
Hope this link helps you with your query... |
|
| Back to top |
|
|
vinu78
Active User
Joined: 02 Oct 2008
Posts: 179
Location: India
|
|
|
|
| Thanks everybody for the inputs and suggestions. |
|
| Back to top |
|
|
|
|
