Using Pointers in a CICS-COBOL program

About CICS and BMS - In this Mainframe Forum - You can post your queries on CICS

Moderators: DikDude, Natarajan, Moderator Group

Post Reply
surbe
Member
Posts: 2
Joined: Sun Feb 02, 2014 11:46 pm
Location: Bangalore

Using Pointers in a CICS-COBOL program

Post by surbe » Mon Feb 03, 2014 2:01 am

Hi, My first post, rather an inquiry. and I would really appreciate a response, because this thing has me in bit of a fix actually. So seeking external help to understand this better.

so, let me give a brief idea on the program structure. I am going pseudo in order to get clarity in the limited amount of space.

ProgA (Main Program) currently receives data in memory locations of the some sizes (for input and output) and passes the pointers (to the memory) to ProgC for processing.

ProgA has two linkage section variables used for addressability.

LINKAGE SECTION.
* Data passed from caller.
* Used to establish addressability of input data;
01 LW-DUMMY-IN.
05 FILLER PIC X(1).
* Used to establish addressability of output data;
01 LW-DUMMY-OUT.
05 FILLER PIC X(1).

ProgC has two pointers and length data items in it's linkage copybook -

01 ProgC-Paramters.

LP-IN-PTR
LP-IN-PTR-LEN
LP-OUT-PTR
LP-OUT-PTR-LEN


Program FLOW:

-----------------------------------------------------------------------------------
Section 0010:
*************
So ProgA calls ProgB to get input/output sizes to be allocated, say 50/200 bytes respectively, in variables WW-IN-LEN/WW-OUT-LEN.

Section 0050:
*************
Prog A allocates the memory and assigns pointers LP-IN-PTR/LP-OUT-PTR to refer them.

Sample:
* * Get input area;
EXEC CICS GETMAIN
SET(LP-IN-PTR)
FLENGTH(WW-IN-LEN)
INITIMG(WC-HEX00)
NOHANDLE
END-EXEC

IF EIBRESP = DFHRESP(NORMAL)
THEN
SET ADDRESS OF LW-DUMMY-IN TO LP-IN-PTR
MOVE WW-IN-LEN TO LP-IN-PTR-LEN
ELSE
* * Getmain error;

Similar processing for output pointer as well.

Section 0100:
*************
ProgA receives data in memory, addressed by LW-DUMMY-IN (Which I guess refers to the first byte of the memory location pointed by LP-IN-PTR).
For instance, if ProgA receives SOAP data, then the output of the SOAP-TO-DATA parser is put received using variable - LW-DUMMY-IN upto length 50 bytes.

Section 0150:
*************
ProgA calls ProgC with the Linkage copybook in commarea.

EXEC CICS LINK
PROGRAM(ProgC)
COMMAREA(ProgC-Paramters)
NOHANDLE
END-EXEC

Section 0200:
*************
After successful call, ProgA frees the pointers allocated.

EXEC CICS FREEMAIN
DATAPOINTER(LP-IN-PTR)
NOHANDLE
END-EXEC

similar for the output pointer as well.

-----------------------------------------------------------------------------------

