Date: 27 Feb 96 21:17:26 EST
From: "Robert J. Sandler" <70023.2572@compuserve.com> To: Peter de Jager
<pdejager@hookup.net> Subject: *** FAQ Ver. 2.1 Revised ***

THE YEAR 2000 FAQ

Version 2.1 - February 29, 1996


FREQUENTLY ASKED QUESTIONS ABOUT THE YEAR 2000 COMPUTER CRISIS


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

Maintained and edited by Robert J. Sandler <70023.2572@compuserve.com>.
Originally created by John Moffitt.
See question 7.1 for a list of contributors.

---------------------------------------------------------------------------

Copyright 1995, 1996 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.


Disclaimer

While the information contained in this document is believed to be
accurate, Robert J. Sandler, Peter de Jager, de Jager & Co., 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.


---------------------------------------------------------------------------
PREFACE -- A Few Quotations to Set the Mood
---------------------------------------------------------------------------


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

-- Kevin Schick, The Gartner Group


"Computer Clock Watchers Anxiously Await the Millennium.

Pessimists warn that on Jan. 1, 2000, thousands of computers may grind to a
halt. Why? To save space when recording dates, many computer programs allow
only two digits for years: as in '93'. Computers using such dates to
determine a person's age or a past-due bill, for instance, may be stymied
by the '00' in 2000.

Larry Bacon, who oversees computers for Travelers Insurance, says 2000 may
mark trouble for many firms with vast records based on the two-digit
system. 'If you just ignore it and go home on Dec. 31, 1999, you could wake
up with some real problems', says Mr. Bacon."

-- Pamela Sebastian, The Wall Street Journal, March 4, 1993


"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


"In a panel discussion, Infoworld columnist Cheryl Currid predicted that
all mainframes will blow up on Dec. 31, 1999, when their clocks cannot
figure out how to make the change to the year 2000."

-- Stewart Alsop, Infoworld, Feb. 22, 1993


"For years, COBOL programmers have been writing programs which calculate
dates for various business operations such as the age of consumer debt, the
annuity on an investment, the monthly paymentson a mortgage, the exact
'nnn' days (weeks, months, years) from now and so on. For just as many
years, programmers have known that time bombs have been planted in these
business applications because in the year 2000, the final year of the
current millennium, numerous programs will incorrectly calculate these date
operations."

-- Jerome Garfunkel, Enterprise Systems Journal, Oct. 1991


"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


"But now we have a unique technological disaster, that can be predicted
very precisely, far ahead of the occurrence. The date on which the disaster
will occur is known, and the time of day is also known. It will sweep all
around the world, one time zone at a time. The nature of the disaster is
known, and has been described precisely by several qualified and credible
people, including Peter de Jager (who published a detailed description of
the impending disaster more that six years in advance). The location of the
disaster is known, and we know who will be affected.

Yet the world continues to ignore it.

It cannot possibly be postponed, and it will certainly be a major upheaval
in many (all?) large organizations worldwide, including thousands of
governments at the national, provincial/state, and municipal levels.

Yet the world continues to ignore it.

It is not really a complicated concept. It can be understood clearly by any
12-year-old who turns his mind to it, and no doubt there are tens of
thousands of 12-year-olds who know all about it and could give a clear
description of the impending disaster to any adult who would listen.

Yet the world continues to ignore it.

So, I subscribe to the Year 2000 mailing list, to keep abreast of current
developments, and to collect ideas on how to awaken the various government
departments."

-- Ivan C. Smith, retired physics teacher


---------------------------------------------------------------------------
CONTENTS
---------------------------------------------------------------------------

1. DEFINING THE PROBLEM

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, 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)?


2. PROBLEMS WITH SPECIFIC HARDWARE AND SOFTWARE

2.1 What is the DOS BIOS problem?
(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 Are there some Y2K problems with UNIX and/or C/C++?

2.3 Is there a special year-2000 problem with VMS?


3. SOCIAL AND HISTORICAL ASPECTS

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
hardware?


4. CALENDARS AND DATE REPRESENTATION

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. FIXING THE PROBLEM

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 some important programming future dates for DOS system
designers besides 1999 and 2000?

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 2000?

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?


6. RESOURCES AND TOOLS

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, news groups, archives and other Y2K references are
available on the Internet? Are there any other published references on this
problem?

6.4 I have to assess how much of a problem we have with legacy assembler
code. Any ideas/products/vendors to facilitate the analysis?

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'm near the beginning of my Y2K effort and 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?


7. APPENDIX

7.1 Contributors

7.2 Copyright and Permission

7.3 Disclaimer

===========================================================================

1. DEFINING THE PROBLEM


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 <dconnall@tiac.net>, Global Software, Inc.


---------------------------------------------------------------------------

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
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 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 <gr266@satyam.jvnc.net>, Satyam Computer Services Limited

***

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, http://arganet.tenagra.com/

***

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 <JoeWar110@aol.com>, 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 <pdejager@hookup.net> (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.

---------------------------------------------------------------------------

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 <deddy@tiac.net>, 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 <deddy@tiac.net>, 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
format.

-- 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?

-- JoeWar110@aol.com, Fri, 16 Jun 1995

***

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
keys.

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 culturallycorrect
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
solution.

-- Sherry L. Goncharsky <sherryg@vnet.ibm.com>, 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 ISPFedit 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.

007300 01 EFFECTIVE-DATE-YEAR4.
007400 05 EFFECTIVE-DATE-CC PIC 99.
007500 05 EFFECTIVE-DATE-YEAR2.
007600 10 EFFECTIVE-DATE-YY PIC 99.
007600 10 FILLER PIC 999.

017200 MOVE EFFECTIVE-DATE TO EFFECTIVE-DATE-YEAR2. 017300 IF
EFFECTIVE-DATE-YY IS GREATER THAN MD2-ENDPOINT 017400 MOVE MD2
-BACKWARD-CENTURY TO EFFECTIVE-DATE-CC 017500 ELSE
017600 MOVE MD2-FORWARD-CENTURY TO EFFECTIVE-DATE-CC.

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 sometimes considered a
show-stopper for this approach. Even today the problem can be overcome with
sort exits. However, sort products currently support data types and
alternate collating sequences. Why can't they recognize DATE types or
sequences -- a choice, each providing a different windowing scheme? I have
talked to two vendors about this, and one said his company would have
something later this year. It would be great to have something which could
be put in place and tested today, without programming. COBOL sorts might
not be accommodated, but these can deal with the problem in the INPUT
PROCEDURE if necessary. If anyone agrees, contact your sort vendor.

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 <nff0075@dsac.dla.mil>, 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 <BChristenson@Wright.Edu>

---------------------------------------------------------------------------

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

***

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!) -
Applications - SIGNIFICANT CONCERNS

-- 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
COBOL II 1.4
RACF 1.9.2
SDSF 1.3.3
DFP/ESA 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 year.

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
back!)

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.

***

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 <nff0075@dsac.dla.mil>, 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 or send them directly to
me via e-mail and I will answer them as best, and as quickly as I can.

-- John Franciscovich <jfrancis@vnet.ibm.com>, VM Development, IBM
Corporation (Endicott, NY)

***

A list of Personal Computers which fail the following test:

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 December 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.

Caution: some software with date checking (for example Windows 95 betas)
may reset and not allow access after setting dates into the future.

Why is this important?

If your PC's date shows 1980 when it should say 2000, what damage will it
do to you date dependent systems?


The GOOD - Passes

GA-586AT with Award Bios at 100 MHz
DEC Venturis 4100 (486DX-100)
Gateway 2000 P5-90
Macintosh PowerBook (model unknown)


The BAD - Failures

AST Advantage Adventure 8090p, AST BIOS R1.02 GA-486US, 33MHz
Micro-Pro 8200 (AWARD MODULAR BIOS Version 3.20-00NM) - fails RTC Rollover
Test, passes RTC 2000 Set Test
Midwest Micro Intel 486
COMPAQ: Proliant 4100, Prosignia 300 5/75, DeskPro 575 DELL 466SE, Phoenix
80486 ROM BIOS Plus version 1.00 A09 Gateway 2000:
- 486DX2/50, Phoenix 480486 ROM BIOS PLUS Version 0.10 GJX30-05E -
4DX2-66V, Phoenix 80486 ROM BIOS PLUS Version 0.10 GJX30-05E Hewlett
Packard Vectra M2 486/66
IBM Cobalt Blue Lightning motherboard, 486 ISA/VESA, BIOS MR 1993, Version
V1.53-OPTI481 - fails RTC Rollover Test, passes RTC 2000 Set Test. TMC
Research Corporation PAT48PR, AMI BIOS


Compiled by Geoff May <geoffmay@enternet.com.au> of Network Business
Services. Last update 01 November, 1995

