|
View previous topic :: View next topic
|
| Author |
Message |
Taimoor.Naviwala
New User
Joined: 22 Nov 2006
Posts: 4
Location: Richmond, VA, US
|
|
|
|
Hi,
I am running code similar to below
---Program A---
Working Storage
01 WS-CONSTANT PIC XX VALUE SPACES.
01 WS-COMMAREA
...
Linkage Section
------
Procedure DIVISION
MOVE 'XX' TO WS-CONSTANT
EXEC CICS LINK PROGRAM-B
DISPLAY WS-CONSTANT
The display shows WS-CONSTANT as spaces. While I know that the working storage of Program B will get reinitialized after return, I did not expect the same of the working storage of Program A.
It works fine if I substitue the EXEC CICS LINK with a CALL. But since I have multiple programs calling Program B, I would prefer to stay with LINK
What am I missing ? |
|
| Back to top |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
If you want anything like a clear answer, you'll have to explain much more clearly.
Paste all the revelent code from the two programs. Use the Code tags and the Preview butto. |
|
| Back to top |
|
|
Taimoor.Naviwala
New User
Joined: 22 Nov 2006
Posts: 4
Location: Richmond, VA, US
|
|
|
|
Ok I am new to this, so here goes a (hopefully) better attempt at explaining my situation.
| Code: |
IDENTIFICATION DIVISION.
PROGRAM-ID.
PROGRAMA.
AUTHOR.
TAIMOOR NAVIWALA
DATE-WRITTEN.
JULY 2010.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-CONSTANTS.
05 WS-TRANSID PIC X(4) VALUE 'ABCD'.
01 TRANSACTION-RECORD-KEY-1 PIC X(10).
01 TRANSACTION-RECORD-KEY-2 PIC X(10).
01 WS-RECORD-LEN-1 PIC S9(4) COMP.
LINKAGE SECTION.
01 DFHCOMMAREA PIC X(1800).
PROCEDURE DIVISION
0000-START.
..
..
..
PERFORM 0100-PROCESS-REQUEST.
..
..
..
0100-PROCESS-REQUEST.
MOVE 'ABCDEFGHIJ' TO TRANSACTION-RECORD-KEY-1
TRANSACTION-RECORD-KEY-2
MOVE LENGTH OF TRANSACTION-RECORD-KEY-1 TO
WS-RECORD-LEN-1.
DISPLAY 'TRAN REC BEF ' TRANSACTION-RECORD-KEY-1
TRANSACTION-RECORD-KEY-2 WS-TRANSID.
EXEC CICS LINK PROGRAM ('PROGRAM2')
COMMAREA (TRANSACTION-RECORD-KEY-1)
LENGTH (WS-RECORD-LEN-1)
RESP (WS-RESP-CODE)
END-EXEC.
DISPLAY 'TRAN REC AFT' TRANSACTION-RECORD-KEY-1
TRANSACTION-RECORD-KEY-2 WS-TRANSID.
....
...
....
|
The above is representative code, Post the EXEC CICS LINK execution all the working storage variables of PROGRAMA are being reinitiatlized.
ProgramB does not have any 'funny code' which could address the working sotrage of ProgramA, It is a straightforward CICS program, with only some basic stuff going on. It gets some data from a database and is meant to be a common data access module.
Program A is the first or initial program for transaction ABCD.
I searched through a lot of material and while I already know that If I LINK to ProgramB for a second time then working storage in ProgramB will be reinitialized, what I did not find explicitly mentioned anywhere is that the working storage of ProgramA will also be reinitialized on return from ProgramB.
I also did not find any reference to any transaction or program level CICS parameter, or any compile or link parameter that would affect the working storage of the calling program.
Hope this is clearer.
Not pasting any code from ProgramB coz I don't think anything there could influence this. To return to ProgramA, ProgramB does a simple
EXEC CICS RETURN
without any parameters, So I understand that there would be probably not be any data in the COMMAREA for ProgramA on return. But I would have thought the working storage of ProgramA would remain intact.
As I mentioned, earlier, ProgramB does not do any addressing of programA's storage apart from the standard commarea addressing. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Quote: |
| the working storage of ProgramA will also be reinitialized on return from ProgramB |
as long as we have to deal with this kind of ignorance,
this thread is going nowhere. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
PM from TS to me:
| Quote: |
While I understand that this may seem very basic to you, I did search a lot, and as I said nowhere is it explicitly said that a new copy of working storage is allocated for the linking program on return from the linked to program.
I have gone through most of the IBM documentation around this over the past day or two of searching as well as several forums including this one.
If there is any documentation that says this, I have missed it, so if you could point me to it, it would be great. |
Maybe there is a language barrier.
1. the only time working-storage is re-initialized by the ops-sys
is during repeated CALLs, Links, of the sub-module.
never, never, never is the CALLing/LINKing module modified by the ops-sys upon return form a CALL/LINK. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
| You should post PROGRAM2 (or PROGRAMB) as it might be altering data that you're attempting to DISPLAY before and after the LINK API. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello and welcome to the forum,
You need to post "real" code (using copy/paste and the Code tag) not something you call "representative code".
You also need to post the relevant pgmB code (again copy/paste).
| Quote: |
| Not pasting any code from ProgramB coz I don't think anything there could influence this. |
As your process is not working correctly, you need to post whatever info is requested.
Use the Preview function to see your post as it will appear to the forum. When it appears as you want, Submit. |
|
| Back to top |
|
|
Peter cobolskolan
Active User
Joined: 06 Feb 2012
Posts: 104
Location: Sweden
|
|
|
|
- Why is there a DFHCOMMAREA in Program A ?
- The only data from Program A that Program B could access is the TRANSACTION-RECORD-KEY-1, only 10 bytes. You dont have to supply the length in the LINK-command, that is taken care of by the translator.
If ProgramB "thinks" is has more storage than the 10 bytes, which is the DFHCOMMAREA in ProgramB, you will have problems!
You say 'I don't think anything there could influence this' is probably wrong as the program doesnt work as expected.
Also, no Working-Storage is ever never reinitialized in ProgramA.
Post the real code that you were asked to, and we will tell you whats wrong. |
|
| Back to top |
|
|
Taimoor.Naviwala
New User
Joined: 22 Nov 2006
Posts: 4
Location: Richmond, VA, US
|
|
|
|
The problem was with the COMMAREA. The area passed to PROGRAMB as Commarea was smaller than the COMMAREA defined in PROGRAMB.
On return all the variables in the working storage of program A, after the data area passed to program B were overwritten with spaces.
It works if you keep the COMMAREA in B the exact length of the data area passed as COMMAREA from Program A. |
|
| Back to top |
|
|
Peter cobolskolan
Active User
Joined: 06 Feb 2012
Posts: 104
Location: Sweden
|
|
|
|
Fine, that was what I thought.
Still question about why you have defined the DFHCOMMAREA in Program A?
I think it was done because you hadn´t read the manual, and just "thought" it had to be there.
Real programmers read the manual(s)!! |
|
| Back to top |
|
|
Taimoor.Naviwala
New User
Joined: 22 Nov 2006
Posts: 4
Location: Richmond, VA, US
|
|
|
|
| Program A is triggered from other transactions, Hence the COMMAREA there. Also in the actual code it stores data in between invokations of Program A in a Pseudoconversational mode. |
|
| Back to top |
|
|
Peter cobolskolan
Active User
Joined: 06 Feb 2012
Posts: 104
Location: Sweden
|
|
|
|
Fine, the code you showed us was not the real code ?
Next time it would probably be easier for all of us if you post the real code. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Yup,
"Representative code" us usually no help in debugging. It may be ok for talking about some approach, but when something is not working, it is basically useless. . .
d |
|
| Back to top |
|
|
|
|