Now:
Aim was to introduce call to another program ProgD, which would make use of the same data stored in memory pointed by the pointers (passed by ProgA in ProgC's linkage copybook) to read some data for some interim processing. But NOT to modify anything in the memory. ONLY READ and then return back to ProgA.

So this is how i modified the program. (Please note the section number to get a sense of where in the program flow I inserted the code.)

ProgD has single pointer (as it needs to only process the input data).

01 ProgD-Paramters.

LP-PROGD-IN-PTR
LP-PROGD-IN-PTR-LEN

-------------------------------------------------------------------------------------

Section 0120:
*************

SET LP-PROGD-IN-PTR TO LP-IN-PTR

ProgA calls ProgD with ProgD-Paramters.

-------------------------------------------------------------------------------------

But here's the problem.

When i execute the program, ProgD processes the Input data properly. But ProgC processes some garbage data as input. I think i lose the pointer by doing this. Not sure how.
And at the end of the program, i get an error entry - FREEMAIN FAILED FOR DATAPOINTER(LP-IN-PTR)

Please help me with troubleshooting this issue. Let me know if you have trouble following this through. I will try and think of some way else.

Thanks in advance.
\m/ Rock On... Legacy never dies...

NicC
Active Member
Posts: 650
Joined: Sun Jul 24, 2011 5:27 pm
Location: Down on the pig farm

Post by NicC » Mon Feb 03, 2014 5:02 am

All tht and not a single mention of one of the most important bits - the PROCEDURE USING statements.
Regards
Nic

William Collins
Active Member
Posts: 732
Joined: Thu May 24, 2012 4:07 am

Post by William Collins » Mon Feb 03, 2014 12:36 pm

LP-IN-PTR has been trashed, that is clear from the freemain message (plus getting the wrong data).

You mention "call" and then show LINK, so exactly, show the code, how does control get from A to C and D?

You seem to show the use of COMMAREA for specific parameters for an individual program. If it is like that, that is not good.

surbe
Member
Posts: 2
Joined: Sun Feb 02, 2014 11:46 pm
Location: Bangalore

Post by surbe » Mon Feb 03, 2014 7:25 pm

William Collins wrote:LP-IN-PTR has been trashed, that is clear from the freemain message (plus getting the wrong data).

You mention "call" and then show LINK, so exactly, show the code, how does control get from A to C and D?

You seem to show the use of COMMAREA for specific parameters for an individual program. If it is like that, that is not good.
Hi William,

It's a LINK command, as the control has to return back to ProgA. And when i say "call", I mean ProgA invokes ProgB/C/D and then passes the control to them expecting a return. My bad, if that misled you.

I have given the code how exactly the ProgA invokes ProgC/D. I hope that's pretty clear. The question here is not about the use of COMMAREA.

You mentioned the LP-IN-PTR is trashed (i could figure that out from the RESP and RESP2 values), can you suggest something that i could do differently which would prevent this from happening?

I am trying to pass the address in pointer LP-IN-PTR to ProgD (with the new code modification) and read the input, return back to ProgA and send the address to the same memory to ProgC to be processed completely.

@Nic- again, i accept my bad. i wasn't going for the exact code here. but the idea of what's happening. Let me know if that's not getting through.
\m/ Rock On... Legacy never dies...

William Collins
Active Member
Posts: 732
Joined: Thu May 24, 2012 4:07 am

Post by William Collins » Mon Feb 03, 2014 8:59 pm

Something is changing the value of LP-IN-PTR after you have SET it, and after it has been used to SET the address for ProgD.

From what you have described, this should not happen. You don't jus "lose" a POINTER for any reason. It is not the case that "you can't just do that, because that will lose the POINTER".

So, something is changing the value in the POINTER. Perhaps it is being overwritten with something, perahps being SET to another value. This last seems less likely, as the FREEMAIN is telling you there is no current GETMAIN for that address, but perhaps it has already had a FREEMAIN elsewhere.

Was the program working before the ProdD code was added? If yes, it will be simpler to track the problem down. It will be caused, somehow, by the new code. Since it is the code, or some code if it was not working before the ProgD stuff went it, that is causing the problem, we can't do much else without seeing the code.

NicC
Active Member
Posts: 650
Joined: Sun Jul 24, 2011 5:27 pm
Location: Down on the pig farm

Post by NicC » Mon Feb 03, 2014 10:30 pm

I was asking for the PROCEDURE USING because the paramters there have to be in the same order as when calling the module and same size etc. You cannot pass a 2 byte parm followed by a 4 byte parm and code in the called program a 4 byte parm followed by a 2 byte parm. You have not shown that all these things line up and it is a common cause of problems with 'trashed' data.
Regards
Nic

Post Reply

FREE TUTORIALS

Tutorials
Free tutorials from mainframegurukul
  • JCL Tutorial
    Covers all important JCL concepts.
  • Cobol Tutorial
    This tutorials covers all Cobol Topics from STRING to COMP-3.
  • DB2 Tutorial
    DB2 Tutorial focuses on DB2 COBOL Programming.
  • SORT Tutorial
    This Tutorial covers all important aspects of DFSORT with examples
  • CICS Tutorial
    This CICS tutorial covers CICS concepts and CICS Basics, CICS COBOL Programming.
Interview
Mainframe Interview questions



Other References
Mainframe Tools and others