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.