Help with this project. Send your reports of computers that either pass or
fail this test to Geoff May <geoffmay@ibm.net>. Tell Geoff the PC's brand
and model and the BIOS brand and version. The information needed will
appear during boot-up (if you can read quickly) or can be found using tools
such as Norton's (Symantec's) SysInfo, Microsoft's MSD or similar
diagnostic product.

Disclaimer: While every effort has been made to ensure the correctness of
this list its accuracy cannot be guaranteed. The author(s), contributor(s),
and publishers advise all people to check their own machines and contact
their own vendors or suppliers.

***

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
found:

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 <mikeaver@prairienet.org>


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).

C:\WIN>ver

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
C:\WIN>
Fri 12-31-1999 23:59:54.72
C:\WIN>
Fri 12-31-1999 23:59:58.07
C:\WIN>
Sat 01-01-2000 0:00:01.64
C:\WIN>
Sat 01-01-2000 0:00:04.77

-- Mike Drabicky <drabicky@network-1.com>

***

For the following IBM platform: MVS/ESA 4.3:

In MVS the expiration date is a flag which simply denotes the file
ordataset'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/DD 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.

***

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 <David_Silver_at_Human__Resources@ccmail-metro.pwcm.com>

***

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.

-- THHACKETT@vaxsar.vassar.edu

***

I am aware that Consilium has recently released a version of their
COBOL-based product which is now Y2K-compliant. I am also aware that
SETPOINT's SETCIM product handles times correctly.

-- Allan E. Van Ness <vanness@pccvax.dnet.dupont.com>

***

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
off-by-one.

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
years.

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
obvious.

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 <bear@fsl.noaa.gov>

---------------------------------------------------------------------------

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 <JLHorton%utl13n%cob%wpgate@yvax.byu.edu>

***

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 (BCHRIS@bast.wright.edu) 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 <serge@cistron.nl> 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
used...

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 <GILES@globsoft.com>, 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
stage.

-- B09VYF5@bafco.bell-atl.com

---------------------------------------------------------------------------

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 oldrecords, you might need to deal with significantly different
calendar structures.

-- Bear Giles <bear@fsl.noaa.gov>

***

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 <76646.333@compuserve.com>

===========================================================================

2. PROBLEMS WITH SPECIFIC HARDWARE AND SOFTWARE


2.1 What is the DOS BIOS problem?
(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
future.

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

***

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

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 <Support@RighTime.Com>, Air System Technologies Inc

***

As previously determined, if you set the date to 12-31-99 and the time to
23:59:30 and let the clock tick, the date becomes 01-04-80. Any files
created from this point forward, have their creation date equal to
01-04-80.

If you set the date to 01-01-2000, the date is displayed as 01-01-2000;
however, any files created at this time, have their creation date equal to
01-01-00. The Intel based PC's do have the capability of supporting dates
in the year 2000 and beyond. The date just needs to be correctly entered on
January 1, 2000.

***

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 <TAYLORRG@ofc004a.sce.com>

***

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 <PMCKEOWN@cbacc.cba.uga.edu>

***

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 <J.Goossens@inter.nl.net>

***

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
that.

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)

---------------------------------------------------------------------------

2.2 Are there some Y2K problems with UNIX and/or C/C++?

***

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
yourself.

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 <bear@fsl.noaa.gov>

***

A potentially very serious problem in the use of the UNIX
seconds-since-01-01-1970 ("time_t"):

Unix maintains the "time_t" date as a signed 32-bit integer containing the
number of seconds since midnight, 01-01-1970 GMT. Strictly speaking, you
are not supposed to do arithmetic on "time_t" objects, but that rule is
often ignored.

19 Jan 2019 03:14:08 GMT: rollover

By my calculations, the largest positive value in a signed 32 bit integer
is 2^31-1 = 2147483647 seconds, or a little over 68 years. The base year
1970 + 68 is 2038, not 2019.

(2147483647 s) / (60 s/m * 60 m/h * 24 h/d * 365.25 d/y) = 68.04965038533
years, approximately ;-)

I know, I know, 365.25 is not exactly correct, depending on how many leap
years versus non-leap years are spanned by the interval in question. That's
why we need to have standardized date routines to do all these
calculations.

Note that negative times _are_ allowed. The man page for ctime(3) in HP-UX
version 9.0 states that a time value of -1 is Dec 31, 1969 23:59:59!

The date(1) command on HP-UX only accepts 2 digit years to change the
system clock.

I would rank this 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.

There will undoubtably be proposals to extend this type to 64-bits well
before 2019, but we're taking about a heavily installed base in telephone
switches, satellite controllers, etc.

-- Bear Giles <bear@fsl.noaa.gov> and Roger Gates <gatesro@aol.com>

***

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 <bear@fsl.noaa.gov>

***

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 <bear@fsl.noaa.gov>

---------------------------------------------------------------------------

2.3 Is there a special year-2000 problem with VMS?

***

I have just spoken to Digital Equipment in Atlanta regarding VMS. They said
that VMS is YEAR 2000 Compliant.

-- Dick Murray <dmurray@map.com>

***

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 <vanness@pccvax.dnet.dupont.com>

***

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

-- Steve Vogel <steven.c.vogel@naperville.nalco.infonet.com>

***

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 <bear@fsl.noaa.gov>

===========================================================================

3. SOCIAL AND HISTORICAL ASPECTS


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.

***

"In 1992 Mary Bandar of Winona, Minn was invited to join kindergarten class
because she was born in '88 ... in fact she was 104 years old!"

-- Brian Hayes in The RISKS Forum


"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 <rhd@FormalSys.CA>


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
backward.

I'd probably start taking short positions in late 1998 though <g>.

-- Joe Warren <JoeWar110@aol.com>, 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.

-- Micamber@aol.com

***

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
calculations.

As a lay-person article I found it not too bad, although it certainly just
skimmed the surface of the problem.

-- Rob Schneider <rschneider@pwss.gov.ab.ca>

***

We are a large Supermarket company in England. We are now considering the
ADDED problem of the fact that we will have utterly bare shelves on 4th Jan
2000 because of the BIGGEST PARTY ... Our ordering system might go haywire
and order 99 years' worth of supplies. Compound this with the possibility
that our suppliers' computers will be down ...

We now think we might have to consider implementing a manual system to run
in parallel with any fixes we make so that we can interface with those
"less fortunates" who have not managed to weather the storm. And then there
is the procedure for interfacing our manual system with our automated
system etc ...

We think we now have enough to make our CEO sit up and listen!

-- Diana van Dyk <Diana.VanDyk@js.btx400.co.uk>, Year 2000 co-ordinator

***

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 action!

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 <ca26@dial.pipex.com>

***

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
food?

Pris Sears <sears@vt.edu>


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 <romy@ddddf.com>


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 <jwhittle@amclg.safb.af.mil>

---------------------------------------------------------------------------

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 <us9lbclb@ibmmail.com>

***

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 <wier@bobcat.etsu.edu>

***

>From the Forum on Risks to the Public in Computers and Related Systems, 20
November 1989, Vol. 9, Issue 45, Peter G. Neumann, moderator

Date: Fri, 17 Nov 89 9:17:33 BST
From: Brian Randell <Brian.Randell@newcastle.ac.uk> 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
March1900. 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!

***

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 <drybar@czn.com>

***

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, an
d 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
change.

Japanese business tends to be more composed concerning the year 2000
change, nevertheless there may well be problems there too.

-- Duncan G Connall <dconnall@tiac.net>

---------------------------------------------------------------------------

3.3 Anyone got any idea what possible Y2K implications are known with
reference to nuclear missiles and other military, software-controlled
hardware?

***

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).

===========================================================================

4. CALENDARS AND DATE REPRESENTATION


4.1 Is 2000 a leap year?

Yes.

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.

***

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. 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 suggested 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." February will have 30
days and the year will be 367 days long.

Fact: There is no such thing as a double leap year. It will be a leap year
like any other leap year, with 29 days in February, and 366 days in the
year.

---------------------------------------------------------------------------

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" (In the gravest concern) issued by Pope Gregory XIII in
1582.

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.

---------------------------------------------------------------------------

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.


However,

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 <jmoffitt@moffitt.aws.waii.com>

***

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. . . ."

***

Millenia

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.

Celebrations

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 http://www.ast.cam.ac.uk/RGO/leaflets/2000/2000.html

---------------------------------------------------------------------------

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
interchangeably.

That's also very appropriate for the year "twenty-oh-oh". :-)

-- Bear Giles <bear@fsl.noaa.gov>

***

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 <Notimetolz@aol.com>

---------------------------------------------------------------------------

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.

---------------------------------------------------------------------------

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,
1900.

===========================================================================

5. FIXING THE PROBLEM


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 each:

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 <tswoyer@peritus.com>
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 <deddy@tiac.net>, 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 overhead.

The upside is overwhelming. the date is Correct ... and MORE to the point
... the instructions to programmers are easy ... ALL YEARS ARE IN THE
FORMAT DDDD

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
necessary.

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
are.

- 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 <serge@cistron.nl>

