|
Autumn 1997
|
The end of a century, let alone a millennium, invariably brings out the doomsayers and the prophets of the apocalypse, and never have they been more apparent than in the computer press in the last year or two. Many of us in the MultiValue world have set back and watched these goings-on with a certain amount of smug amusement, but can we really afford to be complacent?
It's almost among us and IT departments all over the world are full of headless chickens realising that millions of lines of software code are going to have to be checked to ensure that on Saturday 1 January 2000 (or is that 11689?) they can sleep easy, confident that on Monday 3 January 2000 (11691) there'll still be a business to support.
Meanwhile consultants (people who know 365 ways of doing it, but no one to do it with) are all rubbing their hands at the prospect of the money to be made by offering 'millennium compliance analysis' services and ready-to-use, off-the-shelf conversion tools to the now oven-ready poultry mentioned above.
So what's all the fuss about?
Machine BIOS issues apart, it all boils down to how dates are stored within your database, and how they are used in your applications.
In the good old days when hardware cost the earth and shuffling your Hollerith (remember him?) cards led to disaster it made sense to drop the two leading characters from the year in any date, thus 18/08/1997 became 180897 saving 4 characters per card. Quite a saving in those days. So all this talk of lazy programmers causing the problem is unfounded, though who can blame people for thinking this when we shorten the 'year 2000' to 'Y2K'.
That's all very well, you say, so what? The so what is best explained by way of an example, but first, an important point: computers are stupid. They do not understand what they are doing (unless you use a very big hammer).
I was born on 22 August 1962 (22/08/62 or - 1957), making me 35 this year. How did I work that out? Simple you say: subtract 62 from 97, result 35. Okay, that's easy but what happens on The Big Day? Well, the date will be 01/01/2000 (11691) but if we've stored it as 01/01/00 how is our little bit of maths going to work? On that day I'll be into my -62nd year. Of course because this situation was not considered by the software writer the computer is going to tell me I'm 62 and well on my way to my pension book and bus pass!
So now let's try one that will hit you where it hurts, in the bank balance. You need to make a call at 11:59pm on the 31 December 1999. It lasts 2 minutes, ending at 12:01am on 1 January 2000. That's cool, but wait until you get the bill. On current systems you'll be charged for a call that lasted 99 years and 2 minutes. How's that? (Remember computers are stupid.)
Your call started at 11:59pm on 31/12/99 and finished at 12:01am on 01/01/00. Again the maths tells us it should be -99 years but the systems in use today have not considered this situation. (after all, how long does a piece of software stay in use these days?) so the software will use the absolute value and the bill will say 99 years and 2 minutes. Moral: don't make the call until midnight!
The 2 digit coding problem is only one manifestation of the problem that the year 2000 presents. Some systems use a 6-digit coding method where 22/08/1962 is represented by 620822. Typically this method of encoding is used to determine which of the two dates is earlier; obviously this is going to impact on anything that sorts the data by date and as the leading digits of the year are dropped here as well, the year 2000 presents the same problem as the two digit coding system.
So how does this effect the MultiValue world?
That depends on how the applications have been written. If your database has dates stored in Julian format, i.e. the number of days since (or before) 31 December 1967 (0) and your software uses dates in this format, then you should have no problems.
This date handling feature within the MultiValue world uses simple integers to store dates, and processes those numbers for external representation using an algorithm called Zellers Congruence invoked through simple conversion codes that can be used in both active file dictionaries and basic program code. This approach provides total flexibility allowing the application to present dates formatted to American format (mm/dd/yy[yy]) or international format (dd/mm/yy[yy]) as well as allowing 2 and 4 digit year, alphabetic or numeric month and day. This is a well proven system - after all it's been around for 30 years!
If on the other hand you have stored dates or use dates in Gregorian format using either the 2 digit or 6 digit coding mentioned previously you have until 31 December 1998 (11323) to fix it so the system can be tested before The Big Day. Alternatively you can buy a catering pack of sage and onion stuffing and climb into the roasting tray.
Day 10000 - what did we learn?
We all remember the date 10000 event and no doubt we each have our own horror stories about that. Hopefully we learned something from that experience that will help us with this situation.
All of these lessons if learnt at the time will have reduced the potential for Y2K problems in applications. However we cannot claim to be millennium proof just because we've gone through the day 10000 trauma already.
What is millennium compliance anyway?
The British Standards Institution DISC group has set out a definition in document DISC PD2000-1 which states that:
"Year 2000 conformity shall mean that neither performance nor functionality is affected by the year 2000.
In particular:
The above rules can be simplified as follows:
1. General Integrity
No value for current date will cause any interruption in operation and roll-over between all significant time divisions (days, months, years and centuries) will happen correctly. Current date means that today's date is known to the system or application.
2. Date Integrity
All applications and systems must calculate, manipulate and represent dates correctly for the purposes intended.
Functionality includes both processes and the results of those processes.
A common reference point for date values and calculation may be defined by organisations (e.g. day 0, 31 December 1967).
No system shall use particular date values for special meanings.
3. Explicit/Implicit Century
This rule covers two general approaches in representing a year:
4. General Guidance
An organisation may determine specific ranges of values of current date and dates to be manipulated under rules 1 and 2. Such ranges may be determined in regard to the feasible life span of a system and the span of dates that need to be represented for the purposes of the organisation's business processes.
Tests for specifically critical dates may also be defined e.g. leap years, end of period, end of year. Additional requirements may be added to these rules in order to support local requirements.
Wherever the term century is used in denoting a date, clear distinction should should be made between the value indicating the century and the value used in the date itself (e.g. 20th century implies dates 19xx and 21st century years 20xx).
What Now?
So what do you need to look for in your existing systems and are there any software tools out there to assist you?
Consensus among the various vendors seems to be that there are no problems to worry about. This is based on the assumption that all software is using the internal date format and does not do anything else, i.e. it does not use a 2 or 6 digit encoding of the date anywhere. Experience suggests that this is not the case.
We have had a number of experiences of software using 2 digit data/year encoding for building indexes on files to aid data retrieval, for example a file with a date converted to year and month (e.g. 9708) for use in SELECT statements. Such data will cause a problem with millennium dates since a statement such as:
SELECT {filename} WITH YEARMONTH GE "9901" AND WITH YEARMONTH LE "0001"
is going to fail.
Don't bury your head in the sand!
Spare a thought for those poor souls using other database solutions. According to a recent report in Computer Weekly, users of Oracle's financial application software are going to have to allow up to 9 months to upgrade to the Y2K-compliant version, and possibly up to three times as long if they have a large number of modules or the software is heavily customised.
While we in the MultiValue world have some cause for relaxation we cannot be complacent. All systems should be checked out - particularly older ones. However, new systems should be checked as well.
We have routines for checking out file dictionaries but as far as the authors are aware there are no off-the-shelf utilities that can be used to check out applications software. You may know different: if so, let us all in on the secret!
The bottom line is that all systems will have to be checked manually.
Closing thoughts
The doom and gloom merchants are gathering, news reports are becoming more hysterical. Reports of "riots and civil disorder as the financial world collapses" conflict with the reported 25% of managers who think that there software will be affected. Author Simon Reeve, in The millennium Bomb, has described it as the "greatest economic catastrophe since the Second World War", whilst Bill Gates of Microsoft fame says the problem is vastly overrated. Obviously some crystal balls are more cloudy than others!
The biggest area of impact is going to be with legacy systems dating from the 1970s. The trend towards downsizing, outsourcing and generally removing those expensive playthings called programmers from the payroll means that many companies now find that they have no in-house support for their software. Listen carefully and you can hear all the contract programmers gleefully rubbing their wallets. There are a lot of pensioned-off COBOL programmers doing the same thing. In the USA, the state of Oregon has recently passed new legislation that allows pensioners to work on millennium projects without endangering their pensions (these days COBOL programmers are in short supply!)
Taskforce 2000 estimates the cost of reprogramming in the UK will be £31 billion, and will require about 300,000 extra staff to do it. This makes most IT budgets look rather sickly, since UK spending on software development averages about £10 million per annum.
Harrow Council have raised the question of whether an earlier date will cause problems: 9th September 1999 or 9/9/99 - as if there was not enough to worry about!
So all you headless chickens, oven-ready turkeys or ostriches with you heads in the sand, wake up and get you systems checked. The clock is ticking.
Beauchamp Computer Services Ltd
Last Updated: 26 July 1999