PL/I

PL/I

PL/I

 View Only

PL/I coding hints and tips: Optimal use of STATIC

By Di Hu posted Mon July 11, 2022 01:59 AM

  

The Enterprise PL/I compiler issues warning messages when it sees declare statements where the STATIC attribute is used less than optimally.

For example, given:

      DCL 01 LENDER_TYPE,
           05 AUTOMATIC                      CHAR(1) INIT('A'),
            05 OPPORTUNITY                    CHAR(1) INIT('O'),
            05 NO_LENDER                      CHAR(1) INIT('N');

If the program uses only the values of the structure elements, the compiler has, for many years, recommended that INIT be changed to VALUE

With the Enterprise PL/I for z/OS 6.1 compiler, new warning messages will be issued in the following related scenarios:

1. Your code would perform much better if you changed INIT to VALUE

Many users declare a scalar variable to define a constant extent (an array bound or string length). For example, given:

       DCL ASIZE        FIXED BIN(31) STATIC INIT( 200 );
       DCL ARRAY(SIZE)  FIXED BIN(31);

If ASIZE is a constant, you should declare it instead as

       DCL ASIZE        FIXED BIN(31) VALUE( 200 );

This will produce much better code during the allocation of ARRAY and in every reference to any element of that array.

 2. Your code would perform much better if you changed INIT to NONASGN STATIC INIT

Many users have variables that appear to be constant arrays and declare them simply with INIT but not STATIC. So, for example, given:

      DCL BANKCODE(06)   PIC'999’
          INIT (012,014,019,026,027,030);

This declare will cause the compiler to generate code to initialize the array upon every entry to its containing procedure.

If these bank codes are constant, it would be much better to declare this array as

       DCL BANKCODE(06)   PIC'999’
         NONASGN STATIC INIT (012,014,019,026,027,030);

This will eliminate all the code that initializes the array (and if the array is large or if the array data type is not as simple, this code can be non-trivial).

0 comments
21 views

Permalink