FYI: What do we do? (Six Digit Dates)

[Monty Solomon]

Begin forwarded message:

Date: Fri, 11 Aug 1994 23:00:58 -0500 (EST) 

Newsgroups: tdr.problems
From: Problem Reporting Service <PROBLEMS at tdr.com>
Organization: Tansin A. Darcos & Company, Silver Spring MD USA
Errors-To: PROBLEM-ERRORS at tdr.com
Subject: 0026 - Exactly.  What do we do? (Six Digit Dates)
To: Recipients of list Problems <PROBLEMS at tdr.com>

Please excuse the long delay between the prior posting and this
one, I have been busy with a number of very critical issues 

unrelated to the posting below.  I also didn't want to bother 

simply raising this issue - it's been raised many times before - and 

simply offer no solution as everyone else before, because all of them 

seems to have been unable to offer one before. 


I've been trying to think of a way to solve the problem.  I - and 

probably many of you - have been trying to figure out what to do 

about it.  I might have *a* solution.

At the end of the movie of Dr. Michael Chrichton's "The Andromeda Strain" 

in a congressional hearing a Senator asks Dr. Stone what they can do if
another biological emergency occurs.  "What do we do then?" he asks. 

"Exactly, " responds Dr. Stone, "What do we do?" 


The problem is the issue of six-digit dates and the turn of the century, 

now less than six years away.

The problem is probably not as bad as it was, because with the 

introduction of IBM PCs which support dates past the year 2100, 

the issue isn't a problem except to the extent of programs that 

still use six-digit dates.

Some of you might not understand why this is a serious issue.  I'll
explain. 


Much software which is still in use - especially on mainframes - was
written ten, fifteen, even twenty years ago for use in the solving of
current problems at that time.

Some of that software survives, even twenty years later.  As I once 

pointed out in a posting on the newsgroup alt.cobol, a large company 

might have a massive 2,000,000 line cobol program with 500 modules that
requires 50 programmers for its constant maintenance, care and feeding,
and that over the years the company has probably spent in excess of 

fifteen million dollars.

These applications are the "bet the company" applications that are 

used every day to keep it in business.  They are the "crown jewels" that 

if anything goes wrong with the application, the company might actually go 

into Chapter 11 or suffer massive customer backlash.

These applications cannot be rewritten because it would be too expensive,
and the company can't afford to be without them.  Thus, unless something
happens to encourage the company to change its systems, they will continue
running these old, maintenance-heavy applications, even five or ten years
from now. 


In some cases, the program is so huge and so complicated nobody knows 

everything it does; it is beyond the capacity of any one person to know 

every function and interface and module.

Therefore it can't be said with certainty what the different sections are 

doing with each other.  Thus finding where things are happening can be 

frustratingly difficult.  


Which comes to the issue at hand.  Many of these programs were written to 

use dates which are six digits in length.  Three days from now it will be 

August 14, 1994.  You can write that as 08/14/94 or 14/8/94 depending on 

which way your system codes dates.  (I wanted to avoid confusion, because 

8/11 or 11/8 could be referring to August 11 or November 8, but 8/14 or 

14/8 as a date cannot be mistaken for anything else.)

Figuring out the difference between 8/14/94 and 8/15/94 is no problem, and
figuring out that 8/13/95 is after 8/14/94 is also no problem.

The last date of this century is Friday, December 31, 1999.  12/31/99.
Want to tell me what the next date after that is?  Saturday, January 1, 2000.
01/01/00.

Which date is earlier, 01/01/99 or 01/03/00?  What is the mathematical 

difference between 12/15/99 and 12/31/99 or between 11/15/99 and 12/02/99?  

About two weeks.  What is the mathematical difference between 12/15/99 and 

01/03/00? 


About 99 years.  And think about what that means to anything that uses 

dates or timing to calculate things that are to happen.

Hypothetical Example #1. I use my Visa Card to charge $15.00 on December 

15, 1999, and the bill is calculated on Monday, January 3, 2000.  


99 years of 21% compounded interest on $15 can be over a billion dollars.
Depending on where the minus sign is, either the company is going to 

think I haven't paid them for 99 years, and freeze my account, send me a 

bill for $1 billion in interest, or roll over into positive numbers, and 

tell me my account has $1 billion in available credit. 


"Hello, British Embassy?  I'd like to buy Tristan Da Cunha and set up my 

