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 Arnold Trembley Mike Turgeon Diana van Dyk Allan E. Van Ness Steve Vogel Anne Voigt Joe Warren Dale W. Way Jerry Whittle Bob Wier Frank L. Yaeger Michael Yastreboff B. Young Ruth Younie Harold P Zbiegien Mike Zbierski Diana Michael Mike 7.2 Copyright and Permission Copyright 1995, 1996, 1997, 1998 Robert J. Sandler. All rights reserved. Contains material copyright by others. Permission is granted to copy and distribute this document by any means, provided that it is copied in its entirety, including this notice and the disclaimer below, and that no fee is charged other than the actual cost of transmission or reproduction or the standard connection-time charges on a BBS, on-line service, or Internet connection. It may not be distributed for financial gain or included in a commercial collection or compilation without prior permission from the copyright owner. Most company names and product names mentioned in this document are trademarks or registered trademarks of the respective companies. 7.3 Disclaimer While the information contained in this document is believed to be accurate, Robert J. Sandler, Peter de Jager, de Jager & Company Limited, The Tenagra Corporation, and the contributors do not guarantee the accuracy, adequacy, or completeness of the information, and assume no responsibility for errors or omissions, nor any liability for damages resulting from the use of this information. The views and opinions expressed in this document do not necessarily reflect the position of the maintainer. Affiliations are given for identification purposes only. --------------------------------------------------------------------------- End of the Year 2000 FAQ --------------------------------------------------------------------------- Robert J. Sandler