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