Re: DATFMT

["Neil Wood" <neil@xxxxxxxx>]

-----Original Message-----
From: Hans Boldt <boldt@ca.ibm.com>
To: MIDRANGE-L@midrange.com <MIDRANGE-L@midrange.com>
Date: Friday, July 24, 1998 8:39 AM
Subject: Re: DATFMT


>Neil wrote:
>>Workaround:
>>
>>Hence avoid the INZ in the Data specification unless it coincides with the
>>default date format you are using.  Looks like MDY for you.  Instead move
>>the value in during your *INZSR.
>>
>>                MoveL    '91/164'         SURCH_DATE
>
>And what happens if a programmer wants to change the format
>of SURCH_DATE?  Any MOVE and MOVEL statements will then have
>to be changed as well.  Use EVAL and the format is
>automatically converted for you.
>


Only if it's 2 date formats.  Otherwise you'll get an error on compile.  As
I noted (or implied to mean) the above was a workaround.  Obviously the
better solution would be to use a standard *ISO date scheme in the program
and applicable files.

>I think the better question is:  Why is the program using a
>date format that does not have a 4 digit year?


Agreed.  Likely because it's dealing with an older file that hasn't been
converted in their Y2K project yet. ;)

>            D'01/02/98' + *DAYS(1)

>would be ambiguous.  Would the result be '02/02/98' or
>'01/03/98'?  Americans would expect one answer, Europeans the
>other.

I guess I must be a little ignorant.  To me this would always mean add one
day to 01/02/98.  Which would be 01/03/98.  Is that the American answer?


>Again, why use a 2-digit year date format?  Is it because the
>file you are searching in has a key in *JUL format?  No
>problem - if you code an *ISO format date field in F1 of CHAIN,
>the operation will still work.  For most uses of date fields
>in RPG, format conversions happen automatically.  So for most
>purposes, there are very few reasons for using anything other
>than the *ISO default.



Really?  I would agree if all your date fields are type L.  But for the
majority of old files (read: real world files) that were created before the
L data type, this won't work.

The problem is most likely that the field isn't a date format.  If it's in
the key and using *JUL format it's most likely a 5 digit numeric.  At this
point if your file is keyed by a numeric and if you try to CHAIN with a Date
key your program will not compile.

*RNF7072 30    203 000340  KFLD at sequence number 196 is DATE but key field
is
                           NUMERIC.

So no automatic conversion there.

L8r,

Neil Wood
Programmer Analyst
IBM Certified Specialist

smime.p7s