Version 2.3 - May 5, 1998


See question 6.3 for information on how to obtain a copy of this FAQ.

Maintained and edited by Robert J. Sandler .

Originally created by John Moffitt.

See question 7.1 for a list of contributors.


Copyright 1995, 1996, 1997, 1998 Robert J. Sandler. All rights reserved.

Contains material copyright by others.

Permission is granted to copy and distribute this document by any means,

provided that it is copied in its entirety, including this notice and the

disclaimer below, and that no fee is charged other than the actual cost of

transmission or reproduction or the standard connection-time charges on a

BBS, on-line service, or Internet connection. It may not be distributed for

financial gain or included in a commercial collection or compilation

without prior permission from the copyright owner.

Most company names and product names mentioned in this document are

trademarks or registered trademarks of the respective companies.


While the information contained in this document is believed to be

accurate, Robert J. Sandler, Peter de Jager, de Jager & Company Limited,

The Tenagra Corporation, and the contributors do not guarantee the

accuracy, adequacy, or completeness of the information, and assume no

responsibility for errors or omissions, nor any liability for damages

resulting from the use of this information. The views and opinions

expressed in this document do not necessarily reflect the position of the

maintainer. Affiliations are given for identification purposes only.



Disclaimer - Company name changed to de Jager & Company Limited.

Question 1.2 - Updated web address for The Tenagra Corporation.

Question 1.5 - Added item about IGZEDT4.

Question 1.6 - Updated comment about sorting dates with two-digit years.

Question 1.7 - All information about specific products has been moved to

Section 2, Questions 2.1 and 2.6 through 2.13, in order to put all product-

specific information together, with a separate question for each product.

Minor change in the wording of the question. Added cross-reference to

Question 6.3.

Question 2.1 - Added information about BIOS testing programs and about

Award BIOS. Additional information moved from Question 1.7. Added cross-

reference to Question 2.8 concerning File Manager. Deleted some old


Questions 2.1 through 2.5 - Question changed to just the name of the


Question 2.2 - Added information about Linux.

Question 2.3 - Added correction about VMS time format.

Question 2.4 - Added comment on applications.

Question 2.5 - Added new answer about updated information on Novell web


Questions 2.6 through 2.13 - Moved from Question 1.7 and reorganized.

Question 2.8 - Added information about File Manager fixes.

Question 2.9 - Added cross-reference to Question 2.8.

Question 2.10 - Added cross-reference to Question 2.15. Added information

about the 1900 anomaly and about a year-2000 spreadsheet FAQ. Removed a


Questions 2.14 - 2.20 - New questions.

Question 3.1 - Corrected the quotation and attribution from the Risks

forum. (Thanks to Jonathan Swinton  for pointing out the

error.) Removed an article at the request of the sender.

Question 3.4 - Added an additional answer.

Question 3.5 - New question.

Question 4.4 - Added two more answers.

Question 5.3 - Added comparison of expansion, windowing, and encapsulation


Question 5.5 - Revised first answer. Added new material.

Question 5.6 - Completely replaced with a different question.

Question 5.11 - Updated affiliation and e-mail address for Don Estes. Added

note about patent covering program encapsulation.

Questions 5.12 and 5.13 - New questions.

Section 6 reorganized. Question 6.3 split into two questions, 6.3 and 6.4.

Former Question 6.4 is now 6.6. Questions 6.6 and 6.7 renumbered to 6.7 and


Question 6.3 - Revised information about Year 2000 Mailing List and how to

obtain this FAQ. Added cross-reference to question 6.4 for the

book store. Added items about the SIM on-line conference, the Y2K Links web

site, and Microsoft's Year 2000 web site. Added three items about web sites

that list product status. Added clarification of ITAA certification.

Question 6.4 - Added information about the book store and the

U.S. GAO assessment guide.

Question 6.7 - Shortened question. New phone number, e-mail address, and

URL for The Source Recovery Company.

Question 7.1 - Added new contributors to list.

I have tried to include the date that an article or answer was written,

following the author's name. Any article with a name but no date is

probably from 1995 or early 1996.


PREFACE -- A Few Quotations to Set the Mood


"The alternative to addressing the year 2000 will be going out of


-- Kevin Schick, The Gartner Group

The year 2000 date-change project presents organizations with one of the

most interesting challenges since the dawn of the computer age. It is

potentially the largest project the IS department has ever attempted. It

has life-threatening implications for the business. It has an absolute,

immovable deadline. It is a significant, unplanned, out-of-budget expense

and it has no sponsor.

-- James A. Jones, Director of Year 2000 Group, Information Management

Forum, in CIO Magazine, September 15, 1996

Mainframers are in serious denial these days about what will happen a

couple of seconds after midnight on Dec. 31, 1999, when many thousands of

mainframe programs handling critical business applications discover they

don't know how to deal with dates that include the year 2000.

It's not that the world's COBOL programmers don't know how to fix the

problem, or that current mainframe programming languages are incapable of

handling dates in the next century. The problem is that mountain of old,

fragile mainframe code still in use in business around the world - often

running processes that lie right at the heart of a company's business.

These applications have been around so long, were developed in such tangles

of spaghetti code, and have been modified in undocumented ways so many

times that no one now employed by the company knows how to fix them. In

some cases, no one now alive knows how to fix them.

-- Jim Seymour, PC Magazine, Mar. 16, 1993





1.1 What is the year 2000 problem?

1.2 How serious is the year 2000 problem?

1.3 What is the year 2000 day-of-the-week problem?

1.4 What is the 1999 problem?

1.5 Is this only a COBOL problem?

1.6 What is the date-in-key problem?

1.7 What products have been found to have, or not have, year-2000 problems?

1.8 What are the special year 2000 problems about tape archives?

1.9 How can I tell how big the problem is in my company?

1.10 Does anyone have any cost data or statistics on what it will cost to

modify COBOL programs?

1.11 What happens to date programs when you try to use older more

historical dates and at various locations around the world?

1.12 Are there some hidden problems (i.e. date thresholds) related to date

storage that we have not yet thought of (or discussed)?



(a) Why does the BIOS date (year) seem to roll from 1999 to 1900?

(b) Why does DOS (and Win95) seem to change the BIOS date to Jan 4, 1980?

2.2 UNIX, Linux, and/or C/C++

2.3 VMS

2.4 Apple Macintosh

2.5 Novell Netware

2.6 IBM Mainframe MVS, ESA, and OS/390

2.7 IBM Mainframe VM

2.8 Windows 3.1

2.9 Windows 95

2.10 Excel

2.11 Paradox

2.12 Quicken

2.13 Ada

2.14 Sorting

2.15 Microsoft Products

2.16 Windows NT

2.17 Windows 98

2.18 PKZIP

2.19 SAS

2.20 Oracle


3.1 What is the potential social/societal impact?

3.2 Has mankind ever had to deal with this kind of problem before?

3.3 Anyone got any idea what possible Y2K implications are known with

reference to nuclear missiles and other military, software-controlled


3.4 Does the Global Positioning System (GPS) have a year 2000 problem?

3.5 How are credit card companies handling year-2000 expiration dates?


4.1 Is 2000 a leap year?

4.2 Is there an ISO, ANSI, NIST, or other standard that defines the

Gregorian calendar or the rules for leap year?

4.3 On what date will the 21st century begin?

4.4 How will we refer to those initial decades?

4.5 What is a Julian date?

4.6 What is an integer date? What is a Lilian date?


5.1 What are the general programming (standards?) approaches that one could

take to solve the various year 2000 problems?

5.2 In a large system fix, what are the trade-offs in changing the data

versus changing the application programs?

5.3 What strategies are being considered for solving the following year

2000 problems: break point? field expansion? hex code?

5.4 Why should we try to have standardized date computation routines? Why

don't we ALREADY have standardized date computation routines?

5.5 Why is testing year-2000 code so hard?

5.6 What are the critical dates that programs must be tested with?

5.7 My concern centers on those systems that have already hit their "event

horizons" and have been fixed using whatever solution.

(a) Is it possible that these systems will still experience problems come

the first of January on the year 2000?

(b) If System A implements Fix1 instead of Fix2, does this mean System B

later has to implement Fix1 also, for compatibility purposes?

(c) Finally, is it possible that the immediate fixes today on System A may

adversely affect other systems which depend System A, either now (and the

other systems don't know it yet) or after the first of January on the year


5.8 What is a Bridge program? Why should I use a Bridge program? Is it a

permanent solution for Y2K problems?

5.9 What are the problems with converting and testing a worldwide connected

system of computers?

5.10 How does one pull together a reasonable Y2K plan, when management is

clearly reluctant to devote adequate resources to even determine the most

rudimentary extent of the problem?

5.11 What is encapsulation?

5.12 What is windowing?

5.13 How can you properly sort dates with two-digit years?


6.1 Who provides tools and consulting services to help with our Y2K

conversion efforts?

6.2 What role can the Internet take in the solution of the Y2K problems?

6.3 What mailing lists, newsgroups, archives and other Y2K references are

available on the Internet?

6.4 What books and other published references are available on this


6.5 What standards exist for computer representation of dates? Where can I

get copies of these standards? Are they available on the Internet?

6.6 I have to assess how much of a problem we have with legacy assembler

code. Any ideas/products/vendors to facilitate the analysis?

6.7 I've discovered that I have compiled applications that I do not have

the source code for. How can I get the source code back in order to fix it?

6.8 Is there a Year 2000 user group near me?


7.1 Contributors

7.2 Copyright and Permission

7.3 Disclaimer



1.1 What is the year 2000 problem?


People see TIME as an endless continuum.

Computers record time and dates as just another number, and as time

progresses the time number gets bigger - so a FUTURE date is always LARGER

than a PAST date.

Some programmers interfered with this nice progression by deleting the

century digits from dates - they didn't think they would be needed!

Without the century digits the last day of this millennium will be

99-12-31, and after the stroke of midnight many computers will see January

1, 2000, as 00-01-01 - a SMALLER number than the day before - time will

appear to have REVERSED.

OLD will seem YOUNG, a FEW moments will seem like an ENTIRE century, FUTURE

events will have ALREADY occurred.

-- Duncan G. Connall , Global Software, Inc.


"As the year 2000 approaches, MIS organizations across the country have

been wrestling with the problem of reprogramming date-dependent systems.

Date-dependency refers to how most programs depend on the manner in which

dates are represented in order to run computations. But as of the first day

of the next decade, the way in which days, months, and years have been

identified up to now will, in many cases, become invalid. For example,

COBOL programs currently represent Feb. 26, 1990 as 900226, and Jan. 1,

1991 as 910101, allowing the computer to compare the two numbers and

correctly assume that the smaller number represents the earlier date. On

Jan. 1, 2000, or 000101, however, those comparisons will fall apart."

-- Informationweek, Feb. 18, 1991


1.2 How serious is the year 2000 problem?

Selected comments from the Year 2000 mailing list:


According to Gartner group, 90% of the applications will be affected by the

Date 2000 problem, and systems will crash, if the century problem is not

corrected before 1999. 20% of business applications will fail due to date

computations in the year 1995. Most major corporations are expected to

spend about $50-100 million. The Gartner Group estimates "A medium size

shop with approximately 8000 programs, each program averages 1500 LOC, and

a data reference to LOC ratio of 1:50 will cost in the range of

$450/program to $600/program or $3.6-$4.8 million for the entire


There are an estimated 180 billion lines of COBOL code on MVS, and about

900,000 COBOL programmers dedicated to maintaining this code. If you would

like to correct the date change operation, using automation tools and

spread over a three year period 1996-1998, with out affecting the regular

maintenance and new development, a minimum of 200,000 COBOL programmers

should be added to the existing pool (Under the assumption that 1999 would

be used, for fire-fighting measures). Going by the Gartner estimates, the

total cost to correct the entire COBOL code would be US $48-65 billion. All

these only for COBOL. Add Assembler, PL/I, Pick, ...

-- Raghavendra Rao , Satyam Computer Services



A bit more directly ... a major factor in the complexity of the Y2K issue

is that we're dealing with many, many systems that have effectively been on

autopilot for perhaps decades. What & how these systems work is entirely

unknown to the current owners. The fact that System A somehow effects

System Z is a very difficult & expensive piece of knowledge to have.


FYI, The July 1995 issue of CFO "The Magazine for Senior Financial

Executives" ran a two page story by John Xenakis entitled: "The Millennium

Bug, The Fin De Siecle Computer Virus -- COBOL programming can't handle

dates after December 31, 1999. And don't count on your outsourcer to fix

the problem."

The story paints a picture of a catastrophe in the making. According to

Benny Popek of Coopers & Lybrand LLP, "This problem is so big that we will

consider these bugs to be out of the scope of our normal software

maintenance contracts. For those clients who insist that we should take

responsibility, we'll exercise the cancellation clause and terminate the

outsourcing contract."

And another quote from Popek, "We've found that a lot of our clients are in

denial. We spoke to one CIO who just refused to deal with the problem,

since he's going to retire next year."

-- Cliff Kurtzman , The Tenagra Corporation,


Many of the denial party are saying they are going third party and so that

will fix everything. But the reality is that there are many buried issues

here as well such as conversion of existing systems and access to

historical data (Data Dimensions published a very interesting Millennium

Journal article about 3 months ago on third party issues). But it seems

like it is human nature to try to push off the inevitable. Unfortunately

for many, 2000 is a non-negotiable date. No one (not even IBM) can stop it.

-- Joe Warren , TransCentury Data Systems (in 1995)


This the first time I'm going to state some views 'publicly.' I've been

holding back, because the title 'Chicken Little' is hardly one that sits

well with me... nor is it one that reporters accept as 'credible.' AND the

media have been remiss in helping businesses understand this problem,

instead of describing it in detail, they've been treating it as 'Scientist

Predicts All Computers Will Explode in 2000!' Hardly worthwhile reading

material for a CEO, CFO or the Chair of the Board.

Take a look at the input screens of most accounting systems. These systems,

typically legacy systems, the ones most likely to fail, control the true

lifeblood of the organization... not INFORMATION! but something more

mundane. Dollars.

Most of these systems accept ONLY 2-digit years. Why? Possibly because MOST

data entry into these systems is date information and typing those 2 extra

digits, time after time after time would be boring, tedious, inefficient

and generally a pain in the arm.

Try entering 00 into one of these screens... you'll likely get... a data

exception... or it won't accept the data as valid... or it will accept

it... all of these will cause problems. The first two reject the data...

that's good. The last is scary... will it process that 00 correctly?

Based on my personal programming experience, I'll predict that 90% of

accounting systems will either reject the data or fail. To me, that's more

than a reasonable estimate. Assume I'm off by 100% ... that only 45% of

Accounting systems die. Watch what happens.

Okay... now it's 'whenever this happens' sometime between now and Day 1,

Y2K. Most likely in 1999...

Your accounting system is dead in the water. What are the implications?

Well... The most simple consequence is you can't cut or pay an invoice. No

money will come into or leave your organization... (assume payroll is

working... otherwise things only get worse... faster)

There are some organizations so literally computer dependant, they will NOT

be able to get that cash flow moving EVEN if they hire 100 accounting

clerks. What invoices do you pay? What do you bill? EVERYTHING is in the

computer...The clock struck Jan 1, 2000 and the computer had a stroke.

Other companies will be able to generate a trickle of billing and payments

by hiring manual labour... (How many clerks could you hire tomorrow? by

next week?)

How FAST can you get an accounting system going? Can you fix the one you

have? Or do you install a new one... Several of us, on this list have

installed new accounting systems under pressure... how long did it take? 9

months? 6 Months?? 3 Months???

How fast can you install a new system when the entire company is a)

screaming at you? and b) Blaming you? and c) the old system is dead and

dead computers leave no audit trails.

How stable will your project team be ... when the company down the street

is in the same predicament and offers huge 'incentives' to your staff to

jump ship and help them? Will you lose your best and brightest or will you

lose the bottom of your hope?

If you can't get your accounting system up and running in three months

you're dead. Out of business, kaput ... Today's organizations CANNOT

survive three months without cash flow. (and yes there WILL be a run on the

banks as companies get desperate for cash advances NOW!)

Okay ... assume you have the very best and the very brightest ... your

system is up and running in a week. (Loud laughter from the back of the

room... not appreciated... nevertheless, the speaker continues unperturbed)

Remember that 45% failure rate? The VERY optimistic one? It means that 45%

of the people you bill will not be able to pay. This is 100% out of your

control ... 45% of your cash flow will be stopped even if your system is

fine. Even if you have NO Y2K problems ... 45% of your clients do. So do

45% of your vendors ... can you order your raw materials if THEIR systems

are dead? Oh, and remember that you've been pushing JIT inventory for years

now ... your stock levels are deliberately low ... based on the assumption

that the NEXT delivery is next week.

Can you build a car with 45% of the parts? Can you ship a product when 45%

of the distribution channel is 'troubled' by the Y2K problem? Can you sell

your product to me... If I have a Y2K problem? As Ted Nelson said in

ComputerLib "Everything is InterTwingled"

Can you survive with 45% of your cash flow?

Will your computing staff stay around with salaries going through the roof?

Especially for those who have PROVEN conclusively they can write Y2K

compliant code!!!

How many companies need to fail...10% ? 25% ? 45% ? before a critical mass

is achieved and it all comes tumbling down like a house of cards? We are

all inter-dependant upon each other... we might NOT pass 'data' back and

forth... BUT we DO pass invoices and other accounting and inventory

information back and forth... managed by systems totally dependent upon

digit deficient data.

-- Peter de Jager  (in 1995)


1.3 What is the year 2000 day-of-the-week problem?

Most programs that calculate the day of the week using only the last two

digits of the year will get wrong answers for January 1, 2000, and all

subsequent dates. This is because the formulas they use implicitly assume

that the dates are in the 1900s. January 1, 1900, was a Monday, but January

1, 2000, will be a Saturday.

-- Robert J. Sandler 


1.4 What is the 1999 problem?


Many people aware of a related problem that might happen for all computer

files created on Sept. 9, 1999? This date (9/9/99) was popular back in the

1980's as an expiration date for (forever) archived data that you wanted to

have 'no expiration date'.


And of course, if you haven't done anything about the year 2000 by this

time, you are very likely too late to avoid severe computer problems by the

start of business January 3rd in the year 2000.


I was chided by one of my customers Friday for the WSJ piece on me that

said Jan 1, 2000 is the big problem rollover. She emphasized that Jan 1,

1999 is the big problem. At that point (at least from the viewpoint of

their financial & distribution systems) when systems attempt to rollover &

reset themselves is when she said disaster will strike & things will

immediately grind to a halt.

For systems that look a year ahead, the witching hour is 1/1/99.

Every commercial system (banking, mutual funds, payroll) I ever worked on

was typically running 'year-end' jobs well into the middle of the next

year. There was always the flat our panic to get 1099's and W2's out by the

end of January & then lots & lots of runs & reruns of other strange

corrections & adjustments & foreign tax reports, etc.

-- David Eddy , Global Software, Inc.


1.5 Is this only a COBOL problem?

No. The problem has little to do with the language used. Year 2000 problems

have been found in practically every programming language.


Could ANY language have prevented the current Y2K problem?

No, because Y2K is a management (planning) problem, not a technical OR a

languages problem. However there are plenty of Y2K COBOL problems!


We might want to have a section that just lists the known languages by

platform? So far virtually all the discussions seem to revolve around (1)

COBOL, (2) PL/1, and (3) Assembler, as if Focus, Nomad, Ramis, Easytrieve,

DYL260, DYL280, ADF, SAS, CICS Command level, CICS macro level, ETC (yes,

that's also a language), etc. all simply don't exist.

There are plenty of shops that are running languages officially declared

dead & abandoned by the vendor. Prime example is OS/VS COBOL. IBM's

declared it dead for well over a decade. I've been told that perhaps 40% of

IBM mainframe shops are still running OS/VS COBOL.

I keep meaning to call Capers Jones to see if he'll at least release a list

of the 400 languages he collects metrics on. I'd be willing to guess that

perhaps 200 of these are hardware specific military/proprietary languages.

Best I can do is name perhaps 20 commercial languages.

I'd vote for at least giving some visibility to the very real fact that

there are plenty of languages still in active use that don't appear in

ComputerWorld or InformationWeek.

As you can see I'm only looking at the world through big (little?) blue

glasses. I'd have a hard time even listing the major hardware vendors which

each must have their own plethora of unique languages (VAX, HP, DG, Sun,

Apollo, Honeywell, Univac, GE, Burroughs, etc).

-- David Eddy , Global Software, Inc.


I am a networking specialist (IBM/SNA, TCP/IP, Localnet, etc.) On this

moment I am not working because of Multiple Sclerosis but via Internet I

want to keep me up to date and can share experience with you.

I see a lot of problems in the mainframe area (all platforms). There are a

lot of exits written by good people (assembler) in networking applications

databases and other applications that work with date/time. The exits are

used for security logging and accounting in networks. At the day "X" there

are a lot of problems with connected database's etc. All systems of

international operating organisations must have a standard date implemented

in all software.

I work already 25 years in this area and saw a lot of software written by

people that are not working anymore in the place where they made the

exits', applications etc.

Most of the stuff is not documented.

I think that global operating or network connected systems will have a lot

of problems that cost a lot when they don't start a global project to get

the date problem fixed.

You cannot receive records from another system that is using a changed date


-- Hans Goossens 


I'd like to point out a couple of items regarding COBOL.

1. The older COBOL/VS and COBOL II do not now, nor ever will support

4-digit years. IBM has stated this multiple times. They DO provide 4-digit

support in COBOL/370 (new name is COBOL for MVS & VM) and LE/370 (new name

is Language Environment for MVS & VM).

2. Also, any future improvements, to support client/server applications,

etc., will only be made to COBOL/370.

Since COBOL/VS and most likely COBOL II won't be supported by 2000, you'll

have to convert at some point. Why not do both changes at one time?

--, 16 Jun 1995


IBM has created APAR PN84080 which allows COBOL II to get the current date

with a 4 digit year: Sample code:


05 WS-FD-YYYY pic 9999.

05 WS-FD-MM pic 99.

05 WS-FD-DD pic 99.


-- David Alcock , 9 Feb 1998


I was browsing in our HP/3000 COBOL II/XL manual looking for date-stuff and

I see that there is something called "CURRENT-DATE" which returns an 8 byte

field in the format 99/99/99 representing mm/dd/yy. There is also a

function, as in "FUNCTION CURRENT-DATE" which returns everything you ever

wanted to know about the date, time, etc. - even GMT deviation - including

the year with the century included, as in 1995. The aforementioned

"CURRENT-DATE" gets its values from the software clock while the "FUNCTION

CURRENT-DATE" gets its info from the hardware clock.

-- Francis D. MacLellan


1.6 What is the date-in-key problem?

The basic problem is that many systems use a date as part of the key of an

indexed file. This becomes a problem if the date has a two-digit year and

the application depends on records in the file being in chronological

order. Even if processing of the data does not depend on the records being

in chronological order, it could result in records being listed in the

wrong order in reports or on-screen displays. In 2000 and later, an

application that is supposed to show the most recent items at the top, or

on the first screen, would instead show 1999 items first.


Sorting dates in VSAM keys

I have received a couple of inquiries as to whether there will be something

similar to the sorting capability being provided in DFSORT for Year 2000

will also be available for VSAM. As you may notice from the time it has

taken me to respond to this inquiry, the answer is not a simple one.

The interpretation of keys was never expected to be a VSAM responsibility.

Therefore, the key is treated as a string of binary values based on the

EBCDIC values of the characters in the code page used to enter the data.

Therefore, the only valid order for VSAM KSDS to store data is in binary

order. I agree that the actual usage of the keys often assigns meaning

beyond what is recognizable by the programming support behind the

manipulation of these keys. However, at this time, we do not plan on

supporting any VSAM code to assist in proper sorting of dates within VSAM


We do recognize the need to look at the fact that the binary representation

of data is not always the proper way to present data to humans. Other sort

orderings are needed to handle two digit years or to have culturally

correct sorting (another discussion in itself so that the sorted output

uses the same alphabetical ordering as users of the language intend.) I do

not expect that IBM will offer anything to address this issue as part of

our YEAR 2000 support available by the end of 1996.

Now, that does not mean that we do not recognize this as a product

shortcoming. An interim solution would be to use DFSORT to reorder the

output records so that they are presented correctly using a windowing

technique with the appropriate starting value specified. If the records are

too complex to sort (such as for multi-line output produced from a single

key), then it will be necessary to obtain a list of the keys of the desired

records, sort the keys, and obtain the records in the desired output order.

I recognize that none of this is easy.

For those of you who are VSAM KSDS users, I recommend that you evaluate the

impact of this reliance on the interpretation of the keys to produce the

necessary output. You can contact your IBM representative and they will be

glad to assist you in creating a formal request for this requirement,

giving details as to why other methods won't work and its impact. Once this

is done the first time, others can just have their IBM representative

concur with the existing requirement, adding account specific information.

The amount of interest shown in solving 2-digit year designation with VSAM

keys will influence the likelihood and timing of our (IBM) providing a


-- Sherry L. Goncharsky , IBM Strategy/Requirements,

SSD Software Products, February 26, 1996


Of course, it's good to take the long view, and clearly 4-digit years are

where we all want to be. But I think people are underestimating the

difficulty in getting there. One large IBM mainframe COBOL app I am

familiar with has nearly 4000 non-DBMS files and references over 3800

unique copy books. Data is passed among some 1600 batch and 500 TP

programs, but also data is sent to and from outside applications and

organizations via FTP and other means. What's worse, 6 separate copies of

this application are run. It would take until the year 3000 to change one

file at a time, but if you were to do many at once the effect would cascade

throughout the system (and beyond). All programs and files affected would

have to be deployed at the same time (or bridges constructed, also

complex). Falling back in case of an error would be difficult or

impossible, since earlier program versions would use different file

formats. Testing, which would be crucial, would require new test data.

Etc., etc.

We are therefore working on support (as an alternative) for a program-logic

based solution. Failure to consider the century in comparing or calculating

dates amounts to a bug which must be fixed. Likewise with special handling

of 00 or 99 (e.g., using them to mean null). Sorting on date is a special

case -- see below. Reports and screens would be looked at case by case for

readability. There could be bugs there as well, such as hard-coding 19xx or

zero-suppressing the year.

We have created a standard date routine using a sliding date window to

"infer" the century in performing calculations on 2-digit years. The older

routines were also upgraded, and in fact use the same code. The 00-99 range

is divided into a 25-year forward portion (projected dates), and a 75-year

backward portion (current year and 74 past years). The routine calculates a

"forward century" (add 25 to current 4-digit year, take 2 hi-order digits),

a "forward century endpoint" (same calculation, low order digits), and a

"backward century" (subtract 75 from the current century). A special

function makes these values available in open code, so programs can do

their own century inference (e.g., in comparing dates, which could happen

millions of time in a run). All date CALCULATIONS now hard-coded are to use

the new routine, and for ease of use we have provided a macro to generate

code to invoke it.

We recommend a conventional structure to hold the date with 4-digit year,

and provide an ISPF edit macro to generate it. We also provide a macro

which (assuming the conventions) generates code to move the date and infer

the century. In the example below, EFFECTIVE-DATE is a Julian date in a

user program and has a 2-digit year.





007600 10 FILLER PIC 999.




017500 ELSE


This works even for special cases. E.g., in a year ending in 74, all years

would be the current century. A 100-0 window (all dates current or

historical, none in the future) would even work well enough. Note also that

(contrary to opinion in this forum) a date window can, when a MINIMUM value

can be applied, handle a range greater than 100 years. E.g., if you have no

maximum retirement age, but have a minimum of, say, 16, then if in 1995 you

encounter a birth date of 90 you could infer an age of 105 years, not 5.

This might even be practical -- we might have 100-year-old U.S. federal

employees, but we surely don't have any who are 116. Even Strom Thurmond

isn't that old.

[Sorting data with 2-digit years as keys is no longer a problem for this

approach. The major sort products -- DFSORT and SyncSort -- have year-2000

features that allow sorting, merging, and transformation of a wide variety

of two-digit-year dates using a fixed or sliding century window. See

Question 5.13 below for more information. -- RJS 12/97]

One nasty problem which would seem to require a file change would be a data

base key with a 2-digit year. And even with a general "program logic"

approach like the above, there would no doubt be other files which would

make sense to change, mandated changes (IRS, SSA, etc.), bridges to build

to/from outside apps, etc. Hope to see continued discussion on this issue.

-- Gene Lynd , Defense Logistics Agency


I appreciated your candor on 2-digit years and the real-life example of

where you have seen a need to live with them at times. It's almost

"politically incorrect" to support the logic-change approach, yet it is

certainly viable under certain circumstances.

The year in the key is the potential killer, here. My big concern is with

on-line screens which list records in key sequence. User-written on-line

sorts are a real pain, though possible. I am considering asking some of our

clients if the could live with the fact that 00mmdd dates would precede

99mmdd dates. It's a question worth asking. (A major client even suggested

the same!) If they could make the adaptations for certain applications, we

could save ourselves a LOT of time. (Not that we wouldn't have to add date-

manipulation routines to some programs, but it would be far fewer programs

needing conversion.) I HATE not giving our clients perfect, user-friendly

screens. But is it best for the enterprise to spend immense resources on

correcting something which people might be able to adapt to?

I'd like to see some further discussion/ideas on the date-in-key problem.

Some possible questions:

* Does everyone see it as insurmountable without changing to 4-digit years,

or are some finding other ways to deal with it?

* Within systems whose data is not required to span 100's of years (e.g. 7-

year statute of limitations type data), has anyone discovered a situation

where it is IMPOSSIBLE to deal with the problem via code changes?

* Same question as above but change "IMPOSSIBLE" to "unrealistic".

* Has anyone already performed a Y2K conversion on a system without

expanding a date-in-key? (We've had reports of people converting via code-

only changes, but we don't know if there were date-in-key cases involved.)

-- Brian Christenson 


1.7 What products have been found to have, or not have, year-2000 problems?

See Section 2 for information about specific products.

See Question 6.3 for web sites that list the compliance status of products.


1.8 What are the special year 2000 problems about tape archives?


How many otherwise permanent archive tapes (or other data storage media)

will "expire" in 1999 or 1/1/2000 since "99" or "99/99/99" was used to

indicate permanent storage?

-- John L. Horton 


Take a close look at the file creation data attached to MOST (all?) files.

Will backup/archival system be able to tell when a file was created? Is a

file with a creation date of 01/01/00 to be moved off to backup ...

possibly erased because it has not been used since 01/01/1900?


1.9 How can I tell how big the problem is in my company?


An exceedingly difficult question to answer with any degree of certainty.

Essential problem with saying "how big" is the fact that most software

consuming organizations (banks, insurance companies, mutual funds,

government organizations, etc.) simply don't have a clue how much software

they have. In fact most are entirely oblivious to the fact that they don't

know they don't know.


I think that for any company who has a multimillion dollar problem, there

will be a complex mix of solutions. After technical analysis (what IS

technically wrong) a functional analysis (what WILL lead to functional

defects) must be done. (BTW, this is something that has to be done by your

own staff, because Y2K-solution providers don't have a clue how your

processes work, nor did they include it in the contract). From this

functional analysis of your system portfolio, a migration strategy can be

determined. This will include a mix of the 3 solutions, depending on

business exposure and cost-effectiveness and a dozen of other factors. I

think Christenson ( posted some thoughts about this.

Also there are more alternatives. You can add adapters between systems

(solves some problems). You can decide to do nothing and introduce

procedural corrective measures. You can buy new systems and try to get rid

of the legacy system which was outdated anyway. Etc.

I feel that much of the discussion is from a software engineering point of

view. As somebody said before: Y2K is not a technical problem; it's a

planning problem (and of course a financial one).

-- Serge Bouwens  PTT Telecom, Netherlands


A major factor in the complexity of the Y2K issue is that we're dealing

with many, many systems that have effectively been on autopilot for perhaps

decades. What & how these systems work is entirely unknown to their current

owners. The fact that System A somehow effects System Z is a very difficult

& expensive piece of knowledge to have.

This jibes with my experience also. I have been working in the software

field for 13 years, and in software re-engineering for 6 years. In this

time, I have seen many such examples:

- Sites that managed their portfolios, yet we found applications they were

not aware of or had forgotten about.

- Sites that insisted "that application is obsolete, so it doesn't need to

be re-engineered", only to discover that the users thought otherwise (I

would watch this one during Y2K projects!).

- Users & techies who "know the system like the back of their hand", only

to be contradicted by the source code.

- Sites that insisted their applications were "clean", only to discover

missing source code, modules that would not compile, database schemas that

were not consistent with the actual database, modules that are never


We quickly learned to do a thorough audit before beginning work, and to

treat every piece of documentation and every statement by the people who

manage, maintain and use the systems as suspect. The audit is often a

humbling experience for our customers.

To make matters worse, colleagues who have been in the software business

longer tell me that many of these sites are among the better managed that

they have seen!


I have one client with a US $700 million (revenue) business. Last I looked,

they were just at the entry point to the Fortune 500 in revenue size. Their

technical staff is 25. They are EXCEEDINGLY well organized. Unlike

virtually all other organizations of any size, they are at least starting

from a firm baseline & know precisely where their systems are.

Their first estimate was 10 man-years of effort. Their second estimate

(based on more detailed knowledge) came out at 15 man-years! That's 60% of

their staff for a solid year if all other work is put on hold. And they're

not real comfortable with their estimates on what it's going to take to

test their work.

-- David Eddy , Global Software, Inc.


I am in the Application Center of Excellence I.S. Software Factory at Bell

Atlantic. I am currently involved with the task of rounding up numbers on

lines of code, languages used, identifying 'home grown' code as opposed to

vendor supplied/supported code, etc. for the purpose of the initial

quantifying of the problem to upper management. As far as systems

environment is concerned ... we have it all, mainframe, client server,

stand alone P.C. applications, you name it ... we got it. Progress on the

project is increasing on a daily basis as we move through this preparatory




1.10 Does anyone have any cost data or statistics on what it will cost to

modify COBOL programs?


Most major corporations are expected to spend about $50-100 million. The

Gartner Group estimates "A medium size shop with approximately 8000

programs, each program averages 1500 LOC (line of code), and a data

reference to LOC ratio of 1:50 will cost in the range of $450/program to

$600/program or $3.6-$4.8 million for the entire initiative".

There are an estimated 180 billion lines of COBOL code on MVS, and about

900,000 COBOL programmers dedicated to maintaining this code. If you would

like to correct the date change operation, using automation tools and

spread over a three year period 1996-1998, with out affecting the regular

maintenance and new development, a minimum of 200,000 COBOL programmers

should be added to the existing pool (Under the assumption that 1999 would

be used, for fire-fighting measures). Going by the Gartner estimate, the

total cost to correct the entire COBOL code would be US $48-65 billion.


1.11 What happens to date programs when you try to use older more

historical dates and at various locations around the world?

Historical dates that might be stored in computer files could come from

land ownership records, various business and financial records, government

records, genealogy, and many other historical documents.

The Gregorian calendar was adopted at different times in different

countries. The Catholic countries of Europe accepted it in 1582, as decreed

by Pope Gregory XIII, or shortly thereafter. Many Protestant European

countries switched in 1699 or 1700. Great Britain and its colonies made the

change in 1752. Other countries switched at various times, some as late as

the 1920s. China started using the Gregorian calendar in 1912, but used

different year numbers until 1949.

Prior to the Gregorian calendar, different countries used various dates

other than January 1 as the beginning of the year. There were other

variations on the Julian calendar, and some completely different calendars,

like the French Revolutionary Calendar. The year that the calendar was

changed in any country can be particularly confusing, especially if the

date for the beginning of the year was also changed.

What all this means is that dates in historical documents, even some less

than a hundred years old, may not be based on the Gregorian calendar. This

makes any calculation using these dates, such as ages or elapsed time, very

tricky at best.


It's not unreasonable to expect that over the next few decades that much

more historical data will be put into the computerized databases. If you

have very old records, you might need to deal with significantly different

calendar structures.

-- Bear Giles 


After reading all of this, I think that it's very good that the worldwide

computer technology revolution began after the early 20th century. It must

be very tough for programs dealing with old dates! It kind of makes the

year 2000 problem seem easy by comparison.


1.12 Are there some hidden problems (i.e. date thresholds) related to date

storage that we have not yet thought of (or discussed)?


One thing I am interested in is date thresholds (doomsdays) that may not be

obvious at all. Our system, an IBM mainframe based system, carries a day

counter, so many days since the system was first plugged in, and that

counter is of a fixed size, and so somebody has already sat down to figure

when the field would overflow, and it turned out that we are going to do

fine until (I think it is) the year 2055 on that particular one. Most of us

will be dead then; stick the next generation, or the one after.

But the same system also contains another clock/calendar function called

the perpetual minute clock, which carries the number of minutes that have

elapsed since some fixed epoch in the past. That field is 32 bits in

length, and there, too, somebody had already figured out that the minute

and day when somebody will pay the piper. That one is also comfortably far

in the future.

But I thought about that one some more. It is a 32 bit field, sure, and is

good until far in the future. But I said WHAT IF ... what if somebody

manipulated that field using the mainframe address arithmetic in 24 bit

addressing mode? If anybody had happened to do that, the date threshold

would be when the perpetual minute clock overflowed from 24 bits to 25,

wouldn't it? Not when it overflowed out of 32. I did a calculation and

found that this clock will overflow to 25 bits sometime around December of

1997. Oops! That's not terribly far off. And it is just exactly the sort of

error a programmer could make unconsciously, could have made unconsciously

YEARS AGO, and the code would work fine for decades and never attract an

iota of attention.

More importantly, now that I have mentioned it, are there any analogous

hidden booby traps in your code that leap into your awareness, by virtue of

my having described this one?

Note: It seems to me I read somewhere or other that the PICK (?) operating

system had a day clock of this sort, and that doomsday had already struck

in May of this year. Is that correct?

I am going to have to go through our code libraries to see if I can find

any REAL examples.

-- Randall Thomas <>




(a) Why does the BIOS date (year) seem to roll from 1999 to 1900?

(b) Why does DOS (and Win95) seem to change the BIOS date to Jan 4, 1980?


This is just a test. It'll only take five minutes. It won't be painless,

but ... the results may save a lot of anguish in the not too distant


Set the date on your Personal Computer to December 31st 1999. Set the time

to 23:58hrs (11:58pm) and then POWER OFF the computer. Wait at least 3

minutes and then turn the PC back on. Check the date and time. It SHOULD be

a minute or two past midnight, on the morning of Saturday, January 1st

2000... My computer responds with January 4th... 1980. Not exactly what you

would expect.

The problem lies somewhere in your computer. If the system has the wrong

date, then all your software has the wrong date.

The good news is that this was only a test. The bad news is that on Dec

31st 1999, it won't be, it'll be painfully real. More than 80,000,000 PC's

will be switched off as people leave work. When they return, their

computers will be all but useless.

How bad is the problem? How many PCs will really fail? Based upon

predictions of people involved in the year 2000 problem, upwards of 80% of

existing PCs are unreliable.

On Jan 1st 2000, more than 80,000,000 PCs will think the Berlin wall is

still standing and that Trudeau is still the prime Minister of Canada ...

All your applications, Spreadsheets, accounting packages, day-timers,

E-mail systems, even backup cycles will be at risk a few years from now,

unless you solve the problem.

In the meantime your problem is growing. Right now, a new PC is being

installed. Is it year 2000 compatible? What about the PCs you buy tomorrow,

next week and in 1996?

-- Peter de Jager


>From: "PAULYS%DOM10.DOPO1" 

>I have looked into several hardware testing routines and found

>conflicting results and conflicting explanations for those results.

>Specifically, when running Ymark2000 (2000.exe) on a new P166 with a

>AMIBIOS 7/15/95, Ymark finds no flaw in the RTC, but DOSCHK identifies

>the RTC as non-compliant because it fails to convert to 2000 (stays at

>1900). Several sources have told me that the RTC will never roll over

>correctly and that I should ignore the failure of that test component.

>However, other sources say it is important because some programs look

>only at the RTC. Should I reject new hardware from vendors if the RTC

>doesn't roll over to 2000?

No. Although the RTC in a few machines will properly transition from 1999

to 2000, the very large majority of RTCs will not and will therefore fail

DOSCHK's RTC test. Most users can safely disregard that failure and need

only be concerned with the BIOS date, which is actually the CMOS RTC date

passed through the BIOS firmware. The BIOS has an opportunity to correct

the century on its way to an application or to the operating system; some

do, most do not.

Bob Stammer's DOSCHK tests the RTC date, the BIOS date and the DOS

operating system date. NSTL's YMark2000 does not test the RTC date; it

tests the BIOS date alone. The DOS real time date transition does not fail

on any machine, although it will reflect a BIOS date failure after


No common applications use the CMOS RTC date directly, contrary to the

advice given to you. Some applications use the BIOS date, though, and most

use the operating system date. Since the operating system date is

initialized from the BIOS date (at boot), it is the BIOS date that is the

important issue to be tested.

To be complete, the BIOS date needs to be tested at two occasions: in real

time and after a reboot. If the BIOS date transitions from 1999 to 2000 in

real time and then survives a reboot, it is compliant.

Incidentally, there have been no demonstrated failures of leap year

recognition - nor false recognition - in any machine. PC hardware does not

need to be tested for leap years.

Avoid the confusion by using Test2000.Exe, a free, concise and complete PC

hardware year 2000 date diagnostic; it is available on our web page, You may also read Test2000.Txt, Year2000.Txt,

RT2@PTTI.Txt and RighTime.Txt - all available on our web page - if you want

to become knowlegable about PC hardware date and time keeping issues.

-- Tom Becker , The RighTime Company, 22 Aug 1997


For AT-class (286 through Pentiums and clones) PCs running any DOS or


The CMOS RTC hardware maintains a two-digit year (in address 9). The

century (stored in CMOS address 50d and not maintained by the hardware

logic) is not automatically incremented when the year overflows from 99 to

00, so the unfortunate result is that 2000-01-01 00:00:00 will appear to be

1900-01-01 00:00:00 in the CMOS RTC. The BIOS will set and read the

century, but won't maintain it.

DOS and Windows, however, will properly increment the date that they

maintain - if the machine is running at 2000-01-01 00:00:00 - but neither

DOS nor Windows will make the century change in the CMOS RTC. For as long

as the machine continues to run through and after that date, the DOS (and

Windows) date will be correct, but if the machine is rebooted or is started

after 2000-01-01 00:00:00, the CMOS RTC will supply the apparent date of

1900-01-01 to DOS; this is an invalid date to DOS, which internally

represents dates as days since 1980-01-01, so it mishandles it: the

resulting DOS date is 1980-01-04.

I am not aware of any modern AT-class (IBM-compatible) PC which behaves

differently, and if one exists it is non-standard.

-- Tom Becker , The RighTime Company


Comments by Donald G. Davis  about the preceding item,

with responses by Tom Becker, 14 Oct 1996


Are you saying that DOS *cannot* reset the CMOS century, or only that it

doesn't do so automatically?


The latter. DOS does, via BIOS functions, set the date - including the

century byte - anytime either the date or time are set at the OS level.

Although DOS will correctly increment its internal date from 1999 to 2000,

it makes no effort to assure that the CMOS RTC has also made the leap, nor

does the CMOS RTC hardware - as you know - have any provision to increment

the century; it becomes 1900 rather than 2000.


If the former, My PC (a 386-DX clone, AMI BIOS dated 9-15-89, running

MS-DOS 6.22) does behave differently. It agrees in that the CMOS does reset

itself to 1-1-1900 during a rollover from 12-31-1999, whether or not the

machine was turned off at the time. Subsequent behavior depends on whether

the machine was on or off when the rollover occurred; and if on, whether a

DOS date reset had occurred after the rollover.

If the computer was running during the rollover, DOS does increment its

century, and the DOS date remains correct, but is now 100 years later than

the CMOS date (and any BIOS readings from CMOS). This agrees with your

observation. If the computer is turned off at this stage, or if it was

already off during the rollover, the CMOS values of 1-1-1900 will still be

there when it is rebooted.

The CMOS century, and the BIOS RTC functions that depend on it, don't

change until DOS does something to alter them. This doesn't happen

automatically during the rollover, but can be triggered, for example, by

changing the time with the DOS TIME command (even by an arbitrary small

amount that does not directly affect the date).

In the case when the computer has run continuously during and since the

rollover, DOS evidently doesn't read CMOS before such an operation. It

simply writes the DOS date to CMOS, and since that date was correct, CMOS

is reset correctly. If this is done before turning the machine off, both

CMOS and DOS dates will be correct when it is next turned on.


If this date set is done _after_ the 1999-2000 transition but before

powering off, you are correct. Obviously I hope, if it is done before the

transition, it achieves nothing.


DOS does read CMOS (or make BIOS RTC calls?) during startup. In the case

when the computer was off during the rollover--or was turned off before DOS

was triggered to rewrite CMOS--DOS then finds the 1-1-1900 date it

considers invalid, and sets the DOS date to 1-4-1980 instead. At this

stage, DOS and BIOS date functions give entirely different readings, since

BIOS does not reject the CMOS 1900 date. The next DOS operation that writes

to the CMOS date bytes will then kick the 1-4-1980 date into CMOS. After

this CMOS update, DOS and CMOS/BIOS agree again, but both are wrong.

In this case, if the year is then reset explicitly to 2000 with the DOS

DATE command, the CMOS century byte *is* set to 20. This value will remain

until specifically changed, and both DOS and BIOS will give correct dates

when the machine is turned off and restarted thereafter. It seems that, at

least for this PC and DOS 6.22, the year 2000 causes a problem maintaining

the correct date solely because the century byte is the only date/time

value that is not automatically incremented by the CMOS hardware. The

problem's expression is complicated by the DOS mishandling of dates before

1980. Contrary to some suggestions by others in this FAQ, the BIOS routines

do not appear to be responsible; they only reflect the CMOS values. In any

case, the bad date is permanently rectified simply by entering the correct

date in DOS as soon as the year 2000 begins.


Your machine behaves exactly as I think I described the problem. I share

your rejection of the suggestion that the problem is somehow the fault of

the BIOS; it is not the BIOS, but rather the hardware design that

precipitates the error. In later machines the BIOS does play a part in

correcting the error, but only at boot when it can assume that 1900 really

should be 2000.

The summary is this: no machine - even a new "year 2000 compliant" machine

- will increment the CMOS RTC century to 2000 in real time; none. And,

excepting the Award v4.50G BIOS issue, all machines will accept a date set

beyond 2000 which will "stick" appropriately.

The problem is the transition.


I just spent some time playing with this myself. On my PC (a TOSHIBA

T4800), the date rolled over from 12/31/99 to 1/4/80! However, by using the

DOS command DATE, I was able to set my system date forward beyond 2000.

Once I had the date set forward, I was able to create new files which

appeared to have an appropriate creation date (3/15/00 and 2/10/30) for the

date that I had set my system date. FYI, for this part of the test, I used

the DIR command in DOS to look at the directory. I also turned the machine

off and rebooted to see if it retained the date properly; it rebooted with

the date properly set in the future. However when I tried to use WINDOWS

File Manager to look at the files in the directory, WINDOWS didn't show the

date properly (it showed 3/15/%0 and 2/10/.0)!! I'm not sure whether this

is just a display problem or not because the "sort by date" feature of File

Manager placed them correctly.

I also ran some similar tests on another machine (DELL 425s/L). On this

machine, the date appeared to roll over properly but I encountered the same

problems with File Manager for displaying the file information.

Sooooo, I guess the problem might be ROM BIOS-related. But different BIOS's

appear to handle the problem differently. Just what we need in large shop

(11,000+ PCs)!

-- Taylor, Ralph G 

[See Question 2.8 concerning File Manager. -- RJS 12/97]


When I first became aware of the year 2000 problem from Peter's CW article,

I tried a test on my Intel-based PCs. I set the date and time as 11:59:30

PM on Dec. 31, 1999 and let the clock run. The result was uneventful or so

I thought. The clock in Windows jumped to 12:00 AM on 1/1/00 so I thought

that there was no problem. I failed to change the date and time and a few

days later noticed that I now had files dated in 1984 that had just been

created! When I investigated, I found that the date looked OK, but the ROM

chip was not really handling the date correctly. As I understand, the ROM

BIOS is not capable of handling anything after 1999.

-- Dr. Pat McKeown 


I have tested my own three PC's. Two of them make failures (clones) already

mentioned bios (PHE and Award).

And my 10 year old PS/2 model 60 with ref. diskette is 100% performing on

all the test's (LEAP, future , and even has YYYY/MM/DD.

In the early day's everyone told me that this PC was to expensive. This is

the machine I use for my Telebanking ...

-- Hans Goossens 


The following was obtained from the Award Software web site on March 18,

1998. It is an excerpt from

AwardBIOS compliance with Year 2000 depends on the release date:

If your AwardBIOS was released before 26 April 1994, you only need to reset

your system clock once. Turn the system off before midnight on 31 December

1999. Turn it back on some time after midnight, on 1 January 2000. Then set

the system date correctly in Setup.

If your AwardBIOS was released between 26 April 1994 and 31 May 1995, you

need to obtain an AwardBIOS update [see], or reset your system clock every


If your AwardBIOS was released after 31 May 1995, its calendar

automatically rolls from 1999 to 2000 at midnight. You don't need to do

anything, whether the system is turned on or off at midnight. Just leave

the system alone.

(c) 1998 Award Software International Inc. All rights reserved.

Updated 20 February 1998


And moving onto those last two questions ...

(a) That's easy ... the BIOS doesn't support Y2000 properly. It may just

not handle the 1999-2000 rollover, you'd have to try a few Y2000 midnights

to see what happens (see note below).

(b) DOS didn't exist before 1980 so the BIOS/DOS never needed to support

times prior to 1980. Why Jan 4th & not Jan 1st?

NOTE: If you mentioned that you were using Win95. Remember this is beta

code and has 'code fade' built into it. Had your BIOS not been defective,

you would have been re-installing Win95. Once Win95 beta has been booted

beyond the programmed date, the system will shutdown after giving you a

brief message. Resetting the date to a current date doesn't fix this.

-- Adrian Clark with Sears Canada, Technical Development


question b:

Since the person writing BIOS/DOS knew that the "current system date" could

NEVER be before the time that the system (i.e. BIOS/DOS) was invented

(created), then that person must have inserted a piece of code logic that

said something like ... if the "current system date" is ever earlier than

1/4/1980, then set the "current system date" to equal 1/4/1980. It is

evident that the person (or persons) considered 1/4/1980 as the "creation

date" for BIOS/DOS (or something related to it), and that THIS was the date

that the "current system date" could NEVER be earlier than.

It is also clear that this piece of code logic is only activated under

certain conditions, and that there are times when this code segment is

never reached. Additional analysis will likely be done on this subject, as

forces are brought forth to repair it.

It is curious that this choice (setting the "current system date" to equal

the "system creation date") was selected for this obvious error condition.

Many other software action choices COULD have been selected instead of


And what a far-sighted piece of code logic for an individual or individuals

that failed to foresee the implications of selecting a two digit date field

just a VERY short 20 years from the next turn of the century! Should we

someday find that person's name, and post it here in this FAQ.

-- John Moffitt (just an observation and some opinion)


Here is a manual test for personal computers, suggested by Geoff May

 of Network Business Services, 01 November, 1995.

Caution: some software with date checking (for example Windows 95 betas)

may reset and not allow access after setting dates into the future.

[It is strongly recommended that you boot from a floppy before starting

these tests. Do not remove the floppy until after you have reset the date

and time to the present. -- RJS 3/98]

Disconnect the computer from any network or other system that might reset

the date as it boots or connects.

RTC (Real Time Clock) Rollover Test

- Set the date to 31 December 1999.

- Set the time to 23:58 (11:58 p.m.).

- Check that the date and time have been set.

- Switch off the computer.

- Wait five (5) minutes.

- Switch the computer back on.

- Check the date and time. It should be a few minutes after midnight on the

1st of January 2000.

RTC 2000 Set Test

- Set the date to 01 January 2000.

- Check that the date has been set.

- Switch off the computer.

- Wait a (1) minute.

- Switch the computer back on.

- Check the date. It should be the 1st of January 2000.

DON'T FORGET - Reset your PC to the correct date and time!

Many Personal Computers fail either both or the first of these tests and

reset themselves to 04 January 1980, or some other ancient date, whenever

they reboot, if the CMOS RTC (Real Time CLock) says the year is 00.


Check the web page for the index

to PC manufacturer's statements on y2k compliance. Statements from Dell,

Gateway, Compaq, etc., are there.

-- George W. Ball 

Associate Professor of Computer Science, Alfred University

5 Sep 1996


2.2 UNIX, Linux, and/or C/C++


UNIX time structure ("struct tm"):

UNIX/ANSI C also defines a "struct tm" structure for broken-out time

fields. The year is offset from 1900; some libraries have improperly

handled years outside of the range [00..99].

Also, _many_ application programs have problems with this. Some accept

"100" to indicate 2000. Some will print back dates like "01-01-100"

(instead of "01-01-00"). Others will complain about your ignorance -- years

should be two digits only.

Other than that, this time structure has no meaningful "important" dates.

Who cares if the year will roll over in 2 billion years? :-)

-- Bear Giles 


>I've been plowing through a large, undocumented system trying to find

>all the occurences of dates I can. The system does some odd things in

>Y2K. Some dates come up as 01/02/100 on the screen when the record is

>created, but are stored as 01/02/10.

Your application is using tm_year to retrieve the current year. Just so

happens that tm_year starts in 1900, where 2000 is year 100. Your app is

probably using a sprintf into a char[2] field. Yes, you're are getting

corrupted memory on the byte following that char[2]. Need I say more?

The C problem has been overlooked. . . . Oh well, if Y2K was that easy

(like so many "experts" say), we wouldn't be scared to death of what may

occur 01/01/2000.

-- R. Gama , President, Xpress Software, Inc, 8 Jan



Here are a couple suggestions for the UNIX and/or C world.

1. Always use standard library calls. Use strftime(), even if you think

it's a waste of time since it's so easy for you to do the conversions


This way if there is a problem, it's in one place (strftime) and it will be

much easier to fix. If you use "sprintfs" or direct string manipulation,

changing the code is _much_ harder.

2. If you have to write your own time functions, keep them in a single

place. C++ is very good at this; I have some database management routines

which keep meteorological data in files with names based on the date; I

have essentially only _one_ procedure which does the conversion from date

to filename.

3. Try to use 4-digit years. If you use two-digit years, be sure to

_always_ print only the last two digits. For instance, if you decide to

ignore #1 and write the date yourself use:

::printf ("%2d-%2d-%2d", tm->tm_year % 100, 1 + tm->tm_mon, tm->tm_mday);

instead of

::printf ("%2d-%2d-%2d", tm->tm_year, 1 + tm->tm_mon, tm->tm_mday);

Simply putting these practices into effect, and correcting existing code

during maintenance, will do wonders. If time allows (which, with most

management, will be after Thanksgiving 1999) you can also "grep" for usage

of terms like "tm_year" to try to find any uncorrected source code.

-- Bear Giles 


Unix keeps the date and time as the number of seconds that have elapsed

since 0000 hours UTC, January 1, 1970. It keeps this count in a 32-bit

signed integer. The count will overflow on January 19, 2038, when the

number of seconds reaches 2,147,483,647, the maximum number that can be

represented in a 32-bit signed integer. All versions of C and C++ use this

same format for certain library functions.

-- Robert J. Sandler 


I would rank this [rollover in 2038] as being potentially more serious than

Y2K. UNIX is heavily embedded in our infrastructure, and this format is now

standard for most C/C++ programs. That means it is extremely widespread.

-- Bear Giles  and Roger Gates 


The standard C library from a major vendor (Sun?) had an interesting

failure mode. I specified a date in the 21st century and asked it to give

me the ASCII equivalent.

I expected: 07-04-12

What I got was: 07-04-;2

(or something to that effect.)

Conjecture: the library code was "optimized" and year-to-string fields were

handled as:

*s++ = '0' + tm->tm_year / 10;

*s++ = '0' + tm->tm_year % 10;

where "tm->tm_year" is part of one of the standard Unix time formats. The

"year" information is an offset from 1900.

This works fine provided the "tm_year" field is in the range 00..99, but

blows up on years outside of this range.

I reported this to our systems people; later tests verified that the

software had been fixed.

There have been others, but as I recall they were generally local code, not

system-level libraries. Or previously reported misinformation -- I've had

people become extremely hostile to claims that 2000 is a leap year.

-- Bear Giles 


So, Y2K doesn't apply to Linux? Have a gander:

# date -s "Jan 1 00:00:00 1997"

Wed Jan 1 00:00:00 AST 1997

# date -s "Jan 1 00:00:00 2000"

