IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Working Storage of calling program when using EXEC CICS LINK


IBM Mainframe Forums -> CICS
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Taimoor.Naviwala

New User


Joined: 22 Nov 2006
Posts: 4
Location: Richmond, VA, US

PostPosted: Mon Jul 16, 2012 6:17 pm
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Mon Jul 16, 2012 6:21 pm
Reply with quote

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
View user's profile Send private message
Taimoor.Naviwala

New User


Joined: 22 Nov 2006
Posts: 4
Location: Richmond, VA, US

PostPosted: Mon Jul 16, 2012 8:12 pm
Reply with quote

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
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Mon Jul 16, 2012 8:34 pm
Reply with quote

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
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Mon Jul 16, 2012 8:52 pm
Reply with quote

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
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Mon Jul 16, 2012 8:58 pm
Reply with quote

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
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Mon Jul 16, 2012 9:00 pm
Reply with quote

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
View user's profile Send private message
Peter cobolskolan

Active User


Joined: 06 Feb 2012
Posts: 104
Location: Sweden

PostPosted: Mon Jul 16, 2012 9:10 pm
Reply with quote

- 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
View user's profile Send private message
Taimoor.Naviwala

New User


Joined: 22 Nov 2006
Posts: 4
Location: Richmond, VA, US

PostPosted: Tue Jul 17, 2012 2:20 pm
Reply with quote

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
View user's profile Send private message
Peter cobolskolan

Active User


Joined: 06 Feb 2012
Posts: 104
Location: Sweden

PostPosted: Tue Jul 17, 2012 3:18 pm
Reply with quote

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
View user's profile Send private message
Taimoor.Naviwala

New User


Joined: 22 Nov 2006
Posts: 4
Location: Richmond, VA, US

PostPosted: Tue Jul 17, 2012 3:26 pm
Reply with quote

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
View user's profile Send private message
Peter cobolskolan

Active User


Joined: 06 Feb 2012
Posts: 104
Location: Sweden

PostPosted: Tue Jul 17, 2012 3:40 pm
Reply with quote

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
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Wed Jul 18, 2012 6:06 am
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> CICS

 


Similar Topics
Topic Forum Replies
No new posts Using API Gateway from CICS program CICS 0
No new posts CLIST - Virtual storage allocation error CLIST & REXX 5
No new posts Calling DFSORT from Cobol, using OUTF... DFSORT/ICETOOL 5
No new posts Calling Java method from batch COBOL ... COBOL Programming 5
No new posts Calling an Open C library function in... CICS 1
Search our Forums:

Back to Top