Y2K: Cinderella: A Historical Perspective - Topic 007

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



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

No terrorist organisation or disillusioned hacker could
plant a more skilful, destructive or international

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

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,

On July 21st, 1986 in a letter to the Editor of Computing SA, IBM made the following reply:

The IBM Reply

Letter to the Editor

A four-digit clock - and a 'timebomb'


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

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

Editors' Note:

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

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

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

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

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

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".
Editors' Note:

The following article was published in some private South African journals during 1991:


PC's and the Date Dilemma

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 :


Have fun.

Usual disclaimers.

Sponsored in part by

Try Me?