RE: Y2K Customer nuts? -- MIDRANGE-L

Art, Neil     et al.
FWIW - I too  thought this a hair  brained  solution for a few years. Fact is:
""They [your client]"" does not have to do very much to locate the dates of
date fields in programs or files.  There are  two good encapsulation
vendors[ I'll not mention any names on the list] that  have tools that do
this 'very quickly' bring you to the Testing stages. Huge  parts of the
pre testing efforts come from the vendor not he client  and in a
relatively  short period of time.  Interface solutions to client server,
electronic trading partners, and humans via screen & reports have been
considered.

There are places this has merits - as long as 'they understand' what is
being done and the options that  must be considered for success or to just
buy time successfully.


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
 � 1998 copyright,  all rights reserved
____________________________________________________

>From: "Roger Pence" <rp@rogerpence.com>
>To: <MIDRANGE-L@midrange.com>
>Subject: Re: Y2K Customer nuts? 
>Date: Wed, 2 Dec 1998 16:53:34 -0600
>X-MSMail-Priority: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
>Sender: owner-midrange-l@midrange.com
>Reply-To: MIDRANGE-L@midrange.com
>X-List-Name: Midrange Systems Mailing List (MIDRANGE-L@midrange.com)
>
>The calendar crank-back isn't completely crazy.
>
>The 1972 calendar is exactly the same as the 2000 calendar.
>
>Thus, to do any date math, subtract 28 years from both dates, do the math,
>and you get the same (correct) result as if had used the current date.
>
>You don't need to changes dates in the database and dates still print
>appropriately.
>
>I'm not advocating this method, but merely suggesting it's completely out of
>the question for a short (say, 20 years or so!) quick and dirty fix.
>
>rp
>

>Date: Wed, 2 Dec 1998 16:36:29 -0500
>From: "Ilena E. Ayala" <Ilena@compuserve.com>
>Subject: RE: Y2K Customer nuts?
>To: "INTERNET:MIDRANGE-L@midrange.com" <MIDRANGE-L@midrange.com>
>Content-Disposition: inline
>X-MIME-Autoconverted: from quoted-printable to 8bit by midrange.com id
QAB27080
>Sender: owner-midrange-l@midrange.com
>Reply-To: MIDRANGE-L@midrange.com
>X-List-Name: Midrange Systems Mailing List (MIDRANGE-L@midrange.com)
>
>Message text written by INTERNET:MIDRANGE-L@midrange.com
>>I can do this, just wondering if anyone has any serious reason why you
>>can't do this?
>
>The most serious reasons won't be apparent until they get run over by them.
>
>But as already mentioned, any dates that are used for aging purposes, such
>as accounts receivable/payable, tracking expiration for products, contracts,
>etc,etc,etc.  If they do it (let's say it would work), they'd have to:
>
>1) Identify those fields in files where dates would have to be adjusted for
>aging.  The same software packages that age data forward for Y2K
>testing could probably do this.  (Have fun finding all those dates you want
>to muck with ahead of time.)
>
>2) Identify those fields for reports going outside the company where dates
>being printed would have to be adjusted back to reality for cosmetic
>purposes.  Those pgms still have to be adjusted, and remember that at some
>point those changes will probably get undone, so they better be well
>documented.
>
>3) How are they going to handle leap year processing?  They would have to
>set the date back by a number of years divisible by 4.
>
>Depending on their data requirements they *might* get away with this-if
>for example, the data cycle is short (ie, if they don't really do processing
>with data more than one year old) they might be able to do this for one
>year, then force all the date data forward where it should be, and 
>undo any Y2k specific programming changes originally put in to adjust the
>backdated data.
>
>I don't like it as a solution, but if carefully done, for *some* companies,
>it may be a cost effective 'workaround'.  Alternatively, it may be used
>internally as a workaround for subsets of in house data (aging the data
>backwards only in some files, but not setting the system date back)-which
>presents a whole other set of issues... :-p
>
>-Ilena Ayala
>+---

At 05:15 PM 12/2/98 -0500, you wrote:
>Well, it's not April 1st, so you better call the guys in white suits to
take him away !    :-)
>
>There is one solution where you basically turn back the dates in all your
files, but it's 28 years, not 100, to maintain correct day of week and leap
year calculations.  (I suppose 56 years would work too, but I haven't
looked at a calendar to check).  Of course, you STILL have to modify all
your programs to add/subtract 28 years before updating/printing/displaying.
 It's not a simple case of just changing the system date.  What it DOES
gain you is a 28 year's more time to redesign your database to use date
fields, or 4 digit years, or century flags, for all your date fields - and
redo any necessary date calculations.  And you still need to consider the
consequences if you have any type of electronic interface/file transfer to
other companies.
>
>
>Neil Palmer         DPS Data Processing Services Canada Ltd.
>                                             AS/400~~~~~
>Thornhill, Ontario,  Canada    ___________          ___  ~     
>Phone: (905) 731-9000  x238   |OOOOOOOOOO| ________  o|__||=   
>Cell.: (416) 565-1682  x238   |__________|_|______|_|______)   
>Fax:   (905) 731-9202          oo      oo   oo  oo   OOOo=o\   
>mailto:NeilP@DPSlink.com    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
>http://www.DPSlink.com        AS/400  The Ultimate Business Server      
>
>
>-----Original Message-----
>From:  Art Tostaine, Jr. [SMTP:art@link400.com]
>Sent:  Wednesday, December 02, 1998 1:44 PM
>To:    midrange-l@midrange.com
>Subject:       Y2K Customer nuts?
>
>I have a customer who has just told me that they cannot afford the $500K it
>will take to upgrade all of their software/hardware (AS/400, PC's, Retail
>store Cash registers, store controllers, etc.).
>
>They want to know if they can just set the date back on their /400.  The
>controller knows of people who are going to do this.  They want me to test
>this on another 400.
>
>I can do this, just wondering if anyone has any serious reason why you can't
>do this?
>
>I know things like reports will show wrong dates, etc.  But they don't seem
>to bother the customer.  I think they are crazy.  What do you think?
>
>Art Tostaine, Jr.
>CCA, Inc.
>Parlin, NJ  08859
>
>+---
>| This is the Midrange System Mailing List!
>| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
>| To subscribe to this list send email to MIDRANGE-L-SUB@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
>+---
>
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@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
+---