***

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
nothave 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 <CF1.FIRNEWBO@TS3.teale.ca.gov>

***

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 <deddy@tiac.net>, 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 tho
ughts 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 <tom.ster@dns.midata.com> 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:

IF DATE1-YY < DATE2-YY THEN ...

or

SUBTRACT 1 FROM DATE1-YY

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 MMMYY 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
ghost.

-- Andrew Eldridge <ACEldridge@aol.com> 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
face.)


ITEM FOR DISCUSSION:

WHAT ARE THE ARGUMENTS FOR CONVERTING DATA VS CONVERTING APPLICATIONS.

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
environments.

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 (&
linkedit).

f. Client-written ad hoc reports would not need century-determination routines.

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 underlyi
ng 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 reasons:
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 dd.mm.yy 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 <Bchristenson@Wright.Edu> 13 Jun 1995

---------------------------------------------------------------------------

5.3 What strategies are being considered for solving the following year
2000 problems: break point? - field expansion? - hex code?

***

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 <rtoker@best.com>

---------------------------------------------------------------------------

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
routines!

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, parameterrequirements 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 <g>). 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 <JoeWar110@aol.com>, 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!

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.

-- Robert J. Sandler <70023.2572@compuserve.com>

***

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 <mckelveybj@em.agr.ca> from a report on the "Year 2000:
Blueprint for Success" conference in Orlando, Florida, November 1995

---------------------------------------------------------------------------

5.6 What are some important programming future dates for DOS system
designers besides 1999 and 2000?

***

I'm doing these calculations quickly so I may be off by one.

1. DOS "days-since-1900"

Many DOS programs maintain the date as days-since-01-01-1900. This requires
an _unsigned_ 16-bit integer. (There were a few variants of this method,
e.g., to have "0" fall on a Sunday to simplify day-of-week calculations.)

signed vs unsigned:

19 Sep 1989: programmers who failed to specify "unsigned" 16-bit integers
had their dates suddenly change to early in the 19th Century.

07 Jun 2079: 16-bit counters will roll over

2. DOS file system times

DOS has historically maintained the date in a packed integer field. It
allocated 7 bits to the year field, starting in 1980.

01 Jan 2044: poorly written code may have problems with date, if bit
extraction is done improperly.

01 Jan 2108: rollover

BTW, many DOS/Windows proponents will gleefully point out how this range is
among the best of those currently in wide use. In response, point out that
the _accuracy_ of the time is only good +/- 2 seconds. Most other operating
systems have +/- 1 second resolution.

-- Bear Giles <bear@fsl.noaa.gov>

---------------------------------------------------------------------------

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
2000?

***

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
case.

* 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 <cms1@cornell.edu> 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 willstill 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 <BROWND@afc4a.safb.af.mil>

***

on Mike Scullin's <cms1@cornell.edu> 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
drift.

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.

-- Micamber@aol.com

***

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 <serge@cistron.nl>

---------------------------------------------------------------------------

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.

WHAT IS A BRIDGE PROGRAM?

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 <marty.tabnik@greatesc.com> 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.

WHY USE A BRIDGE PROGRAM?

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 re-write.

ARE BRIDGE PROGRAMS PERMANENT?

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.

Micamber@aol.com - discussion of bridge programs inspired by postings from
others, such as ...

bill_parkinson@Merck.Com (Bill Parkinson), rhd@FormalSys.CA (Ron Hunter-Duvar),
nff0075@dsac.dla.mil (Gene Lynd),
dale_vecchio@viasoft.com (Dale Vecchio), serge@cistron.nl (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

MOVE 19 TO CENTURY

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 <jps@dc.dk>

***

I agree with Micamber@aol.com'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
tape.

-- 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 <marty.tabnik@greatesc.com>

***

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
thing.

-- Francis J. Hensler, CDP <FJH@SRUVM.SRU.EDU>

---------------------------------------------------------------------------

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
etc).

- 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-wide).

- Cooperative processing (think network-wide, world-wide).

- A profit center with a large network can go broke when off-line for a few
days.

- 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 <J.Goossens@inter.nl.net>

---------------------------------------------------------------------------

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 <deddy@tiac.net>, 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

===========================================================================

6. RESOURCES AND TOOLS


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
Magazine).

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 <romy@ddddf.com>, Can Do Systems, Inc.

***Here is a list of companies that offer tools and consulting services.
Some of the product descriptions were written by the vendors themselves, or
were excerpted from the vendors' promotional material by the FAQ
maintainer. Others were provided by contributors to the Year2000 mailing
list. Neither the FAQ maintainer and editor, nor any of the contributors,
endorse or represent any vendor, or guarantee the correctness of this
information. Contact the vendors for more detailed information.


ADPAC Corporation
415 777-5400, Cynthia Nisbet
e-mail: adpaccorp@aol.com
Product: SystemVision YEAR 2000, a mainframe based Y2K tool.

SystemVision is an integrated toolset of different applications that offer
comprehensive information and analysis for maintaining, enhancing and
re-engineering legacy systems. Based on the proven PM/SS parser technology,
SystemVision applications provide organizations with packaged solutions for
issues found throughout Information Systems departments. SystemVision YEAR
2000 is the first SystemVision product, and it provides a complete solution
for analyzing, planning and implementing the date conversions which are
necessary for Y2K calculations, simplifying the conversion process by
identifying and locating all date occurrences on a system-wide basis. It
produces detailed "What-If" studies to make the changes, and then guides
the programmers through the code step-by-step for insertion of ISPF edit
macros to make the necessary changes.

ADPAC is an independent software company (since 1964). In the 1970s, ADPAC
focused its technical expertise on providing consulting services and
developing productivity application tools. In the 1980s these tools were
made commercially available, including PM/SS which provides the user with a
powerful system-wide source code parser and analysis toolset with command
driven capabilities for maintaining, re-engineering and redeveloping entire
COBOL, PL/1 and Assembler applications and their JCL. It reverse engineers
a systems' structure and data relationships, providing systems engineers
with the understanding necessary to maintain the software. ADPAC's products
run on all MVS environments using COBOL, PL/1, Assembler, JCL, SQL, DB2,
IMS, IDMS, CICS, IDD and other inputs.


Air System Technologies Inc
(500) 448-9660
e-mail: Support@RighTime.Com

Our clock correcting program, RighTime (now four years old at version
4.64), corrects the CMOS RTC Y2K problem if it is resident and running on
the machine before the 1999-2000 change. It currently supports DOS and all
Windows except NT. A new release is due in a few weeks. (Oct. 23, 1995)


Alydaar Software Corporation
504 845-3322, Robert Gruder
e-mail: alydaar@neosoft.com
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.
Product: SmartCode

Complete solutions to year 2000 software problems. Alydaar's solutions
include impact analysis, thorough and comprehensive detection,
reengineering and correction of code, testing, and delivery. SmartCode,
Alydaar's artificial intelligence reengineering system, can examine and
understand your entire software system, identify inherited date-sensitive
characteristics, evaluate date-solution opportunities and difficulties, and
reengineer your software to incorporate your choices for year 2000
corrections ... synthetically. SmartCode also adapts to your software
design and programming standards, understands any computer language, and
permits you to continue maintaining and developing your software throughout
the detection and analysis portions of the project. Founded in 1982,
Alydaar has a proven record of successes using SmartCode to reengineer
large, complex software systems. The solution to your year 2000 and other
reengineering problems is assured because Alydaar has combined its unique
and powerful technologies with the services of proven software consulting
and auditing firms, such as KMPG Peat Marwick, with thousands of experts
and customer support staff in hundreds of locations around the world.


AMS (Automated Migration Services)
919 380-7877, Sandra R. Gareton
e-mail: srgare@ix.netcom.com

AMS is a services company that specializes in conversion. We have software
for year 2000 impact analysis that also provides inventory lists and cross
references. This software is PC-based, and you can elect to run it
yourselves (1 person familiar with PCs and your applications) or have
assistance from us.


ASPG Inc.
800 662-6090, 813 649-1548, Lisa Hamilton e-mail: 75541.2467@compuserve.com

DATE/2000 is an MVS product which assists users in testing/preparing
applications (TSO/ISPF, CICS, DB2, IMS etc...) for the year 2000.


Cap Gemini America
212 944-6464 ext. 232
Product: TransMillennium Services

Our end-to-end methodology is supported by our integrated toolset, from
assessment and strategy through renovation, validation, and implementation.
Our artificial-intelligence-based ARCdrive toolset brings a high level of
automated renovation to every affected application component, including
programs, JCL, sort control cards, file conversions, bridging and test
data. To provide a faster, better, cheaper year 2000 solution, we built the
highly specialized Application Renovation Center (ARC), and engineered
productivity environment, which leaves your ongoing mainframe operation
safely undisturbed. Staffed by dedicated teams, supported by AI-based
tools, the ARC allows the specialized focus and expert knowledge-sharing
important to successful renovation. ISO9001-certified quality system.


CBSI (Complete Business Solutions, Inc.) 810 488-2088

CBSI is a large U.S.-based systems development firm with proven experience
in facilitating the modification of legacy applications to handle
turn-of-the- century date processing efficiently. CBSI has over 1,000
consultants in project sites and offices around the world. These
consultants are experts in performing large conversion projects. CBSI
maintains cost-effectiveness and quality control through both off-shore and
off-site conversion options.


Chicago Interface Group, Inc.
312 348-8138
e-mail: 73511.3263@compuserve.com

Our company specializes in Impact Analysis, and Configuration Management
products, interfacing with the current change manage products such as
ENDEVOR, Panvalet, and Librarian, etc. We have two commercial product
offerings available. One focusing completely on Year2000 analysis and
verification. We also offer analysis and consulting services in the area of
Year2000 projects and general configuration management. We provide
expertise, products, and 'total view' methodogy that will handle this issue
from the analysis phase through the execution, verification and project
management.


CL Systems
513 369-5864, Mike Smith
Product: VANTAGE YR2000, a converter product


Computer Associates
516 342-2391, Bob Gordon
e-mail: info@cai.com
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.
Product: CA Discovery 2000 Solution

CA Discovery 2000 Solution is a unique combination of software and services
to help reduce the costs and resources associated with Year 2000
processing. CA Discovery 2000 includes technology and services that provide
a total Year 2000 solution.

CA-Impact/2000 is a new multi-platform tool that analyzes applications and
details the information needed to estimate and plan the Year 2000
initiative. It is a powerful impact analysis tool that helps organizations
determine the impact and cost of converting applications for the Year 2000.
CA-Impact/2000 analyzes all of an organization's COBOL and CA-Easytrieve
programs and generates detailed reports that identify the affected business
applications. It executes on both mainframe and desktop platforms.

CA Discovery 2000 Services provide extensive assistance in the Year 2000
initiative, including impact assessments, project planning, education, and
conversion techniques. They provide organizations with a phased approach to
their conversion plan, enabling projects to be more manageable, productive
and cost-effective. Fee-based customized services--from impact assessment
through re-integration of production systems--also are available.

Visit CA on the World Wide Web at http://www.cai.com.


Computer Horizons Corp.
800 321-2421, David Reingold
e-mail: dreingold@msn.com
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.

Signature 2000 is a combination of a proprietary software toolkit and CHC's
proven project management expertise and methodology. It comprises five
major phases: Discovery, Analysis, Construction, Testing and
Implementation.

The software toolkit features a Signature Analyzer, which identifies all
date occurrences within a company's inventory of applications, and a
Signature Replacer, which reformats appropriate data fields, updating the
application code.

The Signature Analyzer provides a number of standard and customizable
reports of all date references and stores them in an SQL-base repository.
The repository is used by CHC analysts, working with a company's technical
and information systems departments, to prepare an individualized approach
for updating the applications.

The Signature Replacer, using the repository, provides a flexible approach
to automating the implementation, using the data in the repository and the
rules stored there during the analysis phase.

The toolkit, which runs in both mainframe and PC environments, is currently
available for COBOL, PL/1, Assembler, SQL, DB2, IDMS, IMS and CICS.

Computer Horizons Corp., founded in 1969, is a diversified information
technology services company specializing in system design, management and
maintenance, client/server migration and network management. It employs
2,200 in its network of 33 offices throughout the United States.


Computer Reserves Inc. (CRI)
800 882-0988, 201 263-9800, Bud Conner
Product: Year 2000 conversion services

We have developed products and offer services that will dramatically reduce
the cost and scope of your year 2000 project. By utilizing automated tools
we are able to reduce the amount of code that needs to be reviewed and
converted. Also, this is a labor-intensive project that does not lend
itself to an internal solution. We have access to a large supply of
competent COBOL programmers as well as highly qualified project leaders to
manage these resources.


Computer Software Corporation
800 908-2000, 216 333-4420, Dan Shaughnessy Product: DateServer 2000 -
calendar routines that use windowing to process two-digit years, for MVS or
VSE on IBM-compatible mainframes. Also consulting services. Expertise
especially in banking systems.


Compuware Corp.
800 358-3048, 810 737-7300
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.

Product: XPEDITER/Xchange inventories programs requesting date or time from
the mainframe, then simulates date or time during testing.

Compuware Corporation, headquartered in Farmington Hills, Michigan, U.S.A,
is a global leader in software products for building, testing and deploying
business applications and related professional services. Our customers are
among the world's 15,000 largest commercial users of information
technology.


Data Dimensions
800 708-0675, 206 688-1000, Larry Martin e-mail: 76311.1542@compuserve.com
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.
Product: Year 2000 consulting and professional services.

Data Dimensions furnishes a full range of year 2000 services to domestic
and international owners of all computing platforms. Employing their own
analysis facilities and Template 2000 (Copyright) methodology plus the
latest tools, they achieve a thorough risk assessment of a given
application or the management of an enterprise-wide update.

Data Dimensions publishes The Millennium Journal, an always interesting and
well-written monthly newsletter on various 2000 subjects. Call them at one
of the numbers above for a copy.


Durham Systems Management Ltd (UK)
+44 (0) 191-492-0429, David S. Walton
e-mail: Dave.Walton@durham.octacon.co.uk

They've been interested in software maintenance issues since 1987, and
offer a number of consultancy and training services. They regard Y2K as the
archetypal software maintenance problem with the added ingredient of a
project completion date, and eagerly await the fact that Y2K will
eventually result in the recognition of maintenance as the highest priority
activity in the management of a software portfolio.


Edge Information Group
513 948-8906, Carl Gehr
e-mail: 73424.543@compuserve.com
Products: Edge Portfolio Analyzer, Bridge to the Next Century, consulting,
as well as migration assessment and a migration planning class. Bridge to
the Next Century simulates COBOL 85's date-related intrinsic functions for
shops not yet on compilers which support them.


Ernst & Young RE Products bv
+31-30-2588345
e-mail: eyrep@mc.mey.nl
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.
Product: Cleopatra

With Cleopatra, Ernst & Young RE Products bv offers a unique service for
programming language conversion. Cleopatra converts PL/I programs into
COBOL II fully automated. It is a proven solution for fast and reliable
conversion of PL/I programs to an open environment.

During the Year 2000 inventory effort, many IS organizations that primarily
utilize COBOL will discover that they have a few "orphan" PL/I applications
that are still operating. These organizations may discover that: -
insufficient PL/I skills are available to support the century date
correction effort;
- few tools are available to support PL/I analysis and change activities; -
they do not want to invest additional capital into applications written in
a "dead-end" language.

PL/I to COBOL conversion offers these organizations a way to add value to
their century date conversion projects by eliminating their orphan PL/I
applications. This approach offers these organizations numerous benefits:

- PL/I coding skills are no longer required; - costs can be saved by
eliminating the PL/I support environment; - applications can be maintained
and extended in COBOL; - more choices for software tools and further
migration options are available.

Furthermore, the ability to use a wide variety of COBOL tools to support
all phases of the century date project saves additional effort and cost
over performing the change in the original PL/I version of these
applications.

Visit our WWW site at: http://www.mey.nl/eyrep/welcome.htm


EXECOM
+61-9-4811256, Tim Pearce
e-mail: timp@acslink.net.au
Product: Automated program conversions. The types of conversions we have
done have included changes in COBOL dialects (FUJITSU, BULL, various IBM),
NCR NEAT3 (Assembler) to MF COBOL, PL/I, hierarchical to relational
databases and change in TP monitors. Sizes have varied from hundreds to
thousands of programs for a single client. As the year 2000 approaches,
more of our clients are including date changes in their conversion
requirements. These requirements will be incorporated in our current tools.
We are also commencing a project to prototype a specific century date
conversion tool. [August 1995]


Formal Systems Inc.
800 249-2222, 506 453-9823, Mike Thibodeau e-mail: Inquiry@FormalSys.Ca

Formal Systems Inc. (FSI) provides high productivity tools and value-added
services to support the maintenance and re-engineering of legacy software.
Founded in 1990, we specialize in Natural/ADABAS and have re-engineered
some 30 million lines of code.
Based on NXL technology, NXL2000 is being designed to assist in identifying
and correcting for Year 2000 remediation. This highly automated toolset is
currently capable of providing a high level impact analysis. The results
from this analysis are useful in estimating the scope of a clients Year
2000 project and creating budgets and management plans for remediation. The
completed toolset will offer full impact analysis including data flow
analysis and highly automated remediation of the affected source code.


Global Software, Inc. (MA)
617 455-0949, David Eddy
e-mail: GILES@globsoft.com
Product: GILES - an MVS/ISPF large scale impact analysis tool designed to:
identify complete systems across multiple application boundaries and
platforms, support multiple languages (including the dead ones), require
minimal human intervention, be very fast, and provide a permanent directory
of components. GILES addresses the critical first step of the
re-engineering process (baseline inventory & assessment) that everyone
assumes is already done.


The Greentree Group
214 369-7022, Bill Wachel
e-mail: wmwachel@onramp.net
Product: Management and technical consulting services and actual analysis
and conversion of applications for year 2000 impacts. Leveraging a suite of
code analysis and modification tools to identify and communicate the
potential impacts of Y2K to the client's business functions as well as
technical IS applications. Addressing the full of application creation and
use life cycle and optimizing technology for business value. Experience
working with both commercial and government clients.


HCL America
408 733-0480 x219, Curt Terwilliger
e-mail: twig@hcla.com
Product: an automated conversion process using a suite of MVS-based tools.


IBM
Call local representative or 800 IBM-3333 e-mail: askibm@info.ibm.com
Products: TRANSFORMATION 2000 (TM) SOLUTIONS; COMUDAS

TRANSFORMATION 2000 is a comprehensive set of solutions that takes into
account applications, systems software, and hardware in both centralized
and distributed environments. The TRANSFORMATION 2000 approach seeks to
balance Year 2000 activities with current and planned strategic
initiatives. It brings together state-of-the-art techniques and
technologies developed and proven through both internal and external
projects for the Year 2000 and other data field expansions. This experience
helps reduce both the cost and the complexity of implementing the Year 2000
change. The components of TRANSFORMATION 2000 solutions are as follows: o
Assessment and Strategy -- provides a documented strategy, cost estimates,
timeframes, and resources required
o Detailed Analysis and Planning -- provides an in-depth analysis of each
of the Year-2000 affected areas of your business o Implementation and
Testing -- automates the changes required to source code and data
o Year 2000 Clean Management (TM) -- protects your investment in application and data modifications

COMUDAS is a common date routine that has been developed to replace all
existing date routines. A CICS and an MVS version are available. With
COMUDAS, you can validate, convert, and calculate dates in any format.


IBS Conversions, Inc.
708 990-1999
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.
Product: IBS/Solution 2000(tm)

IBS Conversions has been the undisputed leader in migration methodologies
and software tools for over 12 years. We are backed by Interactive Business
Systems, a company of over 700 technicians, software designers, and
consultants. IBS Conversions addresses migration projects in three phases:
impact analysis and planning, pilot project, and implementation. This
phased approach brings organization and control to the project and assures
low risk and quality deliverables. Impact analysis uses automated tools to
scan COBOL source code, JCL, and copy libraries to identify every
occurrence of a date field that could require modification. IBS then
develops application sequencing and schedules, and a preliminary project
plan. The pilot project uses the preliminary project plan on a
representative subset of the migration inventory. Implementation is based
on the results of the pilot project. IBS has established conversion and
production facilities utilizing an assembly line and factory approach to
provide our clients with high levels of productivity and quality.


Information Management Resources, Inc.
813 797-7080, Rajan Pandhare
e-mail: rajan@imr.usa.com
Product: Transform2000 and large scale consulting services.

They promise a full life cycle year 2000 conversion from on-site, offsite,
and offshore. IMR is a 7 year old firm headquartered in Clearwater, Florida
and with operations spanning North America, UK and India. They (600
individuals) offer fixed fee applications development, legacy maintenance,
and Migration (which includes year 2000) services. Year 2000 has been their
specific focus for the last 14 months and to-date they have executed four
large full life cycle conversion efforts for fortune 500 companies. They
have also built a toolset (Transform2000), to assist in impact and
conversion.


Infosys Technologies Ltd.
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.

Infosys Technologies Ltd. is India's most respected software company
offering quality software products and services in the global market.
Infosys, in its 14 years of existence, has forged strategic alliances with
several large U.S. and International organizations for offshore software
services. Infosys has successfully executed numerous business and mission
critical projects for these organizations using the offshore methodology at
a fraction of the normal cost.


Integrated Microcomputer Systems
301 948-4790, Joseph Yeh
e-mail: joeyeh@imstech.com
Web page at http://140.92.12.65/
Product: consulting?


Intelecon Research & Consultancy Ltd.
604 527-7744, John C. Glover, CMC, I.S.P. e-mail: John_Glover@mindlink.bc.ca

Independent Management & Technology consultants, a telecommunications and
information technology consulting firm focussing on business results and
workable solutions. Strengths include project management, strategic and
tactical planning, and sound financial analysis. The value that we offer to
the year 2000 CDC is a very firm but friendly business approach to
delivering IT solutions, and strong project management experience (since
1958).Intersolv
800 547-4000
http://www.intersolv.com
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.

The INTERSOLV Year 2000 Solution provides unmatched control over the entire
change process -- the most critical component to solving the Year 2000
crisis. It combines the INTERSOLV Maintenance Workbench and PVCS Series to
give you a clear blueprint for effective change management. And their
openness lets you use any compiler, testing and debugging tool for a
complete, seamless approach. Intersolv's expert ServiceDirect Consulting
can provide a predefined package of standard services or customize a plan
to your specific requirements.


Ironsoft Marketing
800 236-0141
Product: ANALYZER 2000


Isogon Corporation (NY)
212 376-3200, Gerald Sindler
e-mail: romy@telaviv.ddddf.com>
Product: TICTOC (an advanced and popular MVS system date simulator).

In addition to intercepting all TIME macro requests (SVC11), TICTOC is the
only product to also intercept SYSPLEX timing services via the TIME
LINKAGE=SYSTEM macro and the STCKSYNC macro. Both macros are documented by
IBM as the recommended alternatives to using SVC11. Using another product
may only cover some of the time requests your applications, high level
languages, and vendor packages make. That can lead to inaccurate testing.
Many assembler programs obtain the time via the STCK instruction. This is a
hardware instruction that no software product on the market can intercept.
However, using TICTOC's unique interception of the STCKSYNC macro call,
there's an easy method to convert STCK instructions into STCKSYNC macro
calls without making any changes whatsoever to your assembler source code.
TICTOC takes under an hour to install. No IPL needed. TICTOC does not add
noticeable overhead to your system, and does not affect file expiration
dates, catalog or SMF or journal timestamps. TICTOC is fully transparent to
other users on the same system who use the current date. Call for
additional info.


James Martin & Co.
800 248-4562, 703 715-4288, Cindy Berger Product: TSRM Blueprint is a
systems redevelopment methodology, a portion of which is devoted to the Y2K
date change.


Mainware Inc
800 848-4912 x2965, 612 932-9154, Jerry Nelson Product: HourGlass 2000 is a
tool to analyze MVS programs affected by Y2K date rollover. It's a utility
to identify programs affected.


Mastech Corp.
800 311-1970, 412 787-2100

Mastech Corporation, a software services firm with over 1,400 employees,
serves businesses throughout North America and Southeast Asia. In early
1994, Mastech opened its offshore facilities in Bangalore, India. The
50,000- square-foot facility houses IBM and VAX mainframes, PCs,
workstations, state of the art tools such as C++, PowerBuilder, VB, and
Oracle, and a host of the top software specialists from India. It has
direct 64 kbps data communication with the U.S. office. The offshore
facility allows Mastech to download data to a parallel environment in India
or to dial in to the client's facilities during evening hours. This
approach means Mastech can commit larger resources to projects at
significantly lower costs, and gives the client faster turnaround at
significant savings over other options. Mastech also has alliances with key
tool vendors that allow it to take advantage of the efficiency provided by
dedicated year 2000 tools. In addition to the home office in Pittsburgh,
Mastech has offices in Fairfax, Va., Toronto, Bangalore, and Singapore.


Micro Focus
415 843-7070, Dwight Cornwell
e-mail: dwc@mfltd.co.uk
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.
Product: Challenge 2000 is a suite/methodology as being propagated by Micro
Focus. This methodology involves using Revolve as a tool, and therefore
repositions Revolve as a year 2000 tool.


Milan Data Services
619 697-1943
Product: Date analysis software.


Millennium Dynamics
513 369-5864, Mike Smith
e-mail: 75503.3443@compuserve.com
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.

Vantage YR2000 provides a comprehensive, consistent, focused process
specifically designed to solve the critical problem of century date change
for complex applications in legacy systems. In developing Vantage YR2000,
the Millennium Dynamics, Inc. staff was able to draw upon years of
experience with insurance, financial, and other complex business
environments: year 2000 knowledge, building and maintaining legacy systems,
tool design and development. Its comprehensive approach to century
compliance consists of an application tool set, training, a process
strategy, PLUS optional conversion services, resulting in a powerful and
cost effective solution.


Patni Computer Systems (P) Ltd.
800 486-2556, 617 354-7424 x222, M.J. Shivkumar (US) e-mail: mjs@dci.patni.com

Product: Turnkey Software Conversion services from ISO 9001 certified
off-shore firm, with capability to handle large projects. Use of automated
procedures & conversion tools for MVS & UNIX environments and a structured
test methodology to ensure a high integrity effort.

Note: In India, contact Milind Padalkar <msp@pcsbom.patni.com> at
+91-22.836.1454 (x161), the Regional Manager of Patni, a large off-shore
software house located in Bombay India, with offices in U.S. and U.K. Over
18 years of software experience with a cost-effective solution for those in
need of year 2000 adaptations to their applications, using a suite of MVS
based tools as well as C/UNIX products (all developed by Patni).


Peritus Software Services, Inc.
(508) 670-0800 x226, Ted Swoyer
e-mail: tswoyer@peritus.com
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.

Peritus is a software maintenance services company. We offer outsourcing,
insourcing, and custom maintenance services, specializing in Year 2000
conversions.

Automate:2000(tm) is an automation-assisted service based on our unique
maintenance technologies, combining our AutoEnhancer/2000(tm), a
language-independent tool which uses formal mathematical techniques to
automate software maintenance tasks, and our Mass Change Factory, which
provides the methodology and process necessary to support a large scale
transformation of code and data. Automate:2000 offers an unprecedented
level of automation to your Year 2000 enhancement, and can dramatically
decrease time and costs of your companies Year 2000 project.


Piercom Ltd
+353-61-335322, Charles Stanley-Smith
e-mail: charles.stanley-smith@ul.ie
Product: Year 2000 Impact Analyses

Piercom provides Services and Technologies for Analysing and Documenting
Legacy Applications. These services are based on a wide range of tools,
which Piercom have developed and are based on over 40 man years of research
and development, part-funded by the European Commission. The Services are
platform and dialect independent and include: * Year 2000 Impact Analyses,
Scoping and Documentation * Systems Re-Documentation - Hard Copy or On Line
- Hyper Linked - giving intuitive navigation
* Re-Engineering - for quality
* Reverse Engineering into CASE Tools through CDIF etc. Piercom's Year 2000
Impact Analyses produces hyper-linked reports on year and date fields and
their usage throughout an application. Piercom also produce counts of the
occurrence of potential date and year fields into a spreadsheet, this is
used to scope & segment a customer's year 2000 problems and plan the
changes required. The analyses are parameter driven and can thus be used to
detect the impact of other field's that should be adjusted at the same
time. The analyses and reports can be customised in consultation with the
customer. Visit our web pages at http://www.commerce.ie/cp/piercom/


PRINCE Software, Inc.
800 934-2022, 201 934-0022, Phil Courtney e-mail:
prince@PRINCEsoftware.com, PORTAL2000@PRINCEsoftware.com *** Year 2000
Information Center Sponsor *** For more information, visit the Year 2000
Information Center at http://www.year2000.com.

The PORTAL 2000 product group contains three MVS-based components to assist
in a century date conversion. Each product is available for a free 30-day
trial.

SURVEY 2000 determines how dates are used in COBOL, Assembler, and PL/I
programs. It cross-references programs, copy books, subroutines, jobs,
files, CICS tables, and more and helps to determine the magnitude of a
change. Search tables may be customized for any type of impact analysis.

TRANSLATE 2000 is a rules-based product that helps automate century date
conversion for COBOL programs. It provides three conversion techniques to
perform either physical changes to programs and files, insert century
window logic using standard calendar routines, or change programs while
simulating file expansion.

SIMULATE 2000 contains facilities for custom date simulation as well as an
audit facility to identify programs that retrieve dates/times from the
operating systems. A rules-based language enables testing and
identification to be performed at over 100 different checkpoints.

PORTAL 2000 Project Management Facility centralizes cost and project
monitoring for all PORTAL 2000 products and is available with each product.


With more than 20 years experience, PORTAL 2000 Professional Services can
assist in the assessment, planning and complete conversion of legacy
applications.

Also available:
- MHtran-2 to convert COBOL to OS/VS COBOL II or COBOL/370. - Translate R/W
to convert IBM Report Writer programs to native COBOL. - MHtran-1 for
comprehensive VSE to MVS conversions.


Princeton Softech, Inc.
800 457-7060, 609 497-0205
e-mail: info@PrincetonSoftech.com
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.

Princeton Softech provides solutions for several specific challenges that
arise when upgrading applications to be Year 2000 compliant: - Combining
Year 2000 Updates with Ongoing Enhancements - Upgrading to the Year 2000
Releases of Purchased Applications - Reconciling Year 2000 Updates
- Creating Relational Test Data

Version Merger provides powerful facilities to reconcile Year 2000 changes
with other application changes. It is a unique productivity tool that is
being used by hundreds of companies to install new releases of third party
applications that have been customized and to solve internal concurrent
development problems. It can reduce implementation time by over 60% while
significantly improving the quality of new releases.

Relational Tools for DB2 greatly simplify the process of testing Year 2000
applications and verifying test results. With the Relational Tools, you
can: - Build relationally-intact test data bases with only a few minutes of
effort. - Transform production data as you copy it to a test data base.
This facility is especially useful for generating test data that includes
future dates and for Year 2000 changes that include data base
modifications. - Inspect and edit related data, adding special test cases
to your test data base.
- Verify the accuracy of your applications by comparing "before" and
"after" images of your test data base.
- Refresh your test data base to ensure that your iterative tests access
stable test data.
- Port relational subsets of data from DB2/MVS to Oracle, Sybase, DB2 for
OS2 and AIX, and XDB to enable testing in client/server environments.


Quintic Systems, Inc.
800 699-1169, 708 699-1169
Product: Century Conversion Software and services.

Century Conversion Software consists of two separate products. Century File
Conversion automates the conversion of any file that can be produced in a
sequential format. It analyzes data for the occurrence of date fields,
expands fields to include a four-digit year, and adjusts record size. It
can also adjust actual file data to simulate future dates to verify program
accuracy. Century Source Conversion analyzes COBOL source code to identify
potential date processing problem areas. It tracks all date name
references, indirect and direct, until all chaining events are exhausted.
In addition to licensing our software for clients' internal use, we also
offer Pilot Study, Impact Analysis, and System Wide Conversion services.


Reasoning Systems
415 494-6201, Lawrence Markosian
e-mail: info@reasoning.com
Product: A suite of software tools & services for assessment, maintenance,
re-engineering and QA of existing systems: - Software Refinery
- Refine/Cobol
- Refine/Ada
- Refine/C
- Refine/Fortran


Rescue 2000 Inc.
e-mail: NBG01743@niftyserve.or.jp, Hiroyuki Tanemoto

Rescue 2000 Inc. was organized in July 1995 to help mainframe users in
Japan solve the Y2K problem. Our products, the 'RESCUE series' consist of 4
products:
1. RESCUE: Base system
2. RESCUE/2000: system for Y2K problem
3. RESCUE/DOA: system for Data Oriented Approach 4. RESCUE/RE: system for
Reverse engineering RESCUE is a system for IBM mainframe system maintenance
which runs under UNIX. RESCUE has a repository which contains condensed
information of JCL, files, DB, DC, programs and cross references. The main
functions of RESCUE are: item chasing within a program, item chasing within
a job, and item chasing among jobs. For example, when I found a data field
'abc' had wrong data, then I would check how it became wrong. By using
upward chasing function of RESCUE, I get visualized information of how
'abc' is made - such as MOVEs and COMPUTEs within a program and a job and
among jobs. RESCUE/2000 has additional functions which semi-automatically
check and correct Y2K fields and also related fields. RESCUE/DOA has DOA
functions such as Data Dictionary, Business rule Dictionary. RESCUE/RE,
which is under development, has reverse functions using Business rule
Dictionary and information in RESCUE REPOSITORY. Note: products and product
literature are in Japanese only.


SATYAM Computer Services LTD
908 632-9609, Raghavendra Rao (Ragu Rao) e-mail: gr266@satyam.jvnc.net
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.
Product: Professional services, and they also offer an integrated year 2000
solution, involving a defined methodology and associated tools.


SEEC
412 682-4991
Product: COBOL Analyst, the industry-leading PC-based technology for 21st
century analysis, uses sophisticated pattern matching techniques, field
analysis, and identification techniques. Application Dictionary provides
ongoing value during assessment, as well as during the planning and
conversion stages. SEEC is a recognized leader in PC/LAN-based COBOL
maintenance and redevelopment solutions.


Silverline Industries, Inc.
800 75-SILVER, 908 457-0200, 708 571-5555, 408 248-8373 e-mail:
kevinmcn@silverline.com
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.

Silverline's Y/2000 Compliance Business Unit provides high-end solutions to
the conversion concerns of our global clientele. Our structured conversion
methodology stems from a Client Tuned approach, one that covers the entire
project life cycle. Starting with a detailed systems impact analysis, to
moving through pilot conversion, to full system conversion (including
parallel runs) and support final implementation.

Silverline's 550+ full-time professional employees can provide a high
quality, turn-key solution. Silverline has facilities and experienced staff
throughout the United States and India. Distributed development is
facilitated by having the Silverline design team link your facilities
through state-of-the-art satellite communications to Conversion Quality
Centers located in Bombay and Madras India. Conversions performed in
multiple shifts, across multiple time zones have many advantages.

