Re: Y2K blowups - Was: Too many replies to "too many answers" post

Ah, "fix upon failure" .  At least now there's a term for it.  This would
be the 'default' remediation plan for... how many?  I don't subscribe to
the 'end of civilization as we know it' theory, but... Hold on, we are in
for a bumpy ride. Wheee!

Kathleen Kostuck
___________________
(414) 402-0820       fax (414) 495-4986
kkostuck@execpc.com
AS/400 Solutions
Secretary - Wisconsin Midrange Computer Professionals Association   
___________________
----------
> From: James W Kilgore <email@james-w-kilgore.com>
> To: MIDRANGE-L@midrange.com
> Subject: Re: Y2K blowups - Was: Too many replies to "too many answers"
post
> Date: Wednesday, January 13, 1999 4:16 PM
> 
> 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
> +---
+---
| 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
+---