LSACHECK

Use the LSACHECK option (LSACHECK is short for Linkage Section Addressability Check) to prevent inadvertent use of LINKAGE-SECTION data items prior to establishing addressability.

The LSACHECK compiler option tells the compiler to generate code to initialize BLL cells (addresses for LINKAGE-SECTION data items) to x'7FFF000' instead of the previous default of x'00000000'. With NOLSACHECK the BLL cells will still be initialized to x'00000000'.

This particular address is for a page in the z/OS system that has no storage backing it, so that any references to this page will result in an 0C4 ABEND. Using LSACHECK would result in 0C4 ABENDs for any references data items whose addresses have not been set explicitly in program or via input parameters.

LSACHECK option syntax

Default is: NOLSACHECK

Abbreviations are: LSAC | NOLSAC

The most common way to have LINKAGE SECTION data items that do not have addressability is when they are not referenced in a PROCEDURE DIVISION USING statement, like this example:

LINKAGE SECTION.                                                           
      01 LINKAGE-ITEM PIC C(100).                                              
                                                                               
    PROCEDURE DIVISION.       *> LINKAGE-ITEM will not get any                 
                              *> address from a CALLing program

There are several ways that a program can set addressability of Linkage Section data items. One is including them in PROCEDURE DIVISION USING phrase, but here are some other ways as well:

    LINKAGE SECTION.                                                           
      01 LINKAGE-ITEM PIC C(100).                                              
                                                                               
    PROCEDURE DIVISION USING LINKAGE-ITEM.  *> LINKAGE-ITEM will               
                               *> get the address from the USING               
                               *> phrase of the CALL statement                 
                               *> of the CALLing program                       
                                                                               
      *> NOTE: If a program is called with no USING phrase, the                
      *>       address will be changed and will not have the LSACHECK value.               
      *>       Our testing showed a different ABEND from the LSACHECK
      *>       ABEND.                                      
                                                                               
      *> In the following example, the BLL for LINKAGE-ITEM will               
      *> be set to the value in Pointer-1                                      
                                                                               
        SET ADDRESS OF LINKAGE-ITEM To Pointer-1                               
                                                                               
      *> In the following example, the BLL for LINKAGE-ITEM will               
      *> be set to the address of Working-Storage-Item                         
                                                                               
        SET ADDRESS OF LINKAGE-ITEM To                                         
                                ADDRESS OF Working-Storage-item                
                                                                               
      *> In the following example, the BLL for LINKAGE-ITEM will               
      *> be set to the address of the storage acquired by the                  
      *> ALLOCATE statement       
        ALLOCATE LINKAGE-ITEM

Performance implications

LSACHECK will not affect the resulting program performance as there is no extra processing for programs that are compiled with LSACHECK.

AMODE 64 implications

For programs compiled with LSACHECK and LP(64), the compiler generates code to initialize the BLLs to x'000000007FFFF000' to get similar behavior to LP(32) programs with BLLs set to x'7FFFF000'.

Note: Since there is already a way to get a report of uses of zero addresses without an ABEND or stoppage of the application (the z/OS "Zero Address Detection" feature), there is no need to duplicate that feature with an MSG suboption like some other compiler options have.