While I was scratching through my archives and sorting things out in preparation for the impending new web site I found this old thing from ten years ago.
OK, some things have changed. Operating Systems are being upgraded. But not all that much has changed. There are still outstanding issues that have not been addressed.
Anyhow, I hope this provides a few giggles.
----------------------------------------------------
"There is nothing new under the sun".
Considering the current concerns with computing problems posed by encounters with the Year 2000, the following extracts from a ten year old South African controversy may be interesting.
This half-page advertisement appeared in Computing SA on June 30 1986
THE TIMEBOMB IN YOUR IBM MAINFRAME SYSTEM Chris Anderson DEADLINE-2000 Project Anderson Computing Enterprises 62 Viljoen Street Krugersdorp North 1740 South Africa A summary of a potentially severe system problem for all users of IBM mainframe systems. An Open Letter to Executives, Managers and Users, in the IBM world. TIME 00: 01 hours January 1st, 2000: D-DAY The phone rings. Someone is in a panic. They say that your IBM mainframe system is running amok. Master files are being corrupted, programs are bombing out all over the place. It is chaos. All the slick software you bought for vast quantities of money is telling you it has expired and you may not use it. Sad but true. All you have to do to experience this is wait some 14 years. The date timebomb. The cause is that no IBM Mainframe operating system software or compiler properly caters for a date subsequent to December 31st, 1999. The hardware can cope, but the main system software has a bug. VM/SP, VSE, VSE/SP, MVS all have the same glitch. This is also true for the compilers, COBOL, Assembler et al. No problem , you cry, I dont use dates!. Ah, you personally may not, but your operating system does. Wait and see. Is this a real-world problem? Oh yes. A little personal investigation will convince you. No terrorist organisation or disillusioned hacker could plant a more skilful, destructive or international boobytrap. Reactions from people I have observed several reactions from industry people. Most are sublimely indifferent, some have a good laugh, others say let IBM fix it. None are prepared to do anything about it. Fourteen years seems a long time. The gut reaction to this problem is to hope it will go away. Somebody else will fix it. Those of you with children will reflect on how quickly nine years pass by. What is the impact? As an Executive, I would think very carefully about investing in systems which carry time bombs. I might even be worried about protecting my existing investment. If I was investing millions, I would like the assurance that my system would last into the 21st century. Do it Now More computing power exits now than ever before. If corrective action is postponed until D-Day, a further fourteen years of data and programs will be affected. The problem should be solved now. Today, if possible. What we can do about it? Why not ask your friendly supplier, gently, what they intend to do about it? Anticipating the probable reaction, lobbying your congressperson might help. Does this affect us personally? I intend, if still alive, to retire on that particular date. Frantic phone calls will not be welcome. I also intend to have all my insurance policies paid out, my money out of the bank, and will not be making any airtravel arrangements. How about you? You have been warned. A positive approach In a more positive vein. I am setting up an interest group called DEADLINE-2000. The objective of this organisation is to investigate and coordinate implementation of immediate solutions to this problem. Obviously these must be acceptable to the user community at large. If you have any suggestions, can offer coding solutions or donate machine resources or merely wish to be kept informed of developments, problem specifications and fixes, please write to me at the above address. Yours sincerely, CHRIS ANDERSON.-------------------------------------------------
Letter to the Editor A four-digit clock - and a 'timebomb' Sir, Re Mr Chris Anderson's advertisement "The Timebomb in your IBM Mainframe" (Computing SA, June 30), which he describes as "an open letter to executives, managers and users in the IBM world". The letter states that' "No terrorist organisation or disillusioned hacker could plan a more skillful, destructive or international trap". IBM regrets that, in straining for attention, Mr Anderson has implied that IBM goes about its business in a manifestly cynical way. Far from selling operating systems which have in-built obsolescence, IBM strives to protect the investments which customers make in IBM products. The alarm which Mr Anderson seems at pains to spread is over a relatively simple matter: whether one records the year date as a two-digit or four-digit field. If a two-digit field has been used, problems can be foreseen arising at year-end 99. IBM and other vendors have known about this for many years. On the introduction of the IBM System/370, 16 years ago, the architecture included a 64-bit time-of-day clock which records the date and time of day to the microsecond and goes well beyond the year 2000. Thus the hardware presents no problem. What about the software? The current IBM operating systems, such as VSE, VM and MVS were fixed to support four-digit year fields back in 1970. However, certain records maintained by the operating systems were defined in 1964, for example tape labels and disk directories, and these carry two-year digit fields. For compatibility reasons they were not changed in 1970. If they are not changed by the end of the century, computer operators could get themselves into difficulty. Consider for instance, a file marked with an expiry date of, say, 1 December 1999. An operator wishing to override it on 1 February 2000 would find the System Control Programs (SCPs), as they function at present, rejecting his request. This problem is fully understood by IBM's software developers, who anticipate no difficulty in programming around it. There remains the user's individual applications. Typically in the past these recorded the date as a two-digit field and will therefore have to be converted to a four-digit field. Failure to do so before the year 2000 would undoubtedly have serious consequences. Put simply, then, the position is as follows: those users still working a two-digit field can continue to do so, always bearing in mind the need to convert to a four-digit year field by the year 2000. They may do so at any time during the next 14 years. Users devising new applications may as well start them out with a four-digit date field. That said, some additional comments about Mr Anderson's advertisement deserve to be made. We consider that this advertisement is deliberately misleading in a number of respects. Firstly, it claims to be an open letter whereas it is clear on a full reading that it is, in fact, an advertisement by Mr Anderson to solicit business. Secondly, the advertisement claims that it is Mr Anderson who has founded a particular interest group; yet it appears from the use of the word "congressperson" that the copy was probably drafted in the United States of America. Thirdly, Mr Anderson's reporting of the facts is so selective that it completely misjudges the significance of the situation he describes. Fourthly, we are surprised that, although he failed to discuss the matter with us before placing his advertisement, Mr Anderson predicts confidently and in a highly unfavourable manner what our "probable" response will be. We can only conclude that Mr Anderson has a vested interest in portraying the situation as he chooses to do. We believe that, as a minimum, this type of advertisement contravenes the code of the Advertising Standards authority. We intend taking this matter up with that authority directly. Mark Hennessy Manager of marketing staff IBM SA-------------------------------------------------
The threat to take the matter up with the Advertising Standards authority (a South African press watchdog) was highly effective, even though it was never carried through. Computing SA declined any further Deadline 2000 copy. IBM was (and still is) one of their major advertising clients.
The attempt to start the Deadline 2000 user group was abortive. A total of three replies were received, only one of which was in any way serious.
However, before closing the doors the following statement was sent to the replyees:
----------------------------------------------------
DEADLINE 2000: A statement of the Problem. The 50-year date cycle. These computer systems have only been running since the 50's, so the problem has never appeared before. Except for one historical precedent. In mid 1972, OS/VS1 tape catalogs with 9999-day expiry periods went wild. 9999 days is 27 and a bit years, which overlapped into 2000 and thus reset the year to zero. Archive tapes became scratch tapes overnight. The solution was simple, use only 999-day retention. An insignificant event, but it caused some very real problems at the time. An interesting event may occur in the year 1997 (which is 999 days from 2000). For most practical purposes absolute accuracy, relative to today's date, is only really necessary over a 2-5 year window, as most files are only active and current for this time. There are three parts to this problem. Part One. Telling the system the date and time. IBM mainframes have an internal binary clock capable of storing, to an accuracy of a millisecond, a very precise date and time. But you have to set it. And here lies the rub. When you switch on in the morning, or whenever, the system requests the operator to enter the date and time. The format required is usually MM/DD/YY or YY.DDD (Pseudo-Julian). You will notice that only two digits are allowed for year, instead of four. This is fine for most purposes except where the last two significant digits of the year are 00. The system uses this input to set the clock and as it stands can handle 1900, but not 2000. Some changes have been made to system software since 1986, and some versions of system software will recognise a setting of year 00 as 2000, and will interpret the First of January 2000 to be a Saturday, which is correct. A very important fact about this recognition of Saturday, is that the date information is fetched and decoded directly from the internal hardware clock, this is the vital issue - if the clock is read directly then a correct date can be derived, but if not, and the "standard" date functions supplied with the Operating System Software are used, then the date format is ambiguous. Part one of the problem is thus easily solved, and is a relatively minor change. Easy. Change the Initialisation program within the Operating System to ask the operator to enter YYYYMMDD (year, month,day) for date and HHMMSS (hours, minutes, seconds) for time, and set the clock accordingly. However, all IBM Operating System software will have to be fixed to allow this to be done. The most probable compromise solution will be to leave the year representation as 00, but ensure that the logic of all date calculation and comparison routines sees this as 2000. A new cutoff date of 2050 seems reasonable. Thus 00-50 represent 2000-2050 and 51-99 represent 1951-1999. This will give another 50 years of processing. There would still be some difficulty in sorting files by date, but the American format of MM/DD/YY gives this hassle anyhow. Not insuperable but messy. The full 4 digit year would be preferable as we could then forget about it all for the next 8000 years. Part Two. Operating System use of the clock. The real action begins. It is what the Operating System does with this clock data that really fouls things up. Internal macros, deeply embedded in the heart of the system, and heavily replicated in many thousands of routines, are used to communicate the date and time to programs. These only return the last two digits of the year. This system date is used very, very often. There are vast repercussions if these macros have to change, as they must, as all existing programs will have to be modified to account for the difference in length. It is rare for an application program to interrogate the Hardware clock directly, as the conversion from a binary number in milliseconds to date and time is fairly complex and messy, however this is currently the only guaranteed method to obtain the correct date. Another example, The COBOL Current-date special register is returned in the form MM/DD/YY. How many COBOL programs are there in the world? Millions. Similarly, the Fortran and PL/1 compilers use the two digit standard. Labels written to tape and disk, and the complex catalog processor which controls generations and expiry, are based on two digit years. Time stamps are used extensively in database systems. Databases cease to function after a while when their timestamps conflict. Part Three. User programmer use of the clock. User programmers, in their wisdom, do boring calculations on interest and annuities and financial transactions. These usually involve dates. These dates also tend to get stored in files together with other data. How many user programs have been written to follow the system standard of only two year digits? Just take COBOL programs. The answer is, just about all. If you feel so inclined, take a look at some of your own systems. This means time-consuming reprogramming and file manipulation. Costly. Subtle problems, where for example, date comparisons are used to alter program flow, are very difficult to spot and fix. Incidentally, I think I hear all you little fourth and fifth generation guys crowing cockily in the background. This can't happen to us you say. Check it out. For Data Security buffs This is really a data security problem. It would be a good security test to set your system forward,(after taking adequate backup, of course) and see what happens. On some existing systems this is difficult, for you cannot actually set the date forward as yet. Most textbooks on data security practice do not mention this problem. Somehow it has fallen through the cracks. Alternative actions One plan is to start afresh. Ignore all previous dates and data. Start with a clean slate. I would be quite happy for the taxman's computer to adopt this approach. However I feel there might be some opposition to and problems with this method. Various boffins will come up with slick ideas on how to fiddle two digits into four. Ingenious and difficult to program, let alone standardise. Bad news. A lot of research shows that such kludges will not do. I a nutshell, there is no quick and dirty solution. The bullet will have to be bitten at some time or another. Better sooner than later. If we fix it properly now, we can forget the whole thing for almost a thousand years. Comforting thought. What must be done. System software will have to be modified and fixed. Essentially, all user programs that have date dependencies will have to be altered or at least recompiled. Who else is involved? I have considered the IBM problem as it is my speciality. Users of other equipment might check to see if they have the same problem. Some PC's I have seen are OK as they use the full four digit year. The only way that this hypothesis can really be tested is for some brave soul to offer their own mainframe machine as a guinea-pig, start the machine up with a system date set at 23:45 on 31st December, 1999 and wait to see what happens. Within fifteen minutes, the internal hardware clock will inexorably tick over into the year 2000, and the world will be able to see for itself if these prophecies of doom have any foundation. Why the fuss? Essentially the problem has to do with money. Changes to computer software costs money. The information carried on the magnetic media belonging to any computer user is usually vital to the operation of that owners business. Any event which puts such information at risk can only be regarded in a serious light, as it is not inconceivable that loss of data or delays in processing could cost a user many thousands, perhaps millions, and might even result in the total inability of a user to do business. The real computing work of the world is still done on mainframes. Magnetic tapes and the date. The problem with a magnetic medium such as a tape, is that you can change the contents of the tape by remagnetising it, a process called "writing" to tape, in the process of which you lose or overwrite the data on the tape. Obviously strong magnets of any type are forbidden in an area where tapes are stored. Magnetic tape is still the most usual of all storage types for archival type information. Vast quantities of information are stored on billions of tapes throughout the world. Inadvertent overwriting of the information on a tape usually has serious repercussions. There are two techniques used to protect the contents of a tape, one physical and one where the date is used. A "write ring" removed from a slot at the back of a tape prevents any information being written on the tape. Because so many tapes are used, a method of management called "cataloging" is most often used. A standard label header is magnetically encoded onto the tape with a six-digit serial number, a unique name for the contents of the tape and two dates, the date the tape was created or written and an expiry date or date before which the tape may not be rewritten. To keep a tape forever, you create it with a date of 99/365, meaning the 365th day of year 99. To retain the data on a tape for 30 days, the system will add 30 days to todays date and write that on the tape as the expiry date. Automatic programs are used to control the contents of a "tape catalog" or list of all tapes in an installation, together with the serial number, creation date and expiry date. When data must be written to tape, the tape management program scans the tape catalog looking for "free" or "scratch" tapes. in other words, tapes which have an expiry date earlier than "today". if such a tape is found the operator is instructed to mount the tape (giving the unique 6 character volume serial) with a write ring in it, and the data is then written to the tape, overwriting any old data on the tape.. Well? you guessed it. Tape labels and catalogs use 2 digit years for the expiry date. Assume a 30 day retention tape was created on the 30th November 1999. The expiry date would then be 30th december 1999. The expiry date for 60 days retention would be 30th January, 2000. If the 60 days tape was mounted during 1999, it could be overwritten because its year is 00, which is of course less than 99 and could thus be interpreted as "expired". On the 1st January, 2000 your tape catalog system would run out of tapes to use as all the tapes in the catalog would only fall due for reuse in 2099. The 31st December 1999 is also an interesting date for tapes. As it is the 365th day of year 99 any "keep forever" tape could be overwritten. Another interesting process is called "scratching" a catalog. A job is run which frees up any tape in the catalog which has an expiry date less than or equal to todays date. Running such a job on the 31st december 1999 might well "scratch" every tape in the catalog including "keep forever" tapes. Solution? A binary date could be written to the tape label and catalog files, and special handling routines could recognise the "old" format written on all the billions of existing tapes. Some systems allow a "keep forever" date of 99/999, that is the 999th day of 99, which could never occur as a real "today date". This is merely a programming convention, not a standard, but it would be useful "kludge" to adopt it universally to ensure that archive tapes are never overwritten. A "kludge" is a messy and halfhearted sort of patch to half-solve a problem, when time or programmer-energy is not available to fix a problem poperly. Of course, this is the wrong country in which to raise this issue. The local representatives for the overseas manufacturers do not have the decision-making clout to get anything done, nor apparently do they wish to do so or make any waves about potential problems. In 1986, when this problem was first aired, American based companies in South Africa were trying to keep a low profile and avoid disinvestment. The cost of mainframe harware can be anywhere in the range of half-a-million to twenty million rand, the cost of Operating System Software which is hired monthly and never purchased ranges between five thousand to ninety thousand Rand, per month. Software maintenance charges approximating to 5 percent of software costs are also levied monthly. In the current economic climate, where local companies are despartely trying to cut costs, the old version "public domain" systems which do not carry monthly charges are again becoming attractive. The date problem is of course endemic to these old systems. Users should at least be aware that they should be storing dates in julian day format or at least with 4 character centenary years, and that they should be converting to rouytines which read the system hardware clock directly rather than depending on the erroneous methods supported by the current Operating Systems. Similarly they can plan to convert their existing files to new date formats well in advance and with minimum impact. If all new systems wriiten from today onwards would be specified for century dates, this would be a major step forward. The point is that most Users are not even aware of the problem, let alone how to go about fixing it. As the date format of Year/ Month/ Day is actually an International Standards Organisation standard, it is also supported by the SA Bureau of Standards. It would be nice to get a statement of direction from those bodies on how to plan for and implement dates for the year 2000. The laisser-faire approach to this problem , "lets handle it when it happens" and "the Operating System will handle it at that time" is all very well, but if a well-documented and standardised approach could be taken now, then all programs written from now on in would be correct and no further action would be needed. To leave everything to the last moment, particularly when it is not necessary, seems a crazy and irresponsible thing to do. Manufacturers repeatedly tells us to to "Think" and "Plan", but apparently this only applies when buying expensive new equipment. The widespread use of computers means that there are more programs being written now than ever before, and the trend seems to be upward. In other words, we are unnecessarily replicating the date error at an unprecedented and accelerating rate. Surely it is logical to fix the problem now, Today. It is perfectly feasible to write programs that will survive the end of 1999, but it means extra work and additional tools. The standard environment as supplied by the manufacturers does not give the user the tools needed to do the job. The objective of the proposed Deadline-2000 User group was to provide a forum for interchange of information and to pool the computing and skills resources needed to define and write the special processing routines and tools required to allow users to utilise century years. The ideal solution is for the manufacturers to provide the tools and methodologies and guarantee the results. At least this seems to be a logical deduction considering the very high charges made for Operating System "Maintenance".-----------------------------------------------------
The following article was published in some private South African journals during 1991:
----------------------------------------------------
PC's and the Date Dilemma As the Personal Computer is of recent vintage, the date dilemma does not occur until late in the 21st Century. On a PC-XT under MS-DOS version 3.30, you may enter dates between 1st January 1980 and 31st December 2099, using either the DATE or WTDATIM programs. However, enter 1st January 2100 and you get "invalid date". (Ah well, now the Armageddonites have a new date to play with. Sigh.) For myself, this is A-OK. I doubt that I will live to be 155 years old and experience the problem first hand, however it does illustrate that subtle system limits do exist. Possibly it leaves a dubious legacy for our heirs. If I ever have any grandchildren, and they are foolish enough to dabble with computing and inherit my aged old junk, they may see it happen. Oom Paul Kruger was hoist with a similar petard. In 1900, convinced that the motor car was a passing foolishness, he beqeathed a free ox-wagon outspan area to the nation. (Coincidentally the lease expires in 1999, and for those who care to look, the ground is to the left of the motorway between Pretoria and Silverton). The Late President did not anticipate that he would thus frustrate the vile plots of the township developers of our time. A wonderful example of being right for the wrong reason. By the way, if you have an adventurous nature and have access to a PC, you might like to try the following little experiment and see what happens. Turn on your machine and type DATE (Most standard systems should have this DATE program. If however you are rudely told 'Bad Command or file name' then try WTDATIM and enter dd-mm-yy) The system will respond: Current date is (whatever) Enter new date (mm-dd-yy): Now you can try entering some dates of your own: I can recommend : 01-01-2100 01-01-1900 01-01-1970 01-01-00 01-01-99 01-01-2000 02-29-2000 12-31-2099 Have fun.-----------------------------------------------