|
Kathleen, We ran into a similar situation, transaction year must be uyear +-1 Changing the uyear add 1 = hitest so that hitest was a 3,0 field solves the problem for now. Next year (2000) uyear sub 1 = lotest will have to be modified to test for negative result. I was watching CNN last week and there were a couple of Y2K commentators, including the former Labor Secretary, and one method that is gaining popularity is the "fix upon failure" approach. The example used was a gas pipeline with 10,000 imbedded systems, of which only 10% may need upgrading. The cost of determining which 10% is a cost in addition to the actual replacement. "Fix upon failure" eliminates the cost of finding the defectives. They become readily apparent. The replacement cost remains the same. The consumer just has to wrap their pipes and bundle up for a couple of days. No worse than a usual winter outage. At least that's the way the gas company is looking at it. Your non client's "fix on failure" had no more a detrimental impact on their organization than a temporary power outage would have. You'll probably get another call from them (see what you get for being their hero) when the invoicing process tries to compute a due date into the year 2000. Depending upon their terms, you may get the call sometime around October 2nd. Good luck to them. James W. Kilgore email@James-W-Kilgore.com Kathleen Kostuck wrote: > Spent the first Monday after the New Year patching (not fixing, these > aren't 'fixed') Y2K related problems. > > The worst; A non-client called me out of desperation because invoicing had > come to a complete halt. The problem? A year edit on the initial screen > prevented entry of a date in which the year was greater than the current > year plus 1. Ugly ancient S/3x code. The quick patch? Change year field > from 2 long to 3. Very simple, but their ability to invoice was _down_ > because of it. All I can do is wish them luck on their compliancy efforts. > I don't have time to actually help them. And I get the strong feeling > that they're going to need some help. > +--- | 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 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.