Make your own free website on Tripod.com
Recommended Resources
Cyberhaven.com Offshore havens, asset protection, global investing and other useful techniques.
The Year 2000 Bookshelf Books to help your evaluate the Y2K problems you face.

Gary North's Y2K Links and Forums - Mirror

Summary and Comments

(feel free to mail this page)


Category: 

Compliance

Date: 

1997-01-13 00:00:00

Subject: 

The Huge Volume of Repairs

Comment: 

Date: Tue, 31 Dec 1996 02:08:41 -0500 (EST) From: rsandler4@juno.com (Robert J Sandler)

> >Complexity is not the main issue, volume is. It has been often >repeated in this forum that the year 2000 is a management problem, >not a technical problem. The approach outlined by your local >programmer is basically reasonable, though we might quibble with >some of the details. If you have only a small number of programs, >it is as simple as he or she makes it out to be, and any number of >approaches will work. But many medium to large businesses have >thousands or tens of thousands of programs, and a number of files >on a similar order of magnitude. And they are all interrelated. >When you have to change that many things, all in a relatively >short period of time, you have an overwhelming coordination >problem. Your programmer's step #1 could easily be tens or >hundreds of man-years of effort for many companies. Step #4, _the >great copying party,_ is simply not realistic for a company of any >significant size. They would have to shut down for weeks if they >tried to copy all their files at once. > >> If all we need worry about is getting good data out of a system >> and allowing good data to be entered into the system, >> programmers can lick that literally in a couple of weeks. > >That's not all we have to worry about. We have to worry about >whether the system will keep dates in correct chronological order, >and whether it will produce correct results when it uses dates in >calculations and comparisons. But suppose for a moment this were >not a gross oversimplification, and that it is true for one >system. Now multiply _a couple of weeks_ by 400 or 500 systems. >You have just run out of time. There are only 156 weeks between >now and January 1, 2000. Furthermore, many or all of those >systems probably interact with one another. You can't change them >all at once, so you will have to create some temporary interfaces, >which is extra work. Not only do you have to coordinate the work >on all these interrelated systems, but some of them will have to >have other maintenance changes made while you are working on the >year 2000 changes. > >> One area I didn't bother with was data exchange since most is >> done under ISO standards and I assume there is one. > >This suggests a bit of naivete on the part of your programmer. >Where did this person get the idea that most data interchange >follows ISO standards, or any standard, for that matter? He or >she must have had a very narrow exposure to data interchange >practices. There is an ISO standard for dates, but (a) it permits >a two-digit year, so it does not avoid the year 2000 problem, and >(b) it is rarely followed. > >> If the software uses the operating system to determine a >> date/time stamp for the software or the software uses file >> time/date stamps to function then the operating system needs to >> be modified as well. This is a vendor problem. > >Yes, the vendor has to make the modifications to the operating >system. But is the vendor going to do it, and if so, when? When >the vendor ships you the updated operating system, you have to >install it, with all the usual headaches of an operating system >upgrade. Suppose the vendor is not going to have the upgrade >until sometime in 1998. How will you work on the changes to your >own programs if the updated operating system isn't ready? The >_vendor problem_ is very much your problem, too.


Return to Category: Compliance

Return to Main Categories

Return to Home Page