The bottom line? Delivery of converted systems on budget, and ahead of your
best expectations. Silverline's success is based on an ISO-9001-3
accredited methodology, and more than a decade of delivering high quality
commercial software products and large scale custom projects to large
organizations, worldwide.


Softlab Northern Europe
(44) 0181 742 2277, Julie Tucker or David Gambling e-mail:
100567.1363@compuserve.com

The Softlab 2000 programme is a range of services designed to assist
companies plan for & implement Year 2000 projects. Utilising Maestro II,
Europe's leading application development environment, we offer workshops &
health checks, working with an organisation's data to establish the scope &
complexity of tasks. We can scan & analyse samples of a customer's code to
both prove the concepts & quantify the impact on their total system. -
Inventory Management: Industrial strength, LAN-based repository holds a
complete inventory of software assets.
- Knowledge Capture - Intelligent scanners capture knowledge of not just
Cobol, but PL1, Assemblers, AM, SQL etc. - Impact Analysis - Via on-line
browsing, queries and reports identify the true scope of the changes
required.
- Change Management - Maestro II manages change providing instant access to
required deliverables & provides automatic notification of changes to team
members.
- Workflow Management - Sophisticated control mechanisms direct workflow
ensuring the quality & integrity of the process. - Configuration Management
& Version Control - Tracks versions allowing changes to be made in
manageable stages.


Software Evolution Technology (SEVTEC)
703 450-6791, Robert S. Arnold
e-mail: rarnold@cais.com
Product: SEVTEC is a year 2000 problem methodology and re-engineering
information services company, helping companies develop technically
adequate plans for, and troubleshooting/tuning existing efforts for
resolving the year 2000 problem. SEVTEC helps companies put together year
2000 problem solutions. It has a database of tools and services to help
companies find applicable technology and providers. SEVTEC also has on-line
year 2000 solution processes that can be customized. Selected tools and
providers from the database can be matched to the process steps. SEVTEC
helps companies review their own plans for technical adequacy, and can help
them evaluate tools and services in a procurement. SEVTEC can help
companies establish measurable standards for gauging the performance of a
year 2000 problem removal effort. Note: To give people needed expertise in
beginning and undertaking a year 2000 removal effort, SEVTEC offers
seminars on year 2000 problem solutions, impact analysis, and
re-engineering (led by Dr. Robert S. Arnold). Note: Robert S. Arnold is
Editor of Year 2000 News, an Internet newsletter on Y2K, and the author of
the January 1995 "Millennium Now" Application Development Trends article,
detailing strategies and technology for resolving Y2K problems. He also
writes for the Tick, Tick, Tick newsletter, and is the author of, Software
Re-engineering, IEEE Computer Society (1993).


SOFTWARE MIGRATIONS LTD (UK)
+44 (0) 191-386-0420, Simon Grant or John Ashley e-mail:
simon@sjcgrant.demon.co.uk, J.D.Ashley@durham.ac.uk Product: FermaT 2000 is
a formal methods tool targeted at year 2000 analysis, particularly (but not
exclusively) of IBM Assembler code. 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,
year 2000 problem incidence, and cost estimation. FermaT 2000 is available
as a tool and a service.


SPR (Systems and Programming Resources)
800 SPR-6651
Product: Recently sponsored a one-day seminar in Tulsa, OK. They offer
people, software tools and methodology.


Synergy 2000, Inc.
Product: Balennium, to help mainframe systems tell whether '00', for
example, means 1900 or 2000. Mentioned in InformationWeek, Jan. 23, 1995.


TransCentury(tm) Data Systems
800 837-7989, 415 255-7082, Joe Warren (and others) e-mail: joeWar110@aol.com
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.
Product: Calendar Routines

TransCentury Calendar Routines are not limited to the 2000 arena but can be
put to immediate use in any new development or re-engineering project which
involves date processing. The routines provide the most comprehensive and
the largest number of totally integrated, fully documented date processing
functions commercially available today. TransCentury encourages
STANDARDIZED, portable date processing across the enterprise through the
shipment of source code, and the availability of Enterprise-wide licensing.
Using the routines will not only help ensure correct date processing
results and calculations, but can also help your company exit the date
programming and maintenance business (which doesn't generate new revenue
for most companies). Finally, use of the routines can help lower the costs
of year 2000 projects since overall testing time may be shortened due to
the reliability of the routines. Once you have identified existing year
2000 date exposures, you can begin to correct the problems in a managed,
incremental fashion with simple, consistent calls to TransCentury routines.
Call for more info.


VIASOFT
602 952-0050, Dale Vecchio
e-mail: dale_vecchio@viasoft.com
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.
Product: ENTERPRISE 2000

VIASOFT, Inc. is a leading provider of business solutions consisting of
integrated technology and specialized professional consulting services. We
enable customers worldwide to optimize their software investments by
substantially reducing the cost of maintaining and redeveloping existing
COBOL applications and allowing programming resources to be redeployed to
new initiatives, such as new application development and client/server
migration. The year 2000 conversion is a specific example of a large scale
maintenance project. VIASOFT's Enterprise 2000 solution not only applies
our established productivity technology to this problem, but has also
developed a completeprocess specific to the year 2000 for determining the
size of the problem (impact), as well as the more problematic planning and
conversion phases.


Visionet Systems Inc
908 329-8090, Farasat Zeh
e-mail: visionet@superlink.net
*** Year 2000 Information Center Sponsor *** For more information, visit
the Year 2000 Information Center at http://www.year2000.com.

Visionet offers end to end turnkey Year 2000 conversion services. We have
tools & services for the needs of those with S/36, S/38, AS/400 Y2K
problems/projects. We operate internationally, and specialize in AS/400
environments (yes RPG II, III, AS/400 Cobol, etc. -- no other
environments). We will brief you on the Year 2000 problem, perform impact
analysis, expand fields and system test the converted programs. We will
then simulate effects of Year 2000 by switching the date to January 1,
2000, on your system to confirm that your business will run absolutely
error free into the next millennium. Visionet will also offer a Year 2000
Warranty for a fee. With this warranty we will review your systems on a
yearly basis after the conversion to ensure Year 2000 compliance. If you
prefer, you can use our tools and services for impact analysis and field
expansion while doing the testing and implementation yourself.


Wipro Systems
408 737-6125, Anil Garg
215 465-7704, Desmond Nazareth
e-mail: wiprosfo@mcimail.com, nazub@mcimail.com *** Year 2000 Information
Center Sponsor *** For more information, visit the Year 2000 Information
Center at http://www.year2000.com.

Product: DA-TE-2000 is a proprietary toolkit for largely automated Impact
Analysis, File Conversion, Cross Reference and Date Research. The
specialized toolkit handles Y2K application conversions. It provides a
flexible, date data driven approach to dealing with an application's Y2K
problem. An enterprise wide and application specific Y2K methodology has
been developed encompassing Impact Analysis, Data and/or Source Conversions
Testing/Validation and Implementation, positioning us to handle a variety
of onsite/offshore service requests. Wipro Systems, a division of Wipro
Limited, is a premier software consultancy organization in India, offering
software development, Re-engineering/Conversion, porting and maintenance
services to corporate clients in USA, Europe, and the Far East. Its clients
include many Fortune 500 companies and it has provided year 2000 solutions
for large banks in the US. Together with its US based partner, Nazub
Software, Inc., it has developing solutions in the Y2K area since 1988.


XP Software, Inc
508 987-1922, Rui Gama
e-mail: xpsoft@tiac.com

xPress2000(tm) is a group of tools providing Hardware, Computer Language
and Human Language independence. Through visual or batch interfaces,
xPress2000(tm) searches potential date matches (through the use of
preloaded or user added strings), using field names and date routine calls.
An integrated editor allows for quick visualization and manual change of
matches. An automated code modification process (after user authorization
and definition) allows for quick and effortless millennium related changes.
A language definition compiler allows the definition of any computer and/or
human language. An evaluation copy is available. In addition, our service
partners can provide the full range of millennium services. Visit our web
site at http://www.xpsoft.com.


---------------------------------------------------------------------------

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
solutions.

-- Serge Bouwens <serge@cistron.nl>

---------------------------------------------------------------------------

6.3 What mailing lists, news groups, archives and other Y2K references are
available on the Internet? Are there any other published references on this
problem?

***

The Year 2000 Information Center home page on the World Wide Web is at
http://www.year2000.com. The Information Center has a countdown clock,
articles on various aspects of the problem, vendor information, this FAQ,
and links to related information.

***

There is an Internet mailing list for discussions of year 2000 computer
problems. To subscribe, send e-mail to listmanager@hookup.net with
SUBSCRIBE YEAR2000 as the BODY of the message.

Most of the material in this FAQ comes from this mailing list.

***

