• Subject: RE: Y2K Customer nuts?
  • From: "Ilena E. Ayala" <Ilena@xxxxxxxxxxxxxx>
  • Date: Wed, 2 Dec 1998 16:36:29 -0500

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.