|
| Arnold Trembley wrote:
>
>
><Snip>
> The choice of compile options is sometimes capricious. We had a huge
> debate about the INTDATE option in my shop. Basically, we have
> INTDATE(LILLIAN) because a system programmer insisted we needed it. As
> far as I can tell, we have no risks unless someone uses LE to take an
> INTDATE and then store it in a file, and expect COBOL and LE to agree on
> what it means. It seems rather a trivial issue to me, since I don't
> know of any COBOL applications we support that store INTDATEs in files.
>
> With kindest regards,
Actually, your sysprog's selection of LILIAN [only one 'L'] is the
correct selection to protect you in case "...someone uses LE to take an
INTDATE and then store it in a file, and expect COBOL and LE to agree on
what it means." With his/her recommendation, both COBOL and LE will use
the same base value for integer dates, and you have no risk.
The alternative, INTDATE(ANSI) forces COBOL to use Day 1 as Jan 1, 1601,
while LE will be using Day 1 as Oct 15, 1582. That is when you have a risk.
The choice is:
1) Have all of your programs in an IBM mainframe/LE environment
consistent [LILIAN]
Or
2) Have all COBOL programs across IBM and non-IBM platforms use a
consistent value, but become inconsistent with all other IBM mainframe
languages that use the LE Callable Services.
My recommendation during the 'Y2K wars' was to always use #1 [since you
do have to pick one or the other], but then to also avoid storing
integer dates under any circumstances.
|
|