Posted: Mon Feb 03, 2014 2:01 am Post subject: Using Pointers in a CICS-COBOL program
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.
* Data passed from caller.
* Used to establish addressability of input data;
05 FILLER PIC X(1).
* Used to establish addressability of output data;
05 FILLER PIC X(1).
ProgC has two pointers and length data items in it's linkage copybook -
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.
Prog A allocates the memory and assigns pointers LP-IN-PTR/LP-OUT-PTR to refer them.
IF EIBRESP = DFHRESP(NORMAL)
SET ADDRESS OF LW-DUMMY-IN TO LP-IN-PTR
MOVE WW-IN-LEN TO LP-IN-PTR-LEN
* * Getmain error;
Similar processing for output pointer as well.
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.
ProgA calls ProgC with the Linkage copybook in commarea.
EXEC CICS LINK
After successful call, ProgA frees the pointers allocated.
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).
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...
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.
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...
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.
Joined: 24 Jul 2011 Posts: 651 Location: Down on the pig farm
Posted: Mon Feb 03, 2014 10:30 pm Post subject:
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
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum