THE YEAR 2000 FAQ
Version 2.3 - May 5, 1998
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 .
Originally created by John Moffitt.
See question 7.1 for a list of contributors.
---------------------------------------------------------------------------
Copyright 1995, 1996, 1997, 1998 Robert J. Sandler. All rights reserved.
Contains material copyright by others.
Permission is granted to copy and distribute this document by any means,
provided that it is copied in its entirety, including this notice and the
disclaimer below, and that no fee is charged other than the actual cost of
transmission or reproduction or the standard connection-time charges on a
BBS, on-line service, or Internet connection. It may not be distributed for
financial gain or included in a commercial collection or compilation
without prior permission from the copyright owner.
Most company names and product names mentioned in this document are
trademarks or registered trademarks of the respective companies.
Disclaimer
While the information contained in this document is believed to be
accurate, Robert J. Sandler, Peter de Jager, de Jager & Company Limited,
The Tenagra Corporation, and the contributors do not guarantee the
accuracy, adequacy, or completeness of the information, and assume no
responsibility for errors or omissions, nor any liability for damages
resulting from the use of this information. The views and opinions
expressed in this document do not necessarily reflect the position of the
maintainer. Affiliations are given for identification purposes only.
---------------------------------------------------------------------------
CHANGES FROM VERSION 2.2
Disclaimer - Company name changed to de Jager & Company Limited.
Question 1.2 - Updated web address for The Tenagra Corporation.
Question 1.5 - Added item about IGZEDT4.
Question 1.6 - Updated comment about sorting dates with two-digit years.
Question 1.7 - All information about specific products has been moved to
Section 2, Questions 2.1 and 2.6 through 2.13, in order to put all product-
specific information together, with a separate question for each product.
Minor change in the wording of the question. Added cross-reference to
Question 6.3.
Question 2.1 - Added information about BIOS testing programs and about
Award BIOS. Additional information moved from Question 1.7. Added cross-
reference to Question 2.8 concerning File Manager. Deleted some old
material.
Questions 2.1 through 2.5 - Question changed to just the name of the
product.
Question 2.2 - Added information about Linux.
Question 2.3 - Added correction about VMS time format.
Question 2.4 - Added comment on applications.
Question 2.5 - Added new answer about updated information on Novell web
site.
Questions 2.6 through 2.13 - Moved from Question 1.7 and reorganized.
Question 2.8 - Added information about File Manager fixes.
Question 2.9 - Added cross-reference to Question 2.8.
Question 2.10 - Added cross-reference to Question 2.15. Added information
about the 1900 anomaly and about a year-2000 spreadsheet FAQ. Removed a
message.
Questions 2.14 - 2.20 - New questions.
Question 3.1 - Corrected the quotation and attribution from the Risks
forum. (Thanks to Jonathan Swinton for pointing out the
error.) Removed an article at the request of the sender.
Question 3.4 - Added an additional answer.
Question 3.5 - New question.
Question 4.4 - Added two more answers.
Question 5.3 - Added comparison of expansion, windowing, and encapsulation
methods.
Question 5.5 - Revised first answer. Added new material.
Question 5.6 - Completely replaced with a different question.
Question 5.11 - Updated affiliation and e-mail address for Don Estes. Added
note about patent covering program encapsulation.
Questions 5.12 and 5.13 - New questions.
Section 6 reorganized. Question 6.3 split into two questions, 6.3 and 6.4.
Former Question 6.4 is now 6.6. Questions 6.6 and 6.7 renumbered to 6.7 and
6.8.
Question 6.3 - Revised information about Year 2000 Mailing List and how to
obtain this FAQ. Added cross-reference to question 6.4 for the Year2000.com
book store. Added items about the SIM on-line conference, the Y2K Links web
site, and Microsoft's Year 2000 web site. Added three items about web sites
that list product status. Added clarification of ITAA certification.
Question 6.4 - Added information about the Year2000.com book store and the
U.S. GAO assessment guide.
Question 6.7 - Shortened question. New phone number, e-mail address, and
URL for The Source Recovery Company.
Question 7.1 - Added new contributors to list.
I have tried to include the date that an article or answer was written,
following the author's name. Any article with a name but no date is
probably from 1995 or early 1996.
---------------------------------------------------------------------------
PREFACE -- A Few Quotations to Set the Mood
---------------------------------------------------------------------------
"The alternative to addressing the year 2000 will be going out of
business."
-- Kevin Schick, The Gartner Group
The year 2000 date-change project presents organizations with one of the
most interesting challenges since the dawn of the computer age. It is
potentially the largest project the IS department has ever attempted. It
has life-threatening implications for the business. It has an absolute,
immovable deadline. It is a significant, unplanned, out-of-budget expense
and it has no sponsor.
-- James A. Jones, Director of Year 2000 Group, Information Management
Forum, in CIO Magazine, September 15, 1996
Mainframers are in serious denial these days about what will happen a
couple of seconds after midnight on Dec. 31, 1999, when many thousands of
mainframe programs handling critical business applications discover they
don't know how to deal with dates that include the year 2000.
It's not that the world's COBOL programmers don't know how to fix the
problem, or that current mainframe programming languages are incapable of
handling dates in the next century. The problem is that mountain of old,
fragile mainframe code still in use in business around the world - often
running processes that lie right at the heart of a company's business.
These applications have been around so long, were developed in such tangles
of spaghetti code, and have been modified in undocumented ways so many
times that no one now employed by the company knows how to fix them. In
some cases, no one now alive knows how to fix them.
-- Jim Seymour, PC Magazine, Mar. 16, 1993
---------------------------------------------------------------------------
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, year-2000 problems?
1.8 What are the special year 2000 problems about tape archives?
1.9 How can I tell how big the problem is in my company?
1.10 Does anyone have any cost data or statistics on what it will cost to
modify COBOL programs?
1.11 What happens to date programs when you try to use older more
historical dates and at various locations around the world?
1.12 Are there some hidden problems (i.e. date thresholds) related to date
storage that we have not yet thought of (or discussed)?
2. PROBLEMS WITH SPECIFIC HARDWARE AND SOFTWARE
2.1 PC BIOS
(a) Why does the BIOS date (year) seem to roll from 1999 to 1900?
(b) Why does DOS (and Win95) seem to change the BIOS date to Jan 4, 1980?
2.2 UNIX, Linux, and/or C/C++
2.3 VMS
2.4 Apple Macintosh
2.5 Novell Netware
2.6 IBM Mainframe MVS, ESA, and OS/390
2.7 IBM Mainframe VM
2.8 Windows 3.1
2.9 Windows 95
2.10 Excel
2.11 Paradox
2.12 Quicken
2.13 Ada
2.14 Sorting
2.15 Microsoft Products
2.16 Windows NT
2.17 Windows 98
2.18 PKZIP
2.19 SAS
2.20 Oracle
3. 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?
3.4 Does the Global Positioning System (GPS) have a year 2000 problem?
3.5 How are credit card companies handling year-2000 expiration dates?
4. 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 the critical dates that programs must be tested with?
5.7 My concern centers on those systems that have already hit their "event
horizons" and have been fixed using whatever solution.
(a) Is it possible that these systems will still experience problems come
the first of January on the year 2000?
(b) If System A implements Fix1 instead of Fix2, does this mean System B
later has to implement Fix1 also, for compatibility purposes?
(c) Finally, is it possible that the immediate fixes today on System A may
adversely affect other systems which depend System A, either now (and the
other systems don't know it yet) or after the first of January on the year
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?
5.11 What is encapsulation?
5.12 What is windowing?
5.13 How can you properly sort dates with two-digit years?
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, newsgroups, archives and other Y2K references are
available on the Internet?
6.4 What books and other published references are available on this
problem?
6.5 What standards exist for computer representation of dates? Where can I
get copies of these standards? Are they available on the Internet?
6.6 I have to assess how much of a problem we have with legacy assembler
code. Any ideas/products/vendors to facilitate the analysis?
6.7 I've discovered that I have compiled applications that I do not have
the source code for. How can I get the source code back in order to fix it?
6.8 Is there a Year 2000 user group near me?
7. 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 , Global Software, Inc.
***
"As the year 2000 approaches, MIS organizations across the country have
been wrestling with the problem of reprogramming date-dependent systems.
Date-dependency refers to how most programs depend on the manner in which
dates are represented in order to run computations. But as of the first day
of the next decade, the way in which days, months, and years have been
identified up to now will, in many cases, become invalid. For example,
COBOL programs currently represent Feb. 26, 1990 as 900226, and Jan. 1,
1991 as 910101, allowing the computer to compare the two numbers and
correctly assume that the smaller number represents the earlier date. On
Jan. 1, 2000, or 000101, however, those comparisons will fall apart."
-- Informationweek, Feb. 18, 1991
---------------------------------------------------------------------------
1.2 How serious is the year 2000 problem?
Selected comments from the Year 2000 mailing list:
***
According to Gartner group, 90% of the applications will be affected by the
Date 2000 problem, and systems will crash, if the century problem is not
corrected before 1999. 20% of business applications will fail due to date
computations in the year 1995. Most major corporations are expected to
spend about $50-100 million. The Gartner Group estimates "A medium size
shop with approximately 8000 programs, each program averages 1500 LOC, and
a data reference to LOC ratio of 1:50 will cost in the range of
$450/program to $600/program or $3.6-$4.8 million for the entire
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 , 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://www.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 , TransCentury Data Systems (in 1995)
***
This the first time I'm going to state some views 'publicly.' I've been
holding back, because the title 'Chicken Little' is hardly one that sits
well with me... nor is it one that reporters accept as 'credible.' AND the
media have been remiss in helping businesses understand this problem,
instead of describing it in detail, they've been treating it as 'Scientist
Predicts All Computers Will Explode in 2000!' Hardly worthwhile reading
material for a CEO, CFO or the Chair of the Board.
Take a look at the input screens of most accounting systems. These systems,
typically legacy systems, the ones most likely to fail, control the true
lifeblood of the organization... not INFORMATION! but something more
mundane. Dollars.
Most of these systems accept ONLY 2-digit years. Why? Possibly because MOST
data entry into these systems is date information and typing those 2 extra
digits, time after time after time would be boring, tedious, inefficient
and generally a pain in the arm.
Try entering 00 into one of these screens... you'll likely get... a data
exception... or it won't accept the data as valid... or it will accept
it... all of these will cause problems. The first two reject the data...
that's good. The last is scary... will it process that 00 correctly?
Based on my personal programming experience, I'll predict that 90% of
accounting systems will either reject the data or fail. To me, that's more
than a reasonable estimate. Assume I'm off by 100% ... that only 45% of
Accounting systems die. Watch what happens.
Okay... now it's 'whenever this happens' sometime between now and Day 1,
Y2K. Most likely in 1999...
Your accounting system is dead in the water. What are the implications?
Well... The most simple consequence is you can't cut or pay an invoice. No
money will come into or leave your organization... (assume payroll is
working... otherwise things only get worse... faster)
There are some organizations so literally computer dependant, they will NOT
be able to get that cash flow moving EVEN if they hire 100 accounting
clerks. What invoices do you pay? What do you bill? EVERYTHING is in the
computer...The clock struck Jan 1, 2000 and the computer had a stroke.
Other companies will be able to generate a trickle of billing and payments
by hiring manual labour... (How many clerks could you hire tomorrow? by
next week?)
How FAST can you get an accounting system going? Can you fix the one you
have? Or do you install a new one... Several of us, on this list have
installed new accounting systems under pressure... how long did it take? 9
months? 6 Months?? 3 Months???
How fast can you install a new system when the entire company is a)
screaming at you? and b) Blaming you? and c) the old system is dead and
dead computers leave no audit trails.
How stable will your project team be ... when the company down the street
is in the same predicament and offers huge 'incentives' to your staff to
jump ship and help them? Will you lose your best and brightest or will you
lose the bottom of your hope?
If you can't get your accounting system up and running in three months
you're dead. Out of business, kaput ... Today's organizations CANNOT
survive three months without cash flow. (and yes there WILL be a run on the
banks as companies get desperate for cash advances NOW!)
Okay ... assume you have the very best and the very brightest ... your
system is up and running in a week. (Loud laughter from the back of the
room... not appreciated... nevertheless, the speaker continues unperturbed)
Remember that 45% failure rate? The VERY optimistic one? It means that 45%
of the people you bill will not be able to pay. This is 100% out of your
control ... 45% of your cash flow will be stopped even if your system is
fine. Even if you have NO Y2K problems ... 45% of your clients do. So do
45% of your vendors ... can you order your raw materials if THEIR systems
are dead? Oh, and remember that you've been pushing JIT inventory for years
now ... your stock levels are deliberately low ... based on the assumption
that the NEXT delivery is next week.
Can you build a car with 45% of the parts? Can you ship a product when 45%
of the distribution channel is 'troubled' by the Y2K problem? Can you sell
your product to me... If I have a Y2K problem? As Ted Nelson said in
ComputerLib "Everything is InterTwingled"
Can you survive with 45% of your cash flow?
Will your computing staff stay around with salaries going through the roof?
Especially for those who have PROVEN conclusively they can write Y2K
compliant code!!!
How many companies need to fail...10% ? 25% ? 45% ? before a critical mass
is achieved and it all comes tumbling down like a house of cards? We are
all inter-dependant upon each other... we might NOT pass 'data' back and
forth... BUT we DO pass invoices and other accounting and inventory
information back and forth... managed by systems totally dependent upon
digit deficient data.
-- Peter de Jager (in 1995)
---------------------------------------------------------------------------
1.3 What is the year 2000 day-of-the-week problem?
Most programs that calculate the day of the week using only the last two
digits of the year will get wrong answers for January 1, 2000, and all
subsequent dates. This is because the formulas they use implicitly assume
that the dates are in the 1900s. January 1, 1900, was a Monday, but January
1, 2000, will be a Saturday.
-- Robert J. Sandler
---------------------------------------------------------------------------
1.4 What is the 1999 problem?
***
Many people aware of a related problem that might happen for all computer
files created on Sept. 9, 1999? This date (9/9/99) was popular back in the
1980's as an expiration date for (forever) archived data that you wanted to
have 'no expiration date'.
***
And of course, if you haven't done anything about the year 2000 by this
time, you are very likely too late to avoid severe computer problems by the
start of business January 3rd in the year 2000.
***
I was chided by one of my customers Friday for the WSJ piece on me that
said Jan 1, 2000 is the big problem rollover. She emphasized that Jan 1,
1999 is the big problem. At that point (at least from the viewpoint of
their financial & distribution systems) when systems attempt to rollover &
reset themselves is when she said disaster will strike & things will
immediately grind to a halt.
For systems that look a year ahead, the witching hour is 1/1/99.
Every commercial system (banking, mutual funds, payroll) I ever worked on
was typically running 'year-end' jobs well into the middle of the next
year. There was always the flat our panic to get 1099's and W2's out by the
end of January & then lots & lots of runs & reruns of other strange
corrections & adjustments & foreign tax reports, etc.
-- David Eddy , Global Software, Inc.
---------------------------------------------------------------------------
1.5 Is this only a COBOL problem?
No. The problem has little to do with the language used. Year 2000 problems
have been found in practically every programming language.
***
Could ANY language have prevented the current Y2K problem?
No, because Y2K is a management (planning) problem, not a technical OR a
languages problem. However there are plenty of Y2K COBOL problems!
***
We might want to have a section that just lists the known languages by
platform? So far virtually all the discussions seem to revolve around (1)
COBOL, (2) PL/1, and (3) Assembler, as if Focus, Nomad, Ramis, Easytrieve,
DYL260, DYL280, ADF, SAS, CICS Command level, CICS macro level, ETC (yes,
that's also a language), etc. all simply don't exist.
There are plenty of shops that are running languages officially declared
dead & abandoned by the vendor. Prime example is OS/VS COBOL. IBM's
declared it dead for well over a decade. I've been told that perhaps 40% of
IBM mainframe shops are still running OS/VS COBOL.
I keep meaning to call Capers Jones to see if he'll at least release a list
of the 400 languages he collects metrics on. I'd be willing to guess that
perhaps 200 of these are hardware specific military/proprietary languages.
Best I can do is name perhaps 20 commercial languages.
I'd vote for at least giving some visibility to the very real fact that
there are plenty of languages still in active use that don't appear in
ComputerWorld or InformationWeek.
As you can see I'm only looking at the world through big (little?) blue
glasses. I'd have a hard time even listing the major hardware vendors which
each must have their own plethora of unique languages (VAX, HP, DG, Sun,
Apollo, Honeywell, Univac, GE, Burroughs, etc).
-- David Eddy , Global Software, Inc.
***
I am a networking specialist (IBM/SNA, TCP/IP, Localnet, etc.) On this
moment I am not working because of Multiple Sclerosis but via Internet I
want to keep me up to date and can share experience with you.
I see a lot of problems in the mainframe area (all platforms). There are a
lot of exits written by good people (assembler) in networking applications
databases and other applications that work with date/time. The exits are
used for security logging and accounting in networks. At the day "X" there
are a lot of problems with connected database's etc. All systems of
international operating organisations must have a standard date implemented
in all software.
I work already 25 years in this area and saw a lot of software written by
people that are not working anymore in the place where they made the
exits', applications etc.
Most of the stuff is not documented.
I think that global operating or network connected systems will have a lot
of problems that cost a lot when they don't start a global project to get
the date problem fixed.
You cannot receive records from another system that is using a changed date
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, 16 Jun 1995
***
IBM has created APAR PN84080 which allows COBOL II to get the current date
with a 4 digit year: Sample code:
01 WS-YYYYMMDD.
05 WS-FD-YYYY pic 9999.
05 WS-FD-MM pic 99.
05 WS-FD-DD pic 99.
CALL 'IGZEDT4' USING BY REFERENCE WS-YYYYMMDD.
-- David Alcock , 9 Feb 1998
***
I was browsing in our HP/3000 COBOL II/XL manual looking for date-stuff and
I see that there is something called "CURRENT-DATE" which returns an 8 byte
field in the format 99/99/99 representing mm/dd/yy. There is also a
function, as in "FUNCTION CURRENT-DATE" which returns everything you ever
wanted to know about the date, time, etc. - even GMT deviation - including
the year with the century included, as in 1995. The aforementioned
"CURRENT-DATE" gets its values from the software clock while the "FUNCTION
CURRENT-DATE" gets its info from the hardware clock.
-- Francis D. MacLellan
---------------------------------------------------------------------------
1.6 What is the date-in-key problem?
The basic problem is that many systems use a date as part of the key of an
indexed file. This becomes a problem if the date has a two-digit year and
the application depends on records in the file being in chronological
order. Even if processing of the data does not depend on the records being
in chronological order, it could result in records being listed in the
wrong order in reports or on-screen displays. In 2000 and later, an
application that is supposed to show the most recent items at the top, or
on the first screen, would instead show 1999 items first.
***
Sorting dates in VSAM keys
I have received a couple of inquiries as to whether there will be something
similar to the sorting capability being provided in DFSORT for Year 2000
will also be available for VSAM. As you may notice from the time it has
taken me to respond to this inquiry, the answer is not a simple one.
The interpretation of keys was never expected to be a VSAM responsibility.
Therefore, the key is treated as a string of binary values based on the
EBCDIC values of the characters in the code page used to enter the data.
Therefore, the only valid order for VSAM KSDS to store data is in binary
order. I agree that the actual usage of the keys often assigns meaning
beyond what is recognizable by the programming support behind the
manipulation of these keys. However, at this time, we do not plan on
supporting any VSAM code to assist in proper sorting of dates within VSAM
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 culturally
correct sorting (another discussion in itself so that the sorted output
uses the same alphabetical ordering as users of the language intend.) I do
not expect that IBM will offer anything to address this issue as part of
our YEAR 2000 support available by the end of 1996.
Now, that does not mean that we do not recognize this as a product
shortcoming. An interim solution would be to use DFSORT to reorder the
output records so that they are presented correctly using a windowing
technique with the appropriate starting value specified. If the records are
too complex to sort (such as for multi-line output produced from a single
key), then it will be necessary to obtain a list of the keys of the desired
records, sort the keys, and obtain the records in the desired output order.
I recognize that none of this is easy.
For those of you who are VSAM KSDS users, I recommend that you evaluate the
impact of this reliance on the interpretation of the keys to produce the
necessary output. You can contact your IBM representative and they will be
glad to assist you in creating a formal request for this requirement,
giving details as to why other methods won't work and its impact. Once this
is done the first time, others can just have their IBM representative
concur with the existing requirement, adding account specific information.
The amount of interest shown in solving 2-digit year designation with VSAM
keys will influence the likelihood and timing of our (IBM) providing a
solution.
-- Sherry L. Goncharsky , IBM Strategy/Requirements,
SSD Software Products, February 26, 1996
***
Of course, it's good to take the long view, and clearly 4-digit years are
where we all want to be. But I think people are underestimating the
difficulty in getting there. One large IBM mainframe COBOL app I am
familiar with has nearly 4000 non-DBMS files and references over 3800
unique copy books. Data is passed among some 1600 batch and 500 TP
programs, but also data is sent to and from outside applications and
organizations via FTP and other means. What's worse, 6 separate copies of
this application are run. It would take until the year 3000 to change one
file at a time, but if you were to do many at once the effect would cascade
throughout the system (and beyond). All programs and files affected would
have to be deployed at the same time (or bridges constructed, also
complex). Falling back in case of an error would be difficult or
impossible, since earlier program versions would use different file
formats. Testing, which would be crucial, would require new test data.
Etc., etc.
We are therefore working on support (as an alternative) for a program-logic
based solution. Failure to consider the century in comparing or calculating
dates amounts to a bug which must be fixed. Likewise with special handling
of 00 or 99 (e.g., using them to mean null). Sorting on date is a special
case -- see below. Reports and screens would be looked at case by case for
readability. There could be bugs there as well, such as hard-coding 19xx or
zero-suppressing the year.
We have created a standard date routine using a sliding date window to
"infer" the century in performing calculations on 2-digit years. The older
routines were also upgraded, and in fact use the same code. The 00-99 range
is divided into a 25-year forward portion (projected dates), and a 75-year
backward portion (current year and 74 past years). The routine calculates a
"forward century" (add 25 to current 4-digit year, take 2 hi-order digits),
a "forward century endpoint" (same calculation, low order digits), and a
"backward century" (subtract 75 from the current century). A special
function makes these values available in open code, so programs can do
their own century inference (e.g., in comparing dates, which could happen
millions of time in a run). All date CALCULATIONS now hard-coded are to use
the new routine, and for ease of use we have provided a macro to generate
code to invoke it.
We recommend a conventional structure to hold the date with 4-digit year,
and provide an ISPF edit macro to generate it. We also provide a macro
which (assuming the conventions) generates code to move the date and infer
the century. In the example below, EFFECTIVE-DATE is a Julian date in a
user program and has a 2-digit year.
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 no longer a problem for this
approach. The major sort products -- DFSORT and SyncSort -- have year-2000
features that allow sorting, merging, and transformation of a wide variety
of two-digit-year dates using a fixed or sliding century window. See
Question 5.13 below for more information. -- RJS 12/97]
One nasty problem which would seem to require a file change would be a data
base key with a 2-digit year. And even with a general "program logic"
approach like the above, there would no doubt be other files which would
make sense to change, mandated changes (IRS, SSA, etc.), bridges to build
to/from outside apps, etc. Hope to see continued discussion on this issue.
-- Gene Lynd , Defense Logistics Agency
***
I appreciated your candor on 2-digit years and the real-life example of
where you have seen a need to live with them at times. It's almost
"politically incorrect" to support the logic-change approach, yet it is
certainly viable under certain circumstances.
The year in the key is the potential killer, here. My big concern is with
on-line screens which list records in key sequence. User-written on-line
sorts are a real pain, though possible. I am considering asking some of our
clients if the could live with the fact that 00mmdd dates would precede
99mmdd dates. It's a question worth asking. (A major client even suggested
the same!) If they could make the adaptations for certain applications, we
could save ourselves a LOT of time. (Not that we wouldn't have to add date-
manipulation routines to some programs, but it would be far fewer programs
needing conversion.) I HATE not giving our clients perfect, user-friendly
screens. But is it best for the enterprise to spend immense resources on
correcting something which people might be able to adapt to?
I'd like to see some further discussion/ideas on the date-in-key problem.
Some possible questions:
* Does everyone see it as insurmountable without changing to 4-digit years,
or are some finding other ways to deal with it?
* Within systems whose data is not required to span 100's of years (e.g. 7-
year statute of limitations type data), has anyone discovered a situation
where it is IMPOSSIBLE to deal with the problem via code changes?
* Same question as above but change "IMPOSSIBLE" to "unrealistic".
* Has anyone already performed a Y2K conversion on a system without
expanding a date-in-key? (We've had reports of people converting via code-
only changes, but we don't know if there were date-in-key cases involved.)
-- Brian Christenson
---------------------------------------------------------------------------
1.7 What products have been found to have, or not have, year-2000 problems?
See Section 2 for information about specific products.
See Question 6.3 for web sites that list the compliance status of products.
---------------------------------------------------------------------------
1.8 What are the special year 2000 problems about tape archives?
***
How many otherwise permanent archive tapes (or other data storage media)
will "expire" in 1999 or 1/1/2000 since "99" or "99/99/99" was used to
indicate permanent storage?
-- John L. Horton
***
Take a close look at the file creation data attached to MOST (all?) files.
Will backup/archival system be able to tell when a file was created? Is a
file with a creation date of 01/01/00 to be moved off to backup ...
possibly erased because it has not been used since 01/01/1900?
---------------------------------------------------------------------------
1.9 How can I tell how big the problem is in my company?
***
An exceedingly difficult question to answer with any degree of certainty.
Essential problem with saying "how big" is the fact that most software
consuming organizations (banks, insurance companies, mutual funds,
government organizations, etc.) simply don't have a clue how much software
they have. In fact most are entirely oblivious to the fact that they don't
know they don't know.
***
I think that for any company who has a multimillion dollar problem, there
will be a complex mix of solutions. After technical analysis (what IS
technically wrong) a functional analysis (what WILL lead to functional
defects) must be done. (BTW, this is something that has to be done by your
own staff, because Y2K-solution providers don't have a clue how your
processes work, nor did they include it in the contract). From this
functional analysis of your system portfolio, a migration strategy can be
determined. This will include a mix of the 3 solutions, depending on
business exposure and cost-effectiveness and a dozen of other factors. I
think Christenson (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 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 , 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 old records, you might need to deal with significantly different
calendar structures.
-- Bear Giles
***
After reading all of this, I think that it's very good that the worldwide
computer technology revolution began after the early 20th century. It must
be very tough for programs dealing with old dates! It kind of makes the
year 2000 problem seem easy by comparison.
---------------------------------------------------------------------------
1.12 Are there some hidden problems (i.e. date thresholds) related to date
storage that we have not yet thought of (or discussed)?
***
One thing I am interested in is date thresholds (doomsdays) that may not be
obvious at all. Our system, an IBM mainframe based system, carries a day
counter, so many days since the system was first plugged in, and that
counter is of a fixed size, and so somebody has already sat down to figure
when the field would overflow, and it turned out that we are going to do
fine until (I think it is) the year 2055 on that particular one. Most of us
will be dead then; stick the next generation, or the one after.
But the same system also contains another clock/calendar function called
the perpetual minute clock, which carries the number of minutes that have
elapsed since some fixed epoch in the past. That field is 32 bits in
length, and there, too, somebody had already figured out that the minute
and day when somebody will pay the piper. That one is also comfortably far
in the future.
But I thought about that one some more. It is a 32 bit field, sure, and is
good until far in the future. But I said WHAT IF ... what if somebody
manipulated that field using the mainframe address arithmetic in 24 bit
addressing mode? If anybody had happened to do that, the date threshold
would be when the perpetual minute clock overflowed from 24 bits to 25,
wouldn't it? Not when it overflowed out of 32. I did a calculation and
found that this clock will overflow to 25 bits sometime around December of
1997. Oops! That's not terribly far off. And it is just exactly the sort of
error a programmer could make unconsciously, could have made unconsciously
YEARS AGO, and the code would work fine for decades and never attract an
iota of attention.
More importantly, now that I have mentioned it, are there any analogous
hidden booby traps in your code that leap into your awareness, by virtue of
my having described this one?
Note: It seems to me I read somewhere or other that the PICK (?) operating
system had a day clock of this sort, and that doomsday had already struck
in May of this year. Is that correct?
I am going to have to go through our code libraries to see if I can find
any REAL examples.
-- Randall Thomas <76646.333@compuserve.com>
===========================================================================
2. PROBLEMS WITH SPECIFIC HARDWARE AND SOFTWARE
2.1 PC BIOS
(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
***
>From: "PAULYS%DOM10.DOPO1"
>I have looked into several hardware testing routines and found
>conflicting results and conflicting explanations for those results.
>Specifically, when running Ymark2000 (2000.exe) on a new P166 with a
>AMIBIOS 7/15/95, Ymark finds no flaw in the RTC, but DOSCHK identifies
>the RTC as non-compliant because it fails to convert to 2000 (stays at
>1900). Several sources have told me that the RTC will never roll over
>correctly and that I should ignore the failure of that test component.
>However, other sources say it is important because some programs look
>only at the RTC. Should I reject new hardware from vendors if the RTC
>doesn't roll over to 2000?
No. Although the RTC in a few machines will properly transition from 1999
to 2000, the very large majority of RTCs will not and will therefore fail
DOSCHK's RTC test. Most users can safely disregard that failure and need
only be concerned with the BIOS date, which is actually the CMOS RTC date
passed through the BIOS firmware. The BIOS has an opportunity to correct
the century on its way to an application or to the operating system; some
do, most do not.
Bob Stammer's DOSCHK tests the RTC date, the BIOS date and the DOS
operating system date. NSTL's YMark2000 does not test the RTC date; it
tests the BIOS date alone. The DOS real time date transition does not fail
on any machine, although it will reflect a BIOS date failure after
rebooting.
No common applications use the CMOS RTC date directly, contrary to the
advice given to you. Some applications use the BIOS date, though, and most
use the operating system date. Since the operating system date is
initialized from the BIOS date (at boot), it is the BIOS date that is the
important issue to be tested.
To be complete, the BIOS date needs to be tested at two occasions: in real
time and after a reboot. If the BIOS date transitions from 1999 to 2000 in
real time and then survives a reboot, it is compliant.
Incidentally, there have been no demonstrated failures of leap year
recognition - nor false recognition - in any machine. PC hardware does not
need to be tested for leap years.
Avoid the confusion by using Test2000.Exe, a free, concise and complete PC
hardware year 2000 date diagnostic; it is available on our web page,
http://www.RighTime.com. You may also read Test2000.Txt, Year2000.Txt,
RT2@PTTI.Txt and RighTime.Txt - all available on our web page - if you want
to become knowlegable about PC hardware date and time keeping issues.
-- Tom Becker , The RighTime Company, 22 Aug 1997
***
For AT-class (286 through Pentiums and clones) PCs running any DOS or
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 , The RighTime Company
***
Comments by Donald G. Davis about the preceding item,
with responses by Tom Becker, 14 Oct 1996
DD:
Are you saying that DOS *cannot* reset the CMOS century, or only that it
doesn't do so automatically?
TB:
The latter. DOS does, via BIOS functions, set the date - including the
century byte - anytime either the date or time are set at the OS level.
Although DOS will correctly increment its internal date from 1999 to 2000,
it makes no effort to assure that the CMOS RTC has also made the leap, nor
does the CMOS RTC hardware - as you know - have any provision to increment
the century; it becomes 1900 rather than 2000.
DD:
If the former, My PC (a 386-DX clone, AMI BIOS dated 9-15-89, running
MS-DOS 6.22) does behave differently. It agrees in that the CMOS does reset
itself to 1-1-1900 during a rollover from 12-31-1999, whether or not the
machine was turned off at the time. Subsequent behavior depends on whether
the machine was on or off when the rollover occurred; and if on, whether a
DOS date reset had occurred after the rollover.
If the computer was running during the rollover, DOS does increment its
century, and the DOS date remains correct, but is now 100 years later than
the CMOS date (and any BIOS readings from CMOS). This agrees with your
observation. If the computer is turned off at this stage, or if it was
already off during the rollover, the CMOS values of 1-1-1900 will still be
there when it is rebooted.
The CMOS century, and the BIOS RTC functions that depend on it, don't
change until DOS does something to alter them. This doesn't happen
automatically during the rollover, but can be triggered, for example, by
changing the time with the DOS TIME command (even by an arbitrary small
amount that does not directly affect the date).
In the case when the computer has run continuously during and since the
rollover, DOS evidently doesn't read CMOS before such an operation. It
simply writes the DOS date to CMOS, and since that date was correct, CMOS
is reset correctly. If this is done before turning the machine off, both
CMOS and DOS dates will be correct when it is next turned on.
TB:
If this date set is done _after_ the 1999-2000 transition but before
powering off, you are correct. Obviously I hope, if it is done before the
transition, it achieves nothing.
DD:
DOS does read CMOS (or make BIOS RTC calls?) during startup. In the case
when the computer was off during the rollover--or was turned off before DOS
was triggered to rewrite CMOS--DOS then finds the 1-1-1900 date it
considers invalid, and sets the DOS date to 1-4-1980 instead. At this
stage, DOS and BIOS date functions give entirely different readings, since
BIOS does not reject the CMOS 1900 date. The next DOS operation that writes
to the CMOS date bytes will then kick the 1-4-1980 date into CMOS. After
this CMOS update, DOS and CMOS/BIOS agree again, but both are wrong.
In this case, if the year is then reset explicitly to 2000 with the DOS
DATE command, the CMOS century byte *is* set to 20. This value will remain
until specifically changed, and both DOS and BIOS will give correct dates
when the machine is turned off and restarted thereafter. It seems that, at
least for this PC and DOS 6.22, the year 2000 causes a problem maintaining
the correct date solely because the century byte is the only date/time
value that is not automatically incremented by the CMOS hardware. The
problem's expression is complicated by the DOS mishandling of dates before
1980. Contrary to some suggestions by others in this FAQ, the BIOS routines
do not appear to be responsible; they only reflect the CMOS values. In any
case, the bad date is permanently rectified simply by entering the correct
date in DOS as soon as the year 2000 begins.
TB:
Your machine behaves exactly as I think I described the problem. I share
your rejection of the suggestion that the problem is somehow the fault of
the BIOS; it is not the BIOS, but rather the hardware design that
precipitates the error. In later machines the BIOS does play a part in
correcting the error, but only at boot when it can assume that 1900 really
should be 2000.
The summary is this: no machine - even a new "year 2000 compliant" machine
- will increment the CMOS RTC century to 2000 in real time; none. And,
excepting the Award v4.50G BIOS issue, all machines will accept a date set
beyond 2000 which will "stick" appropriately.
The problem is the transition.
***
I just spent some time playing with this myself. On my PC (a TOSHIBA
T4800), the date rolled over from 12/31/99 to 1/4/80! However, by using the
DOS command DATE, I was able to set my system date forward beyond 2000.
Once I had the date set forward, I was able to create new files which
appeared to have an appropriate creation date (3/15/00 and 2/10/30) for the
date that I had set my system date. FYI, for this part of the test, I used
the DIR command in DOS to look at the directory. I also turned the machine
off and rebooted to see if it retained the date properly; it rebooted with
the date properly set in the future. However when I tried to use WINDOWS
File Manager to look at the files in the directory, WINDOWS didn't show the
date properly (it showed 3/15/%0 and 2/10/.0)!! I'm not sure whether this
is just a display problem or not because the "sort by date" feature of File
Manager placed them correctly.
I also ran some similar tests on another machine (DELL 425s/L). On this
machine, the date appeared to roll over properly but I encountered the same
problems with File Manager for displaying the file information.
Sooooo, I guess the problem might be ROM BIOS-related. But different BIOS's
appear to handle the problem differently. Just what we need in large shop
(11,000+ PCs)!
-- Taylor, Ralph G
[See Question 2.8 concerning File Manager. -- RJS 12/97]
***
When I first became aware of the year 2000 problem from Peter's CW article,
I tried a test on my Intel-based PCs. I set the date and time as 11:59:30
PM on Dec. 31, 1999 and let the clock run. The result was uneventful or so
I thought. The clock in Windows jumped to 12:00 AM on 1/1/00 so I thought
that there was no problem. I failed to change the date and time and a few
days later noticed that I now had files dated in 1984 that had just been
created! When I investigated, I found that the date looked OK, but the ROM
chip was not really handling the date correctly. As I understand, the ROM
BIOS is not capable of handling anything after 1999.
-- Dr. Pat McKeown
***
I have tested my own three PC's. Two of them make failures (clones) already
mentioned bios (PHE and Award).
And my 10 year old PS/2 model 60 with ref. diskette is 100% performing on
all the test's (LEAP, future , and even has YYYY/MM/DD.
In the early day's everyone told me that this PC was to expensive. This is
the machine I use for my Telebanking ...
-- Hans Goossens
***
The following was obtained from the Award Software web site on March 18,
1998. It is an excerpt from http://www.award.com/tech/biosfaqs.htm.
AwardBIOS compliance with Year 2000 depends on the release date:
If your AwardBIOS was released before 26 April 1994, you only need to reset
your system clock once. Turn the system off before midnight on 31 December
1999. Turn it back on some time after midnight, on 1 January 2000. Then set
the system date correctly in Setup.
If your AwardBIOS was released between 26 April 1994 and 31 May 1995, you
need to obtain an AwardBIOS update [see
http://www.award.com/tech/upgrade.htm], or reset your system clock every
day!
If your AwardBIOS was released after 31 May 1995, its calendar
automatically rolls from 1999 to 2000 at midnight. You don't need to do
anything, whether the system is turned on or off at midnight. Just leave
the system alone.
(c) 1998 Award Software International Inc. All rights reserved.
Updated 20 February 1998
***
And moving onto those last two questions ...
(a) That's easy ... the BIOS doesn't support Y2000 properly. It may just
not handle the 1999-2000 rollover, you'd have to try a few Y2000 midnights
to see what happens (see note below).
(b) DOS didn't exist before 1980 so the BIOS/DOS never needed to support
times prior to 1980. Why Jan 4th & not Jan 1st?
NOTE: If you mentioned that you were using Win95. Remember this is beta
code and has 'code fade' built into it. Had your BIOS not been defective,
you would have been re-installing Win95. Once Win95 beta has been booted
beyond the programmed date, the system will shutdown after giving you a
brief message. Resetting the date to a current date doesn't fix this.
-- Adrian Clark with Sears Canada, Technical Development
***
question b:
Since the person writing BIOS/DOS knew that the "current system date" could
NEVER be before the time that the system (i.e. BIOS/DOS) was invented
(created), then that person must have inserted a piece of code logic that
said something like ... if the "current system date" is ever earlier than
1/4/1980, then set the "current system date" to equal 1/4/1980. It is
evident that the person (or persons) considered 1/4/1980 as the "creation
date" for BIOS/DOS (or something related to it), and that THIS was the date
that the "current system date" could NEVER be earlier than.
It is also clear that this piece of code logic is only activated under
certain conditions, and that there are times when this code segment is
never reached. Additional analysis will likely be done on this subject, as
forces are brought forth to repair it.
It is curious that this choice (setting the "current system date" to equal
the "system creation date") was selected for this obvious error condition.
Many other software action choices COULD have been selected instead of
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)
***
Here is a manual test for personal computers, suggested by Geoff May
of Network Business Services, 01 November, 1995.
Caution: some software with date checking (for example Windows 95 betas)
may reset and not allow access after setting dates into the future.
[It is strongly recommended that you boot from a floppy before starting
these tests. Do not remove the floppy until after you have reset the date
and time to the present. -- RJS 3/98]
Disconnect the computer from any network or other system that might reset
the date as it boots or connects.
RTC (Real Time Clock) Rollover Test
- Set the date to 31 December 1999.
- Set the time to 23:58 (11:58 p.m.).
- Check that the date and time have been set.
- Switch off the computer.
- Wait five (5) minutes.
- Switch the computer back on.
- Check the date and time. It should be a few minutes after midnight on the
1st of January 2000.
RTC 2000 Set Test
- Set the date to 01 January 2000.
- Check that the date has been set.
- Switch off the computer.
- Wait a (1) minute.
- Switch the computer back on.
- Check the date. It should be the 1st of January 2000.
DON'T FORGET - Reset your PC to the correct date and time!
Many Personal Computers fail either both or the first of these tests and
reset themselves to 04 January 1980, or some other ancient date, whenever
they reboot, if the CMOS RTC (Real Time CLock) says the year is 00.
***
Check the web page http://www.wa.gov/dis/2000/survey/dt_hard for the index
to PC manufacturer's statements on y2k compliance. Statements from Dell,
Gateway, Compaq, etc., are there.
-- George W. Ball
Associate Professor of Computer Science, Alfred University
5 Sep 1996
---------------------------------------------------------------------------
2.2 UNIX, Linux, and/or C/C++
***
UNIX time structure ("struct tm"):
UNIX/ANSI C also defines a "struct tm" structure for broken-out time
fields. The year is offset from 1900; some libraries have improperly
handled years outside of the range [00..99].
Also, _many_ application programs have problems with this. Some accept
"100" to indicate 2000. Some will print back dates like "01-01-100"
(instead of "01-01-00"). Others will complain about your ignorance -- years
should be two digits only.
Other than that, this time structure has no meaningful "important" dates.
Who cares if the year will roll over in 2 billion years? :-)
-- Bear Giles
***
>I've been plowing through a large, undocumented system trying to find
>all the occurences of dates I can. The system does some odd things in
>Y2K. Some dates come up as 01/02/100 on the screen when the record is
>created, but are stored as 01/02/10.
Your application is using tm_year to retrieve the current year. Just so
happens that tm_year starts in 1900, where 2000 is year 100. Your app is
probably using a sprintf into a char[2] field. Yes, you're are getting
corrupted memory on the byte following that char[2]. Need I say more?
The C problem has been overlooked. . . . Oh well, if Y2K was that easy
(like so many "experts" say), we wouldn't be scared to death of what may
occur 01/01/2000.
-- R. Gama , President, Xpress Software, Inc, 8 Jan
1997
***
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
***
Unix keeps the date and time as the number of seconds that have elapsed
since 0000 hours UTC, January 1, 1970. It keeps this count in a 32-bit
signed integer. The count will overflow on January 19, 2038, when the
number of seconds reaches 2,147,483,647, the maximum number that can be
represented in a 32-bit signed integer. All versions of C and C++ use this
same format for certain library functions.
-- Robert J. Sandler
***
I would rank this [rollover in 2038] as being potentially more serious than
Y2K. UNIX is heavily embedded in our infrastructure, and this format is now
standard for most C/C++ programs. That means it is extremely widespread.
-- Bear Giles and Roger Gates
***
The standard C library from a major vendor (Sun?) had an interesting
failure mode. I specified a date in the 21st century and asked it to give
me the ASCII equivalent.
I expected: 07-04-12
What I got was: 07-04-;2
(or something to that effect.)
Conjecture: the library code was "optimized" and year-to-string fields were
handled as:
*s++ = '0' + tm->tm_year / 10;
*s++ = '0' + tm->tm_year % 10;
where "tm->tm_year" is part of one of the standard Unix time formats. The
"year" information is an offset from 1900.
This works fine provided the "tm_year" field is in the range 00..99, but
blows up on years outside of this range.
I reported this to our systems people; later tests verified that the
software had been fixed.
There have been others, but as I recall they were generally local code, not
system-level libraries. Or previously reported misinformation -- I've had
people become extremely hostile to claims that 2000 is a leap year.
-- Bear Giles
***
So, Y2K doesn't apply to Linux? Have a gander:
# date -s "Jan 1 00:00:00 1997"
Wed Jan 1 00:00:00 AST 1997
# date -s "Jan 1 00:00:00 2000"
date: invalid date `Jan 1 00:00:00 2000'
-- William Burrow , Fredericton Area Network, New
Brunswick, Canada, 1 Jan 1997
It is indeed a big problem in Linux, and all Unix systems. The reason is
rooted the standard time functions which use the following structure
defined in /usr/include/time.h (this is quoted from the ctime(3) man page):
struct tm
{
int tm_sec; /* seconds */
int tm_min; /* minutes */
int tm_hour; /* hours */
int tm_mday; /* day of the month */
int tm_mon; /* month */
int tm_year; /* year */
int tm_wday; /* day of the week */
int tm_yday; /* day in the year */
int tm_isdst; /* daylight saving time */
};
...
tm_year The number of years since 1900.
The declaration of tm_year as a type int is large enough work far into the
future, but the definition certainly encourages applications programmers to
take the easy route and hard code all dates for the 20th century.
Hence this problem is not specific to Cobol applications at all. . . . Wall
street may suffer from Cobol applications and be very able to whine in the
press about it, but the implication that payroll applications which might
malfunction is the biggest problem coming, could be a very costly red
hering if all attention is then diverted from other problems. . . .
-- Floyd L. Davidson , 1 Jan 1997
---------------------------------------------------------------------------
2.3 VMS
***
I have just spoken to Digital Equipment in Atlanta regarding VMS. They said
that VMS is YEAR 2000 Compliant.
-- Dick Murray
***
I . . . set the time to 10:50 12/31/1999 on one of our VAXen and let it go.
VMS ran fine (it's been running about a week now and is up to 1/6/2000).
-- Allan Van Ness
***
The Mac and the VAX/VMS systems were the two areas in our analysis with no
year 2000 problems.
-- Steve Vogel
***
VMS uses a bizarre time format which is microseconds(?) since JD 2400000
[see question 4.5]. It allocates 64 bits of information. Because 64 bits is
so large, even with microsecond resolution this timer won't overflow for
another 584,000-odd years.
-- Bear Giles
Actually it's tenths of microseconds, not whole microseconds, if I recall
correctly, which pushes our overflow back to a mere 58,000 years from now.
Better get to work on it right away.....
-- Craig Goodrich , 28 Apr 1998
---------------------------------------------------------------------------
2.4 Apple Macintosh
Here is an official Apple statement, contributed by Brian Bechtel
of Apple's DTS group.
There has been much speculation recently about various computers and their
handling of the year 2000. The MacOS operating system and Apple Macintosh
computers do not have problems with the year 2000.
All MacOS operating system date and time utilities have correctly handled
the year 2000 since the introduction of the Macintosh. The original date
and time utilities (introduced with the original Macintosh 128K in 1984)
used a long word to store seconds, starting at January 1, 1904. Starting
with a long word of seconds since January 1, 1904 means that dates run out
at 6:28:15 a.m. on February 6, 2040. The current date and time utilities
documented in Inside Macintosh:Operating System Utilities use a 64 bit
signed value, which covers dates from 30081 B.C. to 29940 A.D. For further
reference, see the reference volume Inside Macintosh:Operating System
Utilities, or its predecessor, Inside Macintosh Volume II.
Gregorian calendar support is included with all localized versions of the
MacOS operating system. In addition, the Arabic version of the MacOS
operating system supports both the Arabic astronomical lunar calendar and
the Arabic civil lunar calendar. The Hebrew version of the MacOS operating
system supports the Jewish calendar. The Persian version of the MacOS
operating system supports the Iranian national calendar.
Virtually all software available for the Macintosh will not have any issues
with the year 2000, as well. The only problems I have seen were with
developers who were using their own date and time utility packages, rather
than using the toolbox calls supplied by the MacOS operating system. If
you, the developer, are using your own date and time utilities, you should
test carefully to ensure that you handle all of the subtle issues of date
and time conversion.
***
As an aside to the statement above, the Date & Time control panel
constrains user entry to dates between January 1, 1920 and December 31,
2019. This means you can't set your Macintosh clock to a date past 2019
without doing computer programming. This feature was added starting with
System 6.0.4. This is a implementation decision, not a limitation of the
MacOS toolbox. I'm investigating why this control panel was implemented
this way.
-- Brian Bechtel
***
Peter [de Jager] is writing an article about the impact of the Year 2000 on
Macs. He has been besieged by hundreds of Mac owners stating that the Mac
is "Y2K Bug Free". These letters demonstrate a lack of understanding of the
year 2000 problem. It affects software as well as hardware. . . . We use
Eudora which sorts 00 as it should and therefore causes a problem (00 less
than 99). We use Act for the Mac which time stamps entries with a two digit
year and is therefore another example of the Year 2000 bug. We have one or
two other programs with the same problem.
-- Antoinette de Jager, 27 Jan 1997
---------------------------------------------------------------------------
2.5 Novell Netware
***
On August 19th, 1996, Novell released patches to the NetWare 3.12 and 4.10
operating systems to fix NetWare's handling of the year 2000 and beyond.
The patches are in:
ftp://ftp.novell.com/pub/updates/nwos/nw312/312pt9.exe
ftp://ftp.novell.com/pub/updates/nwos/nw410/410pt6.exe
Later versions of of the 312ptx and 410ptx files will also contain the
patches, as will the issued version of NW4.11. i.e. prior versions didn't.
-- Phil Randal
Environmental Services Dept, Hereford and Worcester County Council
***
See
http://www.novell.com/p2000/product.html
last updated 13 March 1998. Novell lists the testing status of their entire
product line. In addition, the page at
http://www.novell.com/p2000/patches.html
lists all the test results and links to downloads. Note that Novell not
only lists the patches available, but also lists the problems with each
associated application. A superior piece of information necessary in doing
risk assessment and prioritizing implementation of upgrades.
Perhaps also of note is the contrast between this information and
information on their site 6-12 months ago. When I searched the site for
GroupWise year 2000 compliance info last May, all I found was a
knowledgebase article that stated "Because of the way dates are calculated
in GroupWise, the year 2000 will not cause problems", and goes on to
describe how GroupWise stores dates in a 4 byte format (document 2910115
last modified 04FEB1997). Per their latest information, GroupWise is in
testing, and results are due Q1 1998; some older versions have been
retired.
-- Sid Faber , 20 Mar 1998
***
Our PCs get the current date whenever we log onto the LAN (Novell 3.12). If
the PC gets the current date from the file server, is is safe to say that
as long as the file server and the NOS are Year 2000 compliant, the PC Bios
issue is not a factor for the PCs that are connected to the LAN??
-- Peter Genadry , NationsBank, 25 Oct 1996
Sorry, but I think you're wrong.
Some apps take their feed from the BIOS, some from the OS and I'm sure that
some PC apps wil still have problems. Even the BIOS may cause problems as
the on-board BIOS is loaded before the network time stamp
Derek - can you comment further?
-- Karl W. Feilder 6 Nov 1996
Karl, you are right in surmising that it depends on how an application was
written as to where it sources its time from. Most desktop applications
today however source their time directly from the workstation clock, whilst
server based applications would source their time stamps etc from the
relevant application / file server.
Having said that, the Novell client, by default, updates the workstation
clock from the server time, i.e. it synchronises the time of the two. This
takes place in one of three ways....
1) On login
2) On attaching to a server
3) On demand via a purpose-built utility, SYSTIME
As with most Novell functions these can be turned off through issuing the
relevant switch as illustrated below. To be entirely sure, workstation
configurations need to be checked to ensure that these settings are not in
effect to disable time synchronisation with the server.
By default, workstation time will be updated to the server time the moment
it gets attached to server. During attachement to the server following line
in the net.cfg will stop updating workstation time.
SET STATION TIME=OFF
During login to the server following line in login script will stop
updating workstation time.
SET_TIME OFF
In the case of the Client32 for Windows95, go into Properties, Advanced
Settings, and "Set Station Time" to Off. This keeps the workstation from
synchronizing with the server that it initially attaches to.
In the case of OS/2 workstations some confusion arises from the difference
between a DOS/Windows workstation using the VLMs and a OS/2 workstation
using the OS/2 requester. A DOS workstation will by default synchronize its
time to the server to which it attaches when VLM.EXE is run. This can be
disabled by the NET.CFG parameter "SET STATION TIME = OFF". When the
DOS/Windows workstation runs LOGIN.EXE the time will be synchronized with
the target server by the LOGIN executable unless "SET_TIME OFF" is included
the login script.
OS/2 workstaitons will not attempt to synchronize the local time until
login. Thus there is no NET.CFG parameter to disable this synchronization.
Similar to the DOS/Windows workstation, time synchronization during the
login process can be disabled by including "SET_TIME OFF" in the login
script. Because of the lack of a NET.CFG parameter for the OS/2 requester
it has been widely asumed that it is impossible to prevent an OS/2 client
from synchronizing with the NetWare server. This is not the case as the
other two alternatives mentioned above are still available.
Finally, I must state quite clearly that even though patches are available
to ensure that the Novell servers are Year2000 compliant w.r.t. the date
and time that they issue to a workstation, this does NOT mean that the
problem disappears.
Year2000 issues are far deeper than simply having a correct workstation
date and time issued to your application. The majority of the issues stem
from the fact that most applications are internally unable to corectly
represent and deal with dates after 31/12/99. Further, we humans have often
taken shortcuts in our own input of date related items such that the
applications - even if retrofixed - would still be unable to discern the
correct meaning of some of our inputted data.
Bottom line, the reliability of the NOS and the integrity of its underlying
file system are paramount as we move closer towards Year2000 - and that is
what has been addressed by Novell, however the NOS & even workstation time
are barely more than foundation pieces in the overall picture. Important
pieces yes, but rather insignificant at the end of the day. The major
problems are in the applications, whether custom written or shrink-wrapped.
Best regards, and I hope that this information helps...
-- Derek Morgan , Special Projects Manager, Novell
South Africa, 08 Nov 1996
---------------------------------------------------------------------------
2.6 IBM Mainframe MVS, ESA, and OS/390
***
Before you go IPLing LPARs or a spare MVS machine, here's IBM's recent
assessment for S/390 MVS year 2000 readiness:
- ETR, 390 processors, MVS Timer facilities - CLEAN
- Basic Control Program - CLEAN INTERNALLY
- Key subsystems - CLEAN or SUPPORT PLANNED
- LANGUAGES - CLEAN (latest releases)
- LE/370 - CLEAN
- Major IBM products - INITIAL ASSESSMENT APPEARS POSITIVE (that's nice!)
- 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.
***
For the following IBM platform: MVS/ESA 4.3:
In MVS the expiration date is a flag which simply denotes the file or
dataset's "delete status." It does *not* mean that MVS will delete the file
or dataset for you when the expiration date has been reached. In other
words, if you try to delete a file or dataset before it's expiration date
has been reached MVS will prompt you with a message like: "HEY, this [file,
or dataset] hasn't expired yet. Are you sure you want to delete it?" And
you say yes and delete it or no and don't. Simple. That was good news for
me; prior to this discovery I ran a report on my DASD farm and discovered
over 600 files and datasets with expiration dates of 99365.
The EXPDT keyword of the TSO Allocate command and JCL DD parameter now
accept YYDDD *and/or* YYYY/DDD as valid expiration dates (formats). This
means you can set *real* Y2K expiration dates. (Ain't MVS grand?)
Furthermore, the EXPDT designations 99365, 99366, and 99999 continue to
have the special meaning of "don't delete this dataset." Except testing
*for that* is a little tougher (have to wait until 31DEC99). I guess if you
*really* want a dataset to expire at the end of this century you will
simply have to set it a day earlier or a day late.
---------------------------------------------------------------------------
2.7 IBM Mainframe VM
***
Re VM and other IBM software: IBM has publicly stated they are reviewing
all their products for Y2K problems, and will publish a document later this
year (1995) giving the releases of each which will be "year 2000 ready."
-- Gene Lynd , Defense Logistics Agency
We are currently assessing the changes that are necessary in the VM/ESA
operating system for the year 2000. You can expect to hear more about year
2000 support for VM, as well as more from an IBM-wide perspective, in the
not-too-distant future. If you have technical questions about VM's support
for the year 2000, you can either post them here [on the Year 2000 mailing
list] or send them directly to me via e-mail and I will answer them as
best, and as quickly as I can.
-- John Franciscovich , VM Development, IBM
Corporation (Endicott, NY)
---------------------------------------------------------------------------
2.8 Windows 3.1
Microsoft has posted patches on its web site for the Windows 3.x and
Windows 95 File Managers to correct the date display problems for files
with year 2000 and later dates. The NT 4.0 version of File Manager does not
exhibit the problem.
They can be downloaded from:
W95FILUP.EXE: Updated File Manager for Windows 95:
http://premium.microsoft.com/support/downloads/dp2902.asp
ftp://ftp.microsoft.com/Softlib/MSLFILES/W95FILUP.EXE
W31FILUP.EXE: Updated File Manager for Windows 3.1:
http://premium.microsoft.com/support/downloads/dp2903.asp
ftp://ftp.microsoft.com/Softlib/MSLFILES/W31FILUP.EXE
WFWFILUP.EXE: Updated File Manager for Windows for Workgroups 3.11:
http://premium.microsoft.com/support/downloads/dp2904.asp
ftp://ftp.microsoft.com/Softlib/MSLFILES/WFWFILUP.EXE
The files are self-extracting and include a new WINFILE.EXE and a TXT file
from Microsoft explaining things. Files are dated either 12/02/97 or
12/03/97.
-- Information provided by:
-- John Carter
-- Chuck Dennison <72165.1005@compuserve.com>
-- David A. Smith
-- Gary L. Smith
-- Arnold Trembley
-- B. Young
-- December, 1997
---------------------------------------------------------------------------
2.9 Windows 95
See Question 2.8 above concerning File Manager.
***
Of course many will be interested in MS-Windows 95. This package seems (at
first glance) to be okay, however it may have a problem 100 years later
(answers provided by the double Mike team).
***
I've tested Windows 95 with dates past the year 2000, and here's what I've
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
***
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
---------------------------------------------------------------------------
2.10 Excel
Also see question 2.15.
***
The other day, I declared an EXCEL 5 cell as a date cell, then typed
1/1/19
It said January 1st, 2019.
But, when entering
1/1/20
it said January 1st, 1920
Lotsa problems at that time!
(but, of course, EXCEL 5 will be EXCEL n+1...)
-- Didier Morandi , 23 Dec 1996
***
When a date containing a 2-digit year is entered in a cell whose format is
declared as d/m/yy, Excel 5 defaults it to being in the range 1/1/1920
through 31/12/2019. When a four-digit year is typed, e.g. 1/1/1900 or
1/1/2020, the ambiguity is removed and the 4-digit year entered is used. In
either case, the full 4-digit year is displayed in the entry box under the
toolbar.
Curious about the data interchange implications, I ran up a CSV file
outside Excel containing a series of 2- and 4-digit dates inside and
outside this range, then opened the file in Excel. The 2-digit-year data
was interpreted according to the same defaults as data entered from screen,
and 4-digit years were imported correctly.
And yes, Excel 5 does recognise the existence of Feb 29, 2000.
-- James Tinsley , 24 Dec 1996
***
All versions of Excel treat 1900 as a leap year to maintain compatibility
with Lotus 1-2-3, which has contained that error since its earliest
releases, when it was the de facto standard to which all other spreadsheets
had to conform. This is a known, documented, and intentional anomaly in
Excel.
-- Robert J. Sandler
***
See the Y2K Spreadsheet FAQ at http://www.iol.ie/sysmod/y2ksprds.htm
-- Patrick O'Beirne , Systems Modelling Ltd, Ireland,
25 Oct 1997
---------------------------------------------------------------------------
2.11 Paradox
***
I've noticed a date problem with Paradox for Windows software. It treats
2000 as 1900 during a sort of the table. Even when the date is entered as
2000, it is treated as 00.
-- David Silver
---------------------------------------------------------------------------
2.12 Quicken
***
I have Quicken version 3 (IBM PC) running on MS-DOS 6. I found that when I
set the date to 01-01-2000 (as people reading this list already know,
letting it wrap from 12-31-1999 results in 01-04-1980), Quicken interprets
this as 1/1/1901. I suppose one obvious question is, why not 1900? But a
more important question (to me anyway) is whether newer versions of Quicken
have fixed this problems. (I REALLY like to post-date checks)
Also, I have found that Quicken 3 does not allow me to enter a date of
01/01/00, nor does it accept YYYY on checks. One other interesting quirk:
When I first start Quicken and open the check register, the year is listed
as 2000. But as soon as I hit the Enter key, it reverts (?) to 1901. Clever
programming, this.
-- THHACKETT@vaxsar.vassar.edu
---------------------------------------------------------------------------
2.13 Ada
***
The ADA-language "relate" database exhibited a very strange Y2K error mode.
(I tested this in the late _80's_ due to a scheduled project lifetime of
15+ years, and was told that it was too early to worry about this problem
even though military contractors tend to buy a product and then sit on it!)
Dates 01-Jan-00 through 29-Feb-00 worked fine. (As I recall it did properly
handle the leap year).
Dates 01-Mar-00 through 28-Feb-01 were screwed up. The day-of-week was
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
---------------------------------------------------------------------------
2.14 Sorting
See question 5.13.
---------------------------------------------------------------------------
2.15 Microsoft Products
See question 6.3 for information about Microsoft's Year 2000 web site.
***
This is from the MS Technet CD:
Microsoft's Products
The table below shows Microsoft products and the date limit (life
expectancy) of the date formats used for each one. Unless noted,
Microsoft's products rely on the system supplied date formats.
Microsoft product date limits and formats
Product Name / Date Limit / Date Format
Microsoft Access 95 (assumed date) / 1999 / assumed "yy" dates
Microsoft Access 95 (explicit date) / 9999 / long dates ("yyyy")
Microsoft Access (next major version) / 2029 / assumed "yy" dates
Microsoft Excel 95 / 2019 / assumed "yy" dates
Microsoft Excel 95 / 2078 / long dates
Microsoft Excel (next major version) / 2029 / assumed "yy" dates
Microsoft Excel (next major version) / 9999 / long dates
Microsoft Project 95 (and previous versions) / 2049 / 32 bits
Microsoft SQL Server / 9999 / "datetime"
MS-DOS file system (FAT16) / 2108 / 16 bits
Visual C++ (4.x) runtime library / 2036 / 32 bits
Visual FoxPro / 9999 / long dates
Windows 3.x file system (FAT16) / 2108 / 16 bits
Windows 95 file system (FAT16) / 2108 / 16 bits
Windows 95 file system (FAT32) / 2108 / 32 bits
Windows 95 runtime library (WIN32) / 2099 / 16 bits
Windows for Workgroups (FAT16) / 2108 / 16 bits
Windows NT file system (FAT16) / 2108 / 16 bits
Windows NT file system (NTFS) / future centuries / 64 bits
Windows NT runtime library (WIN32) / 2099 / 16 bits
-- Patrick O'Beirne , Systems Modelling Ltd, Ireland,
26 Mar 1997
***
Reproduced by kind permission of the poster On Compuserve:
For what it's worth, here's a workup on what I found during test:
Access 2.0:
"yy" dates are assumed to be in the 20th century (even if the PC clock
shows the 21st century).
"yyyy" dates work as entered.
Access 95 and 97:
If oleaut32.dll is the original file that ships with Access 95:
"yy" dates are assumed to be in the 20th century.
"yyyy" dates work as entered.
Access 95 and 97:
If oleaut32.dll is version 2.20.40xx (installed from IE3, O97, or other
newer programs) then:
"yy" dates from 30-99 considered the 20th century.
"yy" dates from 00-29 21st century.
"yyyy" years work as entered.
-- Patrick O'Beirne , Systems Modelling Ltd, Ireland,
09 Feb 1997
---------------------------------------------------------------------------
2.16 Windows NT
***
Here are the results from our independant testing of the Microsoft NT
Operating system running on a variety of y2k non-compliant hardware.
We reviewed Microsofts statements published on their web site and contacted
Microsoft directly before deciding to perform an independent test.
We believe that NT will resolve a significant problem we have with non
compliant hardware infrastructure i.e. if the workstations are not replaced
as part of a normal asset refresh between now and 2000 then the NT
operating system will significantly reduce the risk to any devices left in
service.
The objectives were:
to confirm statement from Microsoft that MS Windows NT Versions 4.0 and
3.51 with service pack 5 can automatically detect and correct the problem
on non-year 2000 compliant PC's;
to investigate how MS Windows 95 handle dates during the change in the
century on non-year 2000 compliant PC.
Scope of testing
Tests were performed on PC's which are not year 2000 compliant running on
MS Windows NT (Versions 4.0 and 3.51) and MS Windows 95. The testing was
performed to determine whether the operating systems detect and correct the
date during the change over to the next century.
The tests were performed on a variety of different machines running MS
Windows NT version 3.51 with service pack 5.0 and version 4.0.
The time synchronisation test was performed on the workstation connected to
a Primary Domain Controller running MS Windows NT Server 4.0.
Summary of testing results
The test results showed that MS Windows NT (both versions) did detect and
correct the problem of crossing over to the next century independantly of
the non compliant hardware.
MS Windows 95 does not detect or correct the problem. If a workstation
running on MS Windows 95 is connected to a MS Window NT server with
synchronisation setup, ie. synchronisation is initiated during logon, the
workstation shows the correct date and time.
Details of testing performed
MS Windows NT 4.0
The main testings performed was as follows:
change over of the date when PC's are switch off during the change of the
century
change over of the date when PC's remains switched on during the change of
the century
impact to the dates when dates were put back after the change to year 2000
check the impact of DOS dates to Windows NT
Other internal testing specific to our project
The testing were performed for both the NTFS and FAT file system.
A MS DOS application that does direct date calls was also executed running
under MS Windows NT 4.0 to confirm that the date the application used was
the date of the system.
MS Windows NT 3.51 (With Service Pack 5)
The test performed for MS Windows NT 4.0 were also performed for MS Windows
NT 3.51 with Service Pack 5 applied. MS Windows NT 3.51 without Service
Pack 5 is not year 2000 compliant.
MS Windows 95
Testings performed for MS Windows 95 were as follows:
change over of the date when PC's are switch off during the change of the
century
change over of the date when PC's remains switched on during the change of
the century
check the impact of DOS dates to Windows 95
We also tested the synchronising of the date of the MS Windows 95
workstation to the MS Windows NT 4.0 Server. A batch file was created to
execute during logon to synchronise the time of the workstation to the MS
Windows NT 4.0 server.
-- Gary Blythe , Blythe Consulting, 23 Dec 1997
---------------------------------------------------------------------------
2.17 Windows 98
***
This is a statement from John Gray at Microsoft regarding Year 2000
compliance of the Windows 98 operating system.
1) Bad BIOSes - BIOSes don't store a 4 digit year, they store a 2 byte
"century" byte, and then the 2 digit Year, Month, Day, Time in another
separate area that they increment. So how does a BIOS have to handle the
century byte? If the last time it was booted was in the late 1990s (say
1999) and the current boot says "1900", then by golly, it's time to
increment the century byte. But, a lot of bioses are missing that code.
So... Windows 98 and Windows NT 5 will do this for the user, automatically.
That's right, those people with bad BIOSes don't need to do anything but
install Windows 98, and on Jan 1, 2000, that's what their system date will
say because the OS will go out and bump the century byte automatically.
2) Display - File Manager will display a screwy date (19;0) instead of 2000
for Windows 3.1, WFW, and Windows 95. Windows 98 fixes this if you still
use Fileman. [However, see question 2.8. -- RJS]
3) MS-DOS 2-digit date entry: On Windows 95, if you enter the date command
at the DOS prompt, and enter 1-1-00 you will get 1900. With Windows 98, you
will get 2000. (The break point for system date assuming 19 vs 20 is
1980/2079. That is b/c that's the year MS-DOS was released). You can always
enter the full 4-digit year in any OS to set it.
4) 4 digit year displays - you can configure Explorer to show 4 digit years
in the Regional settings display tab, Date. (Win95 or 98). But what about
MS-DOS? You can now use the /4 flag to show 4-digit years at an MS-DOS
prompt.
5) Application Date Rollover - post Beta 3, you will see a small addition
to the Regional Settings, Date tab, to allow a system-wide setting for
applications to use for the assumed 2-digit year rollover date (default is
2029). So future apps will be able to use a common setting for data entry.
6) The system has undergone extensive testing (backup, explorer, system
date/time CPL, etc.) to make sure that there are no y2K problems.
-- David Kipping , January 16, 1998
---------------------------------------------------------------------------
2.18 PKZIP
The following was obtained from the PKWARE web site on February 3, 1998.
Year 2000 Compliance for PKWARE Products
Because of growing concerns regarding the impact of the year 2000 on
computer systems running PKWARE's products, we have developed this document
to outline the current and planned future status for all of PKWARE's
products.
The following product(s) have no date related functionality:
PKWARE DATA COMPRESSION LIBRARY (all versions, all platforms)
The following product(s) have no known issues dealing with date-related
functions beyond the year 2000. Date related activities, such as the
sorting and displaying of dates, are handled correctly for all valid dates
within the DOS FAT file structure (1980-2100).
PKZIP for DOS and OS/2 (versions before 1.10)
PKZIP for OS/2 (version 2.50 and later)
PKUNZIP for DOS and OS/2 (all versions)
PKZIP for OpenVMS (all versions)
PKARC/PKXARC (all versions)
PKPAK/PKUNPAK (all versions)
PKLITE (all versions)
PKZFIND/PKZOOM (all versions)
PKZIPFIX and PKSFX (all versions)
The following product(s) have minor year 2000 date related limitations, as
described below. However, these limitations will not affect the actual
files or data stored by PKWARE software. No data conversions will be needed
on any existing .ZIP files.
PKZIP for Windows (versions 2.01 - 2.50)
- Selecting files by date in a .ZIP file will only accept a range from 1980
through 2009.
- Viewing files in a .ZIP file will only display dates in the form
mm/dd/yy.
- Anticipated solution:
Dates entered as a 2 digit value will be interpreted as being in a date
range from 1980 through 2079. Dates entered as a 4 digit value will
accommodate dates that span more than 100 years. The method of correction
will consist of "expanded date fields".
- Scheduled correction date:
PKZIP for Windows Version 2.60 (released December 19, 1997)
PKZIP for DOS (versions 1.10 & 2.04g) and PKZIP for OS/2 (versions 1.09 -
1.11)
- Selecting files to be added to a .ZIP file by date will only accept a
range from 1980 through 1999 (-t and -T options).
- Viewing files in a .ZIP file using the default will display dates in the
form mm/dd/yy. The four digit year can be viewed using the option to view
technical information (-vt).
- Anticipated solution:
Dates entered as a 2 digit value will be interpreted as being in a date
range from 1980 through 2079. Dates entered as a 4 digit value will
accommodate dates that span more than 100 years. The method of correction
will consist of "expanded date fields".
- Scheduled correction date:
Next release of PKZIP for DOS (no release date available)
PKZIP for OS/2, Version 2.50 (released June 2, 1997)
PKZMENU (all versions)
- Selecting files to be extracted by date will only accept a range from
1980 through 1999. File dates stored in a .ZIP file, will only be displayed
correctly from 1980 through 1999.
- Anticipated solution:
PKZMENU is a discontinued product. No modifications are anticipated.
PKWARE, the PKWARE logo, PKZIP, PKLITE, PKLITE Professional and the PKWARE
Data Compression Library are registered trademarks of PKWARE, Inc. PKZFIND
and PKZOOM are trademarks of PKWARE, Inc. Trademarks of other companies
mentioned appear for identification purposes only and are the property of
their respective companies.
Copyright (c) 1998 PKWARE, Inc. All Rights Reserved
---------------------------------------------------------------------------
2.19 SAS
***
Just a comment on SAS. Watch out for the JULDATE and DATEJUL functions,
they are NOT yr2000 complient.
-- Harold P Zbiegien , 21 Mar 1997
CLARIFICATION:
As always, things are often not black nor white but some shade of gray.
Regarding these two SAS functions, we may have some gray.
SAS documents how dates of the format YYDDD or YYYYDDD will be treated.
Basically YYDDD dates provided by a program to SAS will be stored
internally with the appropriate century value based upon your setting of
the YEARCUTOFF value which defines your 100 year window. This is the way
SAS will try to interpret ambiguous dates.
If you convert a SAS date value to a Julian date, SAS will return a YYDDD
format date for those dates that fall within your 100 year window as
defined by YEARCUTOFF and will return a YYYYDDD format date for any date
that falls outside of the window. While someone might argue that they don't
like the way SAS is handling these issues, it seems to me they have
recognized the problems and tried to handle them in a reasonable way.
-- Dave King , 26 March 1997
---------------------------------------------------------------------------
2.20 Oracle
***
Let me try to summarize Y2K compliance in Oracle (and many other DBMSs).
Oracle is doing pretty good (hey, this is coming from a guy who used to
compete against them ;-)) and lets give the credit where the credit is due
(though I understand that there is one lawsuit pending from a client who
challenges Oracle Y2K compliance. I don't know all details but it would not
surprise me if it was due to a misuse of Oracle functionality.)
You have to look at Y2K compliance for database environment in multiple
layers:
1. Oracle internals (e.g. rollback recovery, transaction time-stamps, etc.)
As far as I know Oracle is compliant in this layer (internally it uses a
full time-stamp based on a four digit year).
2. Dates in database. Oracle date internal format contains a full time-
stamp yyyy:mm:dd:hh:mm:ss stored in seven bytes. Manipulation of this date
requires use of data functions (to extract or store time-stamps components)
I think this may be the reason for many database applications storing dates
as character strings or as integers. Obviously, in this case the date
format depends on a database design and may include just two digit year.
But this is not the Oracle fault!
3. Manipulation through PL/SQL. Dates stored in DATE format are manipulated
through date functions (TO_NUMBER, TO_CHARACTER, TO_DATE) using date
formats. Date formats are for external representation (internally year is
always yyyy)
If you try to translate external two digit year into internal four digits
you can use
- "YY" format, where a century value will be based on the current century
"19" until the year 2000, "20" thereafter
- "RR" format, where a century value is based on a date window "20" if the
year is < 50 else century = "19"
Again, Oracle gave you a decent approach to handling dates, it's up to you
to use it properly. If you need any other approach, you can develop your
own date function and pass the result to database through "yyyy" format.
4. Manipulation through host languages. Folks how you handle dates in C,
COBOL, Visual Basic, etc. has nothing to do with Oracle. If you translate
two digit year into for digits in a host language and pass it to Oracle it
is not Oracle problem when the date stored in Oracle database is incorrect!
Yet, I heard too many time "our application is compliant - it uses Oracle
database and all dates are stored in DATE format. Just recently I was
trying to explain this fact to one of our Y2K clients. My explanation was
reinforced by a failure to process next century dates in one of their
applications!
5. Manipulation through end user interfaces (e.g. screen formatting
software, GUI). Many of these packages use their own routines to translate
dates between fore and two digit years. So eventually date may be passed
from GUI interface to a host language, to PL/SQL stored procedure, and
finally stored in Oracle (in DATE or other format). Any layer may use
incorrect translation and manipulation of dates. But do not blame Oracle
for this - blame the designer of your database application and your
development standards and procedures.
-- Miro Medek , 28 Mar 1997
***
I found this quite interesting. You will need to read the entire article at
http://www.dbmsmag.com/9801d20.html to easily understand the full
implications.
[snip]
Oracle columns of the date data-type can store dates ranging from January
1, 4712 BC to December 31, 4712 AD. Oracle uses its own internal format for
storing dates, but conceptually you can think of the server as storing each
date in the format YYYY-MM-DDHH24:MI:SS. Because all dates occurring in a
column of datatype date are stored with a four-digit century, Oracle
regards the Oracle Server as Y2K compliant.
However, the situation gets less rosy when we take into consideration the
default date format. Since Oracle uses its own internal representation for
dates, it must convert from this format to a readable format on output and
vice versa on input. Oracle provides a wide range of date formats that the
programmer can explicitly request or specify by using the to_char() and
to_date() functions, respectively. However, if you don't use these
functions (for example, you just reference the date as a string as in
"select * from emp where hiredate > '01-JAN-97'"), Oracle relies on the
default date format to perform the conversion. There is a great deal of
Oracle SQL code in use that relies on the default date format --
approximately three quarters of the Oracle SQL code that I've seen or coded
in the last 10 years does.
The default date format for Oracle releases in North America has always
been DD-MON-YY. Here's the potential pitfall: The YY always refers to years
in the current century
[snip]
-- Harlan Smith <71530.1637@compuserve.com>, December 18, 1997
===========================================================================
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.
***
The following is from the Risks-Forum Digest, Monday 29 March 1993, Volume
14 : Issue 44, Peter G. Neumann, moderator.
Subject: Call for the Class of '88
I Found the squib below on the Prodigy service --
QUIRKS - Offbeat Computer News
Mary Bandar recently turned down an invitation to attend kindergarten with
others born in '88. "Boy, wouldn't those kids ever be surprised when they
see me coming to school," Bander, 104, told the Associated Press. "Why
would they want me? I know the ABCs yet. And I can count to 10," said the
Winona, Minn, resident, who was born in 1888.
Sister Mary Donald Miller, superintendent of Winona Area Catholic Schools,
told the AP that the mix-up occurred when school officials instructed a
computer to search for the names of people born in '88.
. . .
I expect that as we approach the millenium, we'll see a lot more of these
"off by a century" errors.
-- Ed Ravin , 29 Mar 1993
Reused without explicit authorization under blanket permission granted for
all Risks-Forum Digest materials. The author(s), the RISKS moderator, and
the ACM have no connection with this reuse.
***
"In 1990, a 107 year old woman in Denmark received a letter from the local
school system welcoming her to first grade. A man of 103 checked into a US
hospital and was assigned to the pediatric ward. That's nothing, compared
to what we can expect in the year 2000 - unless every organization that
uses computers starts now to address the problems inherent in the fact that
00 is less than 99."
-- Case Strategies, Dec. 1992
***
FUD (Fear, Uncertainty and Doubt) is a major motivating factor. Marketing
and finance people are typically very familiar with its effective use. You
can bet that come 1999, there will be plenty of short-selling of stock in
corporations expected to be hit hard by this problem.
-- Ron Hunter-Duvar
But we should also remember that there is no uncertainty or doubt on this
issue, just shock and disbelief at the extent of the work required from
those who have reliable estimates. There is a problem now and there will be
many future repercussions unless time to act is moved forward rather than
backward.
I'd probably start taking short positions in late 1998 though .
-- Joe Warren , TransCentury Data Systems
***
A friend in the department that handles some accounts-receivable that span
out 5 years or more have done some work -- mostly by the "sliding window"
approach. But for the most part, everyone else I know of is still sitting
on their collective hands.
I just found out that last year, my department manager was far-sighted
enough to ask for budget to handle Y2K issues. His boss nixed it.
I'm doing all I can to get the budgetary juices flowing, but I'm beginning
to think that FUD (Fear, Uncertainty, & Doubt) should really be DUF.
We start out DOUBTING that there is a problem, then move onto being
UNCERTAIN that we can handle the problem, and finally get to the FEAR phase
-- This is the real motivator.
I just hope that I can move the bosses through these phases quickly enough
and that it doesn't somehow backfire.
-- 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
***
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
***
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
A similar case was recently admitted to by a senior IS staff member of a
major food product chain at a recent Y2K conference. I am being as vague as
possible to protect the innocent, the guilty and those that were minors at
the time the applications were coded.
They had a vacuum packed product (vague again) with a 5 year shelf life.
When calculating the product's expiration date earlier this year, their
program added 95+5 with the result of - you guessed it - zero.
So the next time their inventory system ran, it compared the expiration
date (00/MM/DD) to the current date (95/MM/DD). Since the current date was
greater, that meant the product's shelf life had expired and notices were
issued to toss it all in the incinerator.
Fortunately for them, their warehouse uses humans and not robots to pull
products off the shelves. They managed to detect that something was amiss
and prevented the destruction of perfectly good merchandise. What they did
to manually correct their inventory and accounting systems is unknown.
-- Romy Leibler
Cash Registers Crashed at Midnight
According to the 25 August 1995 edition of the St. Louis (MO)
Post-Dispatch, a local CompUSA store took the unusual step of staying open
late for the release of Windows 95. Unfortunately, the cash registers
crashed at midnight, just as the first Windows 95 buyers were ready to
check out. The store worked half an hour to resolve its problem.
The article did not say what cause the cash registers to crash. My guess is
that the cash register system needs to be cycled off at the end of the day
and on at the beginning of the next. As they never before stayed open after
midnight, they did not know this. Even a reliable system will produce
unusual results when used in an unusual manner.
-- Jerry Whittle
---------------------------------------------------------------------------
3.2 Has mankind ever had to deal with this kind of problem before?
***
Many years ago when I was in the Air Force, we had a major system balk at
going from 1979 to 1980 because of a 1-position year setup.
-- Daniel A. McLaughlin
***
One-digit years were quite common in punch card systems. With only 80
characters in a card, every character was precious. Anyone who was in data
processing in the 1960s or earlier remembers such systems.
***
It's happened before!
Being a graybeard in computing, I'm a bit surprised that this problem is
only now being recognized, since it's happened before. This is a favorite
thing of mine to mention in classes. Normally I say something like ...
"Why were a BUNCH of programmers called into work on an emergency basis
shortly after New Years, 1969?" - My students (who are most 22 or so years
old (sigh)) generally don't have a clue.
The answer is that programs dealing with long term financial instruments
(30 yrs) all of a sudden had ABENDs (as we called them then) when maturity
dates computed from 1970 started producing zeros - mostly mortgages and
long bonds.
-- Bob Wier
***
The following is from the Risks-Forum Digest, 20 November 1989, Vol. 9,
Issue 45, Peter G. Neumann, moderator
Subject: Another foretaste of the Millenium
We apologise for the unexpected system shutdown today (Thursday). This was
caused by a bug in the MTS [Michigan Time Sharing] system that was a
"time-bomb" in all senses of the word. It was triggered by today's date,
16th November 1989.
This date is specially significant. Dates within the file system are stored
as half-word (16 bit) values which are the number of days since the 1st
March 1900. The value of today's date is 32,768 decimal (X'8000'
hexadecimal). This number is exactly 1 more than the largest positive
integer that can be stored in a half-word (the left-most bit is the sign
bit). As a result, various range checks that are performed on these dates
began to fail when the date reached this value.
The problem has a particular interest because all the MTS sites world-wide
are similarly affected. Durham and Newcastle were the first to experience
the bug because of time zone differences and we were the first to fix it.
The American and Canadian MTS installations are some 4 to 8 hours behind us
so the opportunity to be the first MTS site to fix such a serious problem
has been some consolation. The work was done by our MTS specialist who
struggled in from his sick bed to have just that satisfaction!
-- Brian Randell
Reused without explicit authorization under blanket permission granted for
all Risks-Forum Digest materials. The author(s), the RISKS moderator, and
the ACM have no connection with this reuse.
***
Digital Equipment Corporation had a similar problem with the DECsystem-10
in 1975 because of field overflow. DEC's advisory late in 1974 had this to
say (quoted in First Data Corporation, Newsletter 20, December, 1974):
"When the software for the PDP-6 was being designed in 1964, a 12-bit date
format was established. In order to maintain compatibility with old
programs, that format was retained in successive monitor releases.
Unfortunately, the 12-bit format cannot represent any date after January 4,
1975. Therefore, a DATE75 project was initiated in order to convert
DEC-supplied software to a new 15-bit format that properly represents dates
well into the next century. Support for 15-bit dates was designed to
minimize conversion problems. Programs coded in a simple, straight-forward
fashion will work properly with 15-bit dates without any modification.
"Our experience in actually converting our existing software has been
considerably more difficult than we ever anticipated. We keep finding new
DATE75 problems. As a result, we have been forced to release a large amount
of software on the November distribution tape; and customers will not have
as much time as we would wish to install it all. Naturally, we recommend
installing all of this software well before January 5, 1975. If this is not
done, many DATE75 problems will be encountered. Keep in mind that DATE75
problems are essentially cosmetic. It is a nuisance to have files with
incorrect creation and access dates, but it is not a catastrophe."
But, "When a file gets an erroneous date because of a DATE75 problem, it
may not be saved and restored in the intended fashion by FAILSAFE [the
backup daemon]. This is a serious problem since it can result in files
appearing lost."
And, "We regret very much the lateness of the delivery of this software. We
simply did not anticipate all the problems we would encounter. Customers
should take advantage of the lesson we learned so painfully by immediately
upgrading their DEC software to the versions released on the November tape,
and by starting conversion of their own software... Our experience
indicates that it is not sufficient for a programmer to simply 'think
through' a program's structure and functions to determine whether it has a
DATE75 problem. It is not sufficient merely to give the program a quick
test with a monitor set to a date after January 4, 1975. It is necessary to
run the total system for several hours in order to find all the subtle
DATE75 problems."
"Please keep in mind that DATE75 fixes have proven incredibly error prone.
You must use great care and very thorough testing in order to be confident
that DATE75 problems have been fixed... Most of the problems we found were
in cases where we believed our programs followed these [omitted]
procedures. Do not believe yours do!"
-- Dave Rybarczyk
***
Yes, and the Japanese are particularly well placed to take advantage of our
chaos when the year 2000 rolls around (see below).
***
"The year 2000 will be the first century change ever endured by an
automated society and if your organizations uses computers, that means you
are sitting on a time bomb."
-- Randall L. Hitchens, Computerworld, Jan. 28, 1991
The above statement is not entirely true.
When the Japanese Emperor died in 1989, the 64 year "Showa" period ended,
and Japanese business was forced to implement an Emperor Date change to the
period "Heisei". This is equivalent to a century change, since the Emperor
Date starts again at 1 for the new Emperor. Of course it was the first
change in the computer era.
Emperor Dates and Western Dates are used interchangeably in Japan. It is
thought that 'the majority' of Japanese business made corrections to 2
digit Western Dates at the same time as they corrected for the Emperor
change.
Japanese business tends to be more composed concerning the year 2000
change, nevertheless there may well be problems there too.
-- Duncan G Connall
---------------------------------------------------------------------------
3.3 Anyone got any idea what possible Y2K implications are known with
reference to nuclear missiles and other military, software-controlled
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).
---------------------------------------------------------------------------
3.4 Does the Global Positioning System (GPS) have a year 2000 problem?
The following is an excerpt from a longer message in Risks-Forum Digest,
Tuesday 2 July 1996, Volume 18 : Issue 24. For references and more detail,
see the original message.
I have good news and I have bad news.
The good news is that GPS will not have a "Year 2000" problem. The bad news
is that GPS System Time will roll over at midnight 21-22 August 1999, 132
days before the turn of the millennium. On 22 August 1999, unless repaired,
many or all GPS receivers will claim that it is 6 January 1980, 23 August
will become 7 January, and so on. I would expect that some manufacturers
have already solved the problem, but many have not.
-- Joe Gwinn
Reused without explicit authorization under blanket permission granted for
all Risks-Forum Digest materials. The author(s), the RISKS moderator, and
the ACM have no connection with this reuse.
***
I did a web search and found some helpful docs.
Most helpful sites I found were:
http://tcho.usnogps.navy.mil:80/gps_week.html
http://www.navcen.uscg.mil:80/gps/ccgsic/whatsnew.htm
Summary:
Within the GPS system, there is a field called week number. Week 0 started
on approx midnight Jan 05 1980. Each week since then, the count has been
increasing. Since the field size of GPS week number field is 9 bit binary
(mod 1024), the maximum value is 1023. When 1023 is incremented by 1, the
counter rolls over to 0. Week 1023 occurs in August 1999.
Every GPS receiver could fail at the same time in August 1999. The symptoms
are inaccurate date/time and incorrect coordinates. The resolution is to
have the manufacturer upgrade the GPS unit before August 1999.
Hope the manufacturer of your unit is still in business.
-- Nancy Copes <75362.60@compuserve.com>, January 7, 1997
***
I just stumbled on a report on GPS that came out in 1997/06/02
See http://www.laafb.af.mil/SMC/CZ/homepage/y2000/y2k/index.htm
"MILLENNIUM (Y2K) AND GPS END OF WEEK (EOW) ROLLOVER
Lt Al Johnson GPS Y2K Lead Engineer
Navstar Global Positioning System Joint Program Office
As of: 17 June 97
....
The bottom line was that "GPS performance will be unaffected by Millennium
and EOW (End of Week) Rollovers.
For those that don't remember or haven't read about GPS before there was
concern about the end of the 52 week GPS "epoch" in September 1999, that is
an entirely different phenomena than Y2K. In September 1999 a modulo 1024
counter in the receivers would roll over to zero.
A summary of the test results and conclusions:
- The satellites test OK
- The GPS receivers procured by the Joint Program Office tested OK
- Some support equipment on older computers was not OK and must have Y2K
remediation
- The AF will test commercial receiver designs for a fee.
- The GPS receivers put out a 2-digit date, raising a question in the mind
of the AF about interfaces.
So Gary North had raised a question about this and he was right that the
testing was required. So it looks like now the only concern is whether the
commercial receivers will pass the AF Test.
I haven't gone back to his site yet to see if he has mentioned this report
or not. If not, I will bring it to his attention.
-- Harlan Smith <71530.1637@compuserve.com>, September 24, 1997
---------------------------------------------------------------------------
3.5 How are credit card companies handling year-2000 expiration dates?
***
DISCLAIMER: Although I am employed by MasterCard International, I am not an
official corporate spokesperson. These comments are my personal opinions.
MasterCard and Visa are not going to change the format of credit card
expiration dates for a very simple reason (one that applies to a great many
Year 2000 problems). There are literally thousands of banks and hundreds of
thousands of merchants worldwide who would have to convert to a new network
message format. It is not possible to coordinate that kind of change with
hundreds of thousands of independent external users. Therefore, any POS
terminals which attempt to check expiration dates would have to use a
century windowing strategy.
MasterCard and Visa will start fining Merchants whose POS terminals do not
accept '00' in expiration dates. This won't start until probably September
of 1997. The purpose is to give merchants a monetary incentive to achieve
Year 2000 compliance, and not to increase revenue to the credit card
associations.
And finally, merchants do not get their POS terminals from MasterCard and
Visa. The merchants must buy or lease them from an array of competing
manufacturers. As far as I know, MasterCard does not certify POS terminals
for Year 2000 compliance. We do certify acquiring banks and financial
institutions for correct network message layouts.
-- Arnold Trembley , 22 Feb 1997
===========================================================================
4. 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.
-- Robert J. Sandler
***
Leap Year Myths and Facts
Please do not try to discuss these myths, or try to prove that they are not
myths, on the Year 2000 mailing list or in other on-line discussion forums.
We have all had our fill of leap year discussions. There are much more
critical issues to be resolved, and time is running out.
Myth: If the year is evenly divisible by 3200/3600/4000 (pick one) it is
not a leap year.
Fact: There is no such rule. The two rules given above are the complete
rules for determining whether a year is a leap year in the Gregorian
calendar. The popularity of this myth seems to derive from the fact that
the average length of the year in the Gregorian calendar is approximately
26 seconds longer than the tropical or solar year. This difference amounts
to one day in a little over 3300 years, or about three days in 10,000
years. Some experts have proposed rules similar to the mythical rule to
correct for this difference. But no government, standards organization, or
other authoritative body has adopted such a rule.
Myth: The year 2000 will be a "double leap year" or "super leap year."
February will have 30 days and the year will be 367 days long.
Fact: There is no such thing as a double leap year or super leap year. The
year 2000 will be a leap year like any other leap year, with 29 days in
February, and 366 days in the year.
-- Robert J. Sandler
---------------------------------------------------------------------------
4.2 Is there an ISO, ANSI, NIST, or other standard that defines the
Gregorian calendar or the rules for leap year?
No. There is no ISO, ANSI, NIST, or any other official standard, in the
modern sense, for the Gregorian calendar. The Gregorian calendar was
defined by the Roman Catholic Church, not by any modern standards-setting
organization. The definition was established in 1582, long before today's
standards organizations even existed.
In 1582 the Church was the only organization in a position to establish
anything resembling an international standard. The original and ultimate
source for the definition of the Gregorian calendar is the papal bull
"Inter gravissimas" (Among the most serious) issued by Pope Gregory XIII in
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.
-- Robert J. Sandler
---------------------------------------------------------------------------
4.3 On what date will the 21st century begin?
***
The 1st century AD consisted of the years 1 through 100. The 20th century
consists of the years 1901 through 2000 and will end Dec. 31, 2000. The
21st century will begin Jan. 1, 2001.
-- The World Almanac and Book of Facts 1996
***
This is a date that no organization, including NIST, has the authority to
regulate. However, one logical answer to the question is that because there
was never a year "zero," and a century must have 100 years, then each
century must begin with a year numbered "1." In other words, the 20th
century should be considered as ending on Dec. 31, 2000, and the 21st
century as starting on Jan. 1, 2001.
However, human nature being what it is, most of us will still opt to have
that "once-in-a-century" New Year's Eve bash on Dec. 31, 1999.
-- "Time Questions and Answers from NIST," Time and Frequency Division,
National Institute of Standards and Technology
***
The 20th century (this century) will end after December 31, 2000 comes to a
close. The 21st century then begins just after midnight on January 1, 2001.
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
***
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
***
It seems to me that years 1901 to 1909 were often called "aught one" or
"aught nine" (not that I was there, but that's what I have heard.) Maybe we
should do that again. My guess is that it will commonly be "two-thousand
and one" because of Kubrick's movie. How that gets shorthanded will be
interesting to watch.
-- Lanny Jones
***
I'm 60 now, and can remember my grandparents refering to the period of
1900-1910 simply as the "ninteen hundreds". They referred to individual
years as "O one", "O two", etc. up to "O nine". The years 1910-1919 were
referred to as "the nineteen tens". Individual years in this period were
referred to as "ten", "eleven", "twelve", etc, up to "nineteen".
Don't know if this will translate well to eqivalents in the 21st century.
-- Tony Baker <75321.2171@compuserve.com>, January 7, 1998
***
Jack Rosenthal, editor of The New York Times Magazine, considers this
question in the On Language column in the August 18, 1996, issue of the
magazine. After considering and rejecting many of the suggestions above, he
proposes calling 2000 through 2009 "the Ohs." He also points out that the
use of "aught" to mean zero is the result of a mistake, misunderstanding "a
naught" as "an aught."
-- Robert J. Sandler
***
The New York Times Magazine, January 19, 1997, (p. 13) refers to the
"Oh-Ohs."
-- Robert J. Sandler
---------------------------------------------------------------------------
4.5 What is a Julian date?
The term "Julian date" has two different meanings. The one that is most
common in data processing is a number from 1 to 366 representing the day of
the year. This is more properly referred to as the "ordinal date."
The other meaning of Julian date is a system used by astronomers. It is
also called Julian Day and abbreviated JD. It is the number of days since
noon GMT on January 1, 4713 BCE. In this system, Julian Day 2,450,084
begins at noon GMT on January 1, 1996. This system was invented in 1582 by
Joseph Scaliger, who named it for his father, Julius Caesar Scaliger.
-- Robert J. Sandler
---------------------------------------------------------------------------
4.6 What is an integer date? What is a Lilian date?
An integer date is a way of representing dates as the number of days since
a specified starting date. Integer dates make it very simple to calculate
the number of days between two dates, or to find the date a given number of
days before or after a given date.
A Lilian date is an integer date system in which day 1 is October 15, 1582,
the first day of the Gregorian calendar. It is named for Luigi Lilio, who
provided most of the ideas for the Gregorian calendar reform, including the
rule for leap years.
Other integer-date systems use other starting dates. For example, ANSI
COBOL 85 intrinsic functions use January 1, 1601. Most spreadsheets,
following the convention first established by Lotus 1-2-3, use January 1,
1900.
-- Robert J. Sandler
===========================================================================
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
Director of Marketing at Peritus Software Services, Inc.
***
I'm essentially aware (simplistically) of 3 basic approaches to coping with
addressing Y2K in both programs & data:
(1) expand two digit years to 4 digits.
PROS: seems to be the most straight forward.
CONS: terrific downstream impact on sorts, DASD, file sizes, etc. Does
anyone out there have any capacity planning experience? Can you comment on
how much bigger files will become?
(2) bit twiddling - stuff 4 digits into 2 physical positions
PROS: avoids the downstream ripple effect of approach #1
CONS: (I'm told) applying the logic to programs requires precision
(3) sliding dates - leave as two digits & have some logic determine that 60
thru 99 implies 1960 thru 1999 and 00 thru 59 implies 2000 thru 2059.
PROS: avoids the file expansion issue
CONS: doesn't work for certain applications (e.g. - very likely not for
life insurance). The programs need to be changed, but the problem persists.
If you sort on dates, look out.
The nastiest aspect of all these solutions is: No matter which one (or
combination) you choose, you still must deal with the problem of importing
data from other systems. Any dates which come from "outside" will need to
be converted unless they already match your data standard. You can always
ask (insist?) that those providing you with data put it in the desired
format. Whether they will depends on the nature of the relationship between
you (another non-technical aspect of the problem).
Eventually, of course, everyone will see the value of YYYYMMDD dates, and
standardize, right? But until then (don't wait until then to retire), you
will need to maintain some conversion routines. To ease maintenance, using
callable modules for these conversions seems to make sense.
-- David Eddy , Global Software, Inc.
***
Of the three solutions posted above ... only one, in my view, is the
correct way to do this. 4 digit dates ... (I'd press for 5 digit dates, but
some would consider me to be going a little byte overboard)
The downside for DDDD is two fold. Space requirements ... and input
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
***
Our system has been in existence since 1981, therefore, we do not deal with
any dates anywhere near the beginning of the century. Our system also does
not have critical date computational needs with to-the-day accuracy
required. We are primarily an OS/VS COBOL (Release 2.4) shop using VSAM
files in a MVS/ESA SP4.2.2 environment. I am on a team which is tasked with
preparing our COBOL programs for the year 2000.
A detailed plan has been prepared by our project leader and is currently
being implemented. We are using simple design elements:
1. Extensive use of bridging programs for all of the reasons mentioned
previously in our discussions.
2. Expansion of all years to 4 characters.
3. Our simple date computations will remain hard-coded. Most need to only
be approximately correct (mainly for record retention purposes), or are
only calculating fiscal year and month from calendar year and month.
4. The decision has not been finalized, but, 2 digit years may be used on
most screens and reports.
5. And, of course, we are using the opportunity to reorganize our files and
expand other fields!
-- Richard Newbold
***
Per the IEEE definition, software re-engineering is a three step process:
(1) baseline inventory,
(2) analysis, and finally
(3) you change/write code (if appropriate).
Everyone wants to jump immediately to step #3. But unless you have a firm
understanding of where you are (step #1), attempting to jump to nirvana
(step #3) will inevitably lead to a lot of wasted effort.
-- David Eddy , Global Software, Inc.
---------------------------------------------------------------------------
5.2 In a large system fix, what are the trade-offs in changing the data
versus changing the application programs?
There has been continuing discussion of this issue on the Year 2000 mailing
list. What is best for a particular system will depend on many factors.
Here are a few of the messages from the mailing list that outline the
considerations involved. The second message below is a very strong pitch
for the procedural approach - i.e. changing the programs. This message
provoked much of the recent discussion, with many participants disagreeing,
or at least arguing that there is no one right answer for all situations.
***
With cost, risk and reliability as my key concern, I am listing below my
thoughts on the pros and cons of the two methods - Data expansion vs.
Century Derivation/procedural. It is a seminal issue. We need to give clear
direction to analysts and programmers before they dive into the code. We
expect to come up with the preferred instruction set in the next 3-4 weeks.
Century Derivation strengths vs. Data Expansion
(1) No expansion of copybooks, DBDs, working storage, etc. - except for
ambiguous dates and keys in segments.
(2) Can keep current century derivation logic currently in place (3) Can
code, test, system test, regression test more simply - small pieces
(subject to ambig. date and key date exceptions)
(4) Can put into production in very small pieces (again subject to
exceptions) rather than large production installs
(4a) Data expansion with phased production installs implies bridges and
conversion programs - again subject to exceptions.
(5) No need to deal with converting archived data
(6) Can create standard procedure division code or called routine which
will derive century - reduces logic error probability
Comment: perhaps there is a code way to get around ambiguous date -
birthdate, for example - if Birth- YY <50 and Soc-sec-No > x then CC = 20
Data Expansion strengths vis a vis Century Derivation
(1) No procedure division changes - except for yanking out century
derivation logic where it is now (unless we choose to not expand those
dates) - and except for secondary moves.
(2) Easier to employ junior programmers in the program changes, perhaps
even some of the detailed analysis
(3) No speed degradation (3 additional LOC per derivation - meaning 6 per
date comparison)
(4) Probably fewer test errors - no procedure division code changes (unless
we yank the century division logic)
(5) Easier maintainability after it is all over
(6) Less static about speed and about impurity of solution
(7) Cutoff date with CD approach may differ from application to application
(solution to use system date to perpetually change the pivot date plus
ability to have application pass a parm which is an application specific
pivot date exists - but adds to code complexity)
Expected life of applications and ability to marshal resources are
situational factors each co. must evaluate.
-- Tom Ster 14 Feb 1996
***
Losing Sight of the Problem
I read with interest Tom Ster's posting [not the one above], in which he
referred to a "century derivation" approach (the process option), as
opposed to changing the dates on his database (the data option). At the
risk of having us both burned at the stake, let me take up his case.
There has been a lot of discussion in this forum about the best date
formats to make standard, and about the importance of consistency and
standards for data interchange. New systems do need to be built with date
standards in mind, and the external view of a system does need to meet
certain standards if it is going to interface with a common world. The big
problem is how to make *existing* applications run error-free as 21st
century dates enter these systems. My perspective is an IBM mainframe one.
Most of these systems have not encountered, and are not going to encounter
a situation where 2 digit years become ambiguous. For example, in the
context of a hire date, 95 always means 1995, never 1895 or 2095; in the
context of a contract expiry date, 35 always means 2035 and never 1935. If
the 2 digit year has become ambiguous, fix it by including the century - it
has nothing to do with the millennium problem. Two digit years are not
appropriate if the context and other available information does not
uniquely identify the century, and this problem will show up when new
ambiguous year data enter the system, no matter when.
The millennium problem is that date operations and comparisons may not
generate the correct results with 2 digit years, because the CODE is wrong.
So, there is no need to fix the data at all. It is possible to solve the
problem by modifying the code. The type of code which is wrong looks like:
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 MMM YY or use some other way to distinguish day from month from year).
The greatest benefit of the process approach is that the program *bugs* can
be fixed one at a time, and released into production immediately, if you so
choose. To some extent, testing can be done module by module, looking for
correct functioning of the piece of code that changed. (In the data
approach you change data structures which impact all parts of the program,
and therefore you have to test ALL functionality). Of course, you need to
test the system as a whole, and you need to simulate 21st century dates in
the test data and in the system date if possible, but you have
significantly reduced your impact to the system, and it's much more likely
to work. In this approach you are attempting to preserve the current look
of the system - files, reports, databases should all look the same as
before. In the data approach, you are intentionally changing the values in
files, reports and databases.
The Gartner Group suggests $1 a line for millennium compliance. I have seen
an instance of a data solution which cost double that. I have yet to
redevelop a system using a process methodology, but I'm looking forward to
it, if I can convince the fledgling Year 2000 strategists to stop chasing a
ghost.
-- Andrew Eldridge 29 Jan 1996
***
One of the basic decisions to be made with regard to the YEAR 2000 problem
is whether to convert the data or the applications. Actually, it is not an
either/or situation, since data conversions still imply application changes
to accommodate the new data definitions. (Even with a highly "active" data
dictionary, applications may need to decide whether to automatically have
all output increase to 8-digit dates.)
Though one answer is certainly the "theoretically" best solution, the
implementation questions show that there is still room for evaluation of
the trade-offs. Perhaps determination will be based upon the nature of the
application subject area. (Some applications demanded 8-digit dates from
their conception years ago. Some applications may use their dates strictly
for tracking purposes and will be spared the crisis that most systems will
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
underlying data bases are converted.
e. Since programs need to be implemented simultaneously, yet it will take a
long period to make the changes to the source code, keeping the converted
code in sync with updates to the current code will be difficult. The
alternative is to freeze all maintenance and enhancements until conversion
is completed. (Can any installations tolerate that?)
f. Dates will need to be truncated on output much of the time for three
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 13 Jun 1995
---------------------------------------------------------------------------
5.3 What strategies are being considered for solving the following year
2000 problems: break point? - field expansion? - hex code?
***
While catching on my Y2K mail, I noticed an increased number of posts about
expansion versus windowing and questions about encapsulation. That's good,
however, it's been argued mostly from a "purist" point of view, not
considering a reality of Y2K projects. Question "what to use" is posted
mostly by people starting with Y2K project, answer "this approach is the
best" is posted mostly by people who are well into conversion. There is
disconnect between Y2K scenarios for these two groups - mostly in time
available to execute the Y2K project.
When making a decision about technical approach to Y2K compliance, I would
strongly suggest to consider (1) all factors involved, and (2) scoring the
factors based on your specific environment and priorities. The following is
a sample of factors (not a complete list) which should be considered:
- time remaining for the Y2K project
- Y2K event horizons for your critical systems (when will you experience
first failures)
- overall IS plans and strategy (e.g. do you plan to replace some systems
in 5-6 years? will you migrate some of your systems to different platforms?
- on-going development activities (e.g., are you rewriting some of your
systems?)
- how stable is your system, how much modifications you have to implement
each year (some approaches require a much longer "freezing" period,
including data and program synchronization between old/new)
- current environment including
* languages (e.g., if a significant amount of code is in assembler,
encapsulation may look really attractive)
* data management (e.g., data expansion in IMS or CODASYL network DBMS is
much more difficult than in relational DBMS or VSAM files)
* software packages used (approach may be driven by software vendor)
* overall IS architecture (e.g. level of decentralization, heterogeneity of
hardware/software platforms, how monolithic are your systems)
* batch/on-line ratio (e.g., need to modify on-line screens based on
selected approach)
I am sure that everybody can come up with a long list of additional factors
- consider them all using you own priorities. Don't forget that the main
goal of this project is to support your company business activities through
continued operation of your systems minimizing Y2K errors and disruption.
At this point of time I see three main groups of technical approaches, each
of them having some variations:
1. date expansion (including variation of in-place compression, date
shadowing, encoding, etc.)
2. windowing (including fixed windows, sliding windows, and different
implementation techniques, e.g., windowing on I/O time or windowing on
demand)
3. time shifting through data/program encapsulation (including variation of
system boundaries for time shifting, time shifting on demand, when using
dates, or permanent time shifting in files)
Each of them have some positive and negative features which go way beyond
the scope of this post. Some may not be applicable to a specific
environment at all, and you can not take a generic approach "this is a
preferred way to Y2K compliance" - you must evaluate them individually.
Just a "sampler" of pro and cons for each approach (for variations pro/cons
will also differ):
1. Date Expansion.
Overall: this is preferred approach by many companies though it is the most
expansive and time consuming approach
PRO:
- fix is more permanent in nature
- requires less procedural changes
CON:
- requires data conversion
- requires bridging between modified and unchanged programs - requires
additional storage
- screens/reports may be too busy to accommodate expanded dates and this
will require a redesign
- may requires additional tuning due to additional I/Os and excessive
paging
2. Windowing.
Overall: this tends to be less expensive and time consuming than date
expansion but will require more procedural changes, code scanning,
examination, and testing
PRO:
- does not require data conversion
- takes less time to implement
- eliminates requirement for bridging between modified and unchanged
programs
- facilitates a gradual implementation
CON:
- requires more procedural changes
- each program requires more detailed examination and different approach
for applying windowing technique
- each date may require different time window
- may be difficult to implement for some third party software - will
require more testing dues to "procedural orientation"
3. Time Shifting through data/program encapsulation.
Overall: this is the least expansive and time consuming approach (when
applicable) though the approach is less understood and therefore
controversial.
PRO:
- does not require data conversion
- minimum modification to software
- affected code is easier to locate
- requires less testing than other approaches
- after some time (representing a typical time span of dates in your
system) time shifting can be turned off and system will operate in the new
century
CON:
- must be documented and understood by new programmers doing software
maintenance
- may not be possible to implement for third party software
- difficult to implement if system has hardcoded business rules (e.g., if
96 apply this maintenance procedure)
All of the above approaches will require all Y2K phases (inventory,
assessment,... etc.) though the effort foe each phase will differ. None of
the approaches eliminates review and code analysis (if you don't know
what's inside, I would not try a "black box approach").
I a view of "Y2K state of the union", when most of the companies are still
in "assessment" phase, I think that we will see a significant shift from
"date expansion" to "windowing" and even more toward "time shifting" or
other creative approaches (where I think we will see some more
announcements in coming years).
Current orientation toward date expansion and windowing is partially due to
the Y2K tool vendors and service providers who drive the Y2K market. Most
of them did a reasonably good job in gearing their tools and methodologies
toward date expansion and windowing but this, on the other hand, created a
mind set toward these two approaches and limited our creativity and
thinking about alternatives. Well, I would urge every player in this market
to think twice. Year from now, I will have a significant problem in
recommending to my client to use an expensive tool set and approach which
can not be successfully applied within remaining time frame.
When you making good progress on your Y2K project and making recommendation
to the rest of the list, it would be good to ask yourself "would I be able
to use the same approach if was starting today?" before you make your
recommendation. Whatever is the reason for the late start, it does not help
to remind them "if you started two years ago you could use.. " By the way,
it may be your business partner, supplier, or client who is asking "what's
the best thing to do" and if they fail, your Y2K compliant system may not
be enough to keep your company business going.
-- Miro Medek , Mitretek - ITSC, 16 Jan 1997
***
I am writing a subprogram on my home PC that uses break point logic to
determine the century digits for a two-digit year. It subtracts 80 from the
current year to get the first year in the 100-year cycle, and then bases
the century digits on that cycle. For example, in 1995 the cycle runs from
1915 to 2014. A two-digit year between 15 and 99 will be converted to 1915
thru 1999, and 00 thru 14 will be converted to 2000 thru 2014. In 1996, 16
thru 99 will be converted to 1916 thru 1999, and 00 thru 15 will be
converted to 2000 thru 2015.
Even if you have expanded your date's year field to four digits and now
your system appears to be 2000-compliant, there are several other areas
that could cause problems as we approach 2000. For example:
- Embedded two-digit years in serial numbers and other identifiers that may
be sorted.
- Dates with two-digit years that we send to banks, suppliers, and
customers via mag tapes and EDI.
- Dates with two-digit years passed between mainframes and PC applications
such as spreadsheets and databases.
-- Rick Toker
---------------------------------------------------------------------------
5.4 Why should we try to have standardized date computation routines? Why
don't we ALREADY have standardized date computation routines?
***
One of those hidden problems that many shops are discovering in their 2000
evaluations, is that they have anywhere from 5 to over 100 individual date
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, parameter requirements may vary from one of these routines to
another creating the potential for further errors.
When considering the high number of routines in the average shop, one has
to wonder why they were created in the first place? Of course, we will
always have the "it was interesting to write it" response but more often
than not it seems that either the current "standard" routine was not
documented as existing across the enterprise, documentation on how to use
it was poor or missing or the routine(s) was difficult to use and not
logically designed. Another reason I have heard is what I call "latent
demand" (taken from my performance tuning days ). At times, additional
functionality may be desired/required but in today's "lean & mean" shop no
one has the time to write and test the code extensions. So someone finds a
routine, modifies it and then propagates it through word-of-mouth hoping it
will become the new de facto standard. After a few cycles of this, voila,
you suddenly find during 2000 inventory and impact analysis that you have
20 or more variations being used.
But a greater problem is the huge amount of in-line date processing code
that isn't even tied to a routine. In-line date code mixed with regular
code is like a bomb waiting to go off and leads to one major headache! I
was talking to someone recently who found in-line code to test for a leap
year in a system that was not written too long ago. The code was simply to
divide by 4 and check for a remainder! Now although this will work for the
next 104 years, one has to wonder if the person who wrote this knew the
rules or didn't know that there are additional tests related to century
years. Replacing in-line code with a call to a standardized date routine
should be a priority in all 2000 projects.
A reliable, comprehensive and portable date routine is an integral part of
the overall 2000 solution. Such a routine will also help lessen testing
costs and should therefore save project dollars.
Bottom line is: Date code is not as simple or easy to write as many think
and there are many opportunities for errors. Writing, extending and
maintaining date routines is an overhead function that doesn't generate
additional revenue for a company, so why do it?
-- Joe Warren , TransCentury Data Systems
---------------------------------------------------------------------------
5.5 Why is testing year-2000 code so hard?
***
First you have to make sure you haven't messed up the processing of current
1990's dates. This is the easy part. It's the normal testing you do all the
time. The only thing that makes it hard is the scope -- you will have to
retest practically all your systems.
Unfortunately, this doesn't test whether your changes do, in fact,
correctly handle dates after 1999. To do that, you have to use future
dates. There are software packages available for IBM mainframe MVS that
will intercept requests for the system date and substitute a test date. But
even that's not good enough. Your current files don't have dates after 1999
in them, so ...
you will have to create test data with future dates for every application
in your system! There are software packages available to "age" data files
for this purpose.
Once you do that, of course, you have nothing to compare the results to.
You can't do parallel testing, so ...
you will have to manually verify the results!
It is likely that you will make a lot of mistakes in the process of
manually verifying your test results. There are software packages designed
to address this problem by excluding date fields from a file compare. This
still leaves the problem of verifying that the dates in the output are
correct.
I've mentioned three places where software can help. Selecting, installing,
and learning to use that software is a significant effort and expense. It
makes the testing easier, but not easy. People are now saying that testing
will account for at least 50% of the year-2000 conversion effort.
There are some complications in aging data. You can't just roll all the
dates in the data past 2000. If all the dates are in the same century,
there's a good chance the application will work just fine without any
changes. That is, after all, the way it is running now. You need data that
straddles the 1999-2000 boundary to make sure the date calculations,
comparisons, and sorting are correct. Also, simply rolling the dates
forward by an integral number of years may not work if the application is
sensitive to the day of the week, holidays, or a fiscal year that is not
exactly in sync with the calendar year. There are no easy answers, and
there is no one solution that will be right for all situations.
-- Robert J. Sandler , revised Dec. 1997
***
Systems must be well tested to ensure that functionality has not been
changed in any program as a result of the date changes. This means a unit
test of the program, a system test with a test bed of data covering all
functions, a simulation test to any date in the future that may impact your
system (this involves moving your data and your system date into the
future), and finally, a test with historical data to make sure you can
process old data through the system once changes are complete. Developing a
test bed for these changes is a significant task. The testing stage
represents 40% of the effort for the entire project.
Organizations that have established inventories, change control procedures,
and test beds of data can move quickly and efficiently through this
process. For most though, these steps will form a significant part of their
Year 2000 project.
-- Brenda McKelvey from a report on the "Year 2000:
Blueprint for Success" conference in Orlando, Florida, November 1995
***
Having now worked as Y2k project manager with two very different
organizations, we are finding that testing requires a MINIMUM of 60% of the
effort. On my current assignment, it is closer to 80%. This assignment uses
windowing exclusively. The previous one used expansion exclusively. . . .
One of the most significant aspects of testing has been the running of a
baseline test set BEFORE upgrading the software. This was not done on our
pilot and we paid for it big time (that's what pilots are for, right). We
found a number of processing errors during system testing and spent
significant effort resolving them, only to find out they came with the
migrated code.
We just completed doing the baseline on one of our applications and, guess
what, we hit the condition again. There are several programs that won't
compile and a couple of others that don't run the same way as they do in
production. Having the baseline will avoid repeating the pain experienced
in the pilot.
This results in a net time saving but increases the testing vs upgrade
ratio. It also means that we have to resist jumping in and changing code
before the baseline is run (that is a major phychological hurdle when the
pressures are very high to get things fixed).
-- Larry Towner , 19 Mar 1998
***
The Y2K project I am working on is moving into the modification and testing
stage. We've analyzed progams, and picked a pilot (initial release) and now
it's time to get our feet wet. Ideally we'd like to test at the client
site, and not use any testing tools to time warp the date. However, I'm
running into difficulties finding a shop that has Y2K compliant system
software. Our client won't have a Y2K compliant machine until mid 4th
quarter this year. Which is really late for testing to begin.
What's the general approach in this group? Are people using tools? How are
people including the system software in their overall strategy? Do I have
sugarplums in my head if I think I can find a Y2K compliant machine, before
December 25, 1998?
-- Ruth Younie 22 Jan 97
You've encountered a "common" problem. I recognized a similar problem in
getting a separate testing machine spec'ed. I decided on the following
approach to delay the required delivery of that software and hardware.
I'm doing a "multiple pass" testing approach thru the applications
portfolio to get around the problem. The first pass will get our code to a
"minimally compliant" state. That is where the databases, files, programs,
data bridges, etc are all installed and tested using todays date and using
current data. Everything will look right, run right, and go back into
production. You can't say that you are totally compliant but you can say
you are "minimally compliant". I can do this, and you can also, without
changing any systems dates or getting any new versions of software.
The implication is that you haven't accepted "extra baggage" on the project
that require new software from the start. Things such as an operating
systems upgrade to use new intrinsic functions, replacement of systems with
packages that require the new software, etc.
Projects where total efforts are already known to exceed available time
left would probably have real problems using this approach but that isn't
my problem or my company.
I expect, and accept, this to be a more expensive approach but it will
delay the need for the new box and software by several months of time.
Whether that separate box is yours or someone elses is your decision.
The second pass thru the testing cycle will require the software and
hardware you discussed. That second pass will be where
you change systems dates, install the Y2K complaint systems software, and
do the "time warp" testing. You are then successfully and fully "Y2K
compliant", a Y2K hero.
-- Harold Carruthers 24 Jan 97
***
In all the discussions there is one thing that is avoided or forgotten.
Testing applications that communicate over the network to own company
departments but also to outside companies...(EDI,FTP,Appl-Appl etc)
From your posts I see that you are already glad to have it run on and test
it on one machine.
But see the problems of testing, and even get a standard to work on with
linked machines (applications).
Example:
Company "A" has 4 outside links to other than his own company machines.
One of those outside companies has 15 links like that.
The other 14 companies I forget for the ease of talking. (but they are
there)
Now the programs communicate.
But can you test the new Y2K compliant updates?
You need all the machines on the same time online or a planner with an IQ
that is not available.
Or everyone needs testing it to each other one to one...
That means until 2005 when you have more to do or 15 different companies
linked.
This is a simple example of an environment.
Company "A" can't control the standard and testing time for the other
companies. They also can't.
This all in mixed mainframe, minis ,PC and Terminal configurations.
-- Hans Goossens , 05 Feb 1997
---------------------------------------------------------------------------
5.6 What are the critical dates that programs must be tested with?
***
I don't remember how many times such a question has been asked. Each time
it reveals that the questioner does not understand the fundamental aspect
of the Year 2000 Problem - IT IS DIFFERENT FOR EACH AND EVERY ONE OF US!!
There is no way (IMHO) that any one of us on this maillist can take the
responsibility for giving you a list of dates to check without
accomplishing a through evaluation of each and every one of YOUR business
processes to determine WHAT DATES YOU USE. The best that we can do is to
provide you a list of dates WE test for and let you decide which ones YOU
should test for based on YOUR business processes. Even then, I expect that
the list will miss at least one important (to you only) date. You or your
Internal Auditors would be extremely lax and nondiligent to remove even one
date based on a note form this or any other maillist.
I'm sorry, but each and every one of us has to accomplish this work for
ourselves. There is no way someone else can do it for us. Even if you have
some contractor build your systems, it's still YOUR responsibility to check
and make sure he got everything. Look at the postings to this maillist and
you will notice a very strong trend to saying YOU, and YOUR responsibility,
and YOU must test, and YOU must, etc. in everything. No one can do your
enterprise's work for you. Year 2000 is the ultimate "every enterprise for
itself" problem. This is not business as usual, letting a contractor or
"expert" tell you what to do and then slavishly following the advice.
Doesn't work for this problem.
This is not to flame anyone, but everyone MUST understand that you are in
this by yourself. Others can help, but you must do your own work to get
through this successfully.
-- Dave Hall , 23 Apr 1998
---------------------------------------------------------------------------
5.7 My concern centers on those systems that have already hit their "event
horizons" and have been fixed using whatever solution.
(a) Is it possible that these systems will still experience problems come
the first of January on the year 2000?
(b) If System A implements Fix1 instead of Fix2, does this mean System B
later has to implement Fix1 also, for compatibility purposes?
(c) Finally, is it possible that the immediate fixes today on System A may
adversely affect other systems which depend System A, either now (and the
other systems don't know it yet) or after the first of January on the year
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 These
questions are taken from the following note ...
I don't have a technical background but I do have a stake in the management
of this two digit nightmare. My concern centers on those systems that have
already hit their "event horizons" and have been fixed using whatever
solution. Is it possible that these systems will still experience problems
come 1/1/2000? I've been told by some who have already been forced to make
changes, that the only systems that are really in trouble are the ones that
won't hit they're event horizon until 1999 because all other systems will
have already been dealt with. Also, if System A implements Fix1 instead of
Fix2, does this mean System B later has to implement Fix1 also for
compatibility purposes? Finally, is it possible that the immediate fixes
today on System A may adversely affect other systems which depend System A
either now (and the other systems don't know it yet) or after 1/1/2000?
-- Brown, Capt Donald
***
on Mike Scullin's above answer to question a:
I couldn't agree more. Even though most installations will end up using a
combination of solutions (expansion, sliding, & even bit twiddling), we
should provide a standard set of utilities to the programmers, along with
some guiding principles.
First, there is nothing more imaginative than a programmer with an
interesting problem to solve. This usually results in mostly solid code ...
with a few really "nifty" solutions tossed in. In my experience it is the
"nifty" stuff that bites you in the long run ... often by destroying the
ability of vendor provided tools to help you when you need it most.
For instance, imagine that in a COBOL shop all date handling was done by an
assembler routine, software that traces the propagation of dates from one
module to another would probably get lost when the date went into this
"foreign" routine. Maybe it's not a great example, but I hope you get the
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
---------------------------------------------------------------------------
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 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
***
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
***
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
---------------------------------------------------------------------------
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
---------------------------------------------------------------------------
5.10 How does one pull together a reasonable Y2K plan, when management is
clearly reluctant to devote adequate resources to even determine the most
rudimentary extent of the problem?
***
I was just looking at some Howard Rubin statistics that pretty clearly say
that 60-70% of "senior IT management" is essentially oblivious to the Y2K
issue (in 1995).
-- David Eddy , Global Software, Inc.
***
It would seem that the best idea would be to formulate a letter designed
for the CIO/CFO/CEO that hits them (cold) with what the Y2K problem is and
just HOW serious it could be (for them specifically). Also it would also be
a good idea to come up with a list of suggestions that could be put into
place immediately and prior to any thought of a Y2K plan. Of course there
is not much time left for this kind of subtle approach, and this would need
to be done in 1995 or early 1996.
-- John Moffitt
---------------------------------------------------------------------------
5.11 What is encapsulation?
***
This is a very important question, the answer of which will have a major
impact on Y2K thinking in the coming months and years, I believe. It is
part of the larger question as to what are the all the possible major
approaches to Y2K protection.
(Note I used the word "protection" rather than "repair" or "fix." Those
last two imply that our programs are, or will be broken. We could debate
whether they really work now or just haven't broken yet, but the
truth is they do pretty much work now and given their rather fragile,
brittle nature, especially when considered in the context of contemplating
wholesale changes across a wide front in a short period of time, there is
something to be said for leaving them intact as much as possible. Could it
be that they do in fact work and all we have to do is "protect" them from
an "external change in the environment," that is, a time-shift out of their
assumed century?)
There are basically four approaches I see, other than replacement:
1) Date expansion
2) Windowing
3) Data encapsulation
4) Program encapsulation
Only the first two are normally considered on this [mailing] list. The last
two, like windowing, are examples of time-shifting. I am turning for the
definition of these terms to Don Estes of 2000 Technologies Corp. in
Lexington, MA . Don has written a draft
document of his exploration of the two encapsulation techniques which he
posted to this list on Jan 02 and sometime before as well. He has captured
the notions very well. I have his permission to use his words, which I have
reorganized slightly for my purpose and capitalized the key words. (Don
does not necessarily subscribe to my other thoughts.)
****
"DATE EXPANSION strategies change the data, the data descriptions within
the programs, and change logic throughout the programs.
WINDOWING schemes allowing maintenance of a 6 position date will usually
localize the changes to procedural logic, thus markedly reducing the scope
as compared to date expansion, but the changes are still pervasive
throughout the programs.
Time shifting strategies are similar to windowing in that a 6 position date
is maintained, but differ in that the programs effectively execute in the
past. There are two variations of time shifting:
DATA ENCAPSULATION, in which modified programs execute in the past against
unchanged data. Data encapsulation in most cases will localize changes to
the input and output logic sections of the program, which shift the data
back in time on input and forward on output.
PROGRAM ENCAPSULATION, in which unmodified programs execute in the past
against data which has been turned back in time. Program encapsulation in
most cases changes no code at all, which makes it a perfect solution for
cases where the source library is seriously lacking in integrity. In this
strategy, firewalls are constructed at the points where data enter and
leave the system which shift the data back in time on input and forward on
output.
Thus, the only architectural difference between the two strategies is that
data encapsulation does the time shift internally to the program and
program encapsulation does the time shift externally to the program."
(c) Logica Inc. 1996
Permission is granted for reproduction and distribution of this document
provided it is complete, unmodified, and retains all Logica identification
including this statement. All other reproduction and distribution is
expressly forbidden.
****
The most significant thing here, I think, is that program encapsulation
takes the time-shift function out of the program. This has great import for
its theoretical ability to preserve the "working" programs intact and
saving a lot of TIME. It has greater import in the case where source code
is missing or otherwise unavailable, a serious Achilles Heels for most
large organizations.
Source code could be unavailable for a variety of reasons besides just
being lost: it is unreadable from its obsolete media, it is uncompileable
because its compiler is obsolete and lost, it has been disconnected from
the object code that runs because the object was modified directly, it can
be in such an obscure language that no tools are available to analyze and
modify it and the amount to too great for only manual efforts, or it could
belong to a third party and be legally restricted. If programs with
unavailable source code could be protected, then a major sword could be
removed from over the heads of many organizations.
Further, what if more than one program could be encapsulated at a time?
What if collections of programs could be encapsulated as a unit, leaving
their interconnections intact as they are? From their point of view after
their external input data has been backset to the 20th Century, their
between-themselves interactions could be left as they are and their
external output could be forwardset. What if that unit could be large?
Could that not save a great deal of time and effort on this side of the
Millennium and buy us time on the other?
Oh sure, you would say. How can you encapsulate the program by changing the
date (and date-dependent) data incoming and outgoing if you don't know what
the program is doing with dates because you do not have the source code?
Good question. But what other "information source" about the system is
available? Documentation? Forget it. The kindest thing to say is that
documentation is insufficient. Human knowledge? For some code maybe, a big
maybe. But more likely that is also insufficient. But there is another
source of information available: the data itself.
If the data could be analyzed to determine the date-related behavior of
programs or groups of programs, maybe it would be possible to protect them
without intervening in their delicate operations (above all else, do no
harm). This, I believe, is a very promising field of endeavor. There are a
number of difficulties, no doubt, but what other approach offers a chance
to deal with unavailable source code in all of its variations and save big
chunks of time as well?
And for programs that do have available and current source code, program
encapsulation does offer some serious time savings, especially in testing
(another big Achilles Heel), where every change to the code has a potential
of raining "unintended consequences" over other programs, even beyond
application boundaries. True, program encapsulation does not "fix" the
problem, but wouldn't we rather replace many of these systems anyway IF WE
HAD THE TIME?
And what does "fix" really mean anyway? Does it mean carrying 8-digit dates
everywhere and the logic to go with them? I think a good case could be made
for taking date references and computations out of the application code
altogether *where possible* and "universalizing" them in some kind of a
"date server," like one based on TransCentury Data's standard date
routines. That would seem to me to be to be a more permanent and
maintainable fix. And while we are at it, why don't we take data management
out of the code and put it in a "database server" as well for the same
reasons? Sounds like a good idea (think I'll talk to Larry Ellison about
that). How about the user interface, too? (Steve Jobs?) Wow, this sounds
like a client/server architecture.
No, I say fixing but staying in an obsolete architecture is not really
fixing, not when there is a choice. Program encapsulation MAY give us that
choice. Later migration to a modern architecture is certainly a better
"fix" than distributing date representation and logic in every separate
program where "artistic flare" can make for clever programming but lousy
maintenance practice.
And oh, by the way, I would bet that the knowledge one would gain analyzing
the data to determine the date behavior would be VERY useful in later
modernization. Or data warehousing. But that is another story.
-- Dale W. Way , DBStar, Inc., 6 Jan 1997
***
NOTE: Program encapsulation is covered by U.S. Patent number 5,600,836,
which is assigned to Turn of the Century Solution, Inc. of Wayne, PA.
---------------------------------------------------------------------------
5.12 What is windowing?
Windowing is a method used to determine the century (the two high-order
digits of the year) for a two-digit year by presupposing that the year
falls in a specified 100-year range, or window. For example, if the window
is 1980 through 2079, any two-digit year of 80 or higher is in the 1900s,
and any two-digit year less than 80 is in the 2000s. If the range always
starts with the same year, as in this example, it is referred to as a fixed
window. The window can also be determined relative to the current year when
the program is running. This is called a sliding window. For example, if
the sliding window is defined as starting 20 years before the current year,
then when the program runs in 1997 the window is 1977 through 2076. When
the same program runs in 2001, the window is 1981 through 2080.
-- Robert J. Sandler
***
For the past 20 years we have used two digit year formats and all our
systems worked. We were in effect using a fixed window 1900 to 1999. It was
when we all became concerned with the year 2000 probelem that we started to
say that windowing pivot points create for us problems. If we use two digit
year date formats for dates whose range is near or greater then 100 years
we have a date format problem. The problem must have been there
irrespective of year 2000.
If the interfaces have been working for the past 10 years and are today
working then a sliding window with +15, -85 year about current year should
work.
Michael Yastreboff , 3 Apr 1997
---------------------------------------------------------------------------
5.13 How can you properly sort dates with two-digit years?
***
Both DFSORT/MVS Release 13 with PTF UN90139 and DFSORT/VSE with PTF UN99635
can sort, merge, and transform a wide variety of character, zoned decimal,
and packed decimal date formats with two-digit years using a fixed or
sliding century window. For details, see the DFSORT home page at one of the
following URLs.
For DFSORT/MVS:
http://www.storage.ibm.com/software/sort/srtmhome.htm
For DFSORT/VSE:
http://www.storage.ibm.com/software/sort/srtvhome.htm
-- Robert J. Sandler , 21 Jan 1997
***
DFSORT R13 PTF UQ05520, available now, delivers the following additional
DFSORT Year 2000 features requested by our customers:
o A new Y2S format. Y2S can sort, merge and transform two-digit character
or zoned decimal year data according to the century window, while handling
binary zeros, blanks and binary ones in the year field as special
indicators.
o A new Y2B format. Y2B can sort, merge and transform two-digit binary year
data according to the century window.
o FREE=CLOSE support for DFSPARM. This makes it possible to override SORT
statements generated by multiple COBOL SORT verbs in the same COBOL
program, using appropriate DFSPARM data sets with FREE=CLOSE.
Complete details on all of DFSORT's Year 2000 features, including these new
additions, can be found in our SORT2000 paper. You can browse SORT2000 from
the DFSORT home page at URL:
http://www.storage.ibm.com/dfsort/
or download sort2000.zip which contains postscipt and text versions of the
paper, via anonymous FTP from:
lscftp.pok.ibm.com/pub/mvs/docs/
or ask your IBM representative to obtain the SORT2000 paper for you from
MKTTOOLS.
-- Frank L. Yaeger , IBM DFSORT Team, 04 Jun 1997
***
The following two articles in Technical Support Magazine discuss DFSORT's
Year 2000 features:
- December, 1996, "Sorting Out Two-Digit Years" by Frank Yaeger
- October, 1997, "Year 2000 Compliance: New DFSORT Features" by Michael H.
Carroll
-- Frank L. Yaeger , IBM DFSORT Team, 28 Oct 1997
***
SyncSort MVS has been enhanced to provide facilities to define and
manipulate date-related data. New date formats have been added which treat
a two-digit year as an implicit four-digit year. This is accomplished with
a user defined "century window" value which is in effect during an
execution of SyncSort. The "century window" defines a fixed or sliding 100
year window. This places the two-digit year in the proper century for
SyncSort functions such as sorting, merging, record reformatting and data
conversion. The data formats can also be used to process the month and day
portion of a packed decimal field separately from the year portion. [This
feature requires that you have at least Syncsort release 3.6 TPF 2
installed.]
-- John Reda , Syncsort Inc., 06 Jan 1997
***
As of Q3 1996, Unibol supplies year sensitive sort features within UNIBOL
SORT. These work on ASCII or on EBCDIC data.
-- Michael Gerner , Unibol Ltd., U.K., 23 Jan 1997
===========================================================================
6. 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 , Can Do Systems, Inc.
***
The Year 2000 Information Center at http://www.year2000.com contains links
to information on over a hundred vendors of tools and services.
***
Com.Links Magazine, a management e-zine for Year 2000 issues at
http://www.comlinks.com, has a vendor page that "lists vendor web sites
taken from news releases, e-mail, robots & search engines." It has a brief
description of the product or service offered by each vendor.
***
Dreamtap Consulting has published an independent evaluation of tools for
Year2000 Impact Assessment of MVS applications, including CICS IMS COBOL
ASSEMBLER PLI FOCUS EASYTRIEVE DB2 and/or VSAM applications.
If you wish to check it out, it's available through
http://www.ozemail.com.au/~dreamtap/consult/year2000/index.html
-- Peter Eldridge-Smith , 01 Jan 1997
---------------------------------------------------------------------------
6.2 What role can the Internet take in the solution of the Y2K problems?
***
We need to find a way to collaborate on a global basis to set standards of
approach to solutions and to share every bit of knowledge as common
stakeholders in the down-side impact.
If we do not ...
Reactions to this suggestion are 80% based on a win-lose mindset. 'Let them
rot, maybe I can get out on top of this one.' This is based on an
incomplete understanding of the interdependency of this problem and a
paradigm that is more and more out of date. You cannot gain a competitive
advantage if you have handled your Y2K problem, and your suppliers and
customers have not.
Some reactions (from knowledgeable people) give hope. Their approach is
based on a win-win mentality and are in the spirit of organizing within the
company, within the branch, sharing knowledge, and so on. My findings (so
far) are that you're considered naive or overreacting (depending on your
status in the company). I think it will not happen on a large scale, but
that is no reason not to try.
We realize that sharing knowledge with the rest of the world will help
everybody more than trying to invent everything ourselves. That's why the
Year 2000 mailing list is a showcase for every company where top management
has not yet appreciated the value of Internet and the value of win-win
solutions.
-- Serge Bouwens
---------------------------------------------------------------------------
6.3 What mailing lists, newsgroups, archives and other Y2K references are
available on the Internet?
***
The Year 2000 Information Center home page on the World Wide Web is at
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. It also has a year-2000 bookstore -- see
question 6.4 for more information.
***
There is an Internet mailing list operated by Peter de Jager for
discussions of year 2000 computer problems. The list has over 2500 members,
and gets an average of about 60 messages per business day. This is a
moderated mailing list managed by a paid administrator and fully supported
by its members. Each member pays a subscription fee of US$50 yearly. (You
may contribute more if you wish.) New subscribers get a 30-day free trial.
To subscribe, select the "Year 2000 Announcement List" link from the Year
2000 Information Center home page at http://www.year2000.com. On the
subscription form, select the Yes radio button for the Discussion List. You
can also subscribe by sending e-mail to amy@year2000.com with SUBSCRIBE in
the subject line of the message. Subscriptions are processed manually, so
please be patient. The list can optionally be received in digest form
instead of individual messages. Invoices and receipts are available if
needed. Details will be sent when you subscribe.
Most of the material in this FAQ comes from this mailing list.
***
The Year 2000 Forum on CompuServe has discussions of all year 2000 issues,
and a collection of files, including this FAQ. There are over 1000 members.
To reach the forum, GO YEAR2000.
***
The Usenet newsgroup comp.software.year-2000 is dedicated to discussions of
year 2000 computer issues.
***
The current version of this Year 2000 FAQ is available from the Year 2000
Information Center at http://www.year2000.com. On the home page, select the
"Year 2000 Archive" link. The FAQ is the last item listed on the Archive
page.
The FAQ can also be obtained by anonymous FTP to www.year2000.com. It is in
the /pub/year2000 directory. The file name is y2kfaq.txt.
***
For the past 8 months the Society for Information Management (SIM) Year
2000 Working Group has been creating a web-based online conference where
year 2000 project managers can share their best practices and help each
other succeed. We are happy to announce that it is now open for a test
drive. The conference is free of charge to all.
To visit the conference and/or participate, enter via www.simnet.org, then
link to the SIM Year 2000 Working Group's website, and then link to the
conference. First time visitors need to register and then it's just a
matter of logging in and doing your thing. Update your "profile" to tell
people about yourself if you wish. Check out the help function -- It's
pretty good. Most of all, help us make this online conference facility
serve the common good and help all who visit.
The SIM best-practices conference is divided into 12 main "topic" areas
(e.g., conversion, testing, people issues, legal issues) with multiple
"conversations" (aka "threads") under each topic. Currently there are over
100 of these conversations so that one can focus their attention of the
specific matter of interest to them. There's also a "Play Zone" where
visitors can experiment as well as a "suggestion box" email address. The
conference has its own search engine also so that one can look for
information across multiple conversations. All content (unless profane,
mean-spirited , or otherwise unsuitable) will remain posted in the
conference for the duration.
SIM is a non-profit association of IS professionals.
-- Leon A. Kappelman, Ph.D. , Co-chair, Society for
Information Management's (SIM) Year 2000 Working Group; Associate
Professor, Business Computer Information Systems, College of Business
Administration, University of North Texas; March 12, 1997
***
Com.Links Magazine is the primary US web e-zine for Year 2000 issues,
featuring key papers, news, vendor information and all legislative reports
from Washington. This resource can be found at http://www.comlinks.com
Also at this site are details of Countdown 2000, the Y2K television
program, and Y2K Investor, the Washington DC twice-weekly radio program.
-- Alan Simpson , Managing Editor, Com.Links
Magazine, October 19, 1996
***
IBM is making available to everyone a comprehensive Year 2000 resource
guide, at no charge. The guide explains Year 2000 issues and helps users,
vendors and customers successfully plan for and implement Year 2000
transitions. The 180-page document, entitled "The Year 2000 and 2-Digit
Dates: A Guide for Planning and Introduction," is available on the World
Wide Web through the IBM Software Home Page, at
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
***
Here's some info I received today from our [Microsoft] rep:
Microsoft and the Year 2000
Wednesday, April 15, 1998, Microsoft will introduce the "Year 2000 Resource
Center" (http://www.microsoft.com/year2000/). This site will include
Microsoft's definition of compliance, categorize each MS product based on
that definition of compliance (compliant, compliant w/minor issues, or not
compliant), offer detailed testing guidelines and recommendations, and
provide information on Third party "Year 2000" tools.
This will be an evolving site. Check it periodically for updates.
-- Anne Voigt , 14 Apr 1998
***
The Y2K Links Database site is about providing a quick links and
informational databases. We bench test and provide a first-look at software
and hardware that could help solve your Y2K problem. Y2K Links is also the
hub of the Year 2000 Millennium resource Site Ring. A group of web sites
dedicated to the year 2000 problem and combined the largest Y2K resource on
the Net. Y2K Links is owned by Pc Check inc.
http://www.y2klinks.com
http://www.pccheck.com
-- Natasha, 2 Oct 1997
***
Hardware/Software Compliance Information
Feedback from web site visitors tells us that there is a real interest in
accessing compliance information on commercial computer hardware platforms
and software packages. We have just created a new section on the site to
contain links to such information as provided by the manufacturers. Our
listing is small at present but sure to grow:
http://www.year2000.com/NFinfo.html
Companies interested in listing or linking to their compliance information
from this page should contact Shaun de Jager at shaun@year2000.com
-- Cliff Kurtzman , April 4, 1997
***
Vendor compliance lists -- 3rd party software
Mike Zbierski wrote:
>I was just wondering if anyone is keeping a list of non-compliant 3rd
>party software on the market. I am sure there are millions of them but
>it would be handy to know where to start looking.
A few weeks ago, I asked a similar question. Here is a summary.
Thanks to Robert Franchi, Diana and Michael who replied to me directly
(sorry, I lost a couple of surnames).
From Diana (dlk@welchlink.welch.jhu.edu):
http://jhmcis.med.jhu.edu/y2000/y2menu.htm
From Michael (mikeg@lexicon.net.au):
http://www.is.ufl.edu/bawb052h.htm
From Robert Franchi (Robert.Franchi@FMR.Com):
http://ftp.ssa.gov/year2000/y2klist.htm
http://www.mitre.org/research/y2k/
All great resources - thanks.
-- Gihan Perera , 02 May 1997
***
The state of Washington has a pretty good web-site for y2k stuff, including
hardware and software vendor lists. The contents of the lists are responses
from the vendors, not the results of testing by a third party, so should be
taken with a grain or two of salt 8^) The lists aren't complete, and have
lots of "No Response" entries . . .
The url is
http://www.wa.go/dis/2000/y2000.htm
-- Pam Hystad, Sys Dev Spec, CDSI for USEPA at MED-D, 21 Jan 1997
***
The U. S. government Year 2000 Interagency Committee and the General
Services Administration, Office of Governmentwide Policy, maintain a Year
2000 Information Directory at
http://www.itpolicy.gsa.gov/mks/yr2000/y201toc1.htm.
***
Unisys has a year 2000 web site at
http://www.unisys.com/marketplace/year2000/
***
I just updated my annotated bookmarks web page at
http://kode.net/~ggirod/bookmark.html
The objective of this page is to accumulate links to technical articles on
the Y2K problem and supporting information such as testing, software
quality, and project/program management. I am trying to minimize general
Y2K information which seems well supported on other sites and vendor
listings which are similarly well supported.
I hope that you find it useful and I also hope that you will contribute
some of your links to this page. Your comments and ideas are most welcome.
-- George Girod , 05 Jan 1997
***
As part of our "creating awareness" process we have created a web page
containing links to magazine articles and [the Year 2000 Information Center
home page] as well as attempting to maintain an archive of the [mailing
list's] daily digests.
http://www.ttuhsc.edu/pages/year2000/ttuy2k.htm
There's some redundancy but hopefully enough new to make it worth a visit.
Let me know what you think.
-- Robert Lieb
***
Jan de Decker maintains a collection of references to
press articles about the year 2000 problem on the World Wide Web at
http://www.club.innet.be/~janjedsp/y2k.htm
***
The U.S. Air Force HQ Standard Systems Group has a very extensive Y2K Web
site located at URL: http://lgm.ssc.af.mil/y2k/y2k.htm
-- Robert P. Coble , 08 Oct 1996
***
We at Xpress Software, Inc (XPS) have been sponsoring an open discussion in
our web page, both in a Bulletin Board format and Interactive Chat Rooms.
All vendors and users welcome. No censorship. http://www.xpsoft.com/
-- , 8 Jan 1997
***
The Information Technology Association of America (ITAA) and the Software
Productivity Consortium (SPC) have announced a program for certifying the
competency of software and service vendors in dealing with year 2000
software problems. Companies that meet the certification criteria will be
listed in a public database on the World Wide Web at
http://www.itaa.org/2000cert.htm.
-- Gary H. Anthes, "Trade groups roll out year 2000 seal of approval,"
Computerworld, October 7, 1996
I think that there is a bit of confusion about ITAA certification, so more
if you are looking for a software certification.
ITAA certification DOES NOT certify software. It is focused at Y2K service
providers and tries to assess "Y2K process" practices of that service
provider. Very similar to SEI-SMM (Software Maturity Model).
It is suppose to give you a feeling of security when you are outsourcing
your Y2K project, but it won't certify yours (or any commercial software
package) as Y2K compliant.
-- Miro Medek , Mitretek Systems, 26 Feb 1997
***
"The Economic Effects of the Year 2000 Problem on the United States," a
white paper by Capers Jones of Software Productivity Research, Inc., is
available as an Adobe Acrobat document (57 pages!) at http://www.spr.com.
This is probably the most terrifying document I have ever read, and from an
unimpeachable source too. It is must reading for any executive.
-- Bill Daniels , Data Dimensions, Inc,
06 Oct 1996
---------------------------------------------------------------------------
6.4 What books and other published references are available on this
problem?
***
With over 30 titles listed, the Year2000.com book store is the one-stop
place to find the latest Year 2000 books. Many of the in-stock books in the
Year2000.com book store are offered at 20-30% off through our association
with Amazon.com. All books are available from Amazon.com with worldwide
shipping. Visit the Year2000.com book store at:
http://www.year2000.com/y2kbooks.html
***
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.
***
The U.S. General Accounting Office (GAO) has released an exposure draft of
its year 2000 assessment guide. The guide, entitled Year 2000 Computing
Crisis: An Assessment Guide (GAO/AIMD-10.1.14, February 1997), presents a
structured approach and a checklist to aid organizations in planning,
managing, and evaluating their year 2000 programs.
You may order by mail (the first copy is free):
U.S. General Accounting Office
P.O. Box 6015
Gaithersburg, MD 20884-6015
Orders may also be placed by calling (202) 512-6000 or by using fax number
(301) 258-4066, or TDD (301) 413-0006.
An electronic version of this guide is also available from GAO's World Wide
Web server at URL http://www.gao.gov/.
-- Mike Dolak , 26 Feb 1997
---------------------------------------------------------------------------
6.5 What standards exist for computer representation of dates? Where can I
get copies of these standards? Are they available on the Internet?
"The nice thing about standards is that you have so many to choose from
. . ."
(Andrew S. Tanenbaum, "Computer Networks," Prentice-Hall, 1981, p. 168).
Both the American National Standards Institute (ANSI) and the International
Organization for Standardization (ISO) have standards for computer
representation of dates. Unfortunately, both standards allow a number of
different formats, including some formats that have only two digits for the
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 the ANSI home page. (The ordering
information seems to say that you have to have a deposit account with them
to order by phone, but they do accept credit card orders.) From the ISO
home page you can find out who sells ISO standards in other countries.
ANSI X3.30-1985 (R1991) "Representation for Calendar Date and Ordinal Date
for Information Interchange" is two pages and costs US$14 plus $4 handling.
ISO 8601:1988 "Data elements and interchange formats -- Information
interchange -- Representation of dates and times" is 14 pages and costs
US$48 plus $5 handling.
(Prices as of September 1995)
---------------------------------------------------------------------------
6.6 I have to assess how much of a problem we have with legacy assembler
code. Any ideas/products/vendors to facilitate the analysis?
***
There is no silver bullet solution to the year 2000 problem, especially for
low-level languages like Assembler. The best developers can hope for is to
automate the processes of code analysis to identify date problems, and
impact analysis on proposed changes. The objective is to enter testing with
as high a degree of confidence as possible that errors will not be present.
Year 2000 is the most timescaled project in IT history. Vendors must react
quickly to the demands of the industry, yet produce high quality tools.
Assembler and PL/1 are at the unfashionable end of the market for vendors,
yet they present the most complex legacy problems.
***
Software Migrations Limited and Durham Software Engineering are applying
the technology of their reverse engineering tool FermaT to the looming
problem of the year 2000.
FermaT is an easy to use formal methods tool for analysis, restructuring
and migration. It has been proved in industry, notably on migration of
Assembler to C and COBOL. The secret of FermaT is that it captures all the
functionality of the application, and reverse engineers it to a high level
specification, restructured code, or a new language. Retention of semantic
equivalence is guaranteed - black box test suites remain valid.
Functionality, including year 2000, can also be altered during
restructuring or migration.
FermaT 2000 is a version of FermaT tailored explicitly for year 2000
analysis. It tracks date variables through registers, scratch (and misused)
variables, and offsets into memory areas. It then identifies operations
carried out on, and using, dates. The output is an annotated and commented
listing of the source code in machine-readable form, and a set of metrics
giving a profile of the code and year 2000 problem incidence.
Initially FermaT 2000 will handle IBM Assembler and Jovial, to be followed
by other 'difficult' languages for which a demand is established - for
instance PL/1, FORTRAN, CORAL, and other assemblers. Because only a subset
of the full functionality of FermaT is required, it is possible for our
tool development team to react quickly to market demands.
FermaT 2000 is available as a tool or a service. It is the only high-
capability solution available to the owners of Assembler systems.
-- John Ashley , Durham Software Engineering Ltd,
Durham, United Kingdom DH1 3SW
***
Assembler (and other languages beside COBOL) are sticky issues for the year
2000. Most of the tools available assume COBOL and many of them assume IBM
environments. There are a few tools and services, however, that are
language independent and fewer that are platform independent, but you need
to hunt for them. I am continually surprised at the number of languages
concurrently in use in today's MIS shops.
Language independent tools (like the one that facilitates the Peritus Year
2000 Enhancement Program) have an architecture that permits multiple
languages to be processed, but a particular language or dialect may require
customization work by the vendor. Most vendors are willing to do this if
the business makes business sense. (For example, we have discussed doing an
Assembler front-end but have not yet had any serious interest from a client
to do so.)
With respect to the companies we are talking with, Assembler seems to be a
small percentage of their total code and they say they will do the
assembler portions by hand. I would be interested in the sets of languages
(programming, database, 4GL, etc.) that people use in their companies and
what percentage of the total code is in each language.
-- Ted Swoyer , Peritus Software Services, Inc.
---------------------------------------------------------------------------
6.7 I've discovered that I have compiled applications that I do not have
the source code for. How can I get the source code back in order to fix it?
***
The Source Recovery Company in Roswell, Georgia, USA, recovers lost COBOL
or Assembler source from IBM MVS, VM or VSE executable modules. We recover
back to the original language and guarantee functional equivalency to the
original executable.
-- Jim Rahm , The Source Recovery Company,
+1-770-650-1090; http://www.source-recovery.com
***
I realize that missing source code is symptomatic of slack management
procedures and not reserved to Y2K. We could also say that if every I/S
shop had adopted better date standards none of this would be necessary. But
we didn't, so how are we going to deal with it?
Chris Gardner of ViaSoft may have summed it up best however when he
referred to the *problem* as trying to turn a sausage back into a pig! You
can try but what comes out isn't pretty!
-- Mike Turgeon
***
The applications programmers around here always think they have lost source
code, because they forget that systems support takes backups. Did you
remember to check your oldest backup tapes for that source data? Otherwise,
I'm afraid to say that disassembling your programs is your only hope ... or
you can rewrite them.
---------------------------------------------------------------------------
6.8 Is there a Year 2000 user group near me?
A list of Year 2000 user groups can be accessed from the Year 2000
Information Center home page at http://www.year2000.com. Select the "Year
2000 User Groups" link.
***
There is a list of Y2K user groups at http://www.henterprises.com/tick3
-- William H. Goodwin <71776.3131@CompuServe.com>, 12 Nov 1996
===========================================================================
7. APPENDIX
7.1 Contributors
Two people must be given special thanks. First and foremost is John Moffitt
, who performed the enormous task of putting
together the original version of this FAQ.
The second is Peter de Jager , who started the Year
2000 mailing list from which this FAQ grew, and who created and maintains
the Year 2000 Information Center on the World Wide Web, from which this FAQ
is distributed.
Others who have contributed are listed in alphabetical order.
David Alcock
Michael J. Averbuch
Tony Baker <75321.2171@compuserve.com>
George W. Ball
Brian Bechtel
Tom Becker
Gary Blythe
Serge Bouwens
Donald Brown
William Burrow
Harold Carruthers
John Carter
Brian Christenson
Adrian Clark
Pierre Cloutier
Robert P. Coble
Duncan G. Connall
Nancy Copes <75362.60@compuserve.com>
Bill Daniels
Floyd L. Davidson
Donald G. Davis
Antoinette de Jager
Sander de Jong
Chuck Dennison <72165.1005@compuserve.com>
Mike Dolak
Mike Drabicky
David Eddy
Andrew Eldridge
Peter Eldridge-Smith
Don Estes
Sid Faber
Karl W. Feilder
Robert Franchi
John Franciscovich
R. Gama
Roger Gates
Peter Genadry
Michael Gerner
Bear Giles
George Girod
Sherry L. Goncharsky
Craig Goodrich
William H. Goodwin <71776.3131@CompuServe.com>
Hans Goossens
Joe Gwinn
Dave Hall
Reg Harbeck
Francis J. Hensler
Karen D. Herbert
John L. Horton
Ron Hunter-Duvar
Pam Hystad
Lanny Jones
Leon A. Kappelman, Ph.D.
Dave King
David Kipping
Cliff Kurtzman
Romy Leibler
Robert Lieb
Gene Lynd
Jacqui Macdougal
Francis D. MacLellan
Geoff May
Bob McClenon
Brenda McKelvey
Pat McKeown
Daniel A. McLaughlin
Miro Medek
Didier Morandi
Derek Morgan
Dick Murray
David A, Negrey
Robert Neuschul <72241.1346@compuserve.com>
Richard Newbold
Patrick O'Beirne
Alf Ohlsson
Mike Olsem
Bill Parkinson
Sherry Pauly
Gihan Perera
Raghavendra Rao
Phil Randal
Ed Ravin
John Reda
Dave Rybarczyk
Rob Schneider
Pris Sears
Stan Sieler
David Silver
David A. Smith
Gary L. Smith
Harlan Smith <71530.1637@compuserve.com>
Ivan C. Smith
Jens Peter Soltoft
Peter Somers
Tom Ster
Jonathan Swinton
Ted Swoyer
Marty Tabnik
Ralph G. Taylor
Randall Thomas <76646.333@compuserve.com>
James Tinsley
Rick Toker
Larry Towner