Enhancement to the INITCHECK option to find all possible “used without being initialized” fields.

As mentioned in the previous comment, this RFE has been delivered.

Delivered.
https://www.ibm.com/support/pages/apar/PH24413

This RFE is being accepted and will be updated further once put into plan.

Hi, in regards to this RFE, we could handle general cases, but certain things won't work eg table initialisation, pointers. Is that ok?

Hello.. The client who requested this RFT.. asked me to request this RFE gets updated with the following information.. Don't know if I can just plug this in here? If not.. please tell me what I need to do.
Here it comes:
Description:

INITCHECK currently only reports definite “used without being initialized” fields. Requesting an enhancement to the INITCHECK option to additionally report all possible “used without being initialized” fields i.e. something like a new INITCHECK(STRICT) option.

Business case 1:
With COBOL 4 indexes (in TGT storage) if they are used before being set due to a coding error, the indexes default to a value of 1. With COBOL 6.2 indexes (in LE RENTStatic area (static map) storage) if they are used before being set due to a coding error, the indexes have unpredictable values due to uninitialized storage/residual data in the LE RENTStatic area storage. This can result in differences at runtime and/or SSRANGE abends. We would use this INITCHECK(STRICT) compiler option to identify all programs and fields that need to be reviewed and potentially changed due to uninitialized indexes. This would prevent differences at runtime and/or SSRANGE abends.

Business case 2:
For performance reasons we would like to change our LE STORAGE option to not initialize stack storage (LOCAL-STORAGE). We could use this INITCHECK(STRICT) compiler option to identify all programs and fields that need to be reviewed and potentially changed to initialize the variables, before we change from STORAGE(,,00) to STORAGE(,,NONE).

From the COBOL 6.2 Performance Tuning Guide:-

“You should not use STORAGE(,,00) to initialize variables for your application. Instead, you should change your application to initialize their own variables. You should not use STORAGE(,,00) in any performance-critical application.
- For a call intensive program, STORAGE(NONE,NONE,00) can degrade more than 100%, depending on the number of calls.
Note: The call intensive tests measured only the overhead of the CALL (i.e., the subprogram did only a GOBACK); thus, a full application that does more work in the subprograms is not degraded as much.”

See Use Case for an example.

Use case:

Use case 1:

For example, for this program WS-IDX is uninitialized. COBOL currently does not display an INITCHECK message, because WS-IDX *could be* initialized if WS-FLAG is ‘Y'. With INITCHECK(STRICT), COBOL would report a warning for WS-IDX as a possible (potential false positive) data item used before set.

WORKING-STORAGE SECTION.
01 WS-FLAG PIC X VALUE SPACE.
01 FILLER.
10 WS-FIELDS OCCURS 10 TIMES INDEXED BY WS-IDX.
15 WS-ENTRY PIC S9(13)V99 COMP-3 VALUE 0.
PROCEDURE DIVISION.
*
AA000-HOUSEKEEPING SECTION.
IF WS-FLAG = 'Y'
SET WS-IDX TO 10
END-IF.
ADD 1 TO WS-ENTRY(WS-IDX).

Use case 2:
For example, for this program (X, Y and Z have no VALUE clauses), COBOL currently displays an INITCHECK message for X but not Y, because Y *could be* initialized. With INITCHECK(STRICT), COBOL would report X as a definite, Y as a possible (potential false positive) and not report Z.  move this line up from the bottom

PROCEDURE DIVISION.
IF P > 5 THEN
MOVE 5 TO Y
END-IF
DISPLAY X.
DISPLAY Y.
MOVE 5 TO Z.
DISPLAY Z.


thanks
Tom