Avoiding problems with packed-decimal fields
COMPUTATIONAL-3 fields (packed-decimal
format) are often defined as having an odd number of digits even if
the field will not be used to hold a number of that magnitude. The
internal representation of packed-decimal numbers always allows for
an odd number of digits.
About this task
A field that holds a six-digit Gregorian date, for example,
can be declared as PIC S9(6) COMP-3. This declaration
will reserve 4 bytes of storage. But a programmer might have declared
the field as PIC S9(7), knowing that this would reserve
4 bytes with the high-order digit always containing a zero.
If
you add a DATE FORMAT YYXXXX clause to this field,
the compiler will issue a diagnostic message because the number of
digits in the PICTURE clause does not match the size
of the date format specification. In this case, you need to carefully
check each use of the field. If the high-order digit is never used,
you can simply change the field definition to PIC S9(6).
If it is used (for example, if the same field can hold a value other
than a date), you need to take some other action, such as:
- Using a
REDEFINESclause to define the field as both a date and a nondate (this usage will also produce a warning-level diagnostic message) - Defining another
WORKING-STORAGEfield to hold the date, and moving the numeric field to the new field - Not adding a
DATE FORMATclause to the data item, and using theDATEVALintrinsic function when referring to it as a date field