Re: date type field test

[Glenn Ericson <Glenn-Ericson@xxxxxxx>]

At 09:15 PM 1/8/98 +0000, Art  Tostaine scribed:
>boothm@ibm.net wrote:
>
>> >>> "I guess I have to move this date to an alpha or numeric field first,
>> >then do TEST(D)." <<
>>
>> >Right now I think that's the obvious solution.
>>
>> I wonder if it is the appropriate decision though.
>>
>> Is it possible that the real issue is the EDI program that will receive
>> that "20" date, or in a few hundred days, a "00" date and therefore be all
>> messed up?  Is this the sort of Y2K problem that Glenn woories about?
>>
>> ----------------------------------------------------
>> Booth Martin
>> ---------------------------------------------------
>
>I am dealing with this problem in two places right now.  One is the as/400
has
>L-type date fields, but we must print MM/DD/YY on report, and the move to
*MDY
>date fails.  This will not change for 2000, we will still show two digit
year.
>
>Other is EDI transaction 945, version ANSI 3060, date is in MDY format, and
>another field has YYYY.
>
+---
Showing a  tow digit  year on reports and screens is OK... as long as it is
 non ambiguous and humanly understandable. 

 The real problem is at the entry of the dates from external sources EDI
and others.  I suspect  having dealt  with EDI  you've found it is not as
standard as one might want - especially during the Year2000 transition.

One  version of  EDI  supports a Y2K standard the other does not yet have
any standard in place but a meeting scheduled to discuss this.  So now are
you using EDIFACT or another EDI standard<?> even  some home grown  big
company  imposed  standard for  electronic trading?  A mix is not uncommon
unless you are the big company imposing the standard.

The  trick is  to  bridge on input record to your standard via a  "Bridge
Program" [of a long lasting value class Vs build  use  & trash] to
determine the received format and translate to yours.  Surely this will
happen as everyone will not  hit the same mark at the same time. 

 Data  that  slips through will "pollute" your database and  prior Y2K
efforts making your life terribly complex, more than before!  Not to
mention it invalidates that" Big Sigh of Relief" [ and hopefully a party]
when your Year/2000 project completed.



Glenn
___________________________________________________
Glenn Ericson,          Phoenix Consulting                      
P O Box 701164   East Elmhurst NY 11370-3164 USA                            
Phone 718 898 9805       Fax 718 446 1150
AS/400 & Year 2000- - Solutions Specialists
 © 1998copyright,  all rights reserved
____________________________________________________


 
+---
| 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
+---