Inside COBOL #62 (How does COBOL initialize fields)
by
Shawn Gordon
President
The Kompany

Once again the 3000-l serves as a source of inspiration for me. A while back there was a discussion of how INITIALIZE would treat FILLER items in WORKING-STORAGE. So I wrote a little program to test various options.

As most people know, the word FILLER in WORKING-STORAGE was pretty much done away with back in COBOL85, you could just leave the descriptor blank (which is what I always do). What we wanted to establish is what happens with FILLER type fields during an INITIALIZE of the 01 record.

Take a look at the example code. We have 3 types of fields for basic alpha and numeric data types, all of them are initialized with data in WORKING-STORAGE. If we display the record at start up we see that everything contains what we expect. Next we do an initialize and we see that the named fields RB1 and RB2 have been set to spaces and zeroes respectively, which is what we would expect because of their data types. However the FILLER and non-named fields continue to maintain their existing data.

Next we do a MOVE SPACES to the 01 record structure, and as expected everything is cleared out. Finally we use INITIALIZE again, and we see that zeroes were put into RB2. What is the lesson to be learned here? I would say that if you want to be safe, then you should always move spaces to the record structure, followed by an INITIALIZE.

What we didn’t get into here is how redefined items get handled or index items in a table. From some tests I ran it appeared that table index items get ignored, and redefined data will maintain the data and characteristics of the original element. This should be relatively obvious, but sometimes needs to be mentioned.

Here is a Y2K tip for those of you who are interested. It’s not actually necessary to expand dates to be Y2K compliant. There are only three or four problem areas;

1. Selection criteria where the dates span the century
2. Date math with fields that span the century
3. Sorting date fields without the century
4. Date comparisons

Number 3 is a real problem for most people, but I got around that with Millennium/RX, which will handle it. Item 2 is easily solved with the new HP Date Intrinsics, and items 1 and 4 are easily solved in code. A technique we ended up using basically had us using the HPDATECONVERT intrinsic to convert all dates to YYYYMMDD format before any function that was going to be an issue, and then use the converted dates in the comparison or operation.

This allowed us to convert multi-thousand line COBOL programs to be Y2K compliant in usually under an hour each, maybe not quick enough for everyone, but it worked. Your main concern is going to be properly handling pivot years when you are dealing with things like birth days.

See you next month for a surprise topic (surprise to me that is).

$CONTROL USLINIT, BOUNDS, POST85
IDENTIFICATION DIVISION.
PROGRAM-ID. STUFF.
* Test various cobol functions
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
DATA DIVISION.
WORKING-STORAGE SECTION.
*
01 REC-BUFF.
    03 RB1               PIC X(04)  VALUE "ABCD".
    03                   PIC X(02)  VALUE "ZZ".
    03 FILLER            PIC X(03)  VALUE "QQQ".
    03 RB2               PIC 9(04)  VALUE 1234.
    03                   PIC 9(02)  VALUE 99.
    03 FILLER            PIC 9(03)  VALUE 777.
*
PROCEDURE DIVISION.
*
A1000-INIT.
     DISPLAY '[' REC-BUFF ']'.

     INITIALIZE REC-BUFF.
     DISPLAY '[' REC-BUFF ']'.

     MOVE SPACES TO REC-BUFF.
     DISPLAY '[' REC-BUFF ']'.

     INITIALIZE REC-BUFF.
     DISPLAY '[' REC-BUFF ']'.
     STOP RUN.

:RUN STUFFO

[ABCDZZQQQ123499777]
[    ZZQQQ000099777]
[                  ]
[         0000     ]