I'm a little confused by what he is saying. One of the things we did
in our Ideal conversion was to set a Base parameter on every date
statement. I'm not sure how theirs will function. I thought we were
told that the Base defaulted to 1900.
George Levison <George_Levison@STO.COM> 03/24/98
02:23pm >>>
FWIW, a Y2K tip:
After examining every IDEAL program in the house and correcting
and
re-testing every Y2K exposure we found, we began testing in a
separate LPAR
back in January. At that time, we began with a system date of
10/01/99 and
have advanced it several days at a time, preserving month ends,
long
weekends, etc., and up to now we have had only a few very
minor problems,
mostly with missing BASE parameters. (As of now, all programs
have been
compiled under IDEAL 2.1 but we are testing them under IDEAL
2.2).
But today, February 29, 2000, I've just watched the seventh
program go down
the tubes with run time error :
1-IDAETERR47E - DATE: DAY INVALID
Each of these had the same situation. A six position date derived
from
"today's" date is reformatted to another six position field using the
$DATE
function without a BASE parameter, causing the incoming date to
be presumed
to be February 29, 1900.
These were simply things we missed in our original manual
scanning and
fixing and were easily fixed by just adding the BASE parameters.
My reason
for bringing up something so trivial is simply to suggest that using a
system date of February 29, 2000 early in the testing process can
provide
"early warnings" as to the extent of required corrections.
I mean this as a procedural, not a technical pointer.
George Levison
Sr. DBA
Stone Container