Date Data Type Question

>I hope I am alive in the year 2039 to see how IBM explains why we have to go
>through this Y2K thing over again.

I could have sworn we had discussed this before, but if users insist on
using 2-digit years (*MDY, *YMD, *DMY, or *JUL) then they should expect
problems when the defined window range is approached.  2-digit years are
not, in my opinion, a solution to the Year 2000 exposure; 2-digit years
can, with windowing, provide a migration path (or if you will, extension)
beyond 2000.  In the case of AS/400, there is a well defined window
of 1940 to 2039 which can be used to work beyond the year 2000.  This
window has existed since S/38, and is not new.  Because this window is
pervasive throughout AS/400, I think it makes perfect sense for the DBMS
to indicate a file error when a stored date value cannot be represented
within the defined DBMS view (in this case a 4-digit date beyond the
user defined 2-digit window range).  I certainly would not want to see
new specific error messages to monitor for with every enhancement in
existing interfaces (such as files).

As for *CYMD, I believe you will find that CVTDAT supports 1928 to 2071;
and that DB2/400 and ILE RPG support a range of 1900 to 2899.  And
users may have assumed that S/38 used an unconditional 0 = 19xx, etc., but
trying to get a S/38 job to run in 1930 (or 2050), or a S/38 CPF supplied
outfile to provide a century of '2', may be a non-trivial task :-).

Unless users know with complete confidence that company data will NEVER
need to span greater than 100 years, then all databases should be
encoded with dates using unambiguous year formats (whether they be *C,
*YY, or *LILIAN is left to the discretion of the user).  I personally do
not even pretend to know how corporate databases may be used in the next
ten years, let alone the next 100.

I agree with your recommendation of avoiding 2-digit years; and while
some users may elect to put blame on IBM in 2039 for users short sighted
1997/1998/1999 software development, I do not believe just "killing"
2-digit years or sweet talking about floating windows is in the best
interest of current users either.

Speaking only for myself,
Bruce Vining

>
>DO NOT USE *MDY, *YMD, *DMY, or *JUL moves in RPG IV!!!  This is a hard
>coded 1940 to 2039 window.  I hope I am alive in the year 2039 to see how
>IBM explains why we have to go through this Y2K thing over again.
>
>Worse yet, if you code a DATFMT keyword with a 2 digit year in your H-spec
>and you attempt to read a record from a database file with a *USA, *ISO,
>*JIS, or *EUR date less than 1940 or greater than 2039, you get a FILE I/O
>ERROR!!!
>
>Also, do not use a *CYMD move in RPG IV.  Not only is it worthless it's also
>dangerous!  If you move the 7 digit field '0160416' (i.e. 1916-04-16) you
>will get an execution time error.  *CYMD moves are also limited to the
>1940-2039 window.  I asked about this and was told "working as designed as
>evidenced by the underlying *CYMD support in the CVTDAT command".  This is
>hogwash!  Anyone who comes from a System/38 knows a '0' is unconditionally
>'19', a '1' is '20', a '2' is '21', etc.
>
>I hope I am alive in the year 2039 to see how IBM explains why we have to go
>through this Y2K thing over again.
>

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---