own country.  I can charge $500,000,000 to my American Express Card." 


Or it simply dumps every account with outstanding balances for manual 

handling as the numbers are outrageous, which effectively stops automatic 

billing.  Or the system simply crashes.

Scenario #2.  A major petrochemical processing plant has a system that 

cooks a batch of chemicals for a certain period of time, before pushing 

that load out to the next process.  The plant runs continuously, and 

batches are cooked according to time.  


A plant computer shoves a load in to cook for one hour beginning at 11:45
pm on December 31, 1999.  At Midnight, one of these things happens:  (1)
the system notices that the batch has been in the oven too long, and
pushes a batch of molten chemicals into the next process, where the
process of spraying them causes an explosion. (2) the clock counter
overflows and shuts down the whole system. (3) the system counter
overflows and the batch isn't released, so it overcooks in the oven and
perhaps explodes under high heat. (4) the batch stays in the oven while a
new batch is shoved in, overloading the oven and causing an explosion. (5)
any of these explosions carries back through the utilities and supplies,
causing gas line explosions or power surges, as a plant that is eating
perhaps 2 megawatts of power suddenly drops off the grid, causing an
instant overflow and shutting down power for several areas. 


Scenario #3.  Several power plants go into maintenance shutdown because 

they've been running continuously for 98 years and 7 months longer than 

the maximum 90 day operating maximum.  Some Nuclear Power plant goes 

critical or shuts down because the system believes that the rods have 

been installed too long.

So having looked at this issue, what can we do about it?

I got thinking about this.  In some systems, there's little or no room to 

expand their data files and the ability to remove running applications is 

impossible.  Therefore any method that changes the system must allow 

their applications to continue running.

And I thought of a method.

By coding the date into a character field, effectively in base 32, it 

would be possible to encode a larger date and still only use 6 characters.
By encoding the year to use the letters of the alphabet, e.g. AA through 

ZZ plus A0 through Z0, it is possible to cover more than 900 years, e.g.
start counting with 1400 through 2300, thus covering any date that could 

have occurred during civilization.

In fact, if one wants to encode the month and day - Month encoded to add
A,B and C and day encoded as 1-9 and A-V, it is possible to use 4 digits
for the year and still fit everything into 6 bytes.  Or encode both and
fit everything into 4 bytes. 


This would also then work for places using packed decimal for the 

six-digit year and thus only allowing 4 bytes.  


One of the things that is necessary is to make programs expecting numbers
fail so that they can be changed, although it would be better to find the
programs that use date fields and change them before they crash.  Programs
that read these records will have to expect both old and new format
records, while programs that write them should only output the new format. 


The point is that with many sites having hundreds or even thousands of 

programs, the effort could be equivalent to three full-time people over a 

three year period at some sites.  (Some companies have thousands or tens of 

thousands of programs in their libraries.)  This is extra and additional 

maintenance on top of current maintenance.  Expensive overhead that will 

get worse in the future as it needs to be more urgently done.

What is needed are automated searching and checking facilities to find 

programs that manipulate dates and change those programs to handle a new 

date format using this compressed date format I have thought of.  


If we do not make the changes, we could be looking at failed programs, 

massive errors, disasters and setbacks that could produce serious, 

perhaps even fatal problems.  It can't be done in a hurry in the last 6 

months of 1999.

Let us not forget the amount of time needed to do updates, which could be
days or weeks, depending on how good the automated tools are and how many 

applications they have.

What do we need to do?

(1).  If your site has inhouse applications, and lots of source files, 

      you need to push for the acquisition of automated checking tools.
(2).  You need to push for the manpower and resources necessary to do the 

      work now rather than later, because "later" won't be budgeted for.
(3).  You need to push for the updating of databases to allow full
      8-digit dates.
(4).  Push for all reports to eliminate use of 6-digit dates, even in
      display fields.
(5).  Find out what your vendor is doing if you use canned applications.

If we work on the problem now while there is time, we can do this with 

less error and better control, then trying to rush fixes in November of 

1999 when errors could spell disaster.

If you have better ideas on how to solve the six-digit problem, please 

write back.

----
To Reply to this message, write to <PROBLEMS at TDR.COM>; for private 

replies or subscriptions use <problems-request at tdr.com>; or use
newsgroup <tdr.problems>.  Please feel free to redistribute this article 

widely.

This message is file ftp.digex.net:/pub/access/tdarcos/0026