In my last article, I discussed how the technological implications of January 1st. 2000 could mean meltdown for companies using ANY data processing system not designed and coded adequately, whether of primeval origin, or up to date technological pedigree. In this column, I will outline a path of possible salvation.
Year 2000: The impending Meltdown Fact or Fancy?
Several years ago, I worked in the Middle East. Programming in Saudi Arabia does not require the same level of navel gazing (just as well really) which the Gregorian Calendar (a mere figment of a religious perspective) entails. Currently, the year in Saudi Arabia is 1417 and as I recall, little effort went into adjusting for changes in centuries. Israel at the other end of the spectrum at 5756, still has many years to go before any serious investigation is required.
Anyone who has been involved in designing, writing and maintaining data processing systems, knows full well that not only are systems rarely completely stable, but turbulence of a system in most corporations, let alone dynamic ones, is the rule rather than the exception.
Typically, business rules "exceptions" of how a company operates murkup the original system concept. "Didn't I tell you about...... " is the bane of designers. New requirements are always coming along to chafe and twist entrails as to the total incapacity of the current system design to handle the latest requirements of sales and marketing. A data processing system is in fact, only "stable" three months after the last coding has been attempted! This scenario is not however a normal occurrence. Indeed, talk to any systems manager about the day to day operational requirements of any system, be it large, mid sized, "heritage", mainframe, mid-frame or any other, any you will find (if you're not already aware of it) that gut wrenching changes are an INTEGRAL part of any operations mangers environment. The fact is, processing systems are a dynamic entity in their own right.
Now the good news
Given that change is a perpetual, the advantage of the impending need for change relating to the next millennium (if it really does exists), is that it has been foreseen, and the implications can be shown to be a definite reason for concern.
Once again, the only reason why this could suddenly create data anarchy come January 2000, is that even to assess if there is a problem, requires the same nemesis of D.P. managers of the 90's: Time and Budget. Without these, the (possible) time bomb will tick away (sotto voce) behind the day to day panics and fire fighting.
It is also still a "long way off"; in the next 4 years, there are resumes to write, directorships to attain, careers to be re mapped etc: you get the picture.
Strong nerves, budget, or promotion?
Prior to any systems testing, it is essential to realise that the system date is a significant detail which may conspire to kill any system. Programmers and system internals, typically grab this to time stamp information for audits etc. To adjust the clock by several years on your production system, is not something to be taken lightly. This will be the mainspring of testing: whether you need to adjust your data processing system in a production environment requires strong nerves and a clear head. In large systems, changing the system clock can have other undefined consequences. (Kids, do not try this at the office)
To check whether a production system will work in 4 years time, requires that the machine date is set to the next millennium, and data for the years 99 and 00 are entered as regular data with the time stamps for these dates. The simplest way of assessing if your system has a problem is to generate a test environment, and test it out under pretty demanding criteria ie duplicate the details expected in a production environment.
There are three ways to do this: The first two will need raw data: production data can be copied and turned into details for the turn of the century this can be done by simply copying data for December "95" and January "96" say with the all the years changed to "99 and "00". Simply by mapping the date formats in data, you will gain valuable insight into the system architecture.
If you are of the strong nerves persuasion, then the first approach may be for you. In addition to strong nerves, a long weekend and verified backups would be considered essential equipment.
Using this approach, the test system is loaded onto the same processors and drives which house the main production system. Once loaded into a separate controlled area of the system, the main system is shut down, the new environment is brought up and the system clock set to January 31st. 2000. (See above: E&OE). In the time remaining before production resumes, you may delve into the resulting alignments, assess the system, and reset your environment for normal production.
If you are not trained in the disciplines of nerves of steel, (dammit Jim, I'm a programmer, not a doctor!), you may wish to encourage an additional line on your next budget:
Once you have budget approval, the first thing to do is to locate a similar system to the one used in production; do you have a disaster contingency system being paid for at this very instant? If not, find one: there is a secondary market for old equipment that can be purchased by the kilogram. Purchase a low end model of what you are currently using that will run your system, load data as above and tell it the system time is now January 31st. 2000 and enjoy at your leisure.
This second approach appeals to me as it enables the manager to decide what if anything needs to be done on the production system(s), and to instigate these changes into production gradually. It's also politically correct because you can ask everyone to approve it. After all, how many people are going to come into the office on a weekend to worry about something that may happen in 4 years time? That description may also include you of course, in which case you need option#3:
The third option is simply to get promoted and let someone else carry the can for this research: this approach has the advantage that it is tried and tested, and also conforms to ISO 9001.