The current version of this Year 2000 FAQ can be obtained by selecting the
hypertext link from the Archives section of the Year 2000 Information
Center home page (see above), or by anonymous FTP from www.year2000.com. It
is in the /pub/year2000 directory; the file name is y2kfaq.txt.

***

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
http://www.software.ibm.com. 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

***

Year 2000 News is an Internet newsletter distributed free by e-mail. It is
published by Software Evolution Technology, Inc. (SEVTEC) and edited by Dr.
Robert S. Arnold, president of SEVTEC.

To subscribe, send the message "SUBSCRIBE" in the SUBJECT field of your
email to "news2000-request@andrew.cais.com". Omit the quotation marks in
both the message and the email address. Upper and/or lower case letters are
OK.

Dr. Arnold is also the author of the January 1995 "Millennium Now"
Application Development Trends magazine article, detailing strategies and
technology for resolving the year 2000 problem. He also writes for Tick,
Tick, Tick... .

***

Jan de Decker <janjedsp@innet.be> maintains a collection of references to
press articles about the year 2000 problem on the World Wide Web at
http://www.club.innet.be/~janjedsp/y2k.htm

***

The Millennium Journal is a four-page newsletter published every two months by:

Data Dimensions, Inc.
777 108th Ave. NE - Suite 2070
Bellevue, WA 98004

Phone: 800 708-0675, 206 688-1000
Fax: 206 688-1099
E-mail: 76311.1542@compuserve.com, rbergeon@aol.com

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.

***

Here is a list of articles that Ted Swoyer <tswoyer@peritus.com>
recommended. An * indicates a reference that he found particularly useful.

Cohn, Michael B., No Need To Fear The Year 2000, source: unknown.

Hayes, Brian, Waiting for 01-01-00, American Scientist, Volume 83,
January-February 1995.*

Arnold, Dr. Robert S., Millennium Now: Solutions for Century Date Change
Impact, Application Development Trends, January 1995.*

Sullivan, R. Lee, Ghosts in the Machines, Forbes, June 19, 1995. Associated
Press, Troubled Time, Denver Post, May 25, 1995 (and various others across
the country).

Ross, Noah, The End of the Century is Nearer Than You Think, Application
Development Trends, April 1995.*

Furman, Jeff, Marotta, Albert, and Candiotti, Cliff, Party When It's 1999,
Software Magazine, April 1995.*

Fine, Doug, Companies Brace for Millennium, Infoworld, April 10, 1995.

Cini, Al, System Bug of the Apocalypse, Internetwork, January 1995.

Goodwin, Bill, Tick, Tick, Tick... (a newsletter), 2000AD, Inc., Brooklyn, NY.

Arnold, Dr. Robert S. Resolving Year 2000 Problems in Legacy Software, a
presentation at Software Quality Week, San Francisco, CA, June 1, 1995.*

***

Computers in Crisis
How to Avert the Coming Worldwide Computer Systems Collapse by Jerome T.
Murray and Marilyn J. Murray Petrocelli Books Inc.; New York, 1984; ISBN
0-89433-223-6

Table of Contents:

Preface
Acknowledgments
Time Measurement: A Brief Review
Algorithms, Notation, Pseudocode, and Programming The 8-Digit Date Puzzle
Short Interval Aging
Extended Interval Aging
The Translation Algorithm
Date Versus Name of Day
Conversion of the Neojulian Date
The Algorithm for Easter
The Gregorian Status Indicator
The Conversion Plan
Appendix A
Appendix B
Appendix C
Appendix D
References
Index

---------------------------------------------------------------------------

6.4 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 themarket 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 <J.D.Ashley@durham.ac.uk>, 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 (tswoyer@peritus.com), Peritus Software Services, Inc.

---------------------------------------------------------------------------

6.5 What standards exist for computer representation of dates? Where can I
get copies of these standards? Are they available on the Internet?

As someone once said, "The great thing about standards is that there are so
many to choose from." [Can anyone document the source of this quotation?]

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
year.

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:

ANSI - http://www.ansi.org
ISO - http://www.iso.ch

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 their 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'm near the beginning of my Y2K effort and 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?

***

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 <MSMAIL.TURGEONM@TSOD.LMIG.COM>

***

Try Jim Rahm at The Source Recovery Company (catchy name, eh?) in Atlanta
at 770 785-9801 or 72604.2340@compuserve.com.

My understanding is that they offer a service in which you send them what
you have (load module, copybooks, listings, whatever) and they return you a
working source module. According to Jim Rahm, they handle COBOL and
Assembler for MVS, VM or VSE. Price seems quite reasonable.

If you use them (or any similar service), please tell all of us what you
think. There's clearly going to be a LOT of this in year-2000 projects.

***

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.

***

Sometimes, even having the old source code doesn't help too much. Note that
much old source no longer meets the standards of new compilers, but the
generated program still runs.

-- Reg Harbeck <harbeckr@cadvision.com>

===========================================================================

7. APPENDIX

7.1 Contributors

Two people must be given special thanks. First and foremost is John Moffitt
<jmoffitt@moffitt.aws.waii.com>, who performed the enormous task of putting
together the original version of this FAQ.

The second is Peter de Jager <pdejager@hookup.net>, 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.

Michael J. Averbuch <mikeaver@prairienet.org> Serge Bouwens <serge@cistron.nl>
Donald Brown <BROWND@afc4a.safb.af.mil>
Brian Christenson <BChristenson@Wright.Edu> Adrian Clark
Pierre Cloutier
Duncan G. Connall <dconnall@tiac.net>
Mike Drabicky <drabicky@network-1.com>
David Eddy <deddy@tiac.net>
Andrew Eldridge <ACEldridge@aol.com>
John Franciscovich <jfrancis@vnet.ibm.com> Roger Gates <gatesro@aol.com>
Bear Giles <bear@fsl.noaa.gov>
Sherry L. Goncharsky <sherryg@vnet.ibm.com> Hans Goossens
<J.Goossens@inter.nl.net>
Reg Harbeck <harbeckr@cadvision.com>
Francis J. Hensler <FJH@SRUVM.SRU.EDU>
Karen D. Herbert <karen.herbert@state.ar.us> John L. Horton
<JLHorton%utl13n%cob%wpgate@yvax.byu.edu> Ron Hunter-Duvar
<rhd@FormalSys.CA>
Lanny Jones <Notimetolz@aol.com>
Cliff Kurtzman <cliff.kurtzman@tenagra.com> Romy Leibler <romy@ddddf.com>
Gene Lynd <nff0075@dsac.dla.mil>
Jacqui Macdougal <ca26@dial.pipex.com>
Francis D. MacLellan
Geoff May <geoffmay@enternet.com.au>
Bob McClenon <rmcclenon@syncorp.com>
Brenda McKelvey <mckelveybj@em.agr.ca>
Pat McKeown <PMCKEOWN@cbacc.cba.uga.edu> Daniel A. McLaughlin
<us9lbclb@ibmmail.com> Dick Murray <dmurray@map.com>
David A, Negrey <NEGREYDA@WPGATE1.WPAFB.AF.MIL> Richard Newbold
<CF1.FIRNEWBO@TS3.teale.ca.gov> Alf Ohlsson <alfo@algonet.se>
Mike Olsem <olsemm@software.hill.af.mil> Bill Parkinson
<Bill_Parkinson@Merck.Com> Raghavendra Rao <gr266@satyam.jvnc.net>
Dave Rybarczyk <drybar@czn.com>
Rob Schneider <rschneider@pwss.gov.ab.ca> Pris Sears <sears@vt.edu>
Stan Sieler <sieler@denkart.com>
David Silver <David_Silver_at_Human__Resources@ccmail-metro.pwcm.com> Ivan
C. Smith <rustfrog@fox.nstn.ca>
Jens Peter Soltoft <jps@dc.dk>
Peter Somers
Tom Ster <tom.ster@dns.midata.com>
Ted Swoyer <tswoyer@peritus.com>
Marty Tabnik <marty.tabnik@greatesc.com> Ralph G. Taylor
<TAYLORRG@ofc004a.sce.com> Randall Thomas <76646.333@compuserve.com> Rick
Toker <rtoker@best.com>
Mike Turgeon <MSMAIL.TURGEONM@TSOD.LMIG.COM> Diana van Dyk
<Diana.VanDyk@js.btx400.co.uk> Allan E. Van Ness
<vanness@pccvax.dnet.dupont.com> Steve Vogel
<steven.c.vogel@naperville.nalco.infonet.com> Joe Warren
<JoeWar110@aol.com>
Jerry Whittle <jwhittle@amclg.safb.af.mil> Bob Wier <wier@bobcat.etsu.edu>
Mike <B09VYF5@bafco.bell-atl.com>
<THHACKETT@vaxsar.vassar.edu>
<Micamber@aol.com>


7.2 Copyright and Permission

Copyright 1995, 1996 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 & Co., 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 <70023.2572@compuserve.com>


