Topic
2 replies Latest Post - ‏2012-05-29T20:32:51Z by dbzThedinosaur
SystemAdmin
SystemAdmin
403 Posts
ACCEPTED ANSWER

Pinned topic Issue in getting unique pointer address in a CICS reentrant program

‏2012-05-29T10:19:13Z |
I have a CICS-COBOL program- PROGA. This is invoked by transaction TWD1. This program is a re-entrant program (compiled using LIB,OBJECT,APOST,MAP,RENT,XREF,OFFSET,OPT, DATA(31), RMODE=ANY), linked using (LIST,XREF,RENT,RES).

The purpose of this program is to get the pointer addresses to a set of 01 level copy book variables for the application and call a COBOL –batch program passing the pointer addresses in an array. The issue we are facing is that when 2 user run the transaction(ABCD) the pointer address provided by the program is not unique, no matter where the copy books have been placed, be it in working storage or local storage.

Can you please let me know why is this happening?? Ideally we would have expected that every time the program is invoked the addresses of WS-USER-ID and WS-USER-ID-1 be different for a CICS-COBOL program which is a REENTRANT, but that is not the case here.
Below is a sample code in the program.

WORKING-STORAGE SECTION.
01 WS-USER-ID PIC X(08) VALUE SPACES.
01 WS-POINTER USAGE POINTER.

LOCAL-STORAGE SECTION.
01 WS-USER-ID-1 PIC X(08) VALUE SPACES.
01 WS-POINTER-1 USAGE POINTER.
Code present in PROGA:

SET WS-POINTER-1 TO ADDRESS OF WS-USER-ID-1.

SET WS-POINTER TO ADDRESS OF WS-USER-ID.

DISPLAY " ADDRESS OF USER ID IN WORKING STG: " WS-POINTER.
DISPLAY " ADDRESS OF USER ID IN LOCAL STG: " WS-POINTER-1.
CICS LOG

USER: XYZ
0249ABCD 20120525001955 ADDRESS OF USER ID IN WORKING STG: 0741383608
0249ABCD 20120525001955 ADDRESS OF USER ID IN LOCAL STG: 0741402808
0249ABCD 20120525001955 ***********
0249ABCD 20120525001955 ADDRESS OF 1 0741754816
0249ABCD 20120525001955 ADDRESS OF 2 0741403264
0249ABCD 20120525001955 ADDRESS OF 3 0741701072
0249ABCD 20120525001955 ADDRESS OF 4 0741704256
0249ABCD 20120525001955 ADDRESS OF 5 0741705248
0249ABCD 20120525001955 ADDRESS OF 6 0741706432
0249ABCD 20120525001955 ADDRESS OF 7 0741706808
0249ABCD 20120525001955 ADDRESS OF 8 0741707152
0249ABCD 20120525001955 ADDRESS OF 9 0741741032
0249ABCD 20120525001955 ADDRESS OF 10 0741741576
0249ABCD 20120525001955 ***********
0249ABCD 20120525001955 GETMAIN ADDRESS0741754816
0249ABCD 20120525001955 ADMIN-PARM: XYZ LOGEVENTMNEV 3270

USER: ABC
0251ABCD 20120525002258 ADDRESS OF USER ID IN WORKING STG: 0741383608
0251ABCD 20120525002258 ADDRESS OF USER ID IN LOCAL STG: 0741402808
0251ABCD 20120525002258 ***********
0251ABCD 20120525002258 ADDRESS OF 1 0741754816
0251ABCD 20120525002258 ADDRESS OF 2 0741403264
0251ABCD 20120525002258 ADDRESS OF 3 0741701072
0251ABCD 20120525002258 ADDRESS OF 4 0741704256
0251ABCD 20120525002258 ADDRESS OF 5 0741705248
0251ABCD 20120525002258 ADDRESS OF 6 0741706432
0251ABCD 20120525002258 ADDRESS OF 7 0741706808
0251ABCD 20120525002258 ADDRESS OF 8 0741707152
0251ABCD 20120525002258 ADDRESS OF 9 0741741032
0251ABCD 20120525002258 ADDRESS OF 10 0741741576
0251ABCD 20120525002258 ***********
0251ABCD 20120525002258 GETMAIN ADDRESS0741754816
0251ABCD 20120525002258 ADMIN-PARM: ABC LOGEVENTMNEV 3270
Updated on 2012-05-29T20:32:51Z at 2012-05-29T20:32:51Z by dbzThedinosaur
  • brataj
    brataj
    38 Posts
    ACCEPTED ANSWER

    Re: Issue in getting unique pointer address in a CICS reentrant program

    ‏2012-05-29T13:21:43Z  in response to SystemAdmin
    I believe this is the result of the CICS RUWAPOOL feature. It optimizes memory allocation by LE by letting a transaction reuse the allocation of a previous instance of the transaction.

    The allocation includes both the heap (working-storage) and stack (local-storage), so it's quite possible that on a not very busy system, running the transaction twice will result in the same addresses being assigned to the various data items.
  • dbzThedinosaur
    dbzThedinosaur
    57 Posts
    ACCEPTED ANSWER

    Re: Issue in getting unique pointer address in a CICS reentrant program

    ‏2012-05-29T20:32:51Z  in response to SystemAdmin
    two things that come to mind.

    1. the non-cics-precompiled program invoked by a COBOL CALL from an active cics module, does not invoke a COBOL-batch program.....
    batch is batch, cics is cics.
    though it is possible for a module executing in batch, to invoke a cics module in cics,
    a cics module can not cause a job to start in batch via a COBOL CALL.

    2. since address space is relative to a task, and not to the system, i would assume the address contained in the pointer to always be the same, unless you changed working-storage/local storage in the module, or a module in the LINK/CALL chain.

    me thinks someone suffers from a too little understanding.