So you think that this is all a clever ploy by the IT industry to curry a few extra dollars out of the large corporations? Think again. I can assure you, this threat is real and it should be taken seriously. No system is safe from it, everything needs to be checked. Even hardware and software that has been purchased in the last two years specifically to avoid major Y2k issues should not be assumed compliant, especially if they are being used in conjunction with other systems.
So where is the greatest risk? Mainframes. There is still a large amount of COBOL code out there, legacy systems that were written long ago and have been continuously patched and upgraded as time has gone by. Most of these systems were constructed before industrial strength database server systems such as Oracle and DB2 were introduced, and therefore they have their own data management subroutines. This is where life gets interesting for two reasons. In a 'home grown' database there is no standard implementation for date storage, and most of these applications were written on the premise that the application would be decommissioned long before Y2k was due to hit.
In addition to that, many of these systems have 'special meaning' dates in them, that is dates that are trapped by the application itself and interpreted differently to a standard date. For example, 9/9/99 has often been used in code to define an end of file record, a 'never delete' flag, etc. 1/1/11 has been used for similar purposes.
So the developers are to blame, right? Wrong. Granted, most developers are creative people. Like most creative people, they chafe under the structure imposed upon them by their medium, namely computer languages. This is the most structured medium a creative person will work with anywhere (in my humble opinion) and it should therefore surprise no-one that these older applications employ such imaginative use of existing fields to generate different behaviour, after all back then storage space WAS limited. The issue here is not what the developers actually did, most of them have been screaming about Y2k for decades.
No, this is a Management issue. Developers work within the constraints they have as far as storage and processing power are concerned. In this instance, the problem was caused by a lack of provided resources and a directive from the management of the day declaring that the software and data must fit on what was there. Why wouldn't you get creative? That having been said, some developers do not get away free, as in all industries there are highly and poorly skilled people as well as those who fit in-between. There is no doubt that some developers out there couldn't built a compliant contacts database for a Cray, but as more people begin to understand the industry these people are weeded out.
So why do I blame the managers? A good friend of mine (whose request for anonymity has been accepted by me) was working on a project in 1994. He was building code for a large organisation under the direction of a project manager. He was building entry fields with four digit year fields and storing the dates using compliant techniques. He was requested to stop this at once by his project manager for two reasons, namely that the users didn't like entering four digits and therefore would complain, and secondly that the application was only specified for three years of use. My friend laughed and mentioned some of the projects he had worked on that were supposed to have been decommissioned years ago that were still operational. The project manager is alleged to have replied. "I know that, but that is not my problem. There is no Y2k clause in the contract, and all I need to do is get this by the client and then I move on, job well done. Y2k will be someone else's problem."
That sums up Y2k in a nutshell. Someone Else's Problem. In an industry where applications are built for a three year (operational) life by teams of contracted professionals who walk away after sign off by the client, it does not surprise me that this has happened, nor that it has taken us this long to recognise the issue and do something about it. This is not a scam, it is simply the consequence of making do with the barest possible solution. In the computer industry that will always get you into trouble. Systems are always growing, as is their power and speed. If you don't take it up, someone else will and in the commercial sector where productivity is everything that will give them the advantage over you.
So, as a manager you decide that this problem is here because you are using old systems that don't provide for your business like they used to and you go out and invest in huge Client / Server infrastructures and LAN / WAN operating systems, Database packages like Oracle or DB2, and 4GL development tools. This is all recent stuff, right? This will make my systems compliant, right? Wrong. I have seen inside organisations who have done this and their applications and data are still not compliant. Sometimes this is because the aforementioned 'special meaning dates' are ported directly into the new database format as is. Sometimes it's because the developers who wrote the original code stay on with the company after being retrained in the use of the new snazzy 4GL and port their old bad habits to it as well. Usually, it comes back to the age old problem of working with what you have.
I have personally seen cases of sites that have made the move to C/S for Y2k reasons only to find two years down the track that less than five percent of their new applications are compliant. Some of the defects I have discovered in such applications have been so severe that the applications would have been rendered unusable. The assignment of blame is a tricky thing. In some cases, loopholes within database tools allow developers to do silly things. Sometimes windowing rules change between versions of applications. The only way to be sure is to test everything, then instead of blaming people, simply spell out what needs to be fixed and make sure it is done.
So you've checked your systems, remediated your code, retested, everything works. You're okay now, right? Wrong. You have suppliers. Supermarkets are supplied by warehouses who use trucks to get the goods from the manufacturer to the shop. What if the warehouse inventory (stored on computer) fails? What if they can't process the orders? What if everyone is buying generators in case of power failures? That may affect the supermarket in obscure ways. The people buying the generators stockpile fuel for them. That makes the existing supply of fuel scarce. If the trucking company has not stockpiled fuel for itself, it's trucks may have nothing to run on. Wheels within wheels within wheels, no pun intended.
So you ask everyone you do business with about their readiness. They do the same. Your 'supply chain' checks itself out. That will tell you all you need to know, right? Wrong. No one answers those surveys. No one who does knows exactly what to expect come 1 Jan 2000 and fill the forms with huge caveats about being reliant on so many other suppliers themselves. So far, I am more convinced that if this is a marketing ploy, it is on the part of lawyers, not technical groups. They are the ones with the most to benefit from Y2k when the lawsuits start.
So you are not sure. You think you are okay, but you have realised from the sort of responses you have received that you need to be thinking about your own liability. You go to your insurer, they will cover me for this, right? Wrong. The insurance industry has collectively decided to sit this hand out. No insurance firm is covering Y2k related failures nor liability as a result of a Y2k failure. There are reports of IT companies actually having ALL their insurance summarily cancelled by companies afraid of the fallout should this really be a 'Bibles & Ammo' scenario.
So what is the point of all this? There is a real threat in Y2k. Doing nothing about testing your systems is equivalent to sitting on your verandah watching that storm rolling in. Being prepared may not cover you completely, but it is a start. If everyone is doing things right, maybe nothing major will happen. If not, a lot of people could be hurt, hopefully only economically.
Bright Side | Conclusion | Article Index
This page ©Copyright 1999 - 2002 Acid
Site: acid.commandline.com.au