Analyzing and avoiding date-related diagnostic messages
When
the DATEPROC(FLAG) compiler option is in effect, the compiler produces
diagnostic messages for every statement that defines or references a date field.
As with all compiler-generated messages, each date-related message has one of
the following severity levels:
- Information-level, to draw your attention to the definition or use of a
date field.
- Warning-level, to indicate that the compiler has had to make an assumption
about a date field or nondate because of inadequate information coded in the
program, or to indicate the location of date logic that should be manually
checked for correctness. Compilation proceeds, with any assumptions
continuing to be applied.
- Error-level, to indicate that the usage of the date field is incorrect.
Compilation continues, but runtime results are unpredictable.
- Severe-level, to indicate that the usage of the date field is incorrect.
The statement that caused this error is discarded from the compilation.
The easiest way to use the MLE messages is to compile with a FLAG
option setting that embeds the messages in the source listing after the line to
which the messages refer. You can choose to see all MLE messages or just certain
severities.
To see all MLE messages, specify the FLAG(I,I) and DATEPROC(FLAG)
compiler options. Initially, you might want to see all of the messages to
understand how MLE is processing the date fields in your program. For example,
if you want to do a static analysis of the date usage in a program by using the
compile listing, use FLAG (I,I).
However, it is recommended that you specify FLAG(W,W) for MLE-specific
compiles. You must resolve all severe-level (S-level) error messages, and you
should resolve all error-level (E-level) messages as well. For the warning-level
(W-level) messages, you need to examine each message and use the following
guidelines to either eliminate the message or, for unavoidable messages, ensure
that the compiler makes correct assumptions:
- The diagnostic messages might indicate some date data items that should
have had a DATE FORMAT clause. Either add DATE FORMAT
clauses to these items or use the DATEVAL intrinsic function in
references to them.
- Pay particular attention to literals in relation conditions that involve
date fields or in arithmetic expressions that include date fields. You can
use the DATEVAL function on literals (as well as nondate data
items) to specify a DATE FORMAT pattern to be used. As a last
resort, you can use the UNDATE function to enable a date field to
be used in a context where you do not want date-oriented behavior.
- With the REDEFINES and RENAMES clauses, the compiler
might produce a warning-level diagnostic message if a date field and a
nondate occupy the same storage location. You should check these cases
carefully to confirm that all uses of the aliased data items are correct,
and that none of the perceived nondate redefinitions actually is a date or
can adversely affect the date logic in the program.
In some cases, a the W-level message might be acceptable, but you might want
to change the code to get a compile with a return code of zero.
To avoid warning-level diagnostic messages, follow these guidelines:
- Add DATE FORMAT clauses to any data items that will contain
dates, even if the items are not used in comparisons. But see the
related references below about restrictions on using date fields. For
example, you cannot use the DATE FORMAT clause on a data item that
is described implicitly or explicitly as USAGE NATIONAL.
- Do not specify a date field in a context where a date field does not make
sense, such as a FILE STATUS, PASSWORD, ASSIGN USING,
LABEL RECORD, or LINAGE item. If you do, you will get a
warning-level message and the date field will be treated as a nondate.
- Ensure that implicit or explicit aliases for date fields are compatible,
such as in a group item that consists solely of a date field.
- Ensure that if a date field is defined with a VALUE clause, the
value is compatible with the date field definition.
- Use the DATEVAL intrinsic function if you want a nondate treated
as a date field, such as when moving a nondate to a date field or when
comparing a windowed date with a nondate and you want a windowed date
comparison. If you do not use DATEVAL, the compiler will make an
assumption about the use of the nondate and produce a warning-level
diagnostic message. Even if the assumption is correct, you might want to use
DATEVAL to eliminate the message.
- Use the UNDATE intrinsic function if you want a date field
treated as a nondate, such as moving a date field to a nondate, or comparing
a nondate and a windowed date field when you do not want a windowed
comparison.
related tasks
Controlling date processing explicitly
Analyzing date-related diagnostic messages (COBOL Millennium Language Extensions Guide)
related references
Restrictions on using date fields
(COBOL for Windows Language Reference)
|