COBOL

COBOL

COBOL

COBOL is responsible for the efficient, reliable, secure, and unseen day-to-day operations of the world's economy.

 View Only
Expand all | Collapse all

COBOL WORKING-STORAGE reloaded at ENTRY statement

  • 1.  COBOL WORKING-STORAGE reloaded at ENTRY statement

    Posted Tue June 01, 2021 02:43 PM
    I have a COBOL program which has a table in the WORKING-STORAGE which is updated within the same program. The program also has an ENTRY statement . Everytime another program calls the program by the ENTRY name, the table in WORKING-is presented in it's initial state instead of the updated one. I have also tried the REUS linkedit parm but no change.

    ------------------------------
    Ron Mascarenhas
    ------------------------------


  • 2.  RE: COBOL WORKING-STORAGE reloaded at ENTRY statement

    Posted Tue June 01, 2021 03:44 PM
    Hi Ron,
    The program needs to be compiled and bound RENT so you get the same working-storage image each time a call is made.  And of course don't use the IS INITIAL phrase, because that will refresh working-storage items with a VALUE clause each time you enter the program.
    Bernie

    ------------------------------
    Bernie Rataj
    Senior Software Developer
    IBM Canada Ltd.
    Canada
    https://www.ibm.com/marketplace/ibm-compilers
    ------------------------------



  • 3.  RE: COBOL WORKING-STORAGE reloaded at ENTRY statement

    Posted Thu June 03, 2021 12:38 PM
    Hi Bernie,

    I have the COBOL compile with RENT and the Linkedit with RENT, but still the Working-Storage has the initial values  at the ENTRY statement.
    Here are the snippets of a sample program which also has this issue.

    Compile options

    RENT
    RMODE(AUTO)
    CBL DATA(31),RENT

    Program

    000001 ID DIVISION.
    000002 PROGRAM-ID. SFSMAIN.
    000003 ENVIRONMENT DIVISION.
    000004 CONFIGURATION SECTION.
    000005 SOURCE-COMPUTER. IBM-Z13.
    000006 INPUT-OUTPUT SECTION.
    000007 DATA DIVISION.
    000008 FILE SECTION.
    000009 WORKING-STORAGE SECTION.
    000010 01 CALL-SWITCH PIC X(7) VALUE 'INITIAL'.
    000011 PROCEDURE DIVISION.
    000012 MOVE 'FIRST ' TO CALL-SWITCH.
    000013 DISPLAY 'CALL SWITCH ON MAIN CALL=' CALL-SWITCH.
    000014 EXIT PROGRAM.
    000015 ENTRY 'SFSALIAS'
    000016 DISPLAY 'CALL SWITCH ON ENTRY CALL =' CALL-SWITCH.
    000017 EXIT PROGRAM.

    In the above program I am expecting the CALL-SWITCH at the ENTRY statement to show 'FIRST' but it always shows INITIAL


    LINKEDIT OPTIONS

    1z/OS V2 R2 BINDER 18:45:54 THURSDAY JUNE 3, 2021
    BATCH EMULATOR JOB(TSDJIMS1) STEP( ) PGM= IEWL
    IEW2278I B352 INVOCATION PARAMETERS - XREF,LET,LIST,MAP,RENT
    IEW2322I 1220 1 INCLUDE SYSLMOD(SFSMAIN)
    IEW2322I 1220 2 ENTRY SFSMAIN
    IEW2322I 1220 3 ALIAS SFSALIAS
    IEW2322I 1220 4 NAME SFSMAIN(R)

    1SAVE MODULE ATTRIBUTES:

    AC 000
    AMODE 31
    REFR NO
    RENT YES
    REUS YES
    RMODE ANY
    1 ENTRY POINT AND ALIAS SUMMARY:

    NAME: ENTRY TYPE AMODE C_OFFSET CLASS NAME STATUS

    SFSMAIN MAIN_EP 31 00000000 B_TEXT
    SFSALIAS ALTERNATE 31 000003A4 B_TEXT ADDED


    ------------------------------
    Ron Mascarenhas
    ------------------------------



  • 4.  RE: COBOL WORKING-STORAGE reloaded at ENTRY statement

    Posted Thu June 03, 2021 02:49 PM
    Hi Ron,

    I don't know whether I forgot or never really knew, but I was mistaken about this situation with regard to dynamic calls to primary and secondary entry points. If you dynamically call both the primary and secondary entry points, you in effect get two instances of the module, including working-storage, which is why you see the call-switch showing INITIAL both times. SFSMAIN shows with a system use count of 2 as a result of the calls and the RENT bind.

    If you really want a single instance working-storage along with dynamic linkage and multiple entry points, you need to build and call the module as a DLL. This can be done with some workarounds in COBOL 4.2, but is relatively straight forward in COBOL 6.2 and onwards with the >>CALLINTERFACE directive.

    Bernie

    This documentation could be improved...

    Calling alternate entry points
    https://www.ibm.com/docs/en/cobol-zos/6.3?topic=pointers-calling-alternate-entry-points

    Dynamic calls to alternate entry points require the following elements:

    * Either explicitly specified NAME or ALIAS binder (linkage-editor)
    control statements, or use of the NAME compiler option which generates
    them automatically.

    * An intervening CANCEL for any dynamic call to the same module at a
    different entry point. CANCEL causes the program to be invoked in
    initial state when it is called at a new entry point.

    ------------------------------
    Bernie Rataj
    Senior Software Developer
    IBM Canada Ltd.
    Markham ON Canada
    https://www.ibm.com/marketplace/ibm-compilers
    ------------------------------



  • 5.  RE: COBOL WORKING-STORAGE reloaded at ENTRY statement

    Posted Thu June 03, 2021 03:07 PM
    Ron,

    Reentrant programs maintain a CSECT with the program statements and a separate DSECT for each simultaneous invocation of that program which has a copy of all non static variables.   This way CICS needs only one copy of a program's executable statements, but many modules can LINK to it and maintain their own unique variable values in separate DSECTs.

    For your example, you need to put CALL-SWITCH in the linkage section, and then add a USING CALL-SWITCH to the PROCEDURE DIVISON and the ENTRY SFSALIAS statements.  That way when you invoke either SFSMAIN or SFSALIAS the value you set can be preserved across multiple invocations.  

    I think a better solution the original problem might be to use EXTERNAL variable definitions.  







    ------------------------------
    Jon Butler
    ------------------------------



  • 6.  RE: COBOL WORKING-STORAGE reloaded at ENTRY statement

    Posted Wed June 02, 2021 07:57 AM
    To prevent re-initalization of Working Storage, you need to make your program reentrant by using the compiler option RENT.  You probably also want to LinkEdit (now the z/OS BIND) with the RENT option if there are subroutines called by your module that have also been compiled with RENT.  BTW, the use of RENT is mandatory for CICS, IMS, and Db2 Stored Procedures.

    ------------------------------
    Jon Butler
    ------------------------------



  • 7.  RE: COBOL WORKING-STORAGE reloaded at ENTRY statement

    Posted Fri July 16, 2021 12:54 PM
    Sorry for the late reply. Thanks for Bernie and John for the help.

    Just to summarise the issue with the call to the ENTRY

    1. Using RENT at compile and link did not work.
    2. Static calls did not work
    3. DLL interface is not an option here


    Finally I took John's  suggestion for an EXTERNAL area and this works fine under all conditions.

    Ron

    ------------------------------
    Ron Mascarenhas
    ------------------------------



  • 8.  RE: COBOL WORKING-STORAGE reloaded at ENTRY statement

    Posted Fri July 16, 2021 01:59 PM
    I hit upon this from my old days using COMMMON storage in FORTRAN.  It took COBOL 30 years to come up with EXTERNAL storage, but it works!!!

    ------------------------------
    Jon Butler
    ------------------------------



  • 9.  RE: COBOL WORKING-STORAGE reloaded at ENTRY statement

    Posted Mon July 19, 2021 04:41 PM
    This is something I've run in to before, and EXTERNAL was the solution.  But I wasn't totally happy with it.  It would be nice if COBOL had some sort of "module" or "package" unit that would share storage between routines within the unit, but not share them outside of it.  I imagine something like the following:

     ID DIVISION.                                           
     MODULE-ID. SFSMAIN.                                    
                                                            
     DATA DIVISION.                                         
     WORKING-STORAGE SECTION.                               
     01  CALL-SWITCH PIC X(7) VALUE 'INITIAL'.              
     PROCEDURE DIVISION.                                    
                                                            
     ID DIVISION.                                           
     PROGRAM-ID. SFSMAIN.                                   
     PROCEDURE DIVISION.                                    
         MOVE 'FIRST ' TO CALL-SWITCH.                      
         DISPLAY 'CALL SWITCH ON MAIN CALL=' CALL-SWITCH.   
         GOBACK.                                            
     END PROGRAM SFSMAIN.                                   
                                                            
     ID DIVISION.                                           
     PROGRAM-ID. SFSALIAS.                                  
     PROCEDURE DIVISION.                                    
         DISPLAY 'CALL SWITCH ON ENTRY CALL =' CALL-SWITCH. 
         GOBACK.                                            
     END PROGRAM SFSALIAS.                                  
                                                            
     END MODULE SFSMAIN.                                    ​

    The "module" working-storage would be shared between all programs contained within the module, but could not be accessed outside of the module (unless declared EXTERNAL, of course).

    Thoughts?  Not sure the business case is important enough for IBM to spend any resources on it, but figured I'd put it out there.

    ------------------------------
    Frank Swarbrick
    ------------------------------



  • 10.  RE: COBOL WORKING-STORAGE reloaded at ENTRY statement

    Posted Tue July 20, 2021 08:10 AM
    Frank,

    I believe GLOBAL variables may be what you are looking for.  They can only be used on level-1 variables, but I have not found that to be a problem. 

    GLOBAL variables can be used in Working- or Local-Storage, the Linkage Section, and the File Section, and they are now used by CICS for some of its variables.

    ------------------------------
    Jon Butler
    ------------------------------



  • 11.  RE: COBOL WORKING-STORAGE reloaded at ENTRY statement

    Posted Tue July 20, 2021 11:29 AM
    Jon,
    Defining an item as GLOBAL simply makes it visible to nested programs in the compile unit, and a secondary/alternate entry isn't a nested program.
    Bernie

    ------------------------------
    Bernie Rataj
    Senior Software Developer
    IBM Canada Ltd.
    Markham ON Canada
    https://www.ibm.com/marketplace/ibm-compilers
    ------------------------------