Based on some discussion on ibm-main I've been pondering the use of the enhancements to the INITIALIZE statement.  "INITIALIZE data-name WITH FILLER, ALL TO VALUE, THEN TO DEFAULT" looks to me like it could be useful.  I have one small concern.  By specifying a VALUE clause on one or more items within a COBOL group record you can use the above INITIALIZE to set those fields to their associated VALUE literal.  That's all well and good (great, even!).  But it appears to me there are now cases where the "original" usage of the VALUE clause can be made irrelevant b/unnecessary y later usage of INITIALIZE...ALL TO VALUE. 

A simple example is a program that has a group data item in working-storage, and this data item record contains some data items within it that also have the VALUE clause.  The only reason for the existence of the VALUE clause for these items is so that the VALUE phrase of the INITIALIZE statement can be used.  For example, we have a data entry program where a few of the fields have to be entered by the user and the rest default either to zeroes or spaces (good use of the "old" INITIALIZE statement) or in some cases some other value "generally 'Y' or 'N'".  Currently the program does "INITIALIZE data-name" followed by some code to set some of the fields to 'Y' or 'N', followed by setting some of the fields based upon the user input.  My thought was to add VALUE 'Y' or VALUE 'N' to the relevant data item definitions and then replace "INITIALIZE data-item" with "INITIALIZE data-item FILLER ALL VALUE DEFAULT", allowing me to eliminate the "MOVE 'N' to data-item-1, data-item-2" etc.

This all seems to work fine.  The issue is that there is now "startup code" to set those working-storage items to their VALUE literal.  Then later when I do the INITIALIZE statement with FILLER ALL VALUE DEFAULT it does it again.  I looked at the pseudo-assembler generated by the compiler and this appears to be the case.  I wonder if there is an "opportunity" for the compiler to see that the field(s) are not used prior to the INITIALIZE and to not generate the, umm, initial initialization code.    Or is this the case of me worrying to much about nothing?

Frank

The compiler probably should do that.  What OPT level did you use?  In compiler terms, the technique that should have kicked in is "Dead Store Elimination."  When you store a value to a data item and then store another value (or even the same value) to the same data item and you never used the data item in between the stores, the first store is "dead."

There are cases where it's not worth doing this.  If we can initialize a group with one big MVC and "most" of the data items are dirty and a few are still clean, it's probably worthwhile to just do the MVC.  But it sounds from your description as if we actually did generate a series of moves or XCs or similar?

Regardless of how INITIALIZE functions, I've never noticed a case of dead store elimination, even with OPT(2) being set.  Take the following simple example:

 process nooff list opt(2)                        identification division.                         program-id. deadstor.                            data division.                                   working-storage section.                         01  one                         pic x value 'x'.                                                  procedure division.                                  move 'a' to one                                  move 'b' to one                                  display one                                      goback.                                      end program deadstor.                          

This results in the following pseudo-assembler:

    [...]    000124  1818               000002            LR      R1,R8                                                                   000126  A52A 8100          000002            OILH    R2,0x8100                                                               00012A  5010 8000          000000            ST      R1,0(,R8)             #  BLT_1                                          00012E  92A7 1028          000000            MVI     40(,R1),X'A7'         #  ONE                                            000132  5020 1070          000002            ST      R2,112(,R1)           #  IPCB_Status                                    000136  4100 1004          000000            LA      R0,4(,R1)             #                                                 00013A  4120 1008          000000            LA      R2,8(,R1)             #                                                 00013E  5000 1004          000000            ST      R0,4(,R1)             #  BLT_2                                          000142  5020 1008          000000            ST      R2,8(,R1)             #  BLT_3                                          000146                     000002  L0005:    EQU     *                                                                       000146                     000002  USER-ENTRY: EQU     *                                                                     000146                     000002            SNAPSHOT ENTRY                                                               000008:  001610     move 'a' to one                                                                                             000146  4100 8028          000008            LA      R0,40(,R8)            #                                              000010:  001630     display one                                                                                                 00014A  4120 D098          000010            LA      R2,152(,R13)          #  _ArgumentList                                  00014E                     000008            SNAPSHOT STMT                                                                   00014E  9281 8028          000008            MVI     40(,R8),X'81'         #  ONE                                            000152  1812               000010            LR      R1,R2                                                                000009:  001620     move 'b' to one                                                                                             000154                     000009            SNAPSHOT STMT                                                                   000154  9282 8028          000009            MVI     40(,R8),X'82'         #  ONE                                            000158                     000010            SNAPSHOT STMT                                                                   000158  D217 D098 309C     000010            MVC     152(24,R13),156(R3)   #                          _$CONSTANT_AREA+156    00015E  5000 D0A0          000010            ST      R0,160(,R13)          #                                                 000162  58F0 3068          000010            L       R15,104(,R3)          #  _ACON                                          000166  58C0 D080          000010            L       R12,128(,R13)         #  _@CAA                                          00016A  0DEF               000010            BASR    R14,R15               #  Call "IGZXDSP"                                 [...]

As far as I can tell, the field named "one" is initially set to 'x' (X'A7), then to 'a' (X'81'), then to 'b' (X'82), even though the setting to 'b' is the only one that matters in the end.