---------- Forwarded message ----------
Date: Mon, 20 Apr 1998 11:15:45 -0400
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Year 2000 (fwd)
It is simply of matter of where you make and test the changes...in
production or setting up a test environment. Had they already had a
development environment set up the extra expense wouldn't be necessary.
To set up a test environment we had to emulate the production environment.
Unless you "mirror" the production environment, you don't get actual
results. It's not necessary if you want to make your changes in production,
but if you make a mistake/mistakes you've essentially messed up your
production environment and that's a chance they were not willing to take.
This system represented billing revenues of billions. To make the changes
in production would have required "bouncing" the databases/shutting them
down. When making changes to tables you are essentially recreating those
tables and they require data to be reloaded.. When this is done no one can
access any data (use screens, windows, etc that access these tables/views).
Yes, we could do it overnight, but we come back to the same problem...if we
made a mistake and "blew away" something else it could be days or weeks
before we brought the production system back up. Essentially, you have to
assume that mistakes are going to be made. However, if you are willing to
do without $1 billion plus in revenue for a month or so, by all means save
a few hundred thousand. The interest on the revenues is probably a heck of
a lot more than the cost of the hardware. Liken this to the medical
community...as soon as they discover new drugs for curing diseases, they
don't put the drugs into production until they have completely tested. In
the computer industry many think they have the cure for the Year 2000
problems but until it is fully tested, you'd be a fool to put the fix into
production. The risk is just too great. For a small company, of course fix
in production...it's usually a small job and there generally only one or 2
databases but when you are dealing with multiples, with data in one feeding
another, risk increases exponentially. I'll do it in production but you'll
have to sign a waiver form releasing me from all responsibility in case I
do make a mistake and take away your company's source of revenue.
Greg
[EMAIL PROTECTED] on 04/20/98 09:54:06 AM
To: [EMAIL PROTECTED]
cc: Greg Goode
Subject: Re: Year 2000 (fwd)
Maybe Greg would like to answer... I'ld be interested as well...
M
On Mon, 20 Apr 1998, Eva Durant wrote:
> I'm still puzzled, though I know little
> about computers. I picture soft-ware changes only;
> re-writing some command-lines in programms,
> or changing some parameter formats.
> How can so much expence occur, why does
> it take so many hours, where does new
> hard-ware requirement come into it?
>
> Eva
>
>
> > --------- Forwarded message ----------
> > Date: Thu, 16 Apr 1998 15:14:06 -0400
> > From: [EMAIL PROTECTED]
> > Reply-To: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: Year 2000
> >
> > A few months ago, there were many notes regarding the impending doom
> > associated with the possible Year 2000 computer glitches. I was the
> > "naysayer", saying it was "hogwash". Having nearly completed another
> > conversion/fix I must change part of my opinion since my opinion is now
> > factually based and have seen a possible outcome of not addressing the
> > problem. I still however, having experienced what it takes to
investigate
> > and fix such problems, maintain that the process is relatively easy
> > provided those working on it "know what they are doing". The part of my
> > opinion that is changed is the possible disaster that could result. The
> > only thing we fixed was that people wouldn't get free utilities because
of
> > an inability to 'post' customer bills . Now apply this to the angry
> > ex-steelworkers and laid off union people in CB, not receiving their
> > welfare and UIC cheque's....I'll face the New York crowd anyday instead
of
> > this mob!
> >
> > We have just finished a Y2K project. Myself and 2 other gentlemen have
> > finished our investigations. We looked at 3 legacy systems, a 4
terabyte
> > warehouse, 14 Datamarts (2 gig +), 54 applications and all the
copybooks,
> > loadscripts, etc associated with the DBMS's. The legacy systems had 37
non
> > compliant (NC) date columns, the warehouse has 16 NC columns, and the
> > marts had 103 NC columns (duplicates). The applications use views
instead
> > of the base tables. The applications run against the Teradata warehouse
and
> > the Oracle Marts. Any date column defined in the Teradata warehouse as
> > "CHAR" that was non compliant resulted in the applications having to
accept
> > this default definition thus making some date attributes in the
> > applications non compliant. The Oracle date columns are defined as
> > "Timestamp" allowing the application programmers to format the dates
making
> > them compliant. Essentially the legacy system dates had to be
redefined,
> > the warehouse definitions changed to Date versus Char , and the
> > applications that used teradata had to be updated. The applications in
> > question were:
> >
> > VB frontends, with Crystal reports
> > Business Objects
> > Andyne GQL (kingston, Ont)
> > SPSS
> >
> > The total time to do the investigation was 420 man hours. It took us
> > another 300 hours to make the code changes. Presently we have built 2
E3000
> > sun servers, 1 E 6000, and 2 Compag Proliant 3000's, have use of an
E10000
> > and using 14 Dell Optiplex GXA pentium II test boxes. We have just
finished
> > resetting all the system and operating times, have loaded a subset of
> > current data as well as test data. To set up this test environment has
> > taken us another 700 hours. Tomorrow is Dec 31, 1999 and Monday April
20,
> > 1998 will appear to be January 3, 2000. Should everything go as planned
we
> > will have "demystified" the Year 2000 mystery, at least for one
company.
> > The next step will be to load more test data , reset the clocks, etc
and
> > see if the "leap year" is handled as well. Our wages were miniscule in
> > comparison to the hardware expenditures....$374,000. Essentially the
full
> > cost was a $1/2 million. For those of you with concerns and wondering
when
> > the gov't of NS is going to address this problem, you "best dust off
your
> > lobbying skills" because unless the gov't starts seriously addressing
this
> > problem....welfare cheque's, grant cheque's, provincial employee
cheque's,
> > etc, ain't going to arrive. The systems controlled by the NS gov't are
> > probably a heck of a lot larger than what we looked at and would
> > "guesstimate" that you are looking at a task approximately 20 times
> > greater, if not more. By the time we have tested and the actual
production
> > changes are made, total time passed will have been 6-7 months. The NS
gov't
> > if they haven't started yet, have 19 months to fix what I would guess
to be
> > some monstrous systems.
> >
> > Those of you that personally know the gov't ministers, premier, top
> > bureaucrats, etc may want to try to convince them of the need to allot
> > money to investigating these problems. There may very well be no
problems
> > but I'd hate to find out on Jan 1, 2000 that there are indeed problems.
> > Statistics in the past have indicated that each computer replaced 20
> > employees....with year 2000 the gov't will have to find 20 people and
train
> > them to replace each computer....here's one solution for the high
> > unemployment.
> >
> > The point I'm making is that many seem to be "running scared" of the
Year
> > 2000, predicting Armageddon, etc. and investigating this stuff is
> > relatively easy. The tough part is getting started...someone/dept
willing
> > to "cough up the $$$". I will keep you posted as to our test results
next
> > week and as to the results of the "leap year" test. If all our testing
goes
> > well we'll have disappointed many folks 'cause their January year 2000
> > utility bills will arrive as scheduled. Our total time from Start to
setup
> > of the Test environment....4 months. Our estimated test period...2
months.
> > Essentially 6 months to find every non-compliant
> > column/field/attribute/row/ tuple, etc. Once the testing period is
> > complete, I'll let you know if "I'm blowing smoke" or if this is as
easy
> > (although expensive) as I say it is.
> >
> > Greg
> >
> >
> >
> >
> >
>
>
>
Michael Gurstein, Ph.D.
ECBC/NSERC/SSHRC Associate Chair in the Management of Technological Change
Director: Centre for Community and Enterprise Networking (C\CEN)
University College of Cape Breton, POBox 5300, Sydney, NS, CANADA B1P 6L2
Tel. 902-539-4060 (o) 902-562-1055 (h) 902-562-0119 (fax)
[EMAIL PROTECTED] http://ccen.uccb.ns.ca
