z/OS Connect Enterprise Edition

z/OS Connect

z/OS Connect

Truly RESTful APIs to and from your IBM Z mainframe

 View Only
Expand all | Collapse all

COBOL Pointers and Additional 01 level at Linkage Section

  • 1.  COBOL Pointers and Additional 01 level at Linkage Section

    Posted Fri August 15, 2025 08:30 AM

    Hi,

    I have a situation that, I need to expose COBOL CICS program which has both DFHCOMMAREA and additional 01 level at Linkage section. Find below example. 

    LINKAGE SECTION.                                 

    *****************                                                                    

     01  DFHCOMMAREA.                                 

         COPY LINKCPY.                                                                                    

     01  RETURN-AREA            PIC X(32000).  

    In this scenario, the actual response is written to RETURN-AREA any idea how do we include additional variables in API service descriptor? 

    I cannot include RETURN-AREA in the existing DFHCOMMAREA as it will impact the program behavior and also exceeds the maximum capacity of Commarea i.e.32K.

    Please note, copybook LINKCPY has couple of pointer definition, I don't think zOS supports pointers. So i replaced pointers with with dummy variables (to match commarea exact length), unfortunately program is failing with ASRA error i.e. S0C4 error.
    How do I handle above explained scenarios (Pointers in Copybook and Additional 01 level at Linkage section) ? 
    I have included sample Copybook screen capture.
    We are running zoS connect 2.0.


    ------------------------------
    Tamilarasan Pushparaj
    ------------------------------


  • 2.  RE: COBOL Pointers and Additional 01 level at Linkage Section

    Posted Tue August 19, 2025 06:26 PM

    Here's a case where using CICS channels and containers would be beneficial. Passing pointers in the Commarea should only be done when the program that you are LINKing to runs in the same region as the calling program. Otherwise the pointer in region 1 (the region when a calling program is running) is not the address of the data that you want to pass. If you try this, you're setting yourself up for storage violations. And since the calling program is z/OS Connect, it can't get valid address pointers to send in the Commarea.

    The design I would recommend would be to design a wrapper program whose inputs are a set of containers. One container would hold the data associated with LINK-POINTER1, a second would hold the data associated with LINK-POINTER-2, and a third would hold the data from the remainder of the Commarea. Once the wrapper program has been invoked, it will issue start putting data into the original DFHCOMMAREA copybook. Issue a GET CONTAINER to access the data from the first container and place the address of this area in the LINK-POINTER1 variable. Do the same with the data in the second container. You can use GET CONTAINER to populate the rest of the DFHCOMMAREA structure. Now LINK to the original program passing the COMMAREA. Upon return from that program, create a new container from the response data by issuing PUT CONTAINER to the same CHANNEL that was received from z/OS Connect. Upon RETURN, the new container will be passed to z/OS Connect and the data from that container will be used to construct the API response.



    ------------------------------
    Leigh Compton
    Consulting IT Specialist - CICS and Enterprise Integration
    IBM
    ------------------------------