Going back to my last letter on Click [EUG #27 - Gus], I wondered if readers happened to catch ITN News on 12th September. It reported on the Year 2000 "bug". Somewhat dramatically, but truthful to a degree.
I have been aware for sometime that the year 2000 was going to be a problem. However, the problem seems to be steadily increasing in complexity as people try to solve it.
Apart from the actual clock chip which may or may not increment to 2000 (Many will 'wrap around' to 1900, ie. only the last two digits actually count), software is very suspect. If the original programmers were aware that the year 2000 is not a leap year then it is likely that the software traps any attempt to pass 2000 and reverts to 1986. I think Click is in this category. Worse, if the chip responds or a new-style chip is installed and the absence of a leap year is not known to the original software developer, it will calculate and count on a three hundred and sixty-six day year.
A powerful mainframe computer is not an everyday purchase but many have been updated with new software through the years, most of which whilst running on the same mainframe will compile various and conflicting times and dates according to the type and version of the program.
For the national and large financial institutions, the implications are horrendous. For instance, some mainframes run specialist database software that reads all the various applications and also talks to all of them thereby achieving compatibility and data exchange. The Benefits Agency or any similar body may, according to that agency's computer applications, be paying out pensions thirty years before the recipients were actually born!
Of course, while it will never happen quite like that, there may well be quite a lot of "Sorry, can't do this today/this month. The computer's down." Now is the time to perfect our skills in manually typed invoices!
Much of the suspect software is written in obsolete languages and programmers are either retired, driving buses or, if not dead, have totally forgotten their skills.
PC owners should not gloat. What will happen to DOS time and date management of files? How about Lotus 123 and Excel, with their facility to use formulae based upon time and date? Take a local area network where clients' costs are compiled on a time basis. Where access to the internet may be limited to specific days and times?
I wonder if any Electron old-timers can recall a somewhat academic argument in the letters pages of Electron User all about calendars and how to determine a leap year? The general thought was that a year MOD 4 in an IF THEN ELSE statement would return either a zero or a positive number. Zero indicated a leap year, a number not a leap year. The matter was finally resolved by the British Library/Museum confirming that Y2K was not a leap year therefore IF THEN ELSE statements needed to be nested with a further statement to the effect of IF year=2000 THEN x=1 ELSE x=0. Definitely not a case of yesterday's expert being today's fool.
Having just read Ross Little's account of ADFS corrupting his disk and the use of Roland Waddilove's articles to rebuild the disk indexing, I was thinking about Electron User and reflecting that it all took place nearly ten years ago. Clever lot these 8bit buffs!
Here's hoping Andrew Hilbig read the mid 1980s letters on the year 2000 and Click is not a write off. I continue to await comments on how to WRITE to the Click calendar.
PS. If anyone has a copy of the Electron User containing the reference to the British Library letter, I know a man who would like to see a copy of it!
Roy Warner, EUG #28