Jim,
I enjoyed reading Debugging the Y2k Story by William A. Plice, III and Stephen M. Schumacher.
ghsport.com
I have several thoughts on the paper as well as Y2K in general. I think the first thing that should be pointed out is that Y2K is not a bug. It is a design flaw. Whereas a bug is an isolated error, Y2K is a general design flaw and is prevalent across many platforms and systems. Hence I don't put much stock in the arguments that treat it as just another bug that can be fixed on failure. Or arguments that say Y2K won't be a problem because bugs happen all the time.
Anyway, here are my thoughts about the paper.
There were some points that I liked and agreed with.
They all start at the same place, with the well-known fact that a two-digit decimal number has trouble getting past 99
This states the problem very clearly. I'm glad that they didn't use the phase “the computer will read 00 and think that it's 1900 instead of 2000”.
results depend on more details than "compliance" measures
This is a very good point that is often overlooked. A system does not have to be 100% compliant in order to be 100% functional. For example, one of our query screens displays a month's worth of data in date sequence. Modifying this particular program would have been difficult and time consuming and the resulting code would have become difficult to maintain. Since the display will only be out of sequence for the month of January 2000, we decided that the users would have to be made aware that during January 2000, the records will be displayed out of sequence.
Explanations of the Y2k bug tend to be so simplified that the real technical issues are missed or misrepresented
I have also noticed that most article on Y2K take a slanted view of the problem. It is very rare that you see the real issues and facts clearly presented.
The point is that two-digit-year numbers are neither limiting nor were they bad design… The real problem occurs when a mechanism for making the year number unambiguous is missing.
Here again, the authors cut right to the chase. The important thing is, does the system work properly. A system does not have to meet some pre-ordained standard (such as a 4 digit year) in order to be fully functional.
Another thing that complicates matters is the difficulty of simulating a future date for testing purposes. It sounds easy, but full simulations in real-world networked systems can be extremely difficult because of the problems associated with running all data sources forward. If the software has been designed to respect the century, it might be better not to attempt a complete test before 2000
There are some very interesting Catch-22 situations regarding Y2K testing. My experience has taught me that thorough testing is absolutely essential to maintain system integrity. This is especially true in sensitive areas such as banking, finance, national security and others.
But Y2K time machine testing carries it's own risks and costs. Building Y2K test beds is a very tedious and frustrating task. Test situations must be developed and executed to simulate all key Y2K test dates. Test files have to be created with dates fields “aged”. Building an environment to test the remediated software on is a daunting task in it self. Y2K upgrades are usually required for your operating system, database management system, language compilers, utilities and networks. Often hardware upgrades and additions are required. Regardless of these and other issues, Y2K time machine testing is critical. It is the only way to be reasonably sure that your Y2K remediated code functions properly.
In cases of important services or safety-related links, people with flexibility and ingenuity stand by or are even directly involved in the interconnections. And these people (assuming they aren't conditioned to panic) are all Y2k compliant. Every important link has bypasses, workarounds and emergency procedures, depending on its importance, for the simple reason that it probably has not always worked perfectly in the past and is not expected to work perfectly in the future.
Contingency plans and backup systems will be essential to the “fix on failure” solution. Unfortunately, people do make mistakes, especially when under pressure. Some serious accidents have either been caused or aggravated by human error.
most date anomalies are nowhere near threatening to the running of the infrastructure of civilization, nor do they add up to anything significant, since each one impacts only a small number of people. Just because a date stamp has no century field or its century is mislabeled doesn't mean that it's going to cause harm. In some cases it may lead to inconvenience, such as having the date-sorted order of a list become discontinuous. But these things belong in a different category -- the Y2k-bug label has being applied too broadly.
I agree with the author on this point except for the conclusion that they don't add up to anything significant. You can not reach this conclusion until you know where all of the problem systems are.
What's left after debugging the Y2k stories? Maybe not much. If that be the case, it doesn't prove that nothing will happen; it only proves that there have been no convincing arguments for major Y2k consequences beyond inconvenience and overtime work for some people.
Here's a very important point: It's not necessary to prove that an unprecedented future event will not happen. If there is no good reason to believe that it will happen, then, as a rational being, you owe it to yourself to assume that it will not happen.
It all depends on what you, as an individual, believes. If you think that there is a potential for serious Y2K problems, you should plan your life accordingly. On the other hand, if you believe that Y2K does not pose a serious threat, then you should not make any Y2K adjustments in your life. We each have to assess our own exposure to risk.
If you live in a highly industrialized community that has been experiencing financial problems and has not been able to adequately address the Y2K problem, you will have to prepare for Y2K differently than you would if you lived in a rural self-supporting community that has made adequate progress addressing Y2K.
If you work in an industry that is more vulnerable to Y2K problems, you should prepare differently from someone who is working in an industry with low Y2K exposure.
There were some points that I disagree with or didn't like.
The authors spend too much time attacking someone else's point of view and don't spend enough time justifying their own view. When they stick to the topic of describing and discussing the Y2K problem, their points are well taken.
The Money-Being-Spent Bug
I didn't particularly like this section. Although the author's make a few points, it reads more like a couple of programmers trying to talk business and finance. The reason that people should watch the money being spend on Y2K is because it is the only type of comparative empirical evidence that is readily available. The SEC requires companies that have material Y2K exposure or expenses to report them in their filings with the SEC. Accounting regulations require companies to expense their Y2K costs rather than capitalizing them. How else can you judge whether and organization that you dealing with is prepared for Y2K?
When you see a long list of computers that have Y2k problems, remember that in a great many applications these problems are non-problems.
First, if a computer has a Y2K problem, then everything that depends on that computer could have a problem. Even a Y2K compliant application will have a problem if the computer itself has a Y2K problem. Besides, the solution to this problem is usually a simple software patch. The real problems here are the shear number of computers and their application programs.
Many of the application programs that are used by businesses are very date intensive. I have heard many people make statements like, “I have a Mac, so I don't have a Y2K problem”, or “I applied a patch to my BIOS, so I don't have a problem”. I have never heard anyone say that they have checked all of their application software and don't have a Y2K problem. In fact, I don't think that I have ever heard anyone say that they have even checked all of their application software. I'm afraid that too many people are hearing or reading that their computer is Y2K compliant and they are assuming that all of the software that runs on that computer is also Y2K complaint.
But there is another reason for not rushing in to fix things. It's much easier to assess and locate a bug when it appears during actual operations. Simulations just aren't the same. Once it manifests proof of its existence, you can probably devise a temporary workaround to finish the immediate task. Then, by observing its effects in the output, you can often locate the bug immediately (without the tedious and incredibly time-consuming task of combing through the code). This is the way that bugs are ordinarily handled in mature software
Bugs, by their very nature are isolated events. Bugs are usually related to one piece of code or data. Y2K date problems affect many pieces of code and numerous fields. If Y2K were a case of just “a bug”, then this would be an acceptable solution.
If a program has a Y2k problem that is not easily fixed, the program is probably poorly structured. If so, fixes of any kind can have surprising side effects. To make more than one change in such a program without real-life testing between each change is to risk causing other problems.
By searching the code for date calculations you might be able to make the program Y2k compliant, but you will not be sure that you have not caused other serious problems in the process (chances are good that you have). Those who don't have the luxury of looking for Y2k bugs now may actually come out ahead in the end!
The authors make a good point about maintaining poorly structured code. Many of the date routines that I have had to modify were very poorly written. Before the advent of modern database systems and 4th generation languages, programmers were forced to create unique code in order to handle date calculations. I have even seen one routine that subtracted 1 from a date field value (YYMMDD) repetitively until the field contained a valid date in order to calculate the previous day. To suggest that ignoring Y2K bugs until they actually occur is ludicrous; especially in light of the previous statements.
Any such device that shuts down because the date output format has rolled over would have been programmed either by someone too stupid to program or by someone intending sabotage.
The vast majority of microchips are relatively new and contain cheap memory, which removes the economy argument (if there ever was one) for simplistic processing of a 2-digit year. There is really no excuse for them failing on account of a year rollover.
Here the authors are trying to theorize why embedded systems aren't a problem. They completely ignore the fact that there are Y2K problematic chips and embedded system. They also spend a lot of time talking about VCRs, microwave ovens and toasters, but, they ignore vitally important embedded systems like chemical manufacturing control systems, weapons controls systems and the embedded systems that control our core infrastructure.
If these systems have not been double-checked before 2000 arrives, they will certainly be watched and taken off-line if they malfunction. Important automatic systems have manual overrides which are necessary to get through times of malfunction or maintenance.
The authors made a very big assumption here. I sincerely hope that they are right, but my experience tells me that there are going to be many unpleasant and unexpected surprises in this area. Embedded systems are everywhere and most people aren't even aware that a particular device may have a Y2K problem. This is also the area of Y2K that concerns me more than any other aspect of Y2K. We don't even know where all the problematic embedded systems are, how can we possible watch all of them? I see our most serious problems coming from this area.
Y2k-disaster scenarios assume that relatively few failures can shut down a large part of the world's economic engine because everything is so interconnected. What is unreal about this story is that most of the interconnections are far from being completely automated.
The interconnections do not have to be completely automated in order to be affected. Just think about how some of the recent strikes against the automotive industry. Our economic engine now relies on Just In Time inventory. Problems in one organization can affect other organizations.
There were some points that were irrelevant.
The Bug-Free Bug
and
The Black-Box Bug
Every major system has its bugs, which the operators learn to work around. In this light, the idea that computers will simply stop working on January 1st is obviously oversimplified.
I felt that these sections were irrelevant. Sure computer bugs exist, they always have and always will. But, most bugs occur randomly or are only discovered accidentally. Y2K will not be an isolated bug; it will be widespread, systematic and in some cases difficult to fix. Y2K will occur on schedule and will be in addition to currently occurring bugs.
The Self-Sufficient-Computer Bug
Again, I felt that this section was irrelevant. Although the authors make a point, the point applies regardless of Y2K.
The Fit-To-Print Bug
If you hear a juicy story about a test of a power or water utility or some other facility that failed due to a Y2k bug, don't be too eager to believe it, especially if it lacks particulars regarding exactly when and where it occurred and the names of people involved.
This section deals with what should be common sense. Any statements made in the press should be verified before being accepted. The “National Enquirer” should not be your source of Y2K information.
The Wanting-It-Both-Ways Bug
It's probably true that almost every Y2k expert stresses the seriousness of the problem. But that's virtually the definition of being an expert. Anyone who has promoted himself into such a position is not about to say it isn't a big deal.
On the other hand, it seems that many are trying to cover themselves, saying that they don't really know how big the problem will turn out to be, or even approximately what would happen if nothing were done in preparation. In other words, they have no theories that they are willing to back -- because, they maintain, it's an unprecedented event and no theories apply.
This is true, but so what? Salesmen are trying to sell you something, whether it is Y2K or some other product. It is up to each individual organization to decide whether or not the product being sold has any value to them.
The Biblical-Prophesy Bug
Y2K is about a computer date problem, not a biblical prophecy. Religious prophecy is neither the cause nor solution to the problem. They are only related in religious fanatic's minds.
Our Predictions for January 1, 2000
By now you have guessed it, but for the record, here it is:
1) No significant utility failures (power, phones, internet, water, sewer, etc. will not be shut off).
2) No inadvertent missile launches; no airplane crashes; and only the usual daily attrition of microwave ovens.
3) Your television, VCR and computer will still work.
4) What Y2k-panicked people will do, we haven't the slightest idea.
I found it interesting that the article was written by programmers, but all of their predictions seem to involve embedded system failures and peoples reactions. What problems are they expecting? Do they believe that all software related (IT) “bugs” will be fixed? Will financial records be at jeopardy because of Y2K related problems? As programmers, their predictions would be more meaningful if they gave some prediction as to what software/program problems they expect to see.
There were some important points that were left out.
a general-purpose sorting procedure might be used to sort records by date. This type of routine doesn't know and doesn't care what the characters represent. If year 2000 is represented as "00", those records will come out at the wrong end of the file.
There are many ways to correct things like this; the best scheme will depend of the details of the system
I have two comments regarding these points. First, Syncsort (the sort utility on most mainframe computers) has an easy fix. You can define the year fields to Syncsort and feed it a parameter with the pivot year and the records will be sorted in the proper order. This is a fairly simple and quick fix, although determining the exact location of the year fields within the records can be tedious.
The second and larger problem is the sequencing of records by key fields that contain dates. These key fields are often used to read records into a program in date sequence. If you do not expand the year fields to more than 2 digits, these records will be read in the wrong order. Programming around this problem can be very difficult, depending on the design of the code. This is another area where if you have problems, a quick fix is not likely.
One area of Y2K that the authors fail to discuss is the overflow problem. Systems that calculate a date in the future will sometimes have to add 1 to the year. If the year field is defined as a 2 position numeric field, when you add 1 to 99 an overflow condition can occur. Depending on the language that the program is written in, this can result in either a program ABEND or an incorrect result. I had this happen to me during some of our time machine testing. December 31, 1999 was one of our test dates. When I attempted to add some data through one of our data entry screen, the program abended with an overflow condition when it added 1 to the year. An easy problem to fix, but also a problem that is often overlooked.
Code is often shared by multiple systems. Repairing the code in one system can result in creating a failure in another system. This is one of the areas that will make the “fix on failure” solution much more difficult than most people are expecting. The authors do not address this area at all.
Just identifying all of an organization's application systems can be a daunting task. During the spring, summer and fall of 1997, I worked with the Y2K management team of a major US airline. When I first arrived on the contract, there were large banners in all of their buildings proclaiming “Y2K inventory is now 100% complete”. Airline management had already made this statement at public industry Y2K meetings.
I was working with the Natural language team. I created a database of all Natural modules on their production machine and compared it to the list of modules submitted by the airline's programmers. Management was not pleased when they were told that ½ of their production Natural programs were not inventoried. The other language teams reported similar ratios. The “client/server” team estimated that as many as 75% of all their modules had NOT been inventoried.
The inventory phase of a Y2K project is more difficult that most people realize. Large systems are often maintained by different teams. It can be difficult to determine who “owns” each piece of software. Assembling this inventory is boring and time consuming. We were met with a lot of resistance from the programmers who felt that they had more important things to do. When my contract expired (I didn't renew) in the fall, they still had not completed their Y2K inventory. I recently contacted one of my associates at the airline and I was told, “do not be surprised if you see dumb terminals at some airports”. Their failure to get a complete inventory of their client server applications has resulted in this contingency plan. At least they have enough forethought to have a contingency plan!
There are many other areas of Y2K that the author's did not address at all. They make no mention of the business decisions that will have to be made. Will a piece of non-compliant software be remediated, retired or replaced? They barely touch on all of the “system” updates that are needed to make the software Y2K compliant (operating systems, database management systems, system utilities, networks, etc.). The problem is simple much larger and more involved than the authors address.
I hope this help you to see some of the sides of Y2K. Everyone has to look at their own situation and make their own decisions about how Y2K might affect them.
B.K.
|