date: invalid date `Jan 1 00:00:00 2000'

-- William Burrow , Fredericton Area Network, New

Brunswick, Canada, 1 Jan 1997

It is indeed a big problem in Linux, and all Unix systems. The reason is

rooted the standard time functions which use the following structure

defined in /usr/include/time.h (this is quoted from the ctime(3) man page):

struct tm


int tm_sec; /* seconds */

int tm_min; /* minutes */

int tm_hour; /* hours */

int tm_mday; /* day of the month */

int tm_mon; /* month */

int tm_year; /* year */

int tm_wday; /* day of the week */

int tm_yday; /* day in the year */

int tm_isdst; /* daylight saving time */



tm_year The number of years since 1900.

The declaration of tm_year as a type int is large enough work far into the

future, but the definition certainly encourages applications programmers to

take the easy route and hard code all dates for the 20th century.

Hence this problem is not specific to Cobol applications at all. . . . Wall

street may suffer from Cobol applications and be very able to whine in the

press about it, but the implication that payroll applications which might

malfunction is the biggest problem coming, could be a very costly red

hering if all attention is then diverted from other problems. . . .

-- Floyd L. Davidson , 1 Jan 1997


2.3 VMS


I have just spoken to Digital Equipment in Atlanta regarding VMS. They said

that VMS is YEAR 2000 Compliant.

-- Dick Murray 


I . . . set the time to 10:50 12/31/1999 on one of our VAXen and let it go.

VMS ran fine (it's been running about a week now and is up to 1/6/2000).

-- Allan Van Ness 


The Mac and the VAX/VMS systems were the two areas in our analysis with no

year 2000 problems.

-- Steve Vogel 


VMS uses a bizarre time format which is microseconds(?) since JD 2400000

[see question 4.5]. It allocates 64 bits of information. Because 64 bits is

so large, even with microsecond resolution this timer won't overflow for

another 584,000-odd years.

-- Bear Giles 

Actually it's tenths of microseconds, not whole microseconds, if I recall

correctly, which pushes our overflow back to a mere 58,000 years from now.

Better get to work on it right away.....

-- Craig Goodrich , 28 Apr 1998


2.4 Apple Macintosh

Here is an official Apple statement, contributed by Brian Bechtel

 of Apple's DTS group.

There has been much speculation recently about various computers and their

handling of the year 2000. The MacOS operating system and Apple Macintosh

computers do not have problems with the year 2000.

All MacOS operating system date and time utilities have correctly handled

the year 2000 since the introduction of the Macintosh. The original date

and time utilities (introduced with the original Macintosh 128K in 1984)

used a long word to store seconds, starting at January 1, 1904. Starting

with a long word of seconds since January 1, 1904 means that dates run out

at 6:28:15 a.m. on February 6, 2040. The current date and time utilities

documented in Inside Macintosh:Operating System Utilities use a 64 bit

signed value, which covers dates from 30081 B.C. to 29940 A.D. For further

reference, see the reference volume Inside Macintosh:Operating System

Utilities, or its predecessor, Inside Macintosh Volume II.

Gregorian calendar support is included with all localized versions of the

MacOS operating system. In addition, the Arabic version of the MacOS

operating system supports both the Arabic astronomical lunar calendar and

the Arabic civil lunar calendar. The Hebrew version of the MacOS operating

system supports the Jewish calendar. The Persian version of the MacOS

operating system supports the Iranian national calendar.

Virtually all software available for the Macintosh will not have any issues

with the year 2000, as well. The only problems I have seen were with

developers who were using their own date and time utility packages, rather

than using the toolbox calls supplied by the MacOS operating system. If

you, the developer, are using your own date and time utilities, you should

test carefully to ensure that you handle all of the subtle issues of date

and time conversion.


As an aside to the statement above, the Date & Time control panel

constrains user entry to dates between January 1, 1920 and December 31,

2019. This means you can't set your Macintosh clock to a date past 2019

without doing computer programming. This feature was added starting with

System 6.0.4. This is a implementation decision, not a limitation of the

MacOS toolbox. I'm investigating why this control panel was implemented

this way.

-- Brian Bechtel 


Peter [de Jager] is writing an article about the impact of the Year 2000 on

Macs. He has been besieged by hundreds of Mac owners stating that the Mac

is "Y2K Bug Free". These letters demonstrate a lack of understanding of the

year 2000 problem. It affects software as well as hardware. . . . We use

Eudora which sorts 00 as it should and therefore causes a problem (00 less

than 99). We use Act for the Mac which time stamps entries with a two digit

year and is therefore another example of the Year 2000 bug. We have one or

two other programs with the same problem.

-- Antoinette de Jager, 27 Jan 1997


2.5 Novell Netware


On August 19th, 1996, Novell released patches to the NetWare 3.12 and 4.10

operating systems to fix NetWare's handling of the year 2000 and beyond.

The patches are in:

Later versions of of the 312ptx and 410ptx files will also contain the

patches, as will the issued version of NW4.11. i.e. prior versions didn't.

-- Phil Randal 

Environmental Services Dept, Hereford and Worcester County Council



last updated 13 March 1998. Novell lists the testing status of their entire

product line. In addition, the page at

lists all the test results and links to downloads. Note that Novell not

only lists the patches available, but also lists the problems with each

associated application. A superior piece of information necessary in doing

risk assessment and prioritizing implementation of upgrades.

Perhaps also of note is the contrast between this information and

information on their site 6-12 months ago. When I searched the site for

GroupWise year 2000 compliance info last May, all I found was a

knowledgebase article that stated "Because of the way dates are calculated

in GroupWise, the year 2000 will not cause problems", and goes on to

describe how GroupWise stores dates in a 4 byte format (document 2910115

last modified 04FEB1997). Per their latest information, GroupWise is in

testing, and results are due Q1 1998; some older versions have been


-- Sid Faber , 20 Mar 1998


Our PCs get the current date whenever we log onto the LAN (Novell 3.12). If

the PC gets the current date from the file server, is is safe to say that

as long as the file server and the NOS are Year 2000 compliant, the PC Bios

issue is not a factor for the PCs that are connected to the LAN??

-- Peter Genadry , NationsBank, 25 Oct 1996

Sorry, but I think you're wrong.

Some apps take their feed from the BIOS, some from the OS and I'm sure that

some PC apps wil still have problems. Even the BIOS may cause problems as

the on-board BIOS is loaded before the network time stamp

Derek - can you comment further?

-- Karl W. Feilder  6 Nov 1996

Karl, you are right in surmising that it depends on how an application was

written as to where it sources its time from. Most desktop applications

today however source their time directly from the workstation clock, whilst

server based applications would source their time stamps etc from the

relevant application / file server.

Having said that, the Novell client, by default, updates the workstation

clock from the server time, i.e. it synchronises the time of the two. This

takes place in one of three ways....

1) On login

2) On attaching to a server

3) On demand via a purpose-built utility, SYSTIME

As with most Novell functions these can be turned off through issuing the

relevant switch as illustrated below. To be entirely sure, workstation

configurations need to be checked to ensure that these settings are not in

effect to disable time synchronisation with the server.

By default, workstation time will be updated to the server time the moment

it gets attached to server. During attachement to the server following line

in the net.cfg will stop updating workstation time.


During login to the server following line in login script will stop

updating workstation time.


In the case of the Client32 for Windows95, go into Properties, Advanced

Settings, and "Set Station Time" to Off. This keeps the workstation from

synchronizing with the server that it initially attaches to.

In the case of OS/2 workstations some confusion arises from the difference

between a DOS/Windows workstation using the VLMs and a OS/2 workstation

using the OS/2 requester. A DOS workstation will by default synchronize its

time to the server to which it attaches when VLM.EXE is run. This can be

disabled by the NET.CFG parameter "SET STATION TIME = OFF". When the

DOS/Windows workstation runs LOGIN.EXE the time will be synchronized with

the target server by the LOGIN executable unless "SET_TIME OFF" is included

the login script.

OS/2 workstaitons will not attempt to synchronize the local time until

login. Thus there is no NET.CFG parameter to disable this synchronization.

Similar to the DOS/Windows workstation, time synchronization during the

login process can be disabled by including "SET_TIME OFF" in the login

script. Because of the lack of a NET.CFG parameter for the OS/2 requester

it has been widely asumed that it is impossible to prevent an OS/2 client

from synchronizing with the NetWare server. This is not the case as the

other two alternatives mentioned above are still available.

Finally, I must state quite clearly that even though patches are available

to ensure that the Novell servers are Year2000 compliant w.r.t. the date

and time that they issue to a workstation, this does NOT mean that the

problem disappears.

Year2000 issues are far deeper than simply having a correct workstation

date and time issued to your application. The majority of the issues stem

from the fact that most applications are internally unable to corectly

represent and deal with dates after 31/12/99. Further, we humans have often

taken shortcuts in our own input of date related items such that the

applications - even if retrofixed - would still be unable to discern the

correct meaning of some of our inputted data.

Bottom line, the reliability of the NOS and the integrity of its underlying

file system are paramount as we move closer towards Year2000 - and that is

what has been addressed by Novell, however the NOS & even workstation time

are barely more than foundation pieces in the overall picture. Important

pieces yes, but rather insignificant at the end of the day. The major

problems are in the applications, whether custom written or shrink-wrapped.

Best regards, and I hope that this information helps...

-- Derek Morgan , Special Projects Manager, Novell

South Africa, 08 Nov 1996


2.6 IBM Mainframe MVS, ESA, and OS/390


Before you go IPLing LPARs or a spare MVS machine, here's IBM's recent

assessment for S/390 MVS year 2000 readiness:

- ETR, 390 processors, MVS Timer facilities - CLEAN

- Basic Control Program - CLEAN INTERNALLY

- Key subsystems - CLEAN or SUPPORT PLANNED

- LANGUAGES - CLEAN (latest releases)

- LE/370 - CLEAN

- Major IBM products - INITIAL ASSESSMENT APPEARS POSITIVE (that's nice!)


-- Source: Year 2000, David E. Whitney, IBM Corporation, Software Design

Center, Poughkeepsie, NY)


During our last disaster test on June 22, we took the opportunity to see

how our systems would react to a date of June 22, 2000. Our IBM mainframe

software configuration included:

MVS ESA 4.2.2

JES2 4.2.2

PL/I 2.3


RACF 1.9.2

SDSF 1.3.3


ISPF 3.5

Various reports were run with the following results:

RACF: some password expirations were not picked up. In one case, the

password interval left before we changed the system date was six days and

warning messages had been generated. After the date change, this password

was expired. In another case, there was still some time to go before

expiration. After the date change, this password still was not expired.

RACF: ICH70001I LAST ACCESS 14:11 ON NOVEMBER, JUNE 22, 1900 (somehow, this

doesn't seem right!)

RACF: the CONNECT command with a REVOKE date will not accept '00' as a


SYSLOG: the date shows a 2-digit year (example: 00174).

MVS: 'D T' shows a correct date.

TSO: &SYSDATE gives 06/22/00, a 2-digit year.

SDSF: DATE 8/06/52 (incorrect date)

REXX date: 00.174, a 2-digit year.

JES HASP: 22 JUN 00, a 2-digit year.

Temporary DSnames: show a 2-digit year (SYS00174, etc.)

PL/I compiler shows 22 JUNE 00 in the compiler report, a 2-digit year.

PL/I execution: the built-in date function placed 14/08/00 in a report. The

ISA date was 22 JUN 00.

LKED: showed JUN 22, 2000 (Note to those programmers: pat yourselves on the


CA1CTS: 22 JUN 1900, an error.

CA90ENF: 06/22/00, 2-digits.

ASM H: 06/22/00, 2-digits.

FILEAID: reports 'linked on' date as 00/06/22.

JCL Allocation of a new file with EXPDT=99366: ISPF creation date shows

2000/06/22, and an expiration date of 1999/12/31!

ISPF stats: created 00/06/23 (doesn't account for leap year).

IDCAMS: 06/22/00, A 2-digit date.

LISTCAT: shows 2000.174, a correct date.

I know this is incomplete and not very thorough but it is all we had the

time to do.


For the following IBM platform: MVS/ESA 4.3:

In MVS the expiration date is a flag which simply denotes the file or

dataset's "delete status." It does *not* mean that MVS will delete the file

or dataset for you when the expiration date has been reached. In other

words, if you try to delete a file or dataset before it's expiration date

has been reached MVS will prompt you with a message like: "HEY, this [file,

or dataset] hasn't expired yet. Are you sure you want to delete it?" And

you say yes and delete it or no and don't. Simple. That was good news for

me; prior to this discovery I ran a report on my DASD farm and discovered

over 600 files and datasets with expiration dates of 99365.

The EXPDT keyword of the TSO Allocate command and JCL DD parameter now

accept YYDDD *and/or* YYYY/DDD as valid expiration dates (formats). This

means you can set *real* Y2K expiration dates. (Ain't MVS grand?)

Furthermore, the EXPDT designations 99365, 99366, and 99999 continue to

have the special meaning of "don't delete this dataset." Except testing

*for that* is a little tougher (have to wait until 31DEC99). I guess if you

*really* want a dataset to expire at the end of this century you will

simply have to set it a day earlier or a day late.


2.7 IBM Mainframe VM


Re VM and other IBM software: IBM has publicly stated they are reviewing

all their products for Y2K problems, and will publish a document later this

year (1995) giving the releases of each which will be "year 2000 ready."

-- Gene Lynd , Defense Logistics Agency

We are currently assessing the changes that are necessary in the VM/ESA

operating system for the year 2000. You can expect to hear more about year

2000 support for VM, as well as more from an IBM-wide perspective, in the

not-too-distant future. If you have technical questions about VM's support

for the year 2000, you can either post them here [on the Year 2000 mailing

list] or send them directly to me via e-mail and I will answer them as

best, and as quickly as I can.

-- John Franciscovich , VM Development, IBM

Corporation (Endicott, NY)


2.8 Windows 3.1

Microsoft has posted patches on its web site for the Windows 3.x and

Windows 95 File Managers to correct the date display problems for files

with year 2000 and later dates. The NT 4.0 version of File Manager does not

exhibit the problem.

They can be downloaded from:

W95FILUP.EXE: Updated File Manager for Windows 95:

W31FILUP.EXE: Updated File Manager for Windows 3.1:

WFWFILUP.EXE: Updated File Manager for Windows for Workgroups 3.11:

The files are self-extracting and include a new WINFILE.EXE and a TXT file

from Microsoft explaining things. Files are dated either 12/02/97 or


-- Information provided by:

-- John Carter 

-- Chuck Dennison <>

-- David A. Smith 

-- Gary L. Smith 

-- Arnold Trembley 

-- B. Young 

-- December, 1997


2.9 Windows 95

See Question 2.8 above concerning File Manager.


Of course many will be interested in MS-Windows 95. This package seems (at

first glance) to be okay, however it may have a problem 100 years later

(answers provided by the double Mike team).


I've tested Windows 95 with dates past the year 2000, and here's what I've


1. Windows 95 itself has no problems with dates past 2000. It can only go

up to the year 2099, though, but can still go back to 1980. However, the

2099 limit shouldn't be a problem for a while.

2. One of my Win3.1 applications, a talking clock, appropriately enough,

choked on a post-2020 date; from 2000 to 2020, it interpreted the dates at

1900 to 1920!

3. One time, when I forgot to change the time back afterwards, I was unable

to boot because my beta had "expired" in January 1996! I had to reinstall

Windows 95. At least that won't be a problem in the commercial edition

(which I haven't bought yet).

-- Michael J. Averbuch 


I just tried setting the date to the turn of the century on Win95 and it

seemed to work okay. Didn't do a whole lot of testing but its reaction is

certainly different than what I got doing the same test under Win 3.1 and

Wfwg 3.11. I have my prompt set to show the date/time after each RETURN (in

a DOS windows under Windows 95).


Windows 95. [Version 4.00.950]

C:\WIN>date 12/31/99

Fri 12-31-1999 20:28:27.62

C:\WIN>time 23:59:50

Fri 12-31-1999 23:59:49.94


Fri 12-31-1999 23:59:54.72


Fri 12-31-1999 23:59:58.07


Sat 01-01-2000  0:00:01.64


Sat 01-01-2000  0:00:04.77

-- Mike Drabicky 


2.10 Excel

Also see question 2.15.


The other day, I declared an EXCEL 5 cell as a date cell, then typed


It said January 1st, 2019.

But, when entering


it said January 1st, 1920

Lotsa problems at that time!

(but, of course, EXCEL 5 will be EXCEL n+1...)

-- Didier Morandi , 23 Dec 1996


When a date containing a 2-digit year is entered in a cell whose format is

declared as d/m/yy, Excel 5 defaults it to being in the range 1/1/1920

through 31/12/2019. When a four-digit year is typed, e.g. 1/1/1900 or

1/1/2020, the ambiguity is removed and the 4-digit year entered is used. In

either case, the full 4-digit year is displayed in the entry box under the


Curious about the data interchange implications, I ran up a CSV file

outside Excel containing a series of 2- and 4-digit dates inside and

outside this range, then opened the file in Excel. The 2-digit-year data

was interpreted according to the same defaults as data entered from screen,

and 4-digit years were imported correctly.

And yes, Excel 5 does recognise the existence of Feb 29, 2000.

-- James Tinsley , 24 Dec 1996


All versions of Excel treat 1900 as a leap year to maintain compatibility

with Lotus 1-2-3, which has contained that error since its earliest

releases, when it was the de facto standard to which all other spreadsheets

had to conform. This is a known, documented, and intentional anomaly in


-- Robert J. Sandler 


See the Y2K Spreadsheet FAQ at

-- Patrick O'Beirne , Systems Modelling Ltd, Ireland,

25 Oct 1997


2.11 Paradox


I've noticed a date problem with Paradox for Windows software. It treats

2000 as 1900 during a sort of the table. Even when the date is entered as

2000, it is treated as 00.

-- David Silver 


2.12 Quicken


I have Quicken version 3 (IBM PC) running on MS-DOS 6. I found that when I

set the date to 01-01-2000 (as people reading this list already know,

letting it wrap from 12-31-1999 results in 01-04-1980), Quicken interprets

this as 1/1/1901. I suppose one obvious question is, why not 1900? But a

more important question (to me anyway) is whether newer versions of Quicken

have fixed this problems. (I REALLY like to post-date checks)

Also, I have found that Quicken 3 does not allow me to enter a date of

01/01/00, nor does it accept YYYY on checks. One other interesting quirk:

When I first start Quicken and open the check register, the year is listed

as 2000. But as soon as I hit the Enter key, it reverts (?) to 1901. Clever

programming, this.



2.13 Ada


The ADA-language "relate" database exhibited a very strange Y2K error mode.

(I tested this in the late _80's_ due to a scheduled project lifetime of

15+ years, and was told that it was too early to worry about this problem

even though military contractors tend to buy a product and then sit on it!)

Dates 01-Jan-00 through 29-Feb-00 worked fine. (As I recall it did properly

handle the leap year).

Dates 01-Mar-00 through 28-Feb-01 were screwed up. The day-of-week was


Later dates appeared to be fine.

Conjecture: Day-of-Week is computed by a formula due to Gauss (or Euler?)

which uses years starting on March 1st. That makes it easy to handle leap


The leap-year calculations are correct, but the Day-Of-Week calculation

isn't. You would have Tuesday, 29 Feb 2000 "followed" by either Tuesday, 1

Mar 2000 or Thursday, 1 Mar 2000. (I'm not sure which way the error goes.)

A similar problem occurred with 28 Feb 2001 and 01 Mar 2001.

The potential havoc for payroll, if the data is keyed by day-of-week, is


I reported this to my supervisors, but I think they sat on it. I don't know

if this relational database is still in use. (The version we used had

serious deficiencies; it's sole virtue was the fact that the DoD was

pushing Ada as _the_ language.)

This problem might be common. When you bring up a calendar program, don't

just check for 29 Feb 2000; verify that 01 Mar 2000 is a Wednesday! (But

you need to bring up that date/that month alone. This bug might not appear

if you look at the entire year.)

-- Bear Giles 


2.14 Sorting

See question 5.13.


2.15 Microsoft Products

See question 6.3 for information about Microsoft's Year 2000 web site.


This is from the MS Technet CD:

Microsoft's Products

The table below shows Microsoft products and the date limit (life

expectancy) of the date formats used for each one. Unless noted,

Microsoft's products rely on the system supplied date formats.

Microsoft product date limits and formats

Product Name / Date Limit / Date Format

Microsoft Access 95 (assumed date) / 1999 / assumed "yy" dates

Microsoft Access 95 (explicit date) / 9999 / long dates ("yyyy")

Microsoft Access (next major version) / 2029 / assumed "yy" dates

Microsoft Excel 95 / 2019 / assumed "yy" dates

Microsoft Excel 95 / 2078 / long dates

Microsoft Excel (next major version) / 2029 / assumed "yy" dates

Microsoft Excel (next major version) / 9999 / long dates

Microsoft Project 95 (and previous versions) / 2049 / 32 bits

Microsoft SQL Server / 9999 / "datetime"

MS-DOS file system (FAT16) / 2108 / 16 bits

Visual C++ (4.x) runtime library / 2036 / 32 bits

Visual FoxPro / 9999 / long dates

Windows 3.x file system (FAT16) / 2108 / 16 bits

Windows 95 file system (FAT16) / 2108 / 16 bits

Windows 95 file system (FAT32) / 2108 / 32 bits

Windows 95 runtime library (WIN32) / 2099 / 16 bits

Windows for Workgroups (FAT16) / 2108 / 16 bits

Windows NT file system (FAT16) / 2108 / 16 bits

Windows NT file system (NTFS) / future centuries / 64 bits

Windows NT runtime library (WIN32) / 2099 / 16 bits

-- Patrick O'Beirne , Systems Modelling Ltd, Ireland,

26 Mar 1997


Reproduced by kind permission of the poster On Compuserve:

For what it's worth, here's a workup on what I found during test:

Access 2.0:

"yy" dates are assumed to be in the 20th century (even if the PC clock

shows the 21st century).

"yyyy" dates work as entered.

Access 95 and 97:

If oleaut32.dll is the original file that ships with Access 95:

"yy" dates are assumed to be in the 20th century.

"yyyy" dates work as entered.

Access 95 and 97:

If oleaut32.dll is version 2.20.40xx (installed from IE3, O97, or other

newer programs) then:

"yy" dates from 30-99 considered the 20th century.

"yy" dates from 00-29 21st century.

"yyyy" years work as entered.

-- Patrick O'Beirne , Systems Modelling Ltd, Ireland,

09 Feb 1997


2.16 Windows NT


Here are the results from our independant testing of the Microsoft NT

Operating system running on a variety of y2k non-compliant hardware.

We reviewed Microsofts statements published on their web site and contacted

Microsoft directly before deciding to perform an independent test.

We believe that NT will resolve a significant problem we have with non

compliant hardware infrastructure i.e. if the workstations are not replaced

as part of a normal asset refresh between now and 2000 then the NT

operating system will significantly reduce the risk to any devices left in


The objectives were:

to confirm statement from Microsoft that MS Windows NT Versions 4.0 and

3.51 with service pack 5 can automatically detect and correct the problem

on non-year 2000 compliant PC's;

to investigate how MS Windows 95 handle dates during the change in the

century on non-year 2000 compliant PC.

Scope of testing

Tests were performed on PC's which are not year 2000 compliant running on

MS Windows NT (Versions 4.0 and 3.51) and MS Windows 95. The testing was

performed to determine whether the operating systems detect and correct the

date during the change over to the next century.

The tests were performed on a variety of different machines running MS

Windows NT version 3.51 with service pack 5.0 and version 4.0.

The time synchronisation test was performed on the workstation connected to

a Primary Domain Controller running MS Windows NT Server 4.0.

Summary of testing results

The test results showed that MS Windows NT (both versions) did detect and

correct the problem of crossing over to the next century independantly of

the non compliant hardware.

MS Windows 95 does not detect or correct the problem. If a workstation

running on MS Windows 95 is connected to a MS Window NT server with

synchronisation setup, ie. synchronisation is initiated during logon, the

workstation shows the correct date and time.

Details of testing performed

MS Windows NT 4.0

The main testings performed was as follows:

change over of the date when PC's are switch off during the change of the


change over of the date when PC's remains switched on during the change of

the century

impact to the dates when dates were put back after the change to year 2000

check the impact of DOS dates to Windows NT

Other internal testing specific to our project

The testing were performed for both the NTFS and FAT file system.

A MS DOS application that does direct date calls was also executed running

under MS Windows NT 4.0 to confirm that the date the application used was

the date of the system.

MS Windows NT 3.51 (With Service Pack 5)

The test performed for MS Windows NT 4.0 were also performed for MS Windows

NT 3.51 with Service Pack 5 applied. MS Windows NT 3.51 without Service

Pack 5 is not year 2000 compliant.

MS Windows 95

Testings performed for MS Windows 95 were as follows:

change over of the date when PC's are switch off during the change of the


change over of the date when PC's remains switched on during the change of

the century

check the impact of DOS dates to Windows 95

We also tested the synchronising of the date of the MS Windows 95

workstation to the MS Windows NT 4.0 Server. A batch file was created to

execute during logon to synchronise the time of the workstation to the MS

Windows NT 4.0 server.

-- Gary Blythe , Blythe Consulting, 23 Dec 1997


2.17 Windows 98


This is a statement from John Gray at Microsoft regarding Year 2000

compliance of the Windows 98 operating system.

1) Bad BIOSes - BIOSes don't store a 4 digit year, they store a 2 byte

"century" byte, and then the 2 digit Year, Month, Day, Time in another

separate area that they increment. So how does a BIOS have to handle the

century byte? If the last time it was booted was in the late 1990s (say

1999) and the current boot says "1900", then by golly, it's time to

increment the century byte. But, a lot of bioses are missing that code.

So... Windows 98 and Windows NT 5 will do this for the user, automatically.

That's right, those people with bad BIOSes don't need to do anything but

install Windows 98, and on Jan 1, 2000, that's what their system date will

say because the OS will go out and bump the century byte automatically.

2) Display - File Manager will display a screwy date (19;0) instead of 2000

for Windows 3.1, WFW, and Windows 95. Windows 98 fixes this if you still

use Fileman. [However, see question 2.8. -- RJS]

3) MS-DOS 2-digit date entry: On Windows 95, if you enter the date command

at the DOS prompt, and enter 1-1-00 you will get 1900. With Windows 98, you

will get 2000. (The break point for system date assuming 19 vs 20 is

1980/2079. That is b/c that's the year MS-DOS was released). You can always

enter the full 4-digit year in any OS to set it.

4) 4 digit year displays - you can configure Explorer to show 4 digit years

in the Regional settings display tab, Date. (Win95 or 98). But what about

MS-DOS? You can now use the /4 flag to show 4-digit years at an MS-DOS


5) Application Date Rollover - post Beta 3, you will see a small addition

to the Regional Settings, Date tab, to allow a system-wide setting for

applications to use for the assumed 2-digit year rollover date (default is

2029). So future apps will be able to use a common setting for data entry.

6) The system has undergone extensive testing (backup, explorer, system

date/time CPL, etc.) to make sure that there are no y2K problems.

-- David Kipping , January 16, 1998


2.18 PKZIP

The following was obtained from the PKWARE web site on February 3, 1998.

Year 2000 Compliance for PKWARE Products

Because of growing concerns regarding the impact of the year 2000 on

computer systems running PKWARE's products, we have developed this document

to outline the current and planned future status for all of PKWARE's


The following product(s) have no date related functionality:

PKWARE DATA COMPRESSION LIBRARY (all versions, all platforms)

The following product(s) have no known issues dealing with date-related

functions beyond the year 2000. Date related activities, such as the

sorting and displaying of dates, are handled correctly for all valid dates

within the DOS FAT file structure (1980-2100).

PKZIP for DOS and OS/2 (versions before 1.10)

PKZIP for OS/2 (version 2.50 and later)

PKUNZIP for DOS and OS/2 (all versions)

PKZIP for OpenVMS (all versions)

PKARC/PKXARC (all versions)

PKPAK/PKUNPAK (all versions)

PKLITE (all versions)

PKZFIND/PKZOOM (all versions)

PKZIPFIX and PKSFX (all versions)

The following product(s) have minor year 2000 date related limitations, as

described below. However, these limitations will not affect the actual

files or data stored by PKWARE software. No data conversions will be needed

on any existing .ZIP files.

PKZIP for Windows (versions 2.01 - 2.50)

- Selecting files by date in a .ZIP file will only accept a range from 1980

through 2009.

- Viewing files in a .ZIP file will only display dates in the form


- Anticipated solution:

Dates entered as a 2 digit value will be interpreted as being in a date

range from 1980 through 2079. Dates entered as a 4 digit value will

accommodate dates that span more than 100 years. The method of correction

will consist of "expanded date fields".

- Scheduled correction date:

PKZIP for Windows Version 2.60 (released December 19, 1997)

PKZIP for DOS (versions 1.10 & 2.04g) and PKZIP for OS/2 (versions 1.09 -


- Selecting files to be added to a .ZIP file by date will only accept a

range from 1980 through 1999 (-t and -T options).

- Viewing files in a .ZIP file using the default will display dates in the

form mm/dd/yy. The four digit year can be viewed using the option to view

technical information (-vt).

- Anticipated solution:

Dates entered as a 2 digit value will be interpreted as being in a date

range from 1980 through 2079. Dates entered as a 4 digit value will

accommodate dates that span more than 100 years. The method of correction

will consist of "expanded date fields".

- Scheduled correction date:

Next release of PKZIP for DOS (no release date available)

PKZIP for OS/2, Version 2.50 (released June 2, 1997)

PKZMENU (all versions)

- Selecting files to be extracted by date will only accept a range from

1980 through 1999. File dates stored in a .ZIP file, will only be displayed

correctly from 1980 through 1999.

- Anticipated solution:

PKZMENU is a discontinued product. No modifications are anticipated.

PKWARE, the PKWARE logo, PKZIP, PKLITE, PKLITE Professional and the PKWARE

Data Compression Library are registered trademarks of PKWARE, Inc. PKZFIND

and PKZOOM are trademarks of PKWARE, Inc. Trademarks of other companies

mentioned appear for identification purposes only and are the property of

their respective companies.

Copyright (c) 1998 PKWARE, Inc. All Rights Reserved


2.19 SAS


Just a comment on SAS. Watch out for the JULDATE and DATEJUL functions,

they are NOT yr2000 complient.

-- Harold P Zbiegien , 21 Mar 1997


As always, things are often not black nor white but some shade of gray.

Regarding these two SAS functions, we may have some gray.

SAS documents how dates of the format YYDDD or YYYYDDD will be treated.

Basically YYDDD dates provided by a program to SAS will be stored

internally with the appropriate century value based upon your setting of

the YEARCUTOFF value which defines your 100 year window. This is the way

SAS will try to interpret ambiguous dates.

If you convert a SAS date value to a Julian date, SAS will return a YYDDD

format date for those dates that fall within your 100 year window as

defined by YEARCUTOFF and will return a YYYYDDD format date for any date

that falls outside of the window. While someone might argue that they don't

like the way SAS is handling these issues, it seems to me they have

recognized the problems and tried to handle them in a reasonable way.

-- Dave King , 26 March 1997


2.20 Oracle


Let me try to summarize Y2K compliance in Oracle (and many other DBMSs).

Oracle is doing pretty good (hey, this is coming from a guy who used to

compete against them ;-)) and lets give the credit where the credit is due

(though I understand that there is one lawsuit pending from a client who

challenges Oracle Y2K compliance. I don't know all details but it would not

surprise me if it was due to a misuse of Oracle functionality.)

You have to look at Y2K compliance for database environment in multiple


1. Oracle internals (e.g. rollback recovery, transaction time-stamps, etc.)

As far as I know Oracle is compliant in this layer (internally it uses a

full time-stamp based on a four digit year).

2. Dates in database. Oracle date internal format contains a full time-

stamp yyyy:mm:dd:hh:mm:ss stored in seven bytes. Manipulation of this date

requires use of data functions (to extract or store time-stamps components)

I think this may be the reason for many database applications storing dates

as character strings or as integers. Obviously, in this case the date

format depends on a database design and may include just two digit year.

But this is not the Oracle fault!

3. Manipulation through PL/SQL. Dates stored in DATE format are manipulated

through date functions (TO_NUMBER, TO_CHARACTER, TO_DATE) using date

formats. Date formats are for external representation (internally year is

always yyyy)

If you try to translate external two digit year into internal four digits

you can use

- "YY" format, where a century value will be based on the current century

"19" until the year 2000, "20" thereafter

- "RR" format, where a century value is based on a date window "20" if the

year is < 50 else century = "19"

Again, Oracle gave you a decent approach to handling dates, it's up to you

to use it properly. If you need any other approach, you can develop your

own date function and pass the result to database through "yyyy" format.

4. Manipulation through host languages. Folks how you handle dates in C,

COBOL, Visual Basic, etc. has nothing to do with Oracle. If you translate

two digit year into for digits in a host language and pass it to Oracle it

is not Oracle problem when the date stored in Oracle database is incorrect!

Yet, I heard too many time "our application is compliant - it uses Oracle

database and all dates are stored in DATE format. Just recently I was

trying to explain this fact to one of our Y2K clients. My explanation was

reinforced by a failure to process next century dates in one of their


5. Manipulation through end user interfaces (e.g. screen formatting

software, GUI). Many of these packages use their own routines to translate

dates between fore and two digit years. So eventually date may be passed

from GUI interface to a host language, to PL/SQL stored procedure, and

finally stored in Oracle (in DATE or other format). Any layer may use

incorrect translation and manipulation of dates. But do not blame Oracle

for this - blame the designer of your database application and your

development standards and procedures.

-- Miro Medek , 28 Mar 1997


I found this quite interesting. You will need to read the entire article at to easily understand the full



Oracle columns of the date data-type can store dates ranging from January

1, 4712 BC to December 31, 4712 AD. Oracle uses its own internal format for

storing dates, but conceptually you can think of the server as storing each

date in the format YYYY-MM-DDHH24:MI:SS. Because all dates occurring in a

column of datatype date are stored with a four-digit century, Oracle

regards the Oracle Server as Y2K compliant.

However, the situation gets less rosy when we take into consideration the

default date format. Since Oracle uses its own internal representation for

dates, it must convert from this format to a readable format on output and

vice versa on input. Oracle provides a wide range of date formats that the

programmer can explicitly request or specify by using the to_char() and

to_date() functions, respectively. However, if you don't use these

functions (for example, you just reference the date as a string as in

"select * from emp where hiredate > '01-JAN-97'"), Oracle relies on the

default date format to perform the conversion. There is a great deal of

Oracle SQL code in use that relies on the default date format --

approximately three quarters of the Oracle SQL code that I've seen or coded

in the last 10 years does.

The default date format for Oracle releases in North America has always

been DD-MON-YY. Here's the potential pitfall: The YY always refers to years

in the current century


-- Harlan Smith <>, December 18, 1997



3.1 What is the potential social/societal impact?


How stable can your year 2000 software project team be, when the company

down the street is in the same predicament and offers huge 'incentives' to

your staff to jump ship and help them?

Expect computer programmer salaries to skyrocket as the deadline approaches

(high demand and low supply).

Many firms may have large numbers of computer tapes and files unexpectedly

erased due to automated systems that haven't been told that time has

reversed! Fallout from this is difficult to predict. Probably these same

firms will try to hire more of those overpriced programmers. Yum Yum :-)

If you can't get your accounting system up and running in three months

you're out of business. Today's organizations CANNOT survive three months

without cash flow.

Yes, there WILL be a run on the banks as companies get desperate for cash

advances. This is a bad thing :-(

Assume you have the very best and the very brightest and your system is up

and running in a week (loud laughter from the back of the room). How can

you survive when a large number of your vendors and your customers are

going under.

A large depression could result from a large number of business failures.

Now all of those overpriced programmers are back on the streets. This could

be a VERY bad thing :-(

Possible stock market crash???

Add to this the fact that supermarkets could have utterly bare shelves on

4th Jan 2000 because of the BIGGEST PARTY -- And the fact that their

ordering system might go haywire. They might even go the other way and

order 99 years' worth of supplies, but nothing comes in, due to all of

their suppliers' computers being off-line.


The following is from the Risks-Forum Digest, Monday 29 March 1993, Volume

14 : Issue 44, Peter G. Neumann, moderator.

Subject: Call for the Class of '88

I Found the squib below on the Prodigy service --

QUIRKS - Offbeat Computer News

Mary Bandar recently turned down an invitation to attend kindergarten with

others born in '88. "Boy, wouldn't those kids ever be surprised when they

see me coming to school," Bander, 104, told the Associated Press. "Why

would they want me? I know the ABCs yet. And I can count to 10," said the

Winona, Minn, resident, who was born in 1888.

Sister Mary Donald Miller, superintendent of Winona Area Catholic Schools,

told the AP that the mix-up occurred when school officials instructed a

computer to search for the names of people born in '88.

. . .

I expect that as we approach the millenium, we'll see a lot more of these

"off by a century" errors.

-- Ed Ravin , 29 Mar 1993

Reused without explicit authorization under blanket permission granted for

all Risks-Forum Digest materials. The author(s), the RISKS moderator, and

the ACM have no connection with this reuse.


"In 1990, a 107 year old woman in Denmark received a letter from the local

school system welcoming her to first grade. A man of 103 checked into a US

hospital and was assigned to the pediatric ward. That's nothing, compared

to what we can expect in the year 2000 - unless every organization that

uses computers starts now to address the problems inherent in the fact that

00 is less than 99."

-- Case Strategies, Dec. 1992


FUD (Fear, Uncertainty and Doubt) is a major motivating factor. Marketing

and finance people are typically very familiar with its effective use. You

can bet that come 1999, there will be plenty of short-selling of stock in

corporations expected to be hit hard by this problem.

-- Ron Hunter-Duvar 

But we should also remember that there is no uncertainty or doubt on this

issue, just shock and disbelief at the extent of the work required from

those who have reliable estimates. There is a problem now and there will be

many future repercussions unless time to act is moved forward rather than


I'd probably start taking short positions in late 1998 though .

-- Joe Warren , TransCentury Data Systems


A friend in the department that handles some accounts-receivable that span

out 5 years or more have done some work -- mostly by the "sliding window"

approach. But for the most part, everyone else I know of is still sitting

on their collective hands.

I just found out that last year, my department manager was far-sighted

enough to ask for budget to handle Y2K issues. His boss nixed it.

I'm doing all I can to get the budgetary juices flowing, but I'm beginning

to think that FUD (Fear, Uncertainty, & Doubt) should really be DUF.

We start out DOUBTING that there is a problem, then move onto being

UNCERTAIN that we can handle the problem, and finally get to the FEAR phase

-- This is the real motivator.

I just hope that I can move the bosses through these phases quickly enough

and that it doesn't somehow backfire.



One of our local papers (the Edmonton Journal) carried an article on Y2K.

It was fairly prominently featured on page 4 of Section A of the paper. The

article originated from Associated Press, with a dateline of Bellevue,

Washington. It appears to have been primarily fed by a company called Data

Dimensions, who talk about the work they're doing for Boeing.

The headline in our paper was "When the clock strikes 2000, computers will

go haywire". It goes on to explain that when the year 2000 arrives the

computers will think it's 1900, with grave circumstances such as:

- planes being grounded because they're 99 years overdue for maintenance.

- phone calls just after midnight being billed for 53 million minutes.

- VISA balance skyrocketing into the millions due to haywire interest


As a lay-person article I found it not too bad, although it certainly just

skimmed the surface of the problem.

-- Rob Schneider 


I am fascinated that no management forum is yet discussing the liability

issue. For example:

If company X's systems don't work properly after Y2K AND company X then

suffers commercially - sells bad product; fails to sell or ship any

product; fails to bill for a product; thinks all leases have expired, or

worse puts human life or health at risk! etc.- then heads will roll!

Starting at the top of data processing, but inevitably going much higher

than that.

In the USA we have 750,000 lawyers and they will SUE, SUE, SUE. They will

sue company X, they will sue company X's auditors, and their outsourcers,

and their financial backers, and their software suppliers, and their

consultants etc. In fact they will sue anyone remotely connected with the

failure. What do you think will happen to any government official remotely

connected with such a mess?

As a techie I am more than a little involved in the problem and its

solution. If my solution (sold to a customer) does not work completely it

has crossed my mind that I will be picked on as one of many organizations

to BLAME - and help PAY for the cleanup. With this in mind, I have recently

been checking my business liability policies.

There are TWO precedents for this thinking:

(1) The ASBESTOS suits, which have caused the dissolution of one major

company, and has brought Lloyds of London to its knees.

(2) The US Superfund (toxic waste cleanup) Act REQUIRES the owner of land

containing toxic waste to pay for the cleanup even if the owner bought the

land AFTER the waste was deposited.

When the LIABILITY issue finally sinks into 'management', we will get


For more than 30 years I have been using, and developing, 'buggy' software,

so when I try to explain to lay people that all the software they use has

the 'mother of all bugs' in it - they say 'what else is new?' When I

suggest there is some previously unscheduled software maintenance to

perform, they say 'well none of your other estimates was correct either!.

But if I can explain CONVINCINGLY to people that many will lose a LOT of

money, some will lose their JOBS, and some may even go to JAIL - maybe I

will get their attention.

-- Duncan G Connall


I have not had the slightest problem explaining why computer systems will

fail as dates are calculated into the next millennium. I have had great fun

with this at dinner parties and the other guests have had great fun as more

possibilities are suggested. (One person in particular though did not

laugh. His business depended heavily on a computer system and he already

had little confidence in the people who kept it going). - I suspect he

asked some interesting questions on the following Monday.

I start by explaining that the year is often stored as 2 digits and

therefore 1999 will be 99 and 2000 will be 00.

I explain that a human probably does not have much problem with this but a

computer does as it is told, and decides that 00 is smaller than all the

years in the 'nineties'.

I then give examples ...

- Corn beef with a seven year self life and stock management systems. The

computer system that ditches old stock checks stock that was manufactured

on say Jan 5th 1993. It calculated that it will expire on Jan 5th 2000 but

stored the year as 00. As 00 was less than the current year of say 93, the

system thought the stock had expired and released it.

- The Bank vault opening system wakes up on 1st January 2000 which is a

Saturday. It stores the year as 2 digits and therefore misinterprets the

year as 1900. As 1/1/1900 was a Monday it opens the vault!

- A car insurance system logs all driving convictions and calculates the

date they will expire (5 years time). Anything after January 1995 expires

in Jan 00 etc. Jan 00 is compared to the current date, deemed to be

smaller, the conviction is deemed to be spent and is therefore deleted.

The list goes on ...

I have found though that the sorting and extraction of data within ranges

problems are more difficult for a non-techie and the idea that the problem

is not just applications but operating systems etc are impossible (although

the PC date reset is helpful for this).

-- Jacqui Macdougal 


You can tell the non-technical users that their economic futures will

probably depend on the solution of these problems. For example, if they

make loan payments in 1999 for bills that come due in 2000 but the vendor's

software interprets year "00" as 1900, they will be charged 99 years of

late charges.


Possibilities are ATM screw-ups locking them out of THEIR money, incorrect

calculations on THEIR credit card/mortgage/checking/savings interest,

effect of company failures on the stock market (even a few given the state

of the media coverage of negative issues today) which could cause THEIR

investments to lose value (houses, stocks, 401k's, etc.), a possible run on

banks if consumer confidence was broken causing them to lose access to

THEIR money for a period of time and so on. How about vacations? You go to

the airport for a winter vacation and they tell you your plane took off 99

years ago? Even just a general business slowdown due to 2000 problems could

have an impact on job possibilities, raises and so forth. All of which

would have an effect on the general economy ...

All of us will be affected if just a few companies mess-up due to the

extensive linking and communication dependencies in industry these days.

Just think how a little bad news can send the stock market reeling.


There's probably a lot of other 'chicken little' stories and at least a

couple of good SF stories in all of this! And nearly everyone reading this

FAQ will be around to watch all of this happen, or possibly be right in the

middle of it.

Ah, what a delicate web we weave, when first we practice to avoid good

programming techniques.


Some of these Y2K-like problems could already be happening (prior to the

click over to year 2000). Examples include ...

I'm looking at the expiration date printed on a food package - it says

"July 25 1906"! Think someone has a Y2K compliance problem? :)

Actually, this might be an area that most folks haven't considered needs

bringing into Y2K compliance ... guess I better not eat this 90 year old


Pris Sears 

A similar case was recently admitted to by a senior IS staff member of a

major food product chain at a recent Y2K conference. I am being as vague as

possible to protect the innocent, the guilty and those that were minors at

the time the applications were coded.

They had a vacuum packed product (vague again) with a 5 year shelf life.

When calculating the product's expiration date earlier this year, their

program added 95+5 with the result of - you guessed it - zero.

So the next time their inventory system ran, it compared the expiration

date (00/MM/DD) to the current date (95/MM/DD). Since the current date was

greater, that meant the product's shelf life had expired and notices were

issued to toss it all in the incinerator.

Fortunately for them, their warehouse uses humans and not robots to pull

products off the shelves. They managed to detect that something was amiss

and prevented the destruction of perfectly good merchandise. What they did

to manually correct their inventory and accounting systems is unknown.

-- Romy Leibler 

Cash Registers Crashed at Midnight

According to the 25 August 1995 edition of the St. Louis (MO)

Post-Dispatch, a local CompUSA store took the unusual step of staying open

late for the release of Windows 95. Unfortunately, the cash registers

crashed at midnight, just as the first Windows 95 buyers were ready to

check out. The store worked half an hour to resolve its problem.

The article did not say what cause the cash registers to crash. My guess is

that the cash register system needs to be cycled off at the end of the day

and on at the beginning of the next. As they never before stayed open after

midnight, they did not know this. Even a reliable system will produce

unusual results when used in an unusual manner.

-- Jerry Whittle 


3.2 Has mankind ever had to deal with this kind of problem before?


Many years ago when I was in the Air Force, we had a major system balk at

going from 1979 to 1980 because of a 1-position year setup.

-- Daniel A. McLaughlin 


One-digit years were quite common in punch card systems. With only 80

characters in a card, every character was precious. Anyone who was in data

processing in the 1960s or earlier remembers such systems.


It's happened before!

Being a graybeard in computing, I'm a bit surprised that this problem is

only now being recognized, since it's happened before. This is a favorite

thing of mine to mention in classes. Normally I say something like ...

"Why were a BUNCH of programmers called into work on an emergency basis

shortly after New Years, 1969?" - My students (who are most 22 or so years

old (sigh)) generally don't have a clue.

The answer is that programs dealing with long term financial instruments

(30 yrs) all of a sudden had ABENDs (as we called them then) when maturity

dates computed from 1970 started producing zeros - mostly mortgages and

long bonds.

-- Bob Wier 


The following is from the Risks-Forum Digest, 20 November 1989, Vol. 9,

Issue 45, Peter G. Neumann, moderator

Subject: Another foretaste of the Millenium

We apologise for the unexpected system shutdown today (Thursday). This was

caused by a bug in the MTS [Michigan Time Sharing] system that was a

"time-bomb" in all senses of the word. It was triggered by today's date,

16th November 1989.

This date is specially significant. Dates within the file system are stored

as half-word (16 bit) values which are the number of days since the 1st

March 1900. The value of today's date is 32,768 decimal (X'8000'

hexadecimal). This number is exactly 1 more than the largest positive

integer that can be stored in a half-word (the left-most bit is the sign

bit). As a result, various range checks that are performed on these dates

began to fail when the date reached this value.

The problem has a particular interest because all the MTS sites world-wide

are similarly affected. Durham and Newcastle were the first to experience

the bug because of time zone differences and we were the first to fix it.

The American and Canadian MTS installations are some 4 to 8 hours behind us

so the opportunity to be the first MTS site to fix such a serious problem

has been some consolation. The work was done by our MTS specialist who

struggled in from his sick bed to have just that satisfaction!

-- Brian Randell 

Reused without explicit authorization under blanket permission granted for

all Risks-Forum Digest materials. The author(s), the RISKS moderator, and

the ACM have no connection with this reuse.


Digital Equipment Corporation had a similar problem with the DECsystem-10

in 1975 because of field overflow. DEC's advisory late in 1974 had this to

say (quoted in First Data Corporation, Newsletter 20, December, 1974):

"When the software for the PDP-6 was being designed in 1964, a 12-bit date

format was established. In order to maintain compatibility with old

programs, that format was retained in successive monitor releases.

Unfortunately, the 12-bit format cannot represent any date after January 4,

1975. Therefore, a DATE75 project was initiated in order to convert

DEC-supplied software to a new 15-bit format that properly represents dates

well into the next century. Support for 15-bit dates was designed to

minimize conversion problems. Programs coded in a simple, straight-forward

fashion will work properly with 15-bit dates without any modification.

"Our experience in actually converting our existing software has been

considerably more difficult than we ever anticipated. We keep finding new

DATE75 problems. As a result, we have been forced to release a large amount

of software on the November distribution tape; and customers will not have

as much time as we would wish to install it all. Naturally, we recommend

installing all of this software well before January 5, 1975. If this is not

done, many DATE75 problems will be encountered. Keep in mind that DATE75

problems are essentially cosmetic. It is a nuisance to have files with

incorrect creation and access dates, but it is not a catastrophe."

But, "When a file gets an erroneous date because of a DATE75 problem, it

may not be saved and restored in the intended fashion by FAILSAFE [the

backup daemon]. This is a serious problem since it can result in files

appearing lost."

And, "We regret very much the lateness of the delivery of this software. We

simply did not anticipate all the problems we would encounter. Customers

should take advantage of the lesson we learned so painfully by immediately

upgrading their DEC software to the versions released on the November tape,

and by starting conversion of their own software... Our experience

indicates that it is not sufficient for a programmer to simply 'think

through' a program's structure and functions to determine whether it has a

DATE75 problem. It is not sufficient merely to give the program a quick

test with a monitor set to a date after January 4, 1975. It is necessary to

run the total system for several hours in order to find all the subtle

DATE75 problems."

"Please keep in mind that DATE75 fixes have proven incredibly error prone.

You must use great care and very thorough testing in order to be confident

that DATE75 problems have been fixed... Most of the problems we found were

in cases where we believed our programs followed these [omitted]

procedures. Do not believe yours do!"

-- Dave Rybarczyk 


Yes, and the Japanese are particularly well placed to take advantage of our

chaos when the year 2000 rolls around (see below).


"The year 2000 will be the first century change ever endured by an

automated society and if your organizations uses computers, that means you

are sitting on a time bomb."

-- Randall L. Hitchens, Computerworld, Jan. 28, 1991

The above statement is not entirely true.

When the Japanese Emperor died in 1989, the 64 year "Showa" period ended,

and Japanese business was forced to implement an Emperor Date change to the

period "Heisei". This is equivalent to a century change, since the Emperor

Date starts again at 1 for the new Emperor. Of course it was the first

change in the computer era.

Emperor Dates and Western Dates are used interchangeably in Japan. It is

thought that 'the majority' of Japanese business made corrections to 2

digit Western Dates at the same time as they corrected for the Emperor


Japanese business tends to be more composed concerning the year 2000

change, nevertheless there may well be problems there too.

-- Duncan G Connall 


3.3 Anyone got any idea what possible Y2K implications are known with

reference to nuclear missiles and other military, software-controlled



It is generally believed that nobody (especially the military) trusts the

launching of nuclear missiles to software. Good idea as far as I'm

concerned. All of this is believed to be under manual control (worldwide).

Now guidance systems and lots of other software are associated with this

process, but it would be hard to see why anyone would write date

verification code into these algorithms.

I doubt the military will offer this group any insight into where software

takes place before, during, or after the launch of a nuclear missile. Do

worry about all of the financial systems and the possibility of serious

economic problems (which could lead to a war).


3.4 Does the Global Positioning System (GPS) have a year 2000 problem?

The following is an excerpt from a longer message in Risks-Forum Digest,

Tuesday 2 July 1996, Volume 18 : Issue 24. For references and more detail,

see the original message.

I have good news and I have bad news.

The good news is that GPS will not have a "Year 2000" problem. The bad news

is that GPS System Time will roll over at midnight 21-22 August 1999, 132

days before the turn of the millennium. On 22 August 1999, unless repaired,

many or all GPS receivers will claim that it is 6 January 1980, 23 August

will become 7 January, and so on. I would expect that some manufacturers

have already solved the problem, but many have not.

-- Joe Gwinn 

Reused without explicit authorization under blanket permission granted for

all Risks-Forum Digest materials. The author(s), the RISKS moderator, and

the ACM have no connection with this reuse.


I did a web search and found some helpful docs.

Most helpful sites I found were:


Within the GPS system, there is a field called week number. Week 0 started

on approx midnight Jan 05 1980. Each week since then, the count has been

increasing. Since the field size of GPS week number field is 9 bit binary

(mod 1024), the maximum value is 1023. When 1023 is incremented by 1, the

counter rolls over to 0. Week 1023 occurs in August 1999.

Every GPS receiver could fail at the same time in August 1999. The symptoms

are inaccurate date/time and incorrect coordinates. The resolution is to

have the manufacturer upgrade the GPS unit before August 1999.

Hope the manufacturer of your unit is still in business. 

-- Nancy Copes <>, January 7, 1997


I just stumbled on a report on GPS that came out in 1997/06/02



Lt Al Johnson GPS Y2K Lead Engineer

Navstar Global Positioning System Joint Program Office

As of: 17 June 97


The bottom line was that "GPS performance will be unaffected by Millennium

and EOW (End of Week) Rollovers.

For those that don't remember or haven't read about GPS before there was

concern about the end of the 52 week GPS "epoch" in September 1999, that is

an entirely different phenomena than Y2K. In September 1999 a modulo 1024

counter in the receivers would roll over to zero.

A summary of the test results and conclusions:

- The satellites test OK

- The GPS receivers procured by the Joint Program Office tested OK

- Some support equipment on older computers was not OK and must have Y2K


- The AF will test commercial receiver designs for a fee.

- The GPS receivers put out a 2-digit date, raising a question in the mind

of the AF about interfaces.

So Gary North had raised a question about this and he was right that the

testing was required. So it looks like now the only concern is whether the

commercial receivers will pass the AF Test.

I haven't gone back to his site yet to see if he has mentioned this report

or not. If not, I will bring it to his attention.

-- Harlan Smith <>, September 24, 1997


3.5 How are credit card companies handling year-2000 expiration dates?


DISCLAIMER: Although I am employed by MasterCard International, I am not an

official corporate spokesperson. These comments are my personal opinions.

MasterCard and Visa are not going to change the format of credit card

expiration dates for a very simple reason (one that applies to a great many

Year 2000 problems). There are literally thousands of banks and hundreds of

thousands of merchants worldwide who would have to convert to a new network

message format. It is not possible to coordinate that kind of change with

hundreds of thousands of independent external users. Therefore, any POS

terminals which attempt to check expiration dates would have to use a

century windowing strategy.

MasterCard and Visa will start fining Merchants whose POS terminals do not

accept '00' in expiration dates. This won't start until probably September

of 1997. The purpose is to give merchants a monetary incentive to achieve

Year 2000 compliance, and not to increase revenue to the credit card


And finally, merchants do not get their POS terminals from MasterCard and

Visa. The merchants must buy or lease them from an array of competing

manufacturers. As far as I know, MasterCard does not certify POS terminals

for Year 2000 compliance. We do certify acquiring banks and financial

institutions for correct network message layouts.

-- Arnold Trembley , 22 Feb 1997



4.1 Is 2000 a leap year?


The rules for determining whether a given year is a leap year are:

(1) If the year is evenly divisible by 4 it is a leap year, except for

years ending in 00.

(2) A year ending in 00 is a leap year if it is evenly divisible by 400.

Therefore, 1900 was not a leap year, but 2000 will be a leap year.

-- Robert J. Sandler 


Leap Year Myths and Facts

Please do not try to discuss these myths, or try to prove that they are not

myths, on the Year 2000 mailing list or in other on-line discussion forums.

We have all had our fill of leap year discussions. There are much more

critical issues to be resolved, and time is running out.

Myth: If the year is evenly divisible by 3200/3600/4000 (pick one) it is

not a leap year.

Fact: There is no such rule. The two rules given above are the complete

rules for determining whether a year is a leap year in the Gregorian

calendar. The popularity of this myth seems to derive from the fact that

the average length of the year in the Gregorian calendar is approximately

26 seconds longer than the tropical or solar year. This difference amounts

to one day in a little over 3300 years, or about three days in 10,000

years. Some experts have proposed rules similar to the mythical rule to

correct for this difference. But no government, standards organization, or

other authoritative body has adopted such a rule.

Myth: The year 2000 will be a "double leap year" or "super leap year."

February will have 30 days and the year will be 367 days long.

Fact: There is no such thing as a double leap year or super leap year. The

year 2000 will be a leap year like any other leap year, with 29 days in

February, and 366 days in the year.

-- Robert J. Sandler 


4.2 Is there an ISO, ANSI, NIST, or other standard that defines the

Gregorian calendar or the rules for leap year?

No. There is no ISO, ANSI, NIST, or any other official standard, in the

modern sense, for the Gregorian calendar. The Gregorian calendar was

defined by the Roman Catholic Church, not by any modern standards-setting

organization. The definition was established in 1582, long before today's

standards organizations even existed.

In 1582 the Church was the only organization in a position to establish

anything resembling an international standard. The original and ultimate

source for the definition of the Gregorian calendar is the papal bull

"Inter gravissimas" (Among the most serious) issued by Pope Gregory XIII in


The legal basis for the Gregorian calendar in Great Britain and its former

colonies is "An Act for regulating the commencement of the Year, and for

correcting the Calendar now in use" passed by Parliament and approved by

King George II in 1751. This act, of course, merely copies what had already

been defined by the Church 169 years earlier.

-- Robert J. Sandler 


4.3 On what date will the 21st century begin?


The 1st century AD consisted of the years 1 through 100. The 20th century

consists of the years 1901 through 2000 and will end Dec. 31, 2000. The

21st century will begin Jan. 1, 2001.

-- The World Almanac and Book of Facts 1996


This is a date that no organization, including NIST, has the authority to

regulate. However, one logical answer to the question is that because there

was never a year "zero," and a century must have 100 years, then each

century must begin with a year numbered "1." In other words, the 20th

century should be considered as ending on Dec. 31, 2000, and the 21st

century as starting on Jan. 1, 2001.

However, human nature being what it is, most of us will still opt to have

that "once-in-a-century" New Year's Eve bash on Dec. 31, 1999.

-- "Time Questions and Answers from NIST," Time and Frequency Division,

National Institute of Standards and Technology


The 20th century (this century) will end after December 31, 2000 comes to a

close. The 21st century then begins just after midnight on January 1, 2001.


the chaos in computer systems all over the world is expected to begin on

the morning of January 1, 2000, a full year before the end of the 20th

century and the end of the millennium.

-- John Moffitt 


Webster's New World College Dictionary, Third Edition, says:

"In common usage, a century begins with a year ending in 00 and runs

through 99, as 1800-1899, 1900-1999, etc."

However, immediately after that explanation, it gives the following as an

illustrative example of the use of the word "century": "A.D. 1801 through

A.D. 1900 is the 19th century. . . ."



A millenium is a period of 1000 years. The question of which year is the

first year of the millenium hinges on the date of the first year AD.

Unfortunately the sequence of years going from BC to AD does not include a

year 0. The sequence of years runs 3 BC, 2 BC, 1 BC, 1 AD, 2 AD, 3 AD etc.

This means that the first year of the first millenium was 1 AD. The one

thousandth year was 1000 AD and the first day of the second millenium was

1001 AD.

It is thus clear that the start of the new millenium will be just after

midnight on 1 Jan 2001.


The year 2000 AD will certainly be celebrated, as is natural for a year

with such a round number but, accurately speaking, we will be celebrating

the 2000th year or the last year of the millenium, not the start of the new

millenium. Whether this will be an excuse for more celebrations in the

following year will have to be seen!

-- Royal Greenwich Observatory, Information Leaflet No. 52: "The Year 2000

AD," available at


4.4 How will we refer to those initial decades?


In the past ...

1900 - 1909 was called "just after the turn of the century." 1910 - 1919

was called "the teens."

1920 - 1929 was called "the roaring twenties" and a fun time it was!

In the future ...

Poll results are in the May-June 1993 issue of the Futurist, and I give

them integral:

- The year 2001 should be pronounced Two Thousand One (62%), Two Thousand

And One (18%); Twenty-Oh-One (10%); Other (10%). Double Ought One was a

popular alternative.

- The years 2000 to 2009 should be called the Two Thousands (64%); The

Twenty-Ohs (9%); The Oh-Ohs (5%); The Double Oh's (5%); The Zero's (4%);

Other (13%). The most popular write-in alternative were The Aughts, Oughts

or Oughties, and Naughts or Naughties (4% combined).

- The years 2010 to 2019 should be called: The Teens (69%); The One-and-

somethings (10%); The One-ies (4%); Other (18%). Among the suggested

alternatives were The Twen-teens (also Twe-teens), The Tennies, and 'Peak

years of High Global renaissance'.


Has anyone anything definitive to say about what we should call:

2000 - probably "The Year Two Thousand" or "Two Thousand"

2001 - "Two Thousand and One"

200x - "Two Thousand and x"

-- Peter Somers


If this is the nineties then the following should apply:

2000 - 2009 Noughties (nought meaning zero)

or 2001 = Onsies, 2002 = Twosies ...... :-)

2010 - 2019 Tensies

2020 - 2029 Twenties

2030 - 2039 Thirties


Anything between 2010 and 2099 is easy; it's "twenty-twenty-four" or

whatever, the same way we call this year "nineteen-ninety-five."

The problem is 2000 through 2009. I suspect the most common usage will be

the bastardization "twenty-oh-two". I'm calling that a bastardization

because it's a zero, not the letter "O", but the two terms are often used


That's also very appropriate for the year "twenty-oh-oh". :-)

-- Bear Giles 


It seems to me that years 1901 to 1909 were often called "aught one" or

"aught nine" (not that I was there, but that's what I have heard.) Maybe we

should do that again. My guess is that it will commonly be "two-thousand

and one" because of Kubrick's movie. How that gets shorthanded will be

interesting to watch.

-- Lanny Jones 


I'm 60 now, and can remember my grandparents refering to the period of

1900-1910 simply as the "ninteen hundreds". They referred to individual

years as "O one", "O two", etc. up to "O nine". The years 1910-1919 were

referred to as "the nineteen tens". Individual years in this period were

referred to as "ten", "eleven", "twelve", etc, up to "nineteen".

Don't know if this will translate well to eqivalents in the 21st century.

-- Tony Baker <>, January 7, 1998


Jack Rosenthal, editor of The New York Times Magazine, considers this

question in the On Language column in the August 18, 1996, issue of the

magazine. After considering and rejecting many of the suggestions above, he

proposes calling 2000 through 2009 "the Ohs." He also points out that the

use of "aught" to mean zero is the result of a mistake, misunderstanding "a

naught" as "an aught."

-- Robert J. Sandler 


The New York Times Magazine, January 19, 1997, (p. 13) refers to the


-- Robert J. Sandler 


4.5 What is a Julian date?

The term "Julian date" has two different meanings. The one that is most

common in data processing is a number from 1 to 366 representing the day of

the year. This is more properly referred to as the "ordinal date."

The other meaning of Julian date is a system used by astronomers. It is

also called Julian Day and abbreviated JD. It is the number of days since

noon GMT on January 1, 4713 BCE. In this system, Julian Day 2,450,084

begins at noon GMT on January 1, 1996. This system was invented in 1582 by

Joseph Scaliger, who named it for his father, Julius Caesar Scaliger.

-- Robert J. Sandler 


4.6 What is an integer date? What is a Lilian date?

An integer date is a way of representing dates as the number of days since

a specified starting date. Integer dates make it very simple to calculate

the number of days between two dates, or to find the date a given number of

days before or after a given date.

A Lilian date is an integer date system in which day 1 is October 15, 1582,

the first day of the Gregorian calendar. It is named for Luigi Lilio, who

provided most of the ideas for the Gregorian calendar reform, including the

rule for leap years.

Other integer-date systems use other starting dates. For example, ANSI

COBOL 85 intrinsic functions use January 1, 1601. Most spreadsheets,

following the convention first established by Lotus 1-2-3, use January 1,


-- Robert J. Sandler 



5.1 What are the general programming (standards?) approaches that one could

take to solve the various year 2000 problems?


The year 2000 effort can be broken down into three basic steps:

1. Preparation

2. Implementation

3. Deployment

Lets look at each of these, and examine the possibility for automation in


1. Preparation

Preparation is where you inventory all your applications, discover which of

them have year 2000 problems, decide what to do with those that do, and

then prioritize the work. While there is some automation to be applied

here, it is generally to begin to control what a company has, rather than

specifically facilitate the year 2000 process (but I don+t see how one can

enhance entire systems without controlling the code before and after, so in

a sense these tools facilitate the process).

2. Implementation

This is where the enhancements actually take place. The tasks here are

identification, code correction, verification, and data correction. Here is

where automation can come into play. In each one of these steps, there is a

range of automation that can be applied. The level of automation ranges

from facilitating the manual enhancement effort to actually doing most of

the work. We have also found that there is a possibility for +too much

automation+ in these steps. Too much automation does not allow for learning

and customization. We have also found that the accuracy and completeness of

the identification task indicates the productivity and quality for each of

the subsequent tasks. So, in addition to a range of automation, there is

also a range of accuracy and completeness for the automation.

3. Deployment

The deployment phase includes the system test and moving the tested systems

into production. There are tools that can be of assistance in this step.

The primary difficulty here is the phasing in of corrected subsystems

(i.e., making new code work with old data until enough of the system of

application has been enhanced to correct the data). This can be facilitated

by the level of automation in the Implementation phase (after all, if the

identification task has identified all the date-sensitive data elements in

files and databases, couldn't it use that information to facilitate

creating bridges and wrappers?).

-- Ted Swoyer 

Director of Marketing at Peritus Software Services, Inc.


I'm essentially aware (simplistically) of 3 basic approaches to coping with

addressing Y2K in both programs & data:

(1) expand two digit years to 4 digits.

PROS: seems to be the most straight forward.

CONS: terrific downstream impact on sorts, DASD, file sizes, etc. Does

anyone out there have any capacity planning experience? Can you comment on

how much bigger files will become?

(2) bit twiddling - stuff 4 digits into 2 physical positions

PROS: avoids the downstream ripple effect of approach #1

CONS: (I'm told) applying the logic to programs requires precision

(3) sliding dates - leave as two digits & have some logic determine that 60

thru 99 implies 1960 thru 1999 and 00 thru 59 implies 2000 thru 2059.

PROS: avoids the file expansion issue

CONS: doesn't work for certain applications (e.g. - very likely not for

life insurance). The programs need to be changed, but the problem persists.

If you sort on dates, look out.

The nastiest aspect of all these solutions is: No matter which one (or

combination) you choose, you still must deal with the problem of importing

data from other systems. Any dates which come from "outside" will need to

be converted unless they already match your data standard. You can always

ask (insist?) that those providing you with data put it in the desired

format. Whether they will depends on the nature of the relationship between

you (another non-technical aspect of the problem).

Eventually, of course, everyone will see the value of YYYYMMDD dates, and

standardize, right? But until then (don't wait until then to retire), you

will need to maintain some conversion routines. To ease maintenance, using

callable modules for these conversions seems to make sense.

-- David Eddy , Global Software, Inc.


Of the three solutions posted above ... only one, in my view, is the

correct way to do this. 4 digit dates ... (I'd press for 5 digit dates, but

some would consider me to be going a little byte overboard)

The downside for DDDD is two fold. Space requirements ... and input


The upside is overwhelming. the date is Correct ... and MORE to the point

... the instructions to programmers are easy ... ALL YEARS ARE IN THE


Consider a new programmer joining a company that's chosen either solutions

2 or 3 ...

Greetings! welcome to our company ... here is how our date programmes work

... Oh and this date is on a sliding scale of 'X' ... except when it isn't


Aarrggghhh what a rat's nest of logic and instructions! How often will

something have to be re-written because someone misunderstood what 'type'

of data was being used?

Another reason against solutions 2 & 3 is that they will generate 'soft'

errors ... situations where the calculation works but is WRONG for some

subtle reason. These are the most difficult to track down.

The question is of course ... what defines 'better' when we're examining

alternatives? Better to me, means the solution that will create the least

number of problems down the line.

-- Peter de Jager


How do you eat an elephant? Answer: One bite at a time.

We are not yet ready to define strategies for our own company, but some

general remarks:

- The strategy will depend very much on the size of the company and the

systems portfolio. We have a terrible mix of platforms, software old and

new, bought and self-made, undocumented and poorly documented (sigh),

nonstop mission critical, and batch. So we have definitely a different

approach than a 95% IBM based company.

- Of all the different migration strategies, we will make a mix. It will

not be a big-bang approach.

- We will use a lot of bridge programs between systems to convert date

formats old to new and vice versa. This will enable a system by system

eating the elephant.

- We will try take the conversion along with regular maintenance, although

this gives us QA problems (very important!).

- We will have a core project team of presumably 20-40 people that do

nothing but coordinate, check, facilitate and communicate. The real work

will be done in the subsequent IT departments where the systems specialist


- We don't know yet what the role of off-shore software engineers and of

consultants will be. But we do know that we will have to develop a policy

on tools, consultants, solutions, etc. before we acquire them.

-- Serge Bouwens 


Our system has been in existence since 1981, therefore, we do not deal with

any dates anywhere near the beginning of the century. Our system also does

not have critical date computational needs with to-the-day accuracy

required. We are primarily an OS/VS COBOL (Release 2.4) shop using VSAM

files in a MVS/ESA SP4.2.2 environment. I am on a team which is tasked with

preparing our COBOL programs for the year 2000.

A detailed plan has been prepared by our project leader and is currently

being implemented. We are using simple design elements:

1. Extensive use of bridging programs for all of the reasons mentioned

previously in our discussions.

2. Expansion of all years to 4 characters.

3. Our simple date computations will remain hard-coded. Most need to only

be approximately correct (mainly for record retention purposes), or are

only calculating fiscal year and month from calendar year and month.

4. The decision has not been finalized, but, 2 digit years may be used on

most screens and reports.

5. And, of course, we are using the opportunity to reorganize our files and

expand other fields!

-- Richard Newbold 


Per the IEEE definition, software re-engineering is a three step process:

(1) baseline inventory,

(2) analysis, and finally

(3) you change/write code (if appropriate).

Everyone wants to jump immediately to step #3. But unless you have a firm

understanding of where you are (step #1), attempting to jump to nirvana

(step #3) will inevitably lead to a lot of wasted effort.

-- David Eddy , Global Software, Inc.


5.2 In a large system fix, what are the trade-offs in changing the data

versus changing the application programs?

There has been continuing discussion of this issue on the Year 2000 mailing

list. What is best for a particular system will depend on many factors.

Here are a few of the messages from the mailing list that outline the

considerations involved. The second message below is a very strong pitch

for the procedural approach - i.e. changing the programs. This message

provoked much of the recent discussion, with many participants disagreeing,

or at least arguing that there is no one right answer for all situations.


With cost, risk and reliability as my key concern, I am listing below my

thoughts on the pros and cons of the two methods - Data expansion vs.

Century Derivation/procedural. It is a seminal issue. We need to give clear

direction to analysts and programmers before they dive into the code. We

expect to come up with the preferred instruction set in the next 3-4 weeks.

Century Derivation strengths vs. Data Expansion

(1) No expansion of copybooks, DBDs, working storage, etc. - except for

ambiguous dates and keys in segments.

(2) Can keep current century derivation logic currently in place (3) Can

code, test, system test, regression test more simply - small pieces

(subject to ambig. date and key date exceptions)

(4) Can put into production in very small pieces (again subject to

exceptions) rather than large production installs

(4a) Data expansion with phased production installs implies bridges and

conversion programs - again subject to exceptions.

(5) No need to deal with converting archived data

(6) Can create standard procedure division code or called routine which

will derive century - reduces logic error probability

Comment: perhaps there is a code way to get around ambiguous date -

birthdate, for example - if Birth- YY <50 and Soc-sec-No > x then CC = 20

Data Expansion strengths vis a vis Century Derivation

(1) No procedure division changes - except for yanking out century

derivation logic where it is now (unless we choose to not expand those

dates) - and except for secondary moves.

(2) Easier to employ junior programmers in the program changes, perhaps

even some of the detailed analysis

(3) No speed degradation (3 additional LOC per derivation - meaning 6 per

date comparison)

(4) Probably fewer test errors - no procedure division code changes (unless

we yank the century division logic)

(5) Easier maintainability after it is all over

(6) Less static about speed and about impurity of solution

(7) Cutoff date with CD approach may differ from application to application

(solution to use system date to perpetually change the pivot date plus

ability to have application pass a parm which is an application specific

pivot date exists - but adds to code complexity)

Expected life of applications and ability to marshal resources are

situational factors each co. must evaluate.

-- Tom Ster  14 Feb 1996


Losing Sight of the Problem

I read with interest Tom Ster's posting [not the one above], in which he

referred to a "century derivation" approach (the process option), as

opposed to changing the dates on his database (the data option). At the

risk of having us both burned at the stake, let me take up his case.

There has been a lot of discussion in this forum about the best date

formats to make standard, and about the importance of consistency and

standards for data interchange. New systems do need to be built with date

standards in mind, and the external view of a system does need to meet

certain standards if it is going to interface with a common world. The big

problem is how to make *existing* applications run error-free as 21st

century dates enter these systems. My perspective is an IBM mainframe one.

Most of these systems have not encountered, and are not going to encounter

a situation where 2 digit years become ambiguous. For example, in the

context of a hire date, 95 always means 1995, never 1895 or 2095; in the

context of a contract expiry date, 35 always means 2035 and never 1935. If

the 2 digit year has become ambiguous, fix it by including the century - it

has nothing to do with the millennium problem. Two digit years are not

appropriate if the context and other available information does not

uniquely identify the century, and this problem will show up when new

ambiguous year data enter the system, no matter when.

The millennium problem is that date operations and comparisons may not

generate the correct results with 2 digit years, because the CODE is wrong.

So, there is no need to fix the data at all. It is possible to solve the

problem by modifying the code. The type of code which is wrong looks like:




There has been a developing assumption that the correct and best way to

solve the millennium problem is to implement a 4-digit year in all data.

This is a case of group-think - a syndrome which can lead to reinforcement

of ill-considered solutions. I have even seen documents produced by

fledgling Year 2000 groups within large organizations that impose a 4 digit

year solution on all new and existing systems. They happily quote ANSI

X3.30 or ISO 8601, and don't realize that they are constraining their

development teams to a single, costly, and possibly inappropriate solution.

Any system using 2 digit years can readily be made millennium compliant,

provided the definition of millennium compliance doesn't impose 4 digit

years. My definition is that date operations and comparisons will yield

correct results over a range of dates including the 20th and 21st

centuries. Simple as that.

The "process solution" involves changing source code which contains logic

errors. This may be done best by replacing bad code with common subroutine

calls. It's not quite that simple though. There may be dates in keys or

sort fields where you need to take a "data solution" in order for dates to

be ordered correctly. Note that some sorts are just for grouping related

records, and it doesn't matter that 001231 is sorted prior to 990101, so

long as all the records identified by 001231 were contiguous. There may not

be a need to change all dates in sort fields and keys.

So, why wouldn't you choose to change to 4 digit years anyway? It sounds

good. It sounds like a way to standardize to a universally acceptable

system that solves the millennium issue. Ever tried it? With an existing

system, you will find that you basically unglue the system. Virtually every

copybook in the system will change. Virtually every program in the system

will require change or be impacted by the changed data structure. (Changing

the data structures doesn't make all the flawed code work, so in many cases

you have to recode parts of programs, not just recompile them). Many of

your sysin members will need to change for sort keys. Any hard-coded DCBs

in jobs, and all your VSAM DEFINE sysins will be impacted. Do you have any

user-written report queries running against databases holding derived data?

All these database definitions will have to be changed e.g. RAMIS, ASIST.

You have to deal with the user interface in your on-line component. Do you

change these data elements on screens and force users to type in redundant

digits, or put in the smart edits to build the century?

OK, that's the easy part. Now that you've entirely unglued your system, and

dealt with a major reworking, while maintaining your production system in

parallel, you have to test the new system (that's what it is - a NEW

system). You have to write conversion programs, and create converted data.

You just doubled your DASD requirements. Testing this monster is a

nightmare. Do you currently have an environment where you can run every

job, and execute every online screen without impacting other development

and production systems? Not only do you need to test it for dates in the

remaining portion of the 20th century, but you need to test 21st century

data, and if possible, a transition period from 1999 through 2000. When

this involves testing the whole system, that's quite a large amount of

work. Ungluing the system is likely to cause that flakey old undocumented

batch OS/VS COBOL system to stop working altogether, particularly if there

are magical components written in assembler.

How does the process solution avoid these problems? Well, it may increase

the amount of work required on program source code maintenance, but it

saves a whole lot of work in other areas. Unless you need to change dates

to 4 digit years for sorting, copybooks won't change. Programs will not be

impacted purely by virtue of data changes. DCBs, sort sysins, VSAM DEFINEs

and data offsets in derived data will not change. Screens will not change.

(In view of the user interface, you might want to change from MM/DD/YY to

DD MMM YY or use some other way to distinguish day from month from year).

The greatest benefit of the process approach is that the program *bugs* can

be fixed one at a time, and released into production immediately, if you so

choose. To some extent, testing can be done module by module, looking for

correct functioning of the piece of code that changed. (In the data

approach you change data structures which impact all parts of the program,

and therefore you have to test ALL functionality). Of course, you need to

test the system as a whole, and you need to simulate 21st century dates in

the test data and in the system date if possible, but you have

significantly reduced your impact to the system, and it's much more likely

to work. In this approach you are attempting to preserve the current look

of the system - files, reports, databases should all look the same as

before. In the data approach, you are intentionally changing the values in

files, reports and databases.

The Gartner Group suggests $1 a line for millennium compliance. I have seen

an instance of a data solution which cost double that. I have yet to

redevelop a system using a process methodology, but I'm looking forward to

it, if I can convince the fledgling Year 2000 strategists to stop chasing a


-- Andrew Eldridge  29 Jan 1996


One of the basic decisions to be made with regard to the YEAR 2000 problem

is whether to convert the data or the applications. Actually, it is not an

either/or situation, since data conversions still imply application changes

to accommodate the new data definitions. (Even with a highly "active" data

dictionary, applications may need to decide whether to automatically have

all output increase to 8-digit dates.)

Though one answer is certainly the "theoretically" best solution, the

implementation questions show that there is still room for evaluation of

the trade-offs. Perhaps determination will be based upon the nature of the

application subject area. (Some applications demanded 8-digit dates from

their conception years ago. Some applications may use their dates strictly

for tracking purposes and will be spared the crisis that most systems will




To prime the pump, I am offering the following points. Please feel free to

add to this list (or elaborate upon these points).

Note: These cogitations are based upon experience in administrative

university computing in a mainframe environment including MVS/ESA, IMS (DB

& TM), DB2, OS/VS COBOL and COBOL II, QMF, "Vision:Builder" (once known as

MARK IV), etc. Hopefully, some aspects are relevant to a variety of


Approach #1. CONVERT THE DATA:

PRO (Convert the data):

a. The "ideal" solution. Will survive till "near" year 9999!

b. Consistency. Not dependent upon different algorithms (or parameters) for

determining the century.

c. Accuracy of conversion. Single technique for all programs.

d. Would require less exhaustive testing. If all dates are expanded,

"boundary" type testing is minimized.

e. Conversion of many programs might often simply require a recompile (&


f. Client-written ad hoc reports would not need century-determination


g. Selection criteria in client-written ad hoc reports would continue to

work properly.

CON (Convert the data):

a. Requires conversion of virtually ALL programs (unless active data

dictionary dynamically provides new data definitions).

b. Conversion of programs and data must occur (virtually) simultaneously.

(Yes, there can be a degree of phasing the conversion based upon scheduling

predictions but the bulk of programs would be needed to be changed by the

next morning.)

c. Many of today's systems can ill afford the down-time required for such

massive, simultaneous conversions.

d. Due to the multitudinous interfaces between systems (foreign keys,

referential integrity issues), there would either have to be one mass

conversion or repetitive conversions of interfacing programs as the

underlying data bases are converted.

e. Since programs need to be implemented simultaneously, yet it will take a

long period to make the changes to the source code, keeping the converted

code in sync with updates to the current code will be difficult. The

alternative is to freeze all maintenance and enhancements until conversion

is completed. (Can any installations tolerate that?)

f. Dates will need to be truncated on output much of the time for three


1. Many screens and reports lack the available "real estate" to display the

extra data.

2. Clients will probably remain comfortable with the 2-digit year format

such as mm/dd/yy (or dd-mm-yy, or or whatever!).

3. It will be consistent with the 6-digit input that will be practical for

most screens.

g. Existing client-written ad hoc reports may suddenly expand (and

experience line "wrap") forcing output formats to become jumbled.

Approach #2. CONVERT THE APPLICATIONS (i.e. programs):

PRO (Convert the applications):

a. No data conversion. Therefore no required synchronization of data

conversion and program conversion.

b. Program conversion can be phased in - one program at a time. (For large-

scale systems, this may be very important.)

c. Some programs will require no conversion.

d. Some programs will require only minor/trivial conversion.

e. Some dates are used simply for tracking purposes and are always

contextually recognizable. They are simply printed/displayed but are not

used for selection or comparison purposes (currently!).

f. Client-written ad hoc reports would have the same format as before.

g. Downloaded data will remain unchanged. (However, the problem now moves

to the recipient!)

h. Century-determination logic (subroutines) using a "windowed" range that

floats in sync with the current date would only require the system date to

be an 8-digit value and thus could work "toward" the year 9999.

i. Converting the applications does not preclude converting the data at

some point in time. It simply relieves the time constraint, allowing data

conversion to be postponed until system replacement or other major

enhancements or upgrades.

CON (Convert the applications):

a. Some programs will require extensive code changes. (E.g. on-line

programs which do not have sort capabilities or sequence-based logic that

will require repositioning.)

b. Does not handle cases where at least 100 year span is involved.

(However, those systems would have had a need for 8-digit dates from their

initial design.)

c. Determination of century will vary by context (e.g. date of birth would

assume the past, archival dates would assume the future). This implies

"boundary" testing to insure that the determination is correct for the

given field.

d. Ad hoc reporting tools used by clients may not have access to the

programming staff's subroutines for determining century. Their reporting

techniques will have to change and will likely not be consistent.

e. Selection criteria in client-written ad hoc reports might fail.

f. "Derived" systems will have to incorporate century-generation logic at

extract/download time, or throughout their code.

IN EITHER CASE (data or application conversion):

a. Some programs will require restructuring extract files and their

associated job streams to accommodate the enlarged data fields.

b. Date input will generally remain as 6-digit input. Clients are not going

to want to code the "obvious" century portion. When stored as 8- digits,

the software will usually be expected to determine the appropriate century

portion of the date.

c. Testing conclusively is not easy. (We may have test data bases. But is

there data with the values we need for establishing correctness?) Also,

simulating a system date may be difficult. If you do not have current date

override capabilities already built into the code, you may have to purchase

a package to "fake" a future system date.

d. Finding the time and person-power will be the killer!

e. This is an opportunity to simultaneously perform other tasks that we

have not had the opportunity (neglected?) to do. A few examples: inventory

(truly) active programs!; convert to newer release of language (e.g. OS\VS

COBOL to COBOL II or COBOL/370); convert to newer language; rewrite a

system!; install a package to replace an archaic one; review/enforce

standards; modularize to improve maintainability; etc. (This might be

another good area in which we can share ideas on what we'll do while we're

in there doing whichever conversion technique we select.)

-- Brian Christenson  13 Jun 1995


5.3 What strategies are being considered for solving the following year

2000 problems: break point? - field expansion? - hex code?


While catching on my Y2K mail, I noticed an increased number of posts about

expansion versus windowing and questions about encapsulation. That's good,

however, it's been argued mostly from a "purist" point of view, not

considering a reality of Y2K projects. Question "what to use" is posted

mostly by people starting with Y2K project, answer "this approach is the

best" is posted mostly by people who are well into conversion. There is

disconnect between Y2K scenarios for these two groups - mostly in time

available to execute the Y2K project.

When making a decision about technical approach to Y2K compliance, I would

strongly suggest to consider (1) all factors involved, and (2) scoring the

factors based on your specific environment and priorities. The following is

a sample of factors (not a complete list) which should be considered:

- time remaining for the Y2K project

- Y2K event horizons for your critical systems (when will you experience

first failures)

- overall IS plans and strategy (e.g. do you plan to replace some systems

in 5-6 years? will you migrate some of your systems to different platforms?

- on-going development activities (e.g., are you rewriting some of your


- how stable is your system, how much modifications you have to implement

each year (some approaches require a much longer "freezing" period,

including data and program synchronization between old/new)

- current environment including

* languages (e.g., if a significant amount of code is in assembler,

encapsulation may look really attractive)

* data management (e.g., data expansion in IMS or CODASYL network DBMS is

much more difficult than in relational DBMS or VSAM files)

* software packages used (approach may be driven by software vendor)

* overall IS architecture (e.g. level of decentralization, heterogeneity of

hardware/software platforms, how monolithic are your systems)

* batch/on-line ratio (e.g., need to modify on-line screens based on

selected approach)

I am sure that everybody can come up with a long list of additional factors

- consider them all using you own priorities. Don't forget that the main

goal of this project is to support your company business activities through

continued operation of your systems minimizing Y2K errors and disruption.

At this point of time I see three main groups of technical approaches, each

of them having some variations:

1. date expansion (including variation of in-place compression, date

shadowing, encoding, etc.)

2. windowing (including fixed windows, sliding windows, and different

implementation techniques, e.g., windowing on I/O time or windowing on


3. time shifting through data/program encapsulation (including variation of

system boundaries for time shifting, time shifting on demand, when using

dates, or permanent time shifting in files)

Each of them have some positive and negative features which go way beyond

the scope of this post. Some may not be applicable to a specific

environment at all, and you can not take a generic approach "this is a

preferred way to Y2K compliance" - you must evaluate them individually.

Just a "sampler" of pro and cons for each approach (for variations pro/cons

will also differ):

1. Date Expansion.

Overall: this is preferred approach by many companies though it is the most

expansive and time consuming approach


- fix is more permanent in nature

- requires less procedural changes


- requires data conversion

- requires bridging between modified and unchanged programs - requires

additional storage

- screens/reports may be too busy to accommodate expanded dates and this

will require a redesign

- may requires additional tuning due to additional I/Os and excessive


2. Windowing.

Overall: this tends to be less expensive and time consuming than date

expansion but will require more procedural changes, code scanning,

examination, and testing


- does not require data conversion

- takes less time to implement

- eliminates requirement for bridging between modified and unchanged


- facilitates a gradual implementation


- requires more procedural changes

- each program requires more detailed examination and different approach

for applying windowing technique

- each date may require different time window

- may be difficult to implement for some third party software - will

require more testing dues to "procedural orientation"

3. Time Shifting through data/program encapsulation.

Overall: this is the least expansive and time consuming approach (when

applicable) though the approach is less understood and therefore



- does not require data conversion

- minimum modification to software

- affected code is easier to locate

- requires less testing than other approaches

- after some time (representing a typical time span of dates in your

system) time shifting can be turned off and system will operate in the new



- must be documented and understood by new programmers doing software


- may not be possible to implement for third party software

- difficult to implement if system has hardcoded business rules (e.g., if

96 apply this maintenance procedure)

All of the above approaches will require all Y2K phases (inventory,

assessment,... etc.) though the effort foe each phase will differ. None of

the approaches eliminates review and code analysis (if you don't know

what's inside, I would not try a "black box approach").

I a view of "Y2K state of the union", when most of the companies are still

in "assessment" phase, I think that we will see a significant shift from

"date expansion" to "windowing" and even more toward "time shifting" or

other creative approaches (where I think we will see some more

announcements in coming years).

Current orientation toward date expansion and windowing is partially due to

the Y2K tool vendors and service providers who drive the Y2K market. Most

of them did a reasonably good job in gearing their tools and methodologies

toward date expansion and windowing but this, on the other hand, created a

mind set toward these two approaches and limited our creativity and

thinking about alternatives. Well, I would urge every player in this market

to think twice. Year from now, I will have a significant problem in

recommending to my client to use an expensive tool set and approach which

can not be successfully applied within remaining time frame.

When you making good progress on your Y2K project and making recommendation

to the rest of the list, it would be good to ask yourself "would I be able

to use the same approach if was starting today?" before you make your

recommendation. Whatever is the reason for the late start, it does not help

to remind them "if you started two years ago you could use.. " By the way,

it may be your business partner, supplier, or client who is asking "what's

the best thing to do" and if they fail, your Y2K compliant system may not

be enough to keep your company business going.

-- Miro Medek , Mitretek - ITSC, 16 Jan 1997


I am writing a subprogram on my home PC that uses break point logic to

determine the century digits for a two-digit year. It subtracts 80 from the

current year to get the first year in the 100-year cycle, and then bases

the century digits on that cycle. For example, in 1995 the cycle runs from

1915 to 2014. A two-digit year between 15 and 99 will be converted to 1915

thru 1999, and 00 thru 14 will be converted to 2000 thru 2014. In 1996, 16

thru 99 will be converted to 1916 thru 1999, and 00 thru 15 will be

converted to 2000 thru 2015.

Even if you have expanded your date's year field to four digits and now

your system appears to be 2000-compliant, there are several other areas

that could cause problems as we approach 2000. For example:

- Embedded two-digit years in serial numbers and other identifiers that may

be sorted.

- Dates with two-digit years that we send to banks, suppliers, and

customers via mag tapes and EDI.

- Dates with two-digit years passed between mainframes and PC applications

such as spreadsheets and databases.

-- Rick Toker 


5.4 Why should we try to have standardized date computation routines? Why

don't we ALREADY have standardized date computation routines?


One of those hidden problems that many shops are discovering in their 2000

evaluations, is that they have anywhere from 5 to over 100 individual date


In larger shops, programmers that transfer from one department to another

may be making such a big move that they are in essence starting a new

career. If the payroll, purchasing, and production control departments are

all using the same set of date routines, the "learning curve" that the

transferee has to go through is just that much less traumatic. This

learning curve problem is applicable not only in the transfer of people

from project to project but also their movement to other platforms in a

mainframe-client/server environment. Many date routines are written in BAL

which is not portable across hardware platforms and is difficult to

maintain. Having access to a portable, standardized date routine with

consistent documentation means one less thing to worry about.

Many of the existing routines in a shop are actually the same or have only

minor modifications. Mostly, modifications were made ad-hoc, haven't been

thoroughly tested and may not work correctly in all instances. With many

differently named routines, no one is sure what the source root was which

leads to problems with future modifications (sort of like playing the game

of telephone where the message at the end is always significantly different

than it was at the start) and maintenance problems. For example, I was

recently talking with someone who found functionality that worked in one

direction (forwards) but not backwards in a routine they had been using for

many years. Additionally, documentation is outdated or non-existent for

most routines and since there is often little control over routine

development, parameter requirements may vary from one of these routines to

another creating the potential for further errors.

When considering the high number of routines in the average shop, one has

to wonder why they were created in the first place? Of course, we will

always have the "it was interesting to write it" response but more often

than not it seems that either the current "standard" routine was not

documented as existing across the enterprise, documentation on how to use

it was poor or missing or the routine(s) was difficult to use and not

logically designed. Another reason I have heard is what I call "latent

demand" (taken from my performance tuning days ). At times, additional

functionality may be desired/required but in today's "lean & mean" shop no

one has the time to write and test the code extensions. So someone finds a

routine, modifies it and then propagates it through word-of-mouth hoping it

will become the new de facto standard. After a few cycles of this, voila,

you suddenly find during 2000 inventory and impact analysis that you have

20 or more variations being used.

But a greater problem is the huge amount of in-line date processing code

that isn't even tied to a routine. In-line date code mixed with regular

code is like a bomb waiting to go off and leads to one major headache! I

was talking to someone recently who found in-line code to test for a leap

year in a system that was not written too long ago. The code was simply to

divide by 4 and check for a remainder! Now although this will work for the

next 104 years, one has to wonder if the person who wrote this knew the

rules or didn't know that there are additional tests related to century

years. Replacing in-line code with a call to a standardized date routine

should be a priority in all 2000 projects.

A reliable, comprehensive and portable date routine is an integral part of

the overall 2000 solution. Such a routine will also help lessen testing

costs and should therefore save project dollars.

Bottom line is: Date code is not as simple or easy to write as many think

and there are many opportunities for errors. Writing, extending and

maintaining date routines is an overhead function that doesn't generate

additional revenue for a company, so why do it?

-- Joe Warren , TransCentury Data Systems


5.5 Why is testing year-2000 code so hard?


First you have to make sure you haven't messed up the processing of current

1990's dates. This is the easy part. It's the normal testing you do all the

time. The only thing that makes it hard is the scope -- you will have to

retest practically all your systems.

Unfortunately, this doesn't test whether your changes do, in fact,

correctly handle dates after 1999. To do that, you have to use future

dates. There are software packages available for IBM mainframe MVS that

will intercept requests for the system date and substitute a test date. But

even that's not good enough. Your current files don't have dates after 1999

in them, so ...

you will have to create test data with future dates for every application

in your system! There are software packages available to "age" data files

for this purpose.

Once you do that, of course, you have nothing to compare the results to.

You can't do parallel testing, so ...

you will have to manually verify the results!

It is likely that you will make a lot of mistakes in the process of

manually verifying your test results. There are software packages designed

to address this problem by excluding date fields from a file compare. This

still leaves the problem of verifying that the dates in the output are


I've mentioned three places where software can help. Selecting, installing,

and learning to use that software is a significant effort and expense. It

makes the testing easier, but not easy. People are now saying that testing

will account for at least 50% of the year-2000 conversion effort.

There are some complications in aging data. You can't just roll all the

dates in the data past 2000. If all the dates are in the same century,

there's a good chance the application will work just fine without any

changes. That is, after all, the way it is running now. You need data that

straddles the 1999-2000 boundary to make sure the date calculations,

comparisons, and sorting are correct. Also, simply rolling the dates

forward by an integral number of years may not work if the application is

sensitive to the day of the week, holidays, or a fiscal year that is not

exactly in sync with the calendar year. There are no easy answers, and

there is no one solution that will be right for all situations.

-- Robert J. Sandler , revised Dec. 1997


Systems must be well tested to ensure that functionality has not been

changed in any program as a result of the date changes. This means a unit

test of the program, a system test with a test bed of data covering all

functions, a simulation test to any date in the future that may impact your

system (this involves moving your data and your system date into the

future), and finally, a test with historical data to make sure you can

process old data through the system once changes are complete. Developing a

test bed for these changes is a significant task. The testing stage

represents 40% of the effort for the entire project.

Organizations that have established inventories, change control procedures,

and test beds of data can move quickly and efficiently through this

process. For most though, these steps will form a significant part of their

Year 2000 project.

-- Brenda McKelvey  from a report on the "Year 2000:

Blueprint for Success" conference in Orlando, Florida, November 1995


Having now worked as Y2k project manager with two very different

organizations, we are finding that testing requires a MINIMUM of 60% of the

effort. On my current assignment, it is closer to 80%. This assignment uses

windowing exclusively. The previous one used expansion exclusively. . . .

One of the most significant aspects of testing has been the running of a

baseline test set BEFORE upgrading the software. This was not done on our

pilot and we paid for it big time (that's what pilots are for, right). We

found a number of processing errors during system testing and spent

significant effort resolving them, only to find out they came with the

migrated code.

We just completed doing the baseline on one of our applications and, guess

what, we hit the condition again. There are several programs that won't

compile and a couple of others that don't run the same way as they do in

production. Having the baseline will avoid repeating the pain experienced

in the pilot.

This results in a net time saving but increases the testing vs upgrade

ratio. It also means that we have to resist jumping in and changing code

before the baseline is run (that is a major phychological hurdle when the

pressures are very high to get things fixed).

-- Larry Towner , 19 Mar 1998


The Y2K project I am working on is moving into the modification and testing

stage. We've analyzed progams, and picked a pilot (initial release) and now

it's time to get our feet wet. Ideally we'd like to test at the client

site, and not use any testing tools to time warp the date. However, I'm

running into difficulties finding a shop that has Y2K compliant system

software. Our client won't have a Y2K compliant machine until mid 4th

quarter this year. Which is really late for testing to begin.

What's the general approach in this group? Are people using tools? How are

people including the system software in their overall strategy? Do I have

sugarplums in my head if I think I can find a Y2K compliant machine, before

December 25, 1998?

-- Ruth Younie  22 Jan 97

You've encountered a "common" problem. I recognized a similar problem in

getting a separate testing machine spec'ed. I decided on the following

approach to delay the required delivery of that software and hardware.

I'm doing a "multiple pass" testing approach thru the applications

portfolio to get around the problem. The first pass will get our code to a

"minimally compliant" state. That is where the databases, files, programs,

data bridges, etc are all installed and tested using todays date and using

current data. Everything will look right, run right, and go back into

production. You can't say that you are totally compliant but you can say

you are "minimally compliant". I can do this, and you can also, without

changing any systems dates or getting any new versions of software.

The implication is that you haven't accepted "extra baggage" on the project

that require new software from the start. Things such as an operating

systems upgrade to use new intrinsic functions, replacement of systems with

packages that require the new software, etc.

Projects where total efforts are already known to exceed available time

left would probably have real problems using this approach but that isn't

my problem or my company.

I expect, and accept, this to be a more expensive approach but it will

delay the need for the new box and software by several months of time.

Whether that separate box is yours or someone elses is your decision.

The second pass thru the testing cycle will require the software and

hardware you discussed. That second pass will be where

you change systems dates, install the Y2K complaint systems software, and

do the "time warp" testing. You are then successfully and fully "Y2K

compliant", a Y2K hero.

-- Harold Carruthers  24 Jan 97


In all the discussions there is one thing that is avoided or forgotten.

Testing applications that communicate over the network to own company

departments but also to outside companies...(EDI,FTP,Appl-Appl etc)

From your posts I see that you are already glad to have it run on and test

it on one machine.

But see the problems of testing, and even get a standard to work on with

linked machines (applications).


Company "A" has 4 outside links to other than his own company machines.

One of those outside companies has 15 links like that.

The other 14 companies I forget for the ease of talking. (but they are


Now the programs communicate.

But can you test the new Y2K compliant updates?

You need all the machines on the same time online or a planner with an IQ

that is not available.

Or everyone needs testing it to each other one to one...

That means until 2005 when you have more to do or 15 different companies


This is a simple example of an environment.

Company "A" can't control the standard and testing time for the other

companies. They also can't.

This all in mixed mainframe, minis ,PC and Terminal configurations.

-- Hans Goossens , 05 Feb 1997


5.6 What are the critical dates that programs must be tested with?


I don't remember how many times such a question has been asked. Each time

it reveals that the questioner does not understand the fundamental aspect


There is no way (IMHO) that any one of us on this maillist can take the

responsibility for giving you a list of dates to check without

accomplishing a through evaluation of each and every one of YOUR business

processes to determine WHAT DATES YOU USE. The best that we can do is to

provide you a list of dates WE test for and let you decide which ones YOU

should test for based on YOUR business processes. Even then, I expect that

the list will miss at least one important (to you only) date. You or your

Internal Auditors would be extremely lax and nondiligent to remove even one

date based on a note form this or any other maillist.

I'm sorry, but each and every one of us has to accomplish this work for

ourselves. There is no way someone else can do it for us. Even if you have

some contractor build your systems, it's still YOUR responsibility to check

and make sure he got everything. Look at the postings to this maillist and

you will notice a very strong trend to saying YOU, and YOUR responsibility,

and YOU must test, and YOU must, etc. in everything. No one can do your

enterprise's work for you. Year 2000 is the ultimate "every enterprise for

itself" problem. This is not business as usual, letting a contractor or

"expert" tell you what to do and then slavishly following the advice.

Doesn't work for this problem.

This is not to flame anyone, but everyone MUST understand that you are in

this by yourself. Others can help, but you must do your own work to get

through this successfully.

-- Dave Hall , 23 Apr 1998


5.7 My concern centers on those systems that have already hit their "event

horizons" and have been fixed using whatever solution.

(a) Is it possible that these systems will still experience problems come

the first of January on the year 2000?

(b) If System A implements Fix1 instead of Fix2, does this mean System B

later has to implement Fix1 also, for compatibility purposes?

(c) Finally, is it possible that the immediate fixes today on System A may

adversely affect other systems which depend System A, either now (and the

other systems don't know it yet) or after the first of January on the year



question a:

You can almost bet on it. Some of these fixes may have been so

short-sighted as to be almost humorous. If you keep a maintenance log, you

may want to scan it for anything involving "date" and review that work as

part of your analysis.

question b:

Probably not. Depends on the interface between them. Mixing and matching

fixes is no doubt the best approach in most cases, as long as no

inconsistencies causing direct conflict (present or future) are introduced.

question c:

Again, probably (see first answer above). I believe the most important

factors in analyzing the problem are:

* Know the extent of the problem (at least approximately), and know what

the margin of error is. Identify what must be fixed before a certain date

(and just what that date is), and what could be fixed after Jan 1, 2000 if

necessary. Make a conservative estimate of the cost of the fix, then double

it. Allow mountains of time for testing.

* Decide on an approach, so that everyone can have the same picture of

what's going on and how far along things are. Know what the tradeoffs are,

and what level of perfection is acceptable. Make changes as needed, but be

sure everyone knows what changed.

* Try to get someone at a high level to commit to picking a few fix

methods, based on some typical cases, and forbidding anything else unless

it can be proven that none of the chosen fixes will work for a specific


* Keep looking at the scope of work and the time line, to be sure what you

are attempting is still possible. Raise a red flag if this aspect looks

even close to being a problem.

These answers are taken mostly from Mike Scullin  These

questions are taken from the following note ...

I don't have a technical background but I do have a stake in the management

of this two digit nightmare. My concern centers on those systems that have

already hit their "event horizons" and have been fixed using whatever

solution. Is it possible that these systems will still experience problems

come 1/1/2000? I've been told by some who have already been forced to make

changes, that the only systems that are really in trouble are the ones that

won't hit they're event horizon until 1999 because all other systems will

have already been dealt with. Also, if System A implements Fix1 instead of

Fix2, does this mean System B later has to implement Fix1 also for

compatibility purposes? Finally, is it possible that the immediate fixes

today on System A may adversely affect other systems which depend System A

either now (and the other systems don't know it yet) or after 1/1/2000?

-- Brown, Capt Donald 


on Mike Scullin's  above answer to question a:

I couldn't agree more. Even though most installations will end up using a

combination of solutions (expansion, sliding, & even bit twiddling), we

should provide a standard set of utilities to the programmers, along with

some guiding principles.

First, there is nothing more imaginative than a programmer with an

interesting problem to solve. This usually results in mostly solid code ...

with a few really "nifty" solutions tossed in. In my experience it is the

"nifty" stuff that bites you in the long run ... often by destroying the

ability of vendor provided tools to help you when you need it most.

For instance, imagine that in a COBOL shop all date handling was done by an

assembler routine, software that traces the propagation of dates from one

module to another would probably get lost when the date went into this

"foreign" routine. Maybe it's not a great example, but I hope you get the


Second, in larger shops, programmers that transfer from one department to

another may be making such a big move that they are in essence starting a

new career. If the payroll, purchasing, and production control departments

are all using the same set of date routines, the "learning curve" that the

transferee has to go through is just that much less traumatic. Or worse, he

encounters a routine that looks and smells like the one that he is used to

... but which behaves differently. Now you've got a bug.



Good questions. I also have concerns about the sliding-century-window

approach. It is not good enough to investigate the system under test and

its interfacing neighbours. A long way down the line something may go wrong

(e.g. installed base systems tend to be a collection of data from many

sources). So if data on customer contacts, contract periods and so forth is

accumulated there, all with different century-windows or other solutions,

things may get pretty confusing for the employee who is helping a customer.

The problem is that in many cases, even if we have an adequate description

of a machine-machine interface, we lack a clear picture of how information

flows through our processes.

Still, taking chances that your installed base is messed up may be better

than take the certain costs of converting all dates.

-- Serge Bouwens 


5.8 What is a Bridge program? Why should I use a Bridge program? Is it a

permanent solution for Y2K problems?


We may not all agree on what the "right" solution to Y2K is, but most

everyone admits that when the real world invades our plans, we'll end up

using a combination of solutions. Along with "Field Expansion", "Sliding

Calendars", and "Bit Twiddling", "Bridge Programs" are likely to play a big

role in our approaches.


A "Bridge Program" as used for Y2K purposes, is a program that converts one

record layout to another.

The crudest form of a bridge program would occur if a downstream system

changed it's input format to require a four digit year, and then asked you

to provide all future interfaces in the new format. You could write a new

program that:

1. Defines the input record using your old copycard, with two digit years.

2. Defines the output record layout using the new copycard provided by the

downstream system, with four digit years.

3. Copies each field from the input record to the output record (maybe a

"MOVE CORRESPONDING" statement would work in a COBOL shop)

Note: Marty Tabnik  adds that MOVE CORR is

dangerous for three reasons:

1. No internal documentation (which fields DID we move?).

2. If names in the two group items are not IDENTICAL, the field will *NOT*

be moved ... and you may not know! (see # 1)

3. CORRESPONDING means *relative level* NOT actual level number. Insert a

level number and {blam!}, you're dead. And you will get *NO* warning from

the compiler (see # 1). Pay the $2. Write the extra source code.

4. Fixes each of the date fields in the output record. Worst case would be

to plug a literal "19" into the missing century field. Beware - I've seen

it in my systems.

Of course, there will be times when you'll need to take "useless" centuries

out of an input file that has been converted to Y2K format before you are

ready for it. It might make sense to design all bridge programs to convert

in both directions.


There are several reasons that bridge programs will be used.

1. Eat the Elephant One Bite at a Time.

Most of us are facing a task that is so big that we just don't know where

to start. If system A is changed, then systems B and C must be changed at

the same time. If B and C are changed, then systems D, E, F, & G must also

change at the same time. Can you afford to shut down operations for a month

just to do compiles? What do you do if one of the downstream systems is a

vendor or customer that can't or won't face up to the issue yet? This

"cascade effect" can be controlled with bridge programs.

2. The Reverse Cascade Problem.

Even if you COULD schedule all the Y2K work for the same time period, what

happens if one of the downstream systems fails during testing? Do you

suspend work on your nominal backlog of change requests and wait until

EVERYONE is ready to launch Y2K, or do you back out all of your Y2K changes

and start over again later? Remember, if work on system D is undone, then

work on system C must be undone, and systems A, C, F, ad nauseam.

3. Cost Effectiveness Decisions.

Bridge programs can also be used to minimize the cost of the Y2K problem,

or at least the immediate cost. It may not make sense to change all of your

systems right away -- in a few cases, it might NEVER be cost effective.

Bridge programs can "fudge" the input and output files of these programs.

4. Re-Runs, Backing Up, and that "Forgotten" program.

If, for any reason, you need to run a pre-update program with a post-update

file, or vice-versa, a bridge program will let you convert the files into a

suitable format. In my experience, this is the type of need that is

discovered in the middle of the night, not the time to plan a program



Bridge programs are TEMPORARY solutions to launch timing problems. Well,

that's the idea anyway. My biggest concern about bridge programs is that

they will become fixtures in our systems. Worse yet, that they will be

convenient places to put other, non-Y2K, band-aids. If this happens, and

the bridge is removed when "that other" system is finally updated, the old

bugs will re-surface.

An over-all plan should be in place when you start Y2K conversion, and an

expiration date placed on each bridge program. - discussion of bridge programs inspired by postings from

others, such as ...

bill_parkinson@Merck.Com (Bill Parkinson),

rhd@FormalSys.CA (Ron Hunter-Duvar), (Gene Lynd), (Dale Vecchio), (Serge Bouwens),

Sarah Stephens, and many others


Bridge programs will undoubtedly help in the transition year 2000. At my

company, we have had good experiences when I introduced these two modules

on the mainframe some years ago:

(1) FULLDATE - a completion of a year from 2 digits to 4. The century is

the century precisely at the time you call the module, Right now it then

yields '19'.

(2) CHOSECEN - also a completion of a year from 2 digits to 4. You chose

yourself the wanted century, e.g. '18' '19' '20'.

At the same time I urged people NOT to make statements like


and I asked them to change existing statements to one of mentioned calls.

The purpose is of course to encourage storage of years with 4 digits.

-- Jens Peter Soltoft 


I agree with's statements regarding bridge programs with

one exception. Bridge programs are not Temporary. Unless you convert all of

your old tapes, you will always need a bridge to convert an old restored


-- Bill_Parkinson@Merck.Com

On Bridge programs being Temporary ... One of my most trusted advisers, Mr.

Murphy, mentioned that

You will *DESPERATELY* need your bridge program

the day *after* you scratch it!

-- Marty Tabnik 


25 years ago when we were converting our flat files to ISAM we made bridge

programs to recreate the flat files from the ISAM files. This was supposed

to be temporary until systems that used the flat files could be converted

to use the new ISAM files. It has never happened. These bridge programs run

every night and the programs that use the flat files happily do their


-- Francis J. Hensler, CDP 


5.9 What are the problems with converting and testing a worldwide connected

system of computers?


Most of the discussions of the list are technical and that's fine, but it

is not solving the problem that most computer centers don't have a good

change management, recovery management, operations management, Quality

management etc. If worked according to ISO9000 or another Q method, a lot

of problems could be detected by the companies, but this costs $ and the

share holders don't like that.

I am a network consultant and work most of the time with problems of how to

change network topographies etc. and checking the implications on a large

scale. I want to start discussions on this item because it is not a

technical but a organizational problem. Problems include, but are certainly

not limited to:

- Companies with 150 mainframes/mini's networked, have to change and test

at the same time (GMT) at least once.

- What to do when 20% of the systems can't change because of problems (know

how, software documentation, no project leaders, no programmers).

- How to go back when major problems in 3 mainframes (vital to the company)

go to an old situation (unforeseen software problems in bridge programs


- Distributed databases have backup sync's (mainframe, PC's, mini's) I did

a restore one time in a distributed database area and learned that the

biggest problems was how to get the data back to systems that are not

on-line when you want them and at what time/date the systems are after

restoring. Most of the time a lot of transactions have to be recovered

(typed in or automated) but the people at the display's or PC's don't know

where to start and what to type in. Most of the time there is no paper

backlog of what was being done 2 day's ago.

- A software restore is a database restore (think network-wide, world-


- Cooperative processing (think network-wide, world-wide).

- A profit center with a large network can go broke when off-line for a few


- Go into history for companies that did NOT have a good backup management

after an earthquake (all gone after a few years).

I want to get a list of what you people can think of (network-wide, world-

wide) so that good project leaders can try to create projects covering all

of the problems. This case is too dangerous to forget important items. When

our work is not done good it can have big social implications.

--Hans Goossens 


5.10 How does one pull together a reasonable Y2K plan, when management is

clearly reluctant to devote adequate resources to even determine the most

rudimentary extent of the problem?


I was just looking at some Howard Rubin statistics that pretty clearly say

that 60-70% of "senior IT management" is essentially oblivious to the Y2K

issue (in 1995).

-- David Eddy , Global Software, Inc.


It would seem that the best idea would be to formulate a letter designed

for the CIO/CFO/CEO that hits them (cold) with what the Y2K problem is and

just HOW serious it could be (for them specifically). Also it would also be

a good idea to come up with a list of suggestions that could be put into

place immediately and prior to any thought of a Y2K plan. Of course there

is not much time left for this kind of subtle approach, and this would need

to be done in 1995 or early 1996.

-- John Moffitt


5.11 What is encapsulation?


This is a very important question, the answer of which will have a major

impact on Y2K thinking in the coming months and years, I believe. It is

part of the larger question as to what are the all the possible major

approaches to Y2K protection.

(Note I used the word "protection" rather than "repair" or "fix." Those

last two imply that our programs are, or will be broken. We could debate

whether they really work now or just haven't broken yet,  but the

truth is they do pretty much work now and given their rather fragile,

brittle nature, especially when considered in the context of contemplating

wholesale changes across a wide front in a short period of time, there is

something to be said for leaving them intact as much as possible. Could it

be that they do in fact work and all we have to do is "protect" them from

an "external change in the environment," that is, a time-shift out of their

assumed century?)

There are basically four approaches I see, other than replacement:

1) Date expansion

2) Windowing

3) Data encapsulation

4) Program encapsulation

Only the first two are normally considered on this [mailing] list. The last

two, like windowing, are examples of time-shifting. I am turning for the

definition of these terms to Don Estes of 2000 Technologies Corp. in

Lexington, MA . Don has written a draft

document of his exploration of the two encapsulation techniques which he

posted to this list on Jan 02 and sometime before as well. He has captured

the notions very well. I have his permission to use his words, which I have

reorganized slightly for my purpose and capitalized the key words. (Don

does not necessarily subscribe to my other thoughts.)


"DATE EXPANSION strategies change the data, the data descriptions within

the programs, and change logic throughout the programs.

WINDOWING schemes allowing maintenance of a 6 position date will usually

localize the changes to procedural logic, thus markedly reducing the scope

as compared to date expansion, but the changes are still pervasive

throughout the programs.

Time shifting strategies are similar to windowing in that a 6 position date

is maintained, but differ in that the programs effectively execute in the

past. There are two variations of time shifting:

DATA ENCAPSULATION, in which modified programs execute in the past against

unchanged data. Data encapsulation in most cases will localize changes to

the input and output logic sections of the program, which shift the data

back in time on input and forward on output.

PROGRAM ENCAPSULATION, in which unmodified programs execute in the past

against data which has been turned back in time. Program encapsulation in

most cases changes no code at all, which makes it a perfect solution for

cases where the source library is seriously lacking in integrity. In this

strategy, firewalls are constructed at the points where data enter and

leave the system which shift the data back in time on input and forward on


Thus, the only architectural difference between the two strategies is that

data encapsulation does the time shift internally to the program and

program encapsulation does the time shift externally to the program."

(c) Logica Inc. 1996

Permission is granted for reproduction and distribution of this document

provided it is complete, unmodified, and retains all Logica identification

including this statement. All other reproduction and distribution is

expressly forbidden.


The most significant thing here, I think, is that program encapsulation

takes the time-shift function out of the program. This has great import for

its theoretical ability to preserve the "working" programs intact and

saving a lot of TIME. It has greater import in the case where source code

is missing or otherwise unavailable, a serious Achilles Heels for most

large organizations.

Source code could be unavailable for a variety of reasons besides just

being lost: it is unreadable from its obsolete media, it is uncompileable

because its compiler is obsolete and lost, it has been disconnected from

the object code that runs because the object was modified directly, it can

be in such an obscure language that no tools are available to analyze and

modify it and the amount to too great for only manual efforts, or it could

belong to a third party and be legally restricted. If programs with

unavailable source code could be protected, then a major sword could be

removed from over the heads of many organizations.

Further, what if more than one program could be encapsulated at a time?

What if collections of programs could be encapsulated as a unit, leaving

their interconnections intact as they are? From their point of view after

their external input data has been backset to the 20th Century, their

between-themselves interactions could be left as they are and their

external output could be forwardset. What if that unit could be large?

Could that not save a great deal of time and effort on this side of the

Millennium and buy us time on the other?

Oh sure, you would say. How can you encapsulate the program by changing the

date (and date-dependent) data incoming and outgoing if you don't know what

the program is doing with dates because you do not have the source code?

Good question. But what other "information source" about the system is

available? Documentation? Forget it. The kindest thing to say is that

documentation is insufficient. Human knowledge? For some code maybe, a big

maybe. But more likely that is also insufficient. But there is another

source of information available: the data itself.

If the data could be analyzed to determine the date-related behavior of

programs or groups of programs, maybe it would be possible to protect them

without intervening in their delicate operations (above all else, do no

harm). This, I believe, is a very promising field of endeavor. There are a

number of difficulties, no doubt, but what other approach offers a chance

to deal with unavailable source code in all of its variations and save big

chunks of time as well?

And for programs that do have available and current source code, program

encapsulation does offer some serious time savings, especially in testing

(another big Achilles Heel), where every change to the code has a potential

of raining "unintended consequences" over other programs, even beyond

application boundaries. True, program encapsulation does not "fix" the

problem, but wouldn't we rather replace many of these systems anyway IF WE


And what does "fix" really mean anyway? Does it mean carrying 8-digit dates

everywhere and the logic to go with them? I think a good case could be made

for taking date references and computations out of the application code

altogether *where possible* and "universalizing" them in some kind of a

"date server," like one based on TransCentury Data's standard date

routines. That would seem to me to be to be a more permanent and

maintainable fix. And while we are at it, why don't we take data management

out of the code and put it in a "database server" as well for the same

reasons? Sounds like a good idea (think I'll talk to Larry Ellison about

that). How about the user interface, too? (Steve Jobs?) Wow, this sounds

like a client/server architecture.

No, I say fixing but staying in an obsolete architecture is not really

fixing, not when there is a choice. Program encapsulation MAY give us that

choice. Later migration to a modern architecture is certainly a better

"fix" than distributing date representation and logic in every separate

program where "artistic flare" can make for clever programming but lousy

maintenance practice.

And oh, by the way, I would bet that the knowledge one would gain analyzing

the data to determine the date behavior would be VERY useful in later

modernization. Or data warehousing. But that is another story.

-- Dale W. Way , DBStar, Inc., 6 Jan 1997


NOTE: Program encapsulation is covered by U.S. Patent number 5,600,836,

which is assigned to Turn of the Century Solution, Inc. of Wayne, PA.


5.12 What is windowing?

Windowing is a method used to determine the century (the two high-order

digits of the year) for a two-digit year by presupposing that the year

falls in a specified 100-year range, or window. For example, if the window

is 1980 through 2079, any two-digit year of 80 or higher is in the 1900s,

and any two-digit year less than 80 is in the 2000s. If the range always

starts with the same year, as in this example, it is referred to as a fixed

window. The window can also be determined relative to the current year when

the program is running. This is called a sliding window. For example, if

the sliding window is defined as starting 20 years before the current year,

then when the program runs in 1997 the window is 1977 through 2076. When

the same program runs in 2001, the window is 1981 through 2080.

-- Robert J. Sandler 


For the past 20 years we have used two digit year formats and all our

systems worked. We were in effect using a fixed window 1900 to 1999. It was

when we all became concerned with the year 2000 probelem that we started to

say that windowing pivot points create for us problems. If we use two digit

year date formats for dates whose range is near or greater then 100 years

we have a date format problem. The problem must have been there

irrespective of year 2000.

If the interfaces have been working for the past 10 years and are today

working then a sliding window with +15, -85 year about current year should


Michael Yastreboff , 3 Apr 1997


5.13 How can you properly sort dates with two-digit years?


Both DFSORT/MVS Release 13 with PTF UN90139 and DFSORT/VSE with PTF UN99635

can sort, merge, and transform a wide variety of character, zoned decimal,

and packed decimal date formats with two-digit years using a fixed or

sliding century window. For details, see the DFSORT home page at one of the

following URLs.



-- Robert J. Sandler , 21 Jan 1997


DFSORT R13 PTF UQ05520, available now, delivers the following additional

DFSORT Year 2000 features requested by our customers:

o A new Y2S format. Y2S can sort, merge and transform two-digit character

or zoned decimal year data according to the century window, while handling

binary zeros, blanks and binary ones in the year field as special


o A new Y2B format. Y2B can sort, merge and transform two-digit binary year

data according to the century window.

o FREE=CLOSE support for DFSPARM. This makes it possible to override SORT

statements generated by multiple COBOL SORT verbs in the same COBOL

program, using appropriate DFSPARM data sets with FREE=CLOSE.

Complete details on all of DFSORT's Year 2000 features, including these new

additions, can be found in our SORT2000 paper. You can browse SORT2000 from

the DFSORT home page at URL:

or download which contains postscipt and text versions of the

paper, via anonymous FTP from:

or ask your IBM representative to obtain the SORT2000 paper for you from


-- Frank L. Yaeger , IBM DFSORT Team, 04 Jun 1997


The following two articles in Technical Support Magazine discuss DFSORT's

Year 2000 features:

- December, 1996, "Sorting Out Two-Digit Years" by Frank Yaeger

- October, 1997, "Year 2000 Compliance: New DFSORT Features" by Michael H.


-- Frank L. Yaeger , IBM DFSORT Team, 28 Oct 1997


SyncSort MVS has been enhanced to provide facilities to define and

manipulate date-related data. New date formats have been added which treat

a two-digit year as an implicit four-digit year. This is accomplished with

a user defined "century window" value which is in effect during an

execution of SyncSort. The "century window" defines a fixed or sliding 100

year window. This places the two-digit year in the proper century for

SyncSort functions such as sorting, merging, record reformatting and data

conversion. The data formats can also be used to process the month and day

portion of a packed decimal field separately from the year portion. [This

feature requires that you have at least Syncsort release 3.6 TPF 2


-- John Reda , Syncsort Inc., 06 Jan 1997


As of Q3 1996, Unibol supplies year sensitive sort features within UNIBOL

SORT. These work on ASCII or on EBCDIC data.

-- Michael Gerner , Unibol Ltd., U.K., 23 Jan 1997



6.1 Who provides tools and consulting services to help with our Y2K

conversion efforts?


Generally there are 5 categories of vendor products that are applicable to

Y2K conversion projects:

1. System date simulators.

2. Code analyzers.

3. Pre-written add-on date functions.

4. Language upgrades.

5. Database converters.

(See the article "Party When It's 1999" in the April 1995 issue of Software


Categories 2 and 5 are common in many conversion projects.

Categories 1 and 3 are especially designed for Y2K projects.

Category 4 is common for Y2K projects at sites that are not using the

latest languages or levels - either because they haven't had the time to

upgrade (that's another project) or because they decided they can get along

with the old stuff without having to pay for the maintenance contracts.

-- Romy Leibler , Can Do Systems, Inc.


The Year 2000 Information Center at contains links

to information on over a hundred vendors of tools and services.


Com.Links Magazine, a management e-zine for Year 2000 issues at, has a vendor page that "lists vendor web sites

taken from news releases, e-mail, robots & search engines." It has a brief

description of the product or service offered by each vendor.


Dreamtap Consulting has published an independent evaluation of tools for

Year2000 Impact Assessment of MVS applications, including CICS IMS COBOL


If you wish to check it out, it's available through

-- Peter Eldridge-Smith , 01 Jan 1997


6.2 What role can the Internet take in the solution of the Y2K problems?


We need to find a way to collaborate on a global basis to set standards of

approach to solutions and to share every bit of knowledge as common

stakeholders in the down-side impact.

If we do not ...

Reactions to this suggestion are 80% based on a win-lose mindset. 'Let them

rot, maybe I can get out on top of this one.' This is based on an

incomplete understanding of the interdependency of this problem and a

paradigm that is more and more out of date. You cannot gain a competitive

advantage if you have handled your Y2K problem, and your suppliers and

customers have not.

Some reactions (from knowledgeable people) give hope. Their approach is

based on a win-win mentality and are in the spirit of organizing within the

company, within the branch, sharing knowledge, and so on. My findings (so

far) are that you're considered naive or overreacting (depending on your

status in the company). I think it will not happen on a large scale, but

that is no reason not to try.

We realize that sharing knowledge with the rest of the world will help

everybody more than trying to invent everything ourselves. That's why the

Year 2000 mailing list is a showcase for every company where top management

has not yet appreciated the value of Internet and the value of win-win


-- Serge Bouwens 


6.3 What mailing lists, newsgroups, archives and other Y2K references are

available on the Internet?


The Year 2000 Information Center home page on the World Wide Web is at The Information Center has a countdown clock,

articles on various aspects of the problem, vendor information, this FAQ,

and links to related information. It also has a year-2000 bookstore -- see

question 6.4 for more information.


There is an Internet mailing list operated by Peter de Jager for

discussions of year 2000 computer problems. The list has over 2500 members,

and gets an average of about 60 messages per business day. This is a

moderated mailing list managed by a paid administrator and fully supported

by its members. Each member pays a subscription fee of US$50 yearly. (You

may contribute more if you wish.) New subscribers get a 30-day free trial.

To subscribe, select the "Year 2000 Announcement List" link from the Year

2000 Information Center home page at On the

subscription form, select the Yes radio button for the Discussion List. You

can also subscribe by sending e-mail to with SUBSCRIBE in

the subject line of the message. Subscriptions are processed manually, so

please be patient. The list can optionally be received in digest form

instead of individual messages. Invoices and receipts are available if

needed. Details will be sent when you subscribe.

Most of the material in this FAQ comes from this mailing list.


The Year 2000 Forum on CompuServe has discussions of all year 2000 issues,

and a collection of files, including this FAQ. There are over 1000 members.

To reach the forum, GO YEAR2000.


The Usenet newsgroup is dedicated to discussions of

year 2000 computer issues.


The current version of this Year 2000 FAQ is available from the Year 2000

Information Center at On the home page, select the

"Year 2000 Archive" link. The FAQ is the last item listed on the Archive


The FAQ can also be obtained by anonymous FTP to It is in

the /pub/year2000 directory. The file name is y2kfaq.txt.


For the past 8 months the Society for Information Management (SIM) Year

2000 Working Group has been creating a web-based online conference where

year 2000 project managers can share their best practices and help each

other succeed. We are happy to announce that it is now open for a test

drive. The conference is free of charge to all.

To visit the conference and/or participate, enter via, then

link to the SIM Year 2000 Working Group's website, and then link to the

conference. First time visitors need to register and then it's just a

matter of logging in and doing your thing. Update your "profile" to tell

people about yourself if you wish. Check out the help function -- It's

pretty good. Most of all, help us make this online conference facility

serve the common good and help all who visit.

The SIM best-practices conference is divided into 12 main "topic" areas

(e.g., conversion, testing, people issues, legal issues) with multiple

"conversations" (aka "threads") under each topic. Currently there are over

100 of these conversations so that one can focus their attention of the

specific matter of interest to them. There's also a "Play Zone" where

visitors can experiment as well as a "suggestion box" email address. The

conference has its own search engine also so that one can look for

information across multiple conversations. All content (unless profane,

mean-spirited , or otherwise unsuitable) will remain posted in the

conference for the duration.

SIM is a non-profit association of IS professionals.

-- Leon A. Kappelman, Ph.D. , Co-chair, Society for

Information Management's (SIM) Year 2000 Working Group; Associate

Professor, Business Computer Information Systems, College of Business

Administration, University of North Texas; March 12, 1997


Com.Links Magazine is the primary US web e-zine for Year 2000 issues,

featuring key papers, news, vendor information and all legislative reports

from Washington. This resource can be found at

Also at this site are details of Countdown 2000, the Y2K television

program, and Y2K Investor, the Washington DC twice-weekly radio program.

-- Alan Simpson , Managing Editor, Com.Links

Magazine, October 19, 1996


IBM is making available to everyone a comprehensive Year 2000 resource

guide, at no charge. The guide explains Year 2000 issues and helps users,

vendors and customers successfully plan for and implement Year 2000

transitions. The 180-page document, entitled "The Year 2000 and 2-Digit

Dates: A Guide for Planning and Introduction," is available on the World

Wide Web through the IBM Software Home Page, at Customers can also obtain the guide from their

IBM marketing representatives.

This no-charge resource is a compilation of IBM's Year 2000 findings,

recommended approaches and product listings. Also included in the guidance

paper is a bibliography of other Year 2000 publications available

throughout the industry.

-- from IBM press release, "IBM Readies Customers, Products and Services

for Year 2000 Transition," October 30, 1995


Here's some info I received today from our [Microsoft] rep:

Microsoft and the Year 2000

Wednesday, April 15, 1998, Microsoft will introduce the "Year 2000 Resource

Center" ( This site will include

Microsoft's definition of compliance, categorize each MS product based on

that definition of compliance (compliant, compliant w/minor issues, or not

compliant), offer detailed testing guidelines and recommendations, and

provide information on Third party "Year 2000" tools.

This will be an evolving site. Check it periodically for updates.

-- Anne Voigt , 14 Apr 1998


The Y2K Links Database site is about providing a quick links and

informational databases. We bench test and provide a first-look at software

and hardware that could help solve your Y2K problem. Y2K Links is also the

hub of the Year 2000 Millennium resource Site Ring. A group of web sites

dedicated to the year 2000 problem and combined the largest Y2K resource on

the Net. Y2K Links is owned by Pc Check inc.

-- Natasha, 2 Oct 1997


Hardware/Software Compliance Information

Feedback from web site visitors tells us that there is a real interest in

accessing compliance information on commercial computer hardware platforms

and software packages. We have just created a new section on the site to

contain links to such information as provided by the manufacturers. Our

listing is small at present but sure to grow:

Companies interested in listing or linking to their compliance information

from this page should contact Shaun de Jager at

-- Cliff Kurtzman , April 4, 1997


Vendor compliance lists -- 3rd party software

Mike Zbierski  wrote:

>I was just wondering if anyone is keeping a list of non-compliant 3rd

>party software on the market. I am sure there are millions of them but

>it would be handy to know where to start looking.

A few weeks ago, I asked a similar question. Here is a summary.

Thanks to Robert Franchi, Diana and Michael who replied to me directly

(sorry, I lost a couple of surnames).

From Diana (

From Michael (

From Robert Franchi (Robert.Franchi@FMR.Com):

All great resources - thanks.

-- Gihan Perera , 02 May 1997


The state of Washington has a pretty good web-site for y2k stuff, including

hardware and software vendor lists. The contents of the lists are responses

from the vendors, not the results of testing by a third party, so should be

taken with a grain or two of salt 8^) The lists aren't complete, and have

lots of "No Response" entries . . .

The url is


-- Pam Hystad, Sys Dev Spec, CDSI for USEPA at MED-D, 21 Jan 1997


The U. S. government Year 2000 Interagency Committee and the General

Services Administration, Office of Governmentwide Policy, maintain a Year

2000 Information Directory at


Unisys has a year 2000 web site at


I just updated my annotated bookmarks web page at

The objective of this page is to accumulate links to technical articles on

the Y2K problem and supporting information such as testing, software

quality, and project/program management. I am trying to minimize general

Y2K information which seems well supported on other sites and vendor

listings which are similarly well supported.

I hope that you find it useful and I also hope that you will contribute

some of your links to this page. Your comments and ideas are most welcome.

-- George Girod , 05 Jan 1997


As part of our "creating awareness" process we have created a web page

containing links to magazine articles and [the Year 2000 Information Center

home page] as well as attempting to maintain an archive of the [mailing

list's] daily digests.

There's some redundancy but hopefully enough new to make it worth a visit.

Let me know what you think.

-- Robert Lieb 


Jan de Decker  maintains a collection of references to

press articles about the year 2000 problem on the World Wide Web at


The U.S. Air Force HQ Standard Systems Group has a very extensive Y2K Web

site located at URL:

-- Robert P. Coble , 08 Oct 1996


We at Xpress Software, Inc (XPS) have been sponsoring an open discussion in

our web page, both in a Bulletin Board format and Interactive Chat Rooms.

All vendors and users welcome. No censorship.

-- , 8 Jan 1997


The Information Technology Association of America (ITAA) and the Software

Productivity Consortium (SPC) have announced a program for certifying the

competency of software and service vendors in dealing with year 2000

software problems. Companies that meet the certification criteria will be

listed in a public database on the World Wide Web at

-- Gary H. Anthes, "Trade groups roll out year 2000 seal of approval,"

Computerworld, October 7, 1996

I think that there is a bit of confusion about ITAA certification, so more

if you are looking for a software certification.

ITAA certification DOES NOT certify software. It is focused at Y2K service

providers and tries to assess "Y2K process" practices of that service

provider. Very similar to SEI-SMM (Software Maturity Model).

It is suppose to give you a feeling of security when you are outsourcing

your Y2K project, but it won't certify yours (or any commercial software

package) as Y2K compliant.

-- Miro Medek , Mitretek Systems, 26 Feb 1997


"The Economic Effects of the Year 2000 Problem on the United States," a

white paper by Capers Jones of Software Productivity Research, Inc., is

available as an Adobe Acrobat document (57 pages!) at

This is probably the most terrifying document I have ever read, and from an

unimpeachable source too. It is must reading for any executive.

-- Bill Daniels , Data Dimensions, Inc,

06 Oct 1996


6.4 What books and other published references are available on this



With over 30 titles listed, the book store is the one-stop

place to find the latest Year 2000 books. Many of the in-stock books in the book store are offered at 20-30% off through our association

with All books are available from with worldwide

shipping. Visit the book store at:


The Millennium Journal is a four-page newsletter published every two months


Data Dimensions, Inc.

777 108th Ave. NE - Suite 2070

Bellevue, WA 98004

Phone: 800 708-0675, 206 688-1000

Fax: 206 688-1099


An always interesting and well-written monthly newsletter on various 2000

subjects. Call them for a copy.


2000AD, Inc. produces a quarterly newsletter called Tick Tick Tick. The

cost is $75 a year. Their address is PO Box 020538, Brooklyn, NY

11202-0012, phone 1-800-643-TICK (8425), FAX 718-797-9410.


The U.S. General Accounting Office (GAO) has released an exposure draft of

its year 2000 assessment guide. The guide, entitled Year 2000 Computing

Crisis: An Assessment Guide (GAO/AIMD-10.1.14, February 1997), presents a

structured approach and a checklist to aid organizations in planning,

managing, and evaluating their year 2000 programs.

You may order by mail (the first copy is free):

U.S. General Accounting Office

P.O. Box 6015

Gaithersburg, MD 20884-6015

Orders may also be placed by calling (202) 512-6000 or by using fax number

(301) 258-4066, or TDD (301) 413-0006.

An electronic version of this guide is also available from GAO's World Wide

Web server at URL

-- Mike Dolak , 26 Feb 1997


6.5 What standards exist for computer representation of dates? Where can I

get copies of these standards? Are they available on the Internet?

"The nice thing about standards is that you have so many to choose from

. . ."

(Andrew S. Tanenbaum, "Computer Networks," Prentice-Hall, 1981, p. 168).

Both the American National Standards Institute (ANSI) and the International

Organization for Standardization (ISO) have standards for computer

representation of dates. Unfortunately, both standards allow a number of

different formats, including some formats that have only two digits for the


The ANSI standard is ANSI X3.30-1985 (R1991) "Representation for Calendar

Date and Ordinal Date for Information Interchange." The ISO standard is ISO

8601:1988 "Data elements and interchange formats -- Information interchange

-- Representation of dates and times."

The text of ANSI and ISO standards are not on the Internet. They are

copyrighted documents that you have to buy, and the prices are exorbitant.

Both ANSI and ISO have on-line catalogs that you can access and search on

the World Wide Web. You can get to the catalogs, and other information,

from each organization's home page:



You can order both ANSI and ISO standards from ANSI by calling 212 642-4900

between 8:45 a.m. and 4:45 p.m. Eastern time. They accept MasterCard, Visa,

and American Express. For more detail and other ways to order, see the

ordering information accessible from the ANSI home page. (The ordering

information seems to say that you have to have a deposit account with them

to order by phone, but they do accept credit card orders.) From the ISO

home page you can find out who sells ISO standards in other countries.

ANSI X3.30-1985 (R1991) "Representation for Calendar Date and Ordinal Date

for Information Interchange" is two pages and costs US$14 plus $4 handling.

ISO 8601:1988 "Data elements and interchange formats -- Information

interchange -- Representation of dates and times" is 14 pages and costs

US$48 plus $5 handling.

(Prices as of September 1995)


6.6 I have to assess how much of a problem we have with legacy assembler

code. Any ideas/products/vendors to facilitate the analysis?


There is no silver bullet solution to the year 2000 problem, especially for

low-level languages like Assembler. The best developers can hope for is to

automate the processes of code analysis to identify date problems, and

impact analysis on proposed changes. The objective is to enter testing with

as high a degree of confidence as possible that errors will not be present.

Year 2000 is the most timescaled project in IT history. Vendors must react

quickly to the demands of the industry, yet produce high quality tools.

Assembler and PL/1 are at the unfashionable end of the market for vendors,

yet they present the most complex legacy problems.


Software Migrations Limited and Durham Software Engineering are applying

the technology of their reverse engineering tool FermaT to the looming

problem of the year 2000.

FermaT is an easy to use formal methods tool for analysis, restructuring

and migration. It has been proved in industry, notably on migration of

Assembler to C and COBOL. The secret of FermaT is that it captures all the

functionality of the application, and reverse engineers it to a high level

specification, restructured code, or a new language. Retention of semantic

equivalence is guaranteed - black box test suites remain valid.

Functionality, including year 2000, can also be altered during

restructuring or migration.

FermaT 2000 is a version of FermaT tailored explicitly for year 2000

analysis. It tracks date variables through registers, scratch (and misused)

variables, and offsets into memory areas. It then identifies operations

carried out on, and using, dates. The output is an annotated and commented

listing of the source code in machine-readable form, and a set of metrics

giving a profile of the code and year 2000 problem incidence.

Initially FermaT 2000 will handle IBM Assembler and Jovial, to be followed

by other 'difficult' languages for which a demand is established - for

instance PL/1, FORTRAN, CORAL, and other assemblers. Because only a subset

of the full functionality of FermaT is required, it is possible for our

tool development team to react quickly to market demands.

FermaT 2000 is available as a tool or a service. It is the only high-

capability solution available to the owners of Assembler systems.

-- John Ashley , Durham Software Engineering Ltd,

Durham, United Kingdom DH1 3SW


Assembler (and other languages beside COBOL) are sticky issues for the year

2000. Most of the tools available assume COBOL and many of them assume IBM

environments. There are a few tools and services, however, that are

language independent and fewer that are platform independent, but you need

to hunt for them. I am continually surprised at the number of languages

concurrently in use in today's MIS shops.

Language independent tools (like the one that facilitates the Peritus Year

2000 Enhancement Program) have an architecture that permits multiple

languages to be processed, but a particular language or dialect may require

customization work by the vendor. Most vendors are willing to do this if

the business makes business sense. (For example, we have discussed doing an

Assembler front-end but have not yet had any serious interest from a client

to do so.)

With respect to the companies we are talking with, Assembler seems to be a

small percentage of their total code and they say they will do the

assembler portions by hand. I would be interested in the sets of languages

(programming, database, 4GL, etc.) that people use in their companies and

what percentage of the total code is in each language.

-- Ted Swoyer , Peritus Software Services, Inc.


6.7 I've discovered that I have compiled applications that I do not have

the source code for. How can I get the source code back in order to fix it?


The Source Recovery Company in Roswell, Georgia, USA, recovers lost COBOL

or Assembler source from IBM MVS, VM or VSE executable modules. We recover

back to the original language and guarantee functional equivalency to the

original executable.

-- Jim Rahm , The Source Recovery Company,



I realize that missing source code is symptomatic of slack management

procedures and not reserved to Y2K. We could also say that if every I/S

shop had adopted better date standards none of this would be necessary. But

we didn't, so how are we going to deal with it?

Chris Gardner of ViaSoft may have summed it up best however when he

referred to the *problem* as trying to turn a sausage back into a pig! You

can try but what comes out isn't pretty!

-- Mike Turgeon 


The applications programmers around here always think they have lost source

code, because they forget that systems support takes backups. Did you

remember to check your oldest backup tapes for that source data? Otherwise,

I'm afraid to say that disassembling your programs is your only hope ... or

you can rewrite them.


6.8 Is there a Year 2000 user group near me?

A list of Year 2000 user groups can be accessed from the Year 2000

Information Center home page at Select the "Year

2000 User Groups" link.


There is a list of Y2K user groups at

-- William H. Goodwin <>, 12 Nov 1996



7.1 Contributors

Two people must be given special thanks. First and foremost is John Moffitt

, who performed the enormous task of putting

together the original version of this FAQ.

The second is Peter de Jager , who started the Year

2000 mailing list from which this FAQ grew, and who created and maintains

the Year 2000 Information Center on the World Wide Web, from which this FAQ

is distributed.

Others who have contributed are listed in alphabetical order.

David Alcock 

Michael J. Averbuch 

Tony Baker <>

George W. Ball 

Brian Bechtel 

Tom Becker 

Gary Blythe 

Serge Bouwens 

Donald Brown 

William Burrow 

Harold Carruthers 

John Carter 

Brian Christenson 

Adrian Clark

Pierre Cloutier

Robert P. Coble 

Duncan G. Connall 

Nancy Copes <>

Bill Daniels 

Floyd L. Davidson 

Donald G. Davis 

Antoinette de Jager 

Sander de Jong 

Chuck Dennison <>

Mike Dolak 

Mike Drabicky 

David Eddy 

Andrew Eldridge 

Peter Eldridge-Smith 

Don Estes 

Sid Faber 

Karl W. Feilder 

Robert Franchi 

John Franciscovich 

R. Gama 

Roger Gates 

Peter Genadry 

Michael Gerner 

Bear Giles 

George Girod 

Sherry L. Goncharsky 

Craig Goodrich 

William H. Goodwin <>

Hans Goossens 

Joe Gwinn 

Dave Hall 

Reg Harbeck 

Francis J. Hensler 

Karen D. Herbert 

John L. Horton 

Ron Hunter-Duvar 

Pam Hystad

Lanny Jones 

Leon A. Kappelman, Ph.D. 

Dave King 

David Kipping 

Cliff Kurtzman 

Romy Leibler 

Robert Lieb 

Gene Lynd 

Jacqui Macdougal 

Francis D. MacLellan

Geoff May 

Bob McClenon 

Brenda McKelvey 

Pat McKeown 

Daniel A. McLaughlin 

Miro Medek 

Didier Morandi 

Derek Morgan 

Dick Murray 

David A, Negrey 

Robert Neuschul <>

Richard Newbold 

Patrick O'Beirne 

Alf Ohlsson 

Mike Olsem 

Bill Parkinson 

Sherry Pauly 

Gihan Perera 

Raghavendra Rao 

Phil Randal 

Ed Ravin 

John Reda 

Dave Rybarczyk 

Rob Schneider 

Pris Sears 

Stan Sieler 

David Silver 

David A. Smith 

Gary L. Smith 

Harlan Smith <>

Ivan C. Smith 

Jens Peter Soltoft 

Peter Somers

Tom Ster 

Jonathan Swinton 

Ted Swoyer 

Marty Tabnik 

Ralph G. Taylor 

Randall Thomas <>

James Tinsley 

Rick Toker 

Larry Towner 

Arnold Trembley 

Mike Turgeon 

Diana van Dyk 

Allan E. Van Ness 

Steve Vogel 

Anne Voigt 

Joe Warren 

Dale W. Way 

Jerry Whittle 

Bob Wier 

Frank L. Yaeger 

Michael Yastreboff 

B. Young 

Ruth Younie 

Harold P Zbiegien 

Mike Zbierski 




7.2 Copyright and Permission

Copyright 1995, 1996, 1997, 1998 Robert J. Sandler. All rights reserved.

Contains material copyright by others.

Permission is granted to copy and distribute this document by any means,

provided that it is copied in its entirety, including this notice and the

disclaimer below, and that no fee is charged other than the actual cost of

transmission or reproduction or the standard connection-time charges on a

BBS, on-line service, or Internet connection. It may not be distributed for

financial gain or included in a commercial collection or compilation

without prior permission from the copyright owner.

Most company names and product names mentioned in this document are

trademarks or registered trademarks of the respective companies.

7.3 Disclaimer

While the information contained in this document is believed to be

accurate, Robert J. Sandler, Peter de Jager, de Jager & Company Limited,

The Tenagra Corporation, and the contributors do not guarantee the

accuracy, adequacy, or completeness of the information, and assume no

responsibility for errors or omissions, nor any liability for damages

resulting from the use of this information. The views and opinions

expressed in this document do not necessarily reflect the position of the

maintainer. Affiliations are given for identification purposes only.


End of the Year 2000 FAQ


Robert J. Sandler