Lund Sponsor Message Page

How COBOL initializes fields

By Shawn M. Gordon

Once again the 3000 Internet newsgroup 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 in Figure 1. We have three 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 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.

Figure 1

$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     ]

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 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

Item three is a real problem for most people, but I got around that with Millennium/RX, (www.red-tech.com) which will handle it. Item two is easily solved with the new HP Date Intrinsics included in the operating system, and items one and four 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 using 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 birthdays.

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

Shawn Gordon, whose S.M. Gordon & Associates firm supplies HP 3000 utilities, has worked with 3000s since 1983.