Date: 27 Feb 96 21:17:26 EST From: "Robert J. Sandler" <70023.2572@compuserve.com> To: Peter de Jager Subject: *** FAQ Ver. 2.1 Revised *** THE YEAR 2000 FAQ Version 2.1 - February 29, 1996 FREQUENTLY ASKED QUESTIONS ABOUT THE YEAR 2000 COMPUTER CRISIS See question 6.3 for information on how to obtain a copy of this FAQ. Maintained and edited by Robert J. Sandler <70023.2572@compuserve.com>. Originally created by John Moffitt. See question 7.1 for a list of contributors. --------------------------------------------------------------------------- Copyright 1995, 1996 Robert J. Sandler. All rights reserved. Contains material copyright by others. Permission is granted to copy and distribute this document by any means, provided that it is copied in its entirety, including this notice and the disclaimer below, and that no fee is charged other than the actual cost of transmission or reproduction or the standard connection-time charges on a BBS, on-line service, or Internet connection. It may not be distributed for financial gain or included in a commercial collection or compilation without prior permission from the copyright owner. Most company names and product names mentioned in this document are trademarks or registered trademarks of the respective companies. Disclaimer While the information contained in this document is believed to be accurate, Robert J. Sandler, Peter de Jager, de Jager & Co., The Tenagra Corporation, and the contributors do not guarantee the accuracy, adequacy, or completeness of the information, and assume no responsibility for errors or omissions, nor any liability for damages resulting from the use of this information. The views and opinions expressed in this document do not necessarily reflect the position of the maintainer. Affiliations are given for identification purposes only. --------------------------------------------------------------------------- PREFACE -- A Few Quotations to Set the Mood --------------------------------------------------------------------------- "The alternative to addressing the year 2000 will be going out of business." -- Kevin Schick, The Gartner Group "Computer Clock Watchers Anxiously Await the Millennium. Pessimists warn that on Jan. 1, 2000, thousands of computers may grind to a halt. Why? To save space when recording dates, many computer programs allow only two digits for years: as in '93'. Computers using such dates to determine a person's age or a past-due bill, for instance, may be stymied by the '00' in 2000. Larry Bacon, who oversees computers for Travelers Insurance, says 2000 may mark trouble for many firms with vast records based on the two-digit system. 'If you just ignore it and go home on Dec. 31, 1999, you could wake up with some real problems', says Mr. Bacon." -- Pamela Sebastian, The Wall Street Journal, March 4, 1993 "As the year 2000 approaches, MIS organizations across the country have been wrestling with the problem of reprogramming date-dependent systems. Date-dependency refers to how most programs depend on the manner in which dates are represented in order to run computations. But as of the first day of the next decade, the way in which days, months, and years have been identified up to now will, in many cases, become invalid. For example, COBOL programs currently represent Feb. 26, 1990 as 900226, and Jan. 1, 1991 as 910101, allowing the computer to compare the two numbers and correctly assume that the smaller number represents the earlier date. On Jan. 1, 2000, or 000101, however, those comparisons will fall apart." -- Informationweek, Feb. 18, 1991 "In a panel discussion, Infoworld columnist Cheryl Currid predicted that all mainframes will blow up on Dec. 31, 1999, when their clocks cannot figure out how to make the change to the year 2000." -- Stewart Alsop, Infoworld, Feb. 22, 1993 "For years, COBOL programmers have been writing programs which calculate dates for various business operations such as the age of consumer debt, the annuity on an investment, the monthly paymentson a mortgage, the exact 'nnn' days (weeks, months, years) from now and so on. For just as many years, programmers have known that time bombs have been planted in these business applications because in the year 2000, the final year of the current millennium, numerous programs will incorrectly calculate these date operations." -- Jerome Garfunkel, Enterprise Systems Journal, Oct. 1991 "Mainframers are in serious denial these days about what will happen a couple of seconds after midnight on Dec. 31, 1999, when many thousands of mainframe programs handling critical business applications discover they don't know how to deal with dates that include the year 2000. It's not that the world's COBOL programmers don't know how to fix the problem, or that current mainframe programming languages are incapable of handling dates in the next century. The problem is that mountain of old, fragile mainframe code still in use in business around the world - often running processes that lie right at the heart of a company's business. These applications have been around so long, were developed in such tangles of spaghetti code, and have been modified in undocumented ways so many times that no one now employed by the company knows how to fix them. In some cases, no one now alive knows how to fix them." -- Jim Seymour, PC Magazine, Mar. 16, 1993 "But now we have a unique technological disaster, that can be predicted very precisely, far ahead of the occurrence. The date on which the disaster will occur is known, and the time of day is also known. It will sweep all around the world, one time zone at a time. The nature of the disaster is known, and has been described precisely by several qualified and credible people, including Peter de Jager (who published a detailed description of the impending disaster more that six years in advance). The location of the disaster is known, and we know who will be affected. Yet the world continues to ignore it. It cannot possibly be postponed, and it will certainly be a major upheaval in many (all?) large organizations worldwide, including thousands of governments at the national, provincial/state, and municipal levels. Yet the world continues to ignore it. It is not really a complicated concept. It can be understood clearly by any 12-year-old who turns his mind to it, and no doubt there are tens of thousands of 12-year-olds who know all about it and could give a clear description of the impending disaster to any adult who would listen. Yet the world continues to ignore it. So, I subscribe to the Year 2000 mailing list, to keep abreast of current developments, and to collect ideas on how to awaken the various government departments." -- Ivan C. Smith, retired physics teacher --------------------------------------------------------------------------- CONTENTS --------------------------------------------------------------------------- 1. DEFINING THE PROBLEM 1.1 What is the year 2000 problem? 1.2 How serious is the year 2000 problem? 1.3 What is the year 2000 day-of-the-week problem? 1.4 What is the 1999 problem? 1.5 Is this only a COBOL problem? 1.6 What is the date-in-key problem? 1.7 What products have been found to have, or not have, 2000 problems? 1.8 What are the special year 2000 problems about tape archives? 1.9 How can I tell how big the problem is in my company? 1.10 Does anyone have any cost data or statistics on what it will cost to modify COBOL programs? 1.11 What happens to date programs when you try to use older more historical dates and at various locations around the world? 1.12 Are there some hidden problems (i.e. date thresholds) related to date storage that we have not yet thought of (or discussed)? 2. PROBLEMS WITH SPECIFIC HARDWARE AND SOFTWARE 2.1 What is the DOS BIOS problem? (a) Why does the BIOS date (year) seem to roll from 1999 to 1900? (b) Why does DOS (and Win95) seem to change the BIOS date to Jan 4, 1980? 2.2 Are there some Y2K problems with UNIX and/or C/C++? 2.3 Is there a special year-2000 problem with VMS? 3. SOCIAL AND HISTORICAL ASPECTS 3.1 What is the potential social/societal impact? 3.2 Has mankind ever had to deal with this kind of problem before? 3.3 Anyone got any idea what possible Y2K implications are known with reference to nuclear missiles and other military, software-controlled hardware? 4. CALENDARS AND DATE REPRESENTATION 4.1 Is 2000 a leap year? 4.2 Is there an ISO, ANSI, NIST, or other standard that defines the Gregorian calendar or the rules for leap year? 4.3 On what date will the 21st century begin? 4.4 How will we refer to those initial decades? 4.5 What is a Julian date? 4.6 What is an integer date? What is a Lilian date? 5. FIXING THE PROBLEM 5.1 What are the general programming (standards?) approaches that one could take to solve the various year 2000 problems? 5.2 In a large system fix, what are the trade-offs in changing the data versus changing the application programs? 5.3 What strategies are being considered for solving the following year 2000 problems: break point? field expansion? hex code? 5.4 Why should we try to have standardized date computation routines? Why don't we ALREADY have standardized date computation routines? 5.5 Why is testing year-2000 code so hard? 5.6 What are some important programming future dates for DOS system designers besides 1999 and 2000? 5.7 My concern centers on those systems that have already hit their "event horizons" and have been fixed using whatever solution. (a) Is it possible that these systems will still experience problems come the first of January on the year 2000? (b) If System A implements Fix1 instead of Fix2, does this mean System B later has to implement Fix1 also, for compatibility purposes? (c) Finally, is it possible that the immediate fixes today on System A may adversely affect other systems which depend System A, either now (and the other systems don't know it yet) or after the first of January on the year 2000? 5.8 What is a Bridge program? Why should I use a Bridge program? Is it a permanent solution for Y2K problems? 5.9 What are the problems with converting and testing a worldwide connected system of computers? 5.10 How does one pull together a reasonable Y2K plan, when management is clearly reluctant to devote adequate resources to even determine the most rudimentary extent of the problem? 6. RESOURCES AND TOOLS 6.1 Who provides tools and consulting services to help with our Y2K conversion efforts? 6.2 What role can the Internet take in the solution of the Y2K problems? 6.3 What mailing lists, news groups, archives and other Y2K references are available on the Internet? Are there any other published references on this problem? 6.4 I have to assess how much of a problem we have with legacy assembler code. Any ideas/products/vendors to facilitate the analysis? 6.5 What standards exist for computer representation of dates? Where can I get copies of these standards? Are they available on the Internet? 6.6 I'm near the beginning of my Y2K effort and I've discovered that I have compiled applications that I do not have the source code for. How can I get the source code back in order to fix it? 7. APPENDIX 7.1 Contributors 7.2 Copyright and Permission 7.3 Disclaimer =========================================================================== 1. DEFINING THE PROBLEM 1.1 What is the year 2000 problem? People see TIME as an endless continuum. Computers record time and dates as just another number, and as time progresses the time number gets bigger - so a FUTURE date is always LARGER than a PAST date. Some programmers interfered with this nice progression by deleting the century digits from dates - they didn't think they would be needed! Without the century digits the last day of this millennium will be 99-12-31, and after the stroke of midnight many computers will see January 1, 2000, as 00-01-01 - a SMALLER number than the day before - time will appear to have REVERSED. OLD will seem YOUNG, a FEW moments will seem like an ENTIRE century, FUTURE events will have ALREADY occurred. -- Duncan G. Connall , Global Software, Inc. --------------------------------------------------------------------------- 1.2 How serious is the year 2000 problem? Selected comments from the Year 2000 mailing list: *** According to Gartner group, 90% of the applications will be affected by the Date 2000 problem, and systems will crash, if the century problem is not corrected before 1999. 20% of business applications will fail due to date computations in the year 1995. Most major corporations are expected to spend about $50-100 million. The Gartner Group estimates "A medium size shop with approximately 8000 programs, each program averages 1500 LOC, and a data reference to LOC ratio of 1:50 will cost in the range of $450/program to $600/program or $3.6-$4.8 million for the entire initiative". There are an estimated 180 billion lines of COBOL code on MVS, and about 900,000 COBOL programmers dedicated to maintaining this code. If you would like to correct the date change operation, using automation tools and spread over a three year period 1996-1998, with out affecting the regular maintenance and new development, a minimum of 200,000 COBOL programmers should be added to the existing pool (Under the assumption that 1999 would be used, for fire-fighting measures). Going by the Gartner estimates, the total cost to correct the entire COBOL code would be US $48-65 billion. All these only for COBOL. Add Assembler, PL/I, Pick, ... -- Raghavendra Rao , Satyam Computer Services Limited *** A bit more directly ... a major factor in the complexity of the Y2K issue is that we're dealing with many, many systems that have effectively been on autopilot for perhaps decades. What & how these systems work is entirely unknown to the current owners. The fact that System A somehow effects System Z is a very difficult & expensive piece of knowledge to have. *** FYI, The July 1995 issue of CFO "The Magazine for Senior Financial Executives" ran a two page story by John Xenakis entitled: "The Millennium Bug, The Fin De Siecle Computer Virus -- COBOL programming can't handle dates after December 31, 1999. And don't count on your outsourcer to fix the problem." The story paints a picture of a catastrophe in the making. According to Benny Popek of Coopers & Lybrand LLP, "This problem is so big that we will consider these bugs to be out of the scope of our normal software maintenance contracts. For those clients who insist that we should take responsibility, we'll exercise the cancellation clause and terminate the outsourcing contract." And another quote from Popek, "We've found that a lot of our clients are in denial. We spoke to one CIO who just refused to deal with the problem, since he's going to retire next year." -- Cliff Kurtzman, The Tenagra Corporation, http://arganet.tenagra.com/ *** Many of the denial party are saying they are going third party and so that will fix everything. But the reality is that there are many buried issues here as well such as conversion of existing systems and access to historical data (Data Dimensions published a very interesting Millennium Journal article about 3 months ago on third party issues). But it seems like it is human nature to try to push off the inevitable. Unfortunately for many, 2000 is a non- negotiable date. No one (not even IBM) can stop it. -- Joe Warren , 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. --------------------------------------------------------------------------- 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, Fri, 16 Jun 1995 *** I was browsing in our HP/3000 COBOL II/XL manual looking for date-stuff and I see that there is something called "CURRENT-DATE" which returns an 8 byte field in the format 99/99/99 representing mm/dd/yy. There is also a function, as in "FUNCTION CURRENT-DATE" which returns everything you ever wanted to know about the date, time, etc. - even GMT deviation - including the year with the century included, as in 1995. The aforementioned "CURRENT-DATE" gets its values from the software clock while the "FUNCTION CURRENT-DATE" gets its info from the hardware clock. -- Francis D. MacLellan --------------------------------------------------------------------------- 1.6 What is the date-in-key problem? The basic problem is that many systems use a date as part of the key of an indexed file. This becomes a problem if the date has a two-digit year and the application depends on records in the file being in chronological order. Even if processing of the data does not depend on the records being in chronological order, it could result in records being listed in the wrong order in reports or on-screen displays. In 2000 and later, an application that is supposed to show the most recent items at the top, or on the first screen, would instead show 1999 items first. *** Sorting dates in VSAM keys I have received a couple of inquiries as to whether there will be something similar to the sorting capability being provided in DFSORT for Year 2000 will also be available for VSAM. As you may notice from the time it has taken me to respond to this inquiry, the answer is not a simple one. The interpretation of keys was never expected to be a VSAM responsibility. Therefore, the key is treated as a string of binary values based on the EBCDIC values of the characters in the code page used to enter the data. Therefore, the only valid order for VSAM KSDS to store data is in binary order. I agree that the actual usage of the keys often assigns meaning beyond what is recognizable by the programming support behind the manipulation of these keys. However, at this time, we do not plan on supporting any VSAM code to assist in proper sorting of dates within VSAM keys. We do recognize the need to look at the fact that the binary representation of data is not always the proper way to present data to humans. Other sort orderings are needed to handle two digit years or to have culturallycorrect sorting (another discussion in itself so that the sorted output uses the same alphabetical ordering as users of the language intend.) I do not expect that IBM will offer anything to address this issue as part of our YEAR 2000 support available by the end of 1996. Now, that does not mean that we do not recognize this as a product shortcoming. An interim solution would be to use DFSORT to reorder the output records so that they are presented correctly using a windowing technique with the appropriate starting value specified. If the records are too complex to sort (such as for multi-line output produced from a single key), then it will be necessary to obtain a list of the keys of the desired records, sort the keys, and obtain the records in the desired output order. I recognize that none of this is easy. For those of you who are VSAM KSDS users, I recommend that you evaluate the impact of this reliance on the interpretation of the keys to produce the necessary output. You can contact your IBM representative and they will be glad to assist you in creating a formal request for this requirement, giving details as to why other methods won't work and its impact. Once this is done the first time, others can just have their IBM representative concur with the existing requirement, adding account specific information. The amount of interest shown in solving 2-digit year designation with VSAM keys will influence the likelihood and timing of our (IBM) providing a solution. -- Sherry L. Goncharsky , IBM Strategy/Requirements, SSD Software Products, February 26, 1996 *** Of course, it's good to take the long view, and clearly 4-digit years are where we all want to be. But I think people are underestimating the difficulty in getting there. One large IBM mainframe COBOL app I am familiar with has nearly 4000 non-DBMS files and references over 3800 unique copy books. Data is passed among some 1600 batch and 500 TP programs, but also data is sent to and from outside applications and organizations via FTP and other means. What's worse, 6 separate copies of this application are run. It would take until the year 3000 to change one file at a time, but if you were to do many at once the effect would cascade throughout the system (and beyond). All programs and files affected would have to be deployed at the same time (or bridges constructed, also complex). Falling back in case of an error would be difficult or impossible, since earlier program versions would use different file formats. Testing, which would be crucial, would require new test data. Etc., etc. We are therefore working on support (as an alternative) for a program-logic based solution. Failure to consider the century in comparing or calculating dates amounts to a bug which must be fixed. Likewise with special handling of 00 or 99 (e.g., using them to mean null). Sorting on date is a special case -- see below. Reports and screens would be looked at case by case for readability. There could be bugs there as well, such as hard-coding 19xx or zero-suppressing the year. We have created a standard date routine using a sliding date window to "infer" the century in performing calculations on 2-digit years. The older routines were also upgraded, and in fact use the same code. The 00-99 range is divided into a 25-year forward portion (projected dates), and a 75-year backward portion (current year and 74 past years). The routine calculates a "forward century" (add 25 to current 4-digit year, take 2 hi-order digits), a "forward century endpoint" (same calculation, low order digits), and a "backward century" (subtract 75 from the current century). A special function makes these values available in open code, so programs can do their own century inference (e.g., in comparing dates, which could happen millions of time in a run). All date CALCULATIONS now hard-coded are to use the new routine, and for ease of use we have provided a macro to generate code to invoke it. We recommend a conventional structure to hold the date with 4-digit year, and provide an ISPFedit macro to generate it. We also provide a macro which (assuming the conventions) generates code to move the date and infer the century. In the example below, EFFECTIVE-DATE is a Julian date in a user program and has a 2-digit year. 007300 01 EFFECTIVE-DATE-YEAR4. 007400 05 EFFECTIVE-DATE-CC PIC 99. 007500 05 EFFECTIVE-DATE-YEAR2. 007600 10 EFFECTIVE-DATE-YY PIC 99. 007600 10 FILLER PIC 999. 017200 MOVE EFFECTIVE-DATE TO EFFECTIVE-DATE-YEAR2. 017300 IF EFFECTIVE-DATE-YY IS GREATER THAN MD2-ENDPOINT 017400 MOVE MD2 -BACKWARD-CENTURY TO EFFECTIVE-DATE-CC 017500 ELSE 017600 MOVE MD2-FORWARD-CENTURY TO EFFECTIVE-DATE-CC. This works even for special cases. E.g., in a year ending in 74, all years would be the current century. A 100-0 window (all dates current or historical, none in the future) would even work well enough. Note also that (contrary to opinion in this forum) a date window can, when a MINIMUM value can be applied, handle a range greater than 100 years. E.g., if you have no maximum retirement age, but have a minimum of, say, 16, then if in 1995 you encounter a birth date of 90 you could infer an age of 105 years, not 5. This might even be practical -- we might have 100-year-old U.S. federal employees, but we surely don't have any who are 116. Even Strom Thurmond isn't that old. Sorting data with 2-digit years as keys is sometimes considered a show-stopper for this approach. Even today the problem can be overcome with sort exits. However, sort products currently support data types and alternate collating sequences. Why can't they recognize DATE types or sequences -- a choice, each providing a different windowing scheme? I have talked to two vendors about this, and one said his company would have something later this year. It would be great to have something which could be put in place and tested today, without programming. COBOL sorts might not be accommodated, but these can deal with the problem in the INPUT PROCEDURE if necessary. If anyone agrees, contact your sort vendor. One nasty problem which would seem to require a file change would be a data base key with a 2-digit year. And even with a general "program logic" approach like the above, there would no doubt be other files which would make sense to change, mandated changes (IRS, SSA, etc.), bridges to build to/from outside apps, etc. Hope to see continued discussion on this issue. -- Gene Lynd , 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, 2000 problems? *** Before you go IPLing LPARs or a spare MVS machine, here's IBM's recent assessment for S/390 MVS year 2000 readiness: - ETR, 390 processors, MVS Timer facilities - CLEAN - Basic Control Program - CLEAN INTERNALLY - Key subsystems - CLEAN or SUPPORT PLANNED - LANGUAGES - CLEAN (latest releases) - LE/370 - CLEAN - Major IBM products - INITIAL ASSESSMENT APPEARS POSITIVE (that's nice!) - Applications - SIGNIFICANT CONCERNS -- Source: Year 2000, David E. Whitney, IBM Corporation, Software Design Center, Poughkeepsie, NY) *** During our last disaster test on June 22, we took the opportunity to see how our systems would react to a date of June 22, 2000. Our IBM mainframe software configuration included: MVS ESA 4.2.2 JES2 4.2.2 PL/I 2.3 COBOL II 1.4 RACF 1.9.2 SDSF 1.3.3 DFP/ESA 3.3 ISPF 3.5 Various reports were run with the following results: RACF: some password expirations were not picked up. In one case, the password interval left before we changed the system date was six days and warning messages had been generated. After the date change, this password was expired. In another case, there was still some time to go before expiration. After the date change, this password still was not expired. RACF: ICH70001I LAST ACCESS 14:11 ON NOVEMBER, JUNE 22, 1900 (somehow, this doesn't seem right!) RACF: the CONNECT command with a REVOKE date will not accept '00' as a year. SYSLOG: the date shows a 2-digit year (example: 00174). MVS: 'D T' shows a correct date. TSO: &SYSDATE gives 06/22/00, a 2-digit year. SDSF: DATE 8/06/52 (incorrect date) REXX date: 00.174, a 2-digit year. JES HASP: 22 JUN 00, a 2-digit year. Temporary DSnames: show a 2-digit year (SYS00174, etc.) PL/I compiler shows 22 JUNE 00 in the compiler report, a 2-digit year. PL/I execution: the built-in date function placed 14/08/00 in a report. The ISA date was 22 JUN 00. LKED: showed JUN 22, 2000 (Note to those programmers: pat yourselves on the back!) CA1CTS: 22 JUN 1900, an error. CA90ENF: 06/22/00, 2-digits. ASM H: 06/22/00, 2-digits. FILEAID: reports 'linked on' date as 00/06/22. JCL Allocation of a new file with EXPDT=99366: ISPF creation date shows 2000/06/22, and an expiration date of 1999/12/31! ISPF stats: created 00/06/23 (doesn't account for leap year). IDCAMS: 06/22/00, A 2-digit date. LISTCAT: shows 2000.174, a correct date. I know this is incomplete and not very thorough but it is all we had the time to do. *** Re VM and other IBM software: IBM has publicly stated they are reviewing all their products for Y2K problems, and will publish a document later this year (1995) giving the releases of each which will be "year 2000 ready." -- Gene Lynd , Defense Logistics Agency We are currently assessing the changes that are necessary in the VM/ESA operating system for the year 2000. You can expect to hear more about year 2000 support for VM, as well as more from an IBM-wide perspective, in the not- too-distant future. If you have technical questions about VM's support for the year 2000, you can either post them here or send them directly to me via e-mail and I will answer them as best, and as quickly as I can. -- John Franciscovich , VM Development, IBM Corporation (Endicott, NY) *** A list of Personal Computers which fail the following test: Disconnect the computer from any network or other system that might reset the date as it boots or connects. RTC (Real Time Clock) Rollover Test - Set the date to 31 December 1999. - Set the time to 23:58 (11:58 p.m.). - Check that the date and time have been set. - Switch off the computer. - Wait five (5) minutes. - Switch the computer back on. - Check the date and time. It should be a few minutes after midnight on the 1st of January 2000. RTC 2000 Set Test - Set the date to 01 December 2000. - Check that the date has been set. - Switch off the computer. - Wait a (1) minute. - Switch the computer back on. - Check the date. It should be the 1st of January 2000. DON'T FORGET - Reset your PC to the correct date and time! Many Personal Computers fail either both or the first of these tests and reset themselves to 04 January 1980, or some other ancient date, whenever they reboot, if the CMOS RTC (Real Time CLock) says the year is 00. Caution: some software with date checking (for example Windows 95 betas) may reset and not allow access after setting dates into the future. Why is this important? If your PC's date shows 1980 when it should say 2000, what damage will it do to you date dependent systems? The GOOD - Passes GA-586AT with Award Bios at 100 MHz DEC Venturis 4100 (486DX-100) Gateway 2000 P5-90 Macintosh PowerBook (model unknown) The BAD - Failures AST Advantage Adventure 8090p, AST BIOS R1.02 GA-486US, 33MHz Micro-Pro 8200 (AWARD MODULAR BIOS Version 3.20-00NM) - fails RTC Rollover Test, passes RTC 2000 Set Test Midwest Micro Intel 486 COMPAQ: Proliant 4100, Prosignia 300 5/75, DeskPro 575 DELL 466SE, Phoenix 80486 ROM BIOS Plus version 1.00 A09 Gateway 2000: - 486DX2/50, Phoenix 480486 ROM BIOS PLUS Version 0.10 GJX30-05E - 4DX2-66V, Phoenix 80486 ROM BIOS PLUS Version 0.10 GJX30-05E Hewlett Packard Vectra M2 486/66 IBM Cobalt Blue Lightning motherboard, 486 ISA/VESA, BIOS MR 1993, Version V1.53-OPTI481 - fails RTC Rollover Test, passes RTC 2000 Set Test. TMC Research Corporation PAT48PR, AMI BIOS Compiled by Geoff May of Network Business Services. Last update 01 November, 1995 Help with this project. Send your reports of computers that either pass or fail this test to Geoff May . Tell Geoff the PC's brand and model and the BIOS brand and version. The information needed will appear during boot-up (if you can read quickly) or can be found using tools such as Norton's (Symantec's) SysInfo, Microsoft's MSD or similar diagnostic product. Disclaimer: While every effort has been made to ensure the correctness of this list its accuracy cannot be guaranteed. The author(s), contributor(s), and publishers advise all people to check their own machines and contact their own vendors or suppliers. *** Of course many will be interested in MS-Windows 95. This package seems (at first glance) to be okay, however it may have a problem 100 years later (answers provided by the double Mike team). I've tested Windows 95 with dates past the year 2000, and here's what I've found: 1. Windows 95 itself has no problems with dates past 2000. It can only go up to the year 2099, though, but can still go back to 1980. However, the 2099 limit shouldn't be a problem for a while. 2. One of my Win3.1 applications, a talking clock, appropriately enough, choked on a post-2020 date; from 2000 to 2020, it interpreted the dates at 1900 to 1920! 3. One time, when I forgot to change the time back afterwards, I was unable to boot because my beta had "expired" in January 1996! I had to reinstall Windows 95. At least that won't be a problem in the commercial edition (which I haven't bought yet). -- Michael J. Averbuch 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 *** For the following IBM platform: MVS/ESA 4.3: In MVS the expiration date is a flag which simply denotes the file ordataset's "delete status." It does *not* mean that MVS will delete the file or dataset for you when the expiration date has been reached. In other words, if you try to delete a file or dataset before it's expiration date has been reached MVS will prompt you with a message like: "HEY, this [file, or dataset] hasn't expired yet. Are you sure you want to delete it?" And you say yes and delete it or no and don't. Simple. That was good news for me; prior to this discovery I ran a report on my DASD farm and discovered over 600 files and datasets with expiration dates of 99365. The EXPDT keyword of the TSO Allocate command and JCL DD parameter now accept YYDDD *and/or* YYYY/DD as valid expiration dates (formats). This means you can set *real* Y2K expiration dates. (Ain't MVS grand?) Furthermore, the EXPDT designations 99365, 99366, and 99999 continue to have the special meaning of "don't delete this dataset." Except testing *for that* is a little tougher (have to wait until 31DEC99). I guess if you *really* want a dataset to expire at the end of this century you will simply have to set it a day earlier or a day late. *** I've noticed a date problem with Paradox for Windows software. It treats 2000 as 1900 during a sort of the table. Even when the date is entered as 2000, it is treated as 00. -- David Silver *** I have Quicken version 3 (IBM PC) running on MS-DOS 6. I found that when I set the date to 01-01-2000 (as people reading this list already know, letting it wrap from 12-31-1999 results in 01-04-1980), Quicken interprets this as 1/1/1901. I suppose one obvious question is, why not 1900? But a more important question (to me anyway) is whether newer versions of Quicken have fixed this problems. (I REALLY like to post-date checks) Also, I have found that Quicken 3 does not allow me to enter a date of 01/01/00, nor does it accept YYYY on checks. One other interesting quirk: When I first start Quicken and open the check register, the year is listed as 2000. But as soon as I hit the Enter key, it reverts (?) to 1901. Clever programming, this. -- THHACKETT@vaxsar.vassar.edu *** I am aware that Consilium has recently released a version of their COBOL-based product which is now Y2K-compliant. I am also aware that SETPOINT's SETCIM product handles times correctly. -- Allan E. Van Ness *** 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 --------------------------------------------------------------------------- 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 oldrecords, 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 What is the DOS BIOS problem? (a) Why does the BIOS date (year) seem to roll from 1999 to 1900? (b) Why does DOS (and Win95) seem to change the BIOS date to Jan 4, 1980? *** This is just a test. It'll only take five minutes. It won't be painless, but ... the results may save a lot of anguish in the not too distant future. Set the date on your Personal Computer to December 31st 1999. Set the time to 23:58hrs (11:58pm) and then POWER OFF the computer. Wait at least 3 minutes and then turn the PC back on. Check the date and time. It SHOULD be a minute or two past midnight, on the morning of Saturday, January 1st 2000... My computer responds with January 4th... 1980. Not exactly what you would expect. The problem lies somewhere in your computer. If the system has the wrong date, then all your software has the wrong date. The good news is that this was only a test. The bad news is that on Dec 31st 1999, it won't be, it'll be painfully real. More than 80,000,000 PC's will be switched off as people leave work. When they return, their computers will be all but useless. How bad is the problem? How many PCs will really fail? Based upon predictions of people involved in the year 2000 problem, upwards of 80% of existing PCs are unreliable. On Jan 1st 2000, more than 80,000,000 PCs will think the Berlin wall is still standing and that Trudeau is still the prime Minister of Canada ... All your applications, Spreadsheets, accounting packages, day-timers, E-mail systems, even backup cycles will be at risk a few years from now, unless you solve the problem. In the meantime your problem is growing. Right now, a new PC is being installed. Is it year 2000 compatible? What about the PCs you buy tomorrow, next week and in 1996? -- Peter de Jager *** For AT-class (286 through Pentiums and clones) PCs running any DOS or Windows, The CMOS RTC hardware maintains a two-digit year (in address 9). The century (stored in CMOS address 50d and not maintained by the hardware logic) is not automatically incremented when the year overflows from 99 to 00, so the unfortunate result is that 2000-01-01 00:00:00 will appear to be 1900-01-01 00:00:00 in the CMOS RTC. The BIOS will set and read the century, but won't maintain it. DOS and Windows, however, will properly increment the date that they maintain - if the machine is running at 2000-01-01 00:00:00 - but neither DOS nor Windows will make the century change in the CMOS RTC. For as long as the machine continues to run through and after that date, the DOS (and Windows) date will be correct, but if the machine is rebooted or is started after 2000-01-01 00:00:00, the CMOS RTC will supply the apparent date of 1900-01-01 to DOS; this is an invalid date to DOS, which internally represents dates as days since 1980-01-01, so it mishandles it: the resulting DOS date is 1980-01-04. I am not aware of any modern AT-class (IBM-compatible) PC which behaves differently, and if one exists it is non-standard. -- Tom Becker , Air System Technologies Inc *** As previously determined, if you set the date to 12-31-99 and the time to 23:59:30 and let the clock tick, the date becomes 01-04-80. Any files created from this point forward, have their creation date equal to 01-04-80. If you set the date to 01-01-2000, the date is displayed as 01-01-2000; however, any files created at this time, have their creation date equal to 01-01-00. The Intel based PC's do have the capability of supporting dates in the year 2000 and beyond. The date just needs to be correctly entered on January 1, 2000. *** I just spent some time playing with this myself. On my PC (a TOSHIBA T4800), the date rolled over from 12/31/99 to 1/4/80! However, by using the DOS command DATE, I was able to set my system date forward beyond 2000. Once I had the date set forward, I was able to create new files which appeared to have an appropriate creation date (3/15/00 and 2/10/30) for the date that I had set my system date. FYI, for this part of the test, I used the DIR command in DOS to look at the directory. I also turned the machine off and rebooted to see if it retained the date properly; it rebooted with the date properly set in the future. However when I tried to use WINDOWS File Manager to look at the files in the directory, WINDOWS didn't show the date properly (it showed 3/15/%0 and 2/10/.0)!! I'm not sure whether this is just a display problem or not because the "sort by date" feature of File Manager placed them correctly. I also ran some similar tests on another machine (DELL 425s/L). On this machine, the date appeared to roll over properly but I encountered the same problems with File Manager for displaying the file information. Sooooo, I guess the problem might be ROM BIOS-related. But different BIOS's appear to handle the problem differently. Just what we need in large shop (11,000+ PCs)! -- Taylor, Ralph G *** 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 *** And moving onto those last two questions ... (a) That's easy ... the BIOS doesn't support Y2000 properly. It may just not handle the 1999-2000 rollover, you'd have to try a few Y2000 midnights to see what happens (see note below). (b) DOS didn't exist before 1980 so the BIOS/DOS never needed to support times prior to 1980. Why Jan 4th & not Jan 1st? NOTE: If you mentioned that you were using Win95. Remember this is beta code and has 'code fade' built into it. Had your BIOS not been defective, you would have been re-installing Win95. Once Win95 beta has been booted beyond the programmed date, the system will shutdown after giving you a brief message. Resetting the date to a current date doesn't fix this. -- Adrian Clark with Sears Canada, Technical Development *** question b: Since the person writing BIOS/DOS knew that the "current system date" could NEVER be before the time that the system (i.e. BIOS/DOS) was invented (created), then that person must have inserted a piece of code logic that said something like ... if the "current system date" is ever earlier than 1/4/1980, then set the "current system date" to equal 1/4/1980. It is evident that the person (or persons) considered 1/4/1980 as the "creation date" for BIOS/DOS(or something related to it), and that THIS was the date that the "current system date" could NEVER be earlier than. It is also clear that this piece of code logic is only activated under certain conditions, and that there are times when this code segment is never reached. Additional analysis will likely be done on this subject, as forces are brought forth to repair it. It is curious that this choice (setting the "current system date" to equal the "system creation date") was selected for this obvious error condition. Many other software action choices COULD have been selected instead of that. And what a far-sighted piece of code logic for an individual or individuals that failed to foresee the implications of selecting a two digit date field just a VERY short 20 years from the next turn of the century! Should we someday find that person's name, and post it here in this FAQ. -- John Moffitt (just an observation and some opinion) --------------------------------------------------------------------------- 2.2 Are there some Y2K problems with UNIX and/or C/C++? *** Here are a couple suggestions for the UNIX and/or C world. 1. Always use standard library calls. Use strftime(), even if you think it's a waste of time since it's so easy for you to do the conversions yourself. This way if there is a problem, it's in one place (strftime) and it will be much easier to fix. If you use "sprintfs" or direct string manipulation, changing the code is _much_ harder. 2. If you have to write your own time functions, keep them in a single place. C++ is very good at this; I have some database management routines which keep meteorological data in files with names based on the date; I have essentially only _one_ procedure which does the conversion from date to filename. 3. Try to use 4-digit years. If you use two-digit years, be sure to _always_ print only the last two digits. For instance, if you decide to ignore #1 and write the date yourself use: ::printf ("%2d-%2d-%2d", tm->tm_year % 100, 1 + tm->tm_mon, tm->tm_mday); instead of ::printf ("%2d-%2d-%2d", tm->tm_year, 1 + tm->tm_mon, tm->tm_mday); Simply putting these practices into effect, and correcting existing code during maintenance, will do wonders. If time allows (which, with most management, will be after Thanksgiving 1999) you can also "grep" for usage of terms like "tm_year" to try to find any uncorrected source code. -- Bear Giles *** A potentially very serious problem in the use of the UNIX seconds-since-01-01-1970 ("time_t"): Unix maintains the "time_t" date as a signed 32-bit integer containing the number of seconds since midnight, 01-01-1970 GMT. Strictly speaking, you are not supposed to do arithmetic on "time_t" objects, but that rule is often ignored. 19 Jan 2019 03:14:08 GMT: rollover By my calculations, the largest positive value in a signed 32 bit integer is 2^31-1 = 2147483647 seconds, or a little over 68 years. The base year 1970 + 68 is 2038, not 2019. (2147483647 s) / (60 s/m * 60 m/h * 24 h/d * 365.25 d/y) = 68.04965038533 years, approximately ;-) I know, I know, 365.25 is not exactly correct, depending on how many leap years versus non-leap years are spanned by the interval in question. That's why we need to have standardized date routines to do all these calculations. Note that negative times _are_ allowed. The man page for ctime(3) in HP-UX version 9.0 states that a time value of -1 is Dec 31, 1969 23:59:59! The date(1) command on HP-UX only accepts 2 digit years to change the system clock. I would rank this as being potentially more serious than Y2K. UNIX is heavily embedded in our infrastructure, and this format is now standard for most C/C++ programs. That means it is extremely widespread. There will undoubtably be proposals to extend this type to 64-bits well before 2019, but we're taking about a heavily installed base in telephone switches, satellite controllers, etc. -- Bear Giles and Roger Gates *** 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 *** 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 --------------------------------------------------------------------------- 2.3 Is there a special year-2000 problem with VMS? *** I have just spoken to Digital Equipment in Atlanta regarding VMS. They said that VMS is YEAR 2000 Compliant. -- Dick Murray *** 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 =========================================================================== 3. SOCIAL AND HISTORICAL ASPECTS 3.1 What is the potential social/societal impact? *** How stable can your year 2000 software project team be, when the company down the street is in the same predicament and offers huge 'incentives' to your staff to jump ship and help them? Expect computer programmer salaries to skyrocket as the deadline approaches (high demand and low supply). Many firms may have large numbers of computer tapes and files unexpectedly erased due to automated systems that haven't been told that time has reversed! Fallout from this is difficult to predict. Probably these same firms will try to hire more of those overpriced programmers. Yum Yum :-) If you can't get your accounting system up and running in three months you're out of business. Today's organizations CANNOT survive three months without cash flow. Yes, there WILL be a run on the banks as companies get desperate for cash advances. This is a bad thing :-( Assume you have the very best and the very brightest and your system is up and running in a week (loud laughter from the back of the room). How can you survive when a large number of your vendors and your customers are going under. A large depression could result from a large number of business failures. Now all of those overpriced programmers are back on the streets. This could be a VERY bad thing :-( Possible stock market crash??? Add to this the fact that supermarkets could have utterly bare shelves on 4th Jan 2000 because of the BIGGEST PARTY -- And the fact that their ordering system might go haywire. They might even go the other way and order 99 years' worth of supplies, but nothing comes in, due to all of their suppliers' computers being off-line. *** "In 1992 Mary Bandar of Winona, Minn was invited to join kindergarten class because she was born in '88 ... in fact she was 104 years old!" -- Brian Hayes in The RISKS Forum "In 1990, a 107 year old woman in Denmark received a letter from the local school system welcoming her to first grade. A man of 103 checked into a US hospital and was assigned to the pediatric ward. That's nothing, compared to what we can expect in the year 2000 - unless every organization that uses computers starts now to address the problems inherent in the fact that 00 is less than 99." -- Case Strategies, Dec. 1992 *** FUD (Fear, Uncertainty and Doubt) is a major motivating factor. Marketing and finance people are typically very familiar with its effective use. You can bet that come 1999, there will be plenty of short-selling of stock in corporations expected to be hit hard by this problem. -- Ron Hunter-Duvar 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 *** We are a large Supermarket company in England. We are now considering the ADDED problem of the fact that we will have utterly bare shelves on 4th Jan 2000 because of the BIGGEST PARTY ... Our ordering system might go haywire and order 99 years' worth of supplies. Compound this with the possibility that our suppliers' computers will be down ... We now think we might have to consider implementing a manual system to run in parallel with any fixes we make so that we can interface with those "less fortunates" who have not managed to weather the storm. And then there is the procedure for interfacing our manual system with our automated system etc ... We think we now have enough to make our CEO sit up and listen! -- Diana van Dyk , Year 2000 co-ordinator *** I am fascinated that no management forum is yet discussing the liability issue. For example: If company X's systems don't work properly after Y2K AND company X then suffers commercially - sells bad product; fails to sell or ship any product; fails to bill for a product; thinks all leases have expired, or worse puts human life or health at risk! etc.- then heads will roll! Starting at the top of data processing, but inevitably going much higher than that. In the USA we have 750,000 lawyers and they will SUE, SUE, SUE. They will sue company X, they will sue company X's auditors, and their outsourcers, and their financial backers, and their software suppliers, and their consultants etc. In fact they will sue anyone remotely connected with the failure. What do you think will happen to any government official remotely connected with such a mess? As a techie I am more than a little involved in the problem and its solution. If my solution (sold to a customer) does not work completely it has crossed my mind that I will be picked on as one of many organizations to BLAME - and help PAY for the cleanup. With this in mind, I have recently been checking my business liability policies. There are TWO precedents for this thinking: (1) The ASBESTOS suits, which have caused the dissolution of one major company, and has brought Lloyds of London to its knees. (2) The US Superfund (toxic waste cleanup) Act REQUIRES the owner of land containing toxic waste to pay for the cleanup even if the owner bought the land AFTER the waste was deposited. When the LIABILITY issue finally sinks into 'management', we will get action! For more than 30 years I have been using, and developing, 'buggy' software, so when I try to explain to lay people that all the software they use has the 'mother of all bugs' in it - they say 'what else is new?' When I suggest there is some previously unscheduled software maintenance to perform, they say 'well none of your other estimates was correct either!. But if I can explain CONVINCINGLY to people that many will lose a LOT of money, some will lose their JOBS, and some may even go to JAIL - maybe I will get their attention. -- Duncan G Connall *** I have not had the slightest problem explaining why computer systems will fail as dates are calculated into the next millennium. I have had great fun with this at dinner parties and the other guests have had great fun as more possibilities are suggested. (One person in particular though did not laugh. His business depended heavily on a computer system and he already had little confidence in the people who kept it going). - I suspect he asked some interesting questions on the following Monday. I start by explaining that the year is often stored as 2 digits and therefore 1999 will be 99 and 2000 will be 00. I explain that a human probably does not have much problem with this but a computer does as it is told, and decides that 00 is smaller than all the years in the 'nineties'. I then give examples ... - Corn beef with a seven year self life and stock management systems. The computer system that ditches old stock checks stock that was manufactured on say Jan 5th 1993. It calculated that it will expire on Jan 5th 2000 but stored the year as 00. As 00 was less than the current year of say 93, the system thought the stock had expired and released it. - The Bank vault opening system wakes up on 1st January 2000 which is a Saturday. It stores the year as 2 digits and therefore misinterprets the year as 1900. As 1/1/1900 was a Monday it opens the vault! - A car insurance system logs all driving convictions and calculates the date they will expire (5 years time). Anything after January 1995 expires in Jan 00 etc. Jan 00 is compared to the current date, deemed to be smaller, the conviction is deemed to be spent and is therefore deleted. The list goes on ... I have found though that the sorting and extraction of data within ranges problems are more difficult for a non-techie and the idea that the problem is not just applications but operating systems etc are impossible (although the PC date reset is helpful for this). -- Jacqui Macdougal *** 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 *** >From the Forum on Risks to the Public in Computers and Related Systems, 20 November 1989, Vol. 9, Issue 45, Peter G. Neumann, moderator Date: Fri, 17 Nov 89 9:17:33 BST From: Brian Randell Subject: Another foretaste of the Millenium We apologise for the unexpected system shutdown today (Thursday). This was caused by a bug in the MTS [Michigan Time Sharing] system that was a "time-bomb" in all senses of the word. It was triggered by today's date, 16th November 1989. This date is specially significant. Dates within the file system are stored as half-word (16 bit) values which are the number of days since the 1st March1900. The value of today's date is 32,768 decimal (X'8000' hexadecimal). This number is exactly 1 more than the largest positive integer that can be stored in a half-word (the left-most bit is the sign bit). As a result, various range checks that are performed on these dates began to fail when the date reached this value. The problem has a particular interest because all the MTS sites world-wide are similarly affected. Durham and Newcastle were the first to experience the bug because of time zone differences and we were the first to fix it. The American and Canadian MTS installations are some 4 to 8 hours behind us so the opportunity to be the first MTS site to fix such a serious problem has been some consolation. The work was done by our MTS specialist who struggled in from his sick bed to have just that satisfaction! *** Digital Equipment Corporation had a similar problem with the DECsystem-10 in 1975 because of field overflow. DEC's advisory late in 1974 had this to say (quoted in First Data Corporation, Newsletter 20, December, 1974): "When the software for the PDP-6 was being designed in 1964, a 12-bit date format was established. In order to maintain compatibility with old programs, that format was retained in successive monitor releases. Unfortunately, the 12-bit format cannot represent any date after January 4, 1975. Therefore, a DATE75 project was initiated in order to convert DEC-supplied software to a new 15-bit format that properly represents dates well into the next century. Support for 15-bit dates was designed to minimize conversion problems. Programs coded in a simple, straight-forward fashion will work properly with 15-bit dates without any modification. "Our experience in actually converting our existing software has been considerably more difficult than we ever anticipated. We keep finding new DATE75 problems. As a result, we have been forced to release a large amount of software on the November distribution tape; and customers will not have as much time as we would wish to install it all. Naturally, we recommend installing all of this software well before January 5, 1975. If this is not done, many DATE75 problems will be encountered. Keep in mind that DATE75 problems are essentially cosmetic. It is a nuisance to have files with incorrect creation and access dates, but it is not a catastrophe." But, "When a file gets an erroneous date because of a DATE75 problem, it may not be saved and restored in the intended fashion by FAILSAFE [the backup daemon]. This is a serious problem since it can result in files appearing lost." And, "We regret very much the lateness of the delivery of this software. We simply did not anticipate all the problems we would encounter. Customers should take advantage of the lesson we learned so painfully by immediately upgrading their DEC software to the versions released on the November tape, and by starting conversion of their own software... Our experience indicates that it is not sufficient for a programmer to simply 'think through' a program's structure and functions to determine whether it has a DATE75 problem. It is not sufficient merely to give the program a quick test with a monitor set to a date after January 4, 1975. It is necessary to run the total system for several hours in order to find all the subtle DATE75 problems." "Please keep in mind that DATE75 fixes have proven incredibly error prone. You must use great care and very thorough testing in order to be confident that DATE75 problems have been fixed... Most of the problems we found were in cases where we believed our programs followed these [omitted] procedures. Do not believe yours do!" -- Dave Rybarczyk *** Yes, and the Japanese are particularly well placed to take advantage of our chaos when the year 2000 rolls around (see below). *** "The year 2000 will be the first century change ever endured by an automated society and if your organizations uses computers, that means you are sitting on a time bomb." -- Randall L. Hitchens, Computerworld, Jan. 28, 1991 The above statement is not entirely true. When the Japanese Emperor died in 1989, the 64 year "Showa" period ended, an d Japanese business was forced to implement an Emperor Date change to the period "Heisei". This is equivalent to a century change, since the Emperor Date starts again at 1 for the new Emperor. Of course it was the first change in the computer era. Emperor Dates and Western Dates are used interchangeably in Japan. It is thought that 'the majority' of Japanese business made corrections to 2 digit Western Dates at the same time as they corrected for the Emperor change. Japanese business tends to be more composed concerning the year 2000 change, nevertheless there may well be problems there too. -- Duncan G Connall --------------------------------------------------------------------------- 3.3 Anyone got any idea what possible Y2K implications are known with reference to nuclear missiles and other military, software-controlled hardware? *** It is generally believed that nobody (especially the military) trusts the launching of nuclear missiles to software. Good idea as far as I'm concerned. All of this is believed to be under manual control (worldwide). Now guidance systems and lots of other software are associated with this process, but it would be hard to see why anyone would write date verification code into these algorithms. I doubt the military will offer this group any insight into where software takes place before, during, or after the launch of a nuclear missile. Do worry about all of the financial systems and the possibility of serious economic problems (which could lead to a war). =========================================================================== 4. CALENDARS AND DATE REPRESENTATION 4.1 Is 2000 a leap year? Yes. The rules for determining whether a given year is a leap year are: (1) If the year is evenly divisible by 4 it is a leap year, except for years ending in 00. (2) A year ending in 00 is a leap year if it is evenly divisible by 400. Therefore, 1900 was not a leap year, but 2000 will be a leap year. *** Leap Year Myths and Facts Please do not try to discuss these myths, or try to prove that they are not myths, on the Year 2000 Mailing List. We have all had our fill of leap year discussions. There are much more critical issues to be resolved, and time is running out. Myth: If the year is evenly divisible by 3200/3600/4000 (pick one) it is not a leap year. Fact: There is no such rule. The two rules given above are the complete rules for determining whether a year is a leap year in the Gregorian calendar. The popularity of this myth seems to derive from the fact that the average length of the year in the Gregorian calendar is approximately 26 seconds longer than the tropical or solar year. This difference amounts to one day in a little over 3300 years, or about three days in 10,000 years. Some experts have suggested rules similar to the mythical rule to correct for this difference. But no government, standards organization, or other authoritative body has adopted such a rule. Myth: The year 2000 will be a "double leap year." February will have 30 days and the year will be 367 days long. Fact: There is no such thing as a double leap year. It will be a leap year like any other leap year, with 29 days in February, and 366 days in the year. --------------------------------------------------------------------------- 4.2 Is there an ISO, ANSI, NIST, or other standard that defines the Gregorian calendar or the rules for leap year? No. There is no ISO, ANSI, NIST, or any other official standard, in the modern sense, for the Gregorian calendar. The Gregorian calendar was defined by the Roman Catholic Church, not by any modern standards-setting organization. The definition was established in 1582, long before today's standards organizations even existed. In 1582 the Church was the only organization in a position to establish anything resembling an international standard. The original and ultimate source for the definition of the Gregorian calendar is the papal bull "Inter gravissimas" (In the gravest concern) issued by Pope Gregory XIII in 1582. The legal basis for the Gregorian calendar in Great Britain and its former colonies is "An Act for regulating the commencement of the Year, and for correcting the Calendar now in use" passed by Parliament and approved by King George II in 1751. This act, of course, merely copies what had already been defined by the Church 169 years earlier. --------------------------------------------------------------------------- 4.3 On what date will the 21st century begin? *** The 1st century AD consisted of the years 1 through 100. The 20th century consists of the years 1901 through 2000 and will end Dec. 31, 2000. The 21st century will begin Jan. 1, 2001. -- The World Almanac and Book of Facts 1996 *** This is a date that no organization, including NIST, has the authority to regulate. However, one logical answer to the question is that because there was never a year "zero," and a century must have 100 years, then each century must begin with a year numbered "1." In other words, the 20th century should be considered as ending on Dec. 31, 2000, and the 21st century as starting on Jan. 1, 2001. However, human nature being what it is, most of us will still opt to have that "once-in-a-century" New Year's Eve bash on Dec. 31, 1999. -- "Time Questions and Answers from NIST," Time and Frequency Division, National Institute of Standards and Technology *** The 20th century (this century) will end after December 31, 2000 comes to a close. The 21st century then begins just after midnight on January 1, 2001. However, the chaos in computer systems all over the world is expected to begin on the morning of January 1, 2000, a full year before the end of the 20th century and the end of the millennium. -- John Moffitt *** 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 --------------------------------------------------------------------------- 4.5 What is a Julian date? The term "Julian date" has two different meanings. The one that is most common in data processing is a number from 1 to 366 representing the day of the year. This is more properly referred to as the "ordinal date." The other meaning of Julian date is a system used by astronomers. It is also called Julian Day and abbreviated JD. It is the number of days since noon GMT on January 1, 4713 BCE. In this system, Julian Day 2,450,084 begins at noon GMT on January 1, 1996. This system was invented in 1582 by Joseph Scaliger, who named it for his father, Julius Caesar Scaliger. --------------------------------------------------------------------------- 4.6 What is an integer date? What is a Lilian date? An integer date is a way of representing dates as the number of days since a specified starting date. Integer dates make it very simple to calculate the number of days between two dates, or to find the date a given number of days before or after a given date. A Lilian date is an integer date system in which day 1 is October 15, 1582, the first day of the Gregorian calendar. It is named for Luigi Lilio, who provided most of the ideas for the Gregorian calendar reform, including the rule for leap years. Other integer-date systems use other starting dates. For example, ANSI COBOL 85 intrinsic functions use January 1, 1601. Most spreadsheets, following the convention first established by Lotus 1-2-3, use January 1, 1900. =========================================================================== 5. FIXING THE PROBLEM 5.1 What are the general programming (standards?) approaches that one could take to solve the various year 2000 problems? *** The year 2000 effort can be broken down into three basic steps: 1. Preparation 2. Implementation 3. Deployment Lets look at each of these, and examine the possibility for automation in each: 1. Preparation Preparation is where you inventory all your applications, discover which of them have year 2000 problems, decide what to do with those that do, and then prioritize the work. While there is some automation to be applied here, it is generally to begin to control what a company has, rather than specifically facilitate the year 2000 process (but I don+t see how one can enhance entire systems without controlling the code before and after, so in a sense these tools facilitate the process). 2. Implementation This is where the enhancements actually take place. The tasks here are identification, code correction, verification, and data correction. Here is where automation can come into play. In each one of these steps, there is a range of automation that can be applied. The level of automation ranges from facilitating the manual enhancement effort to actually doing most of the work. We have also found that there is a possibility for +too much automation+ in these steps. Too much automation does not allow for learning and customization. We have also found that the accuracy and completeness of the identification task indicates the productivity and quality for each of the subsequent tasks. So, in addition to a range of automation, there is also a range of accuracy and completeness for the automation. 3. Deployment The deployment phase includes the system test and moving the tested systems into production. There are tools that can be of assistance in this step. The primary difficulty here is the phasing in of corrected subsystems (i.e., making new code work with old data until enough of the system of application has been enhanced to correct the data). This can be facilitated by the level of automation in the Implementation phase (after all, if the identification task has identified all the date-sensitive data elements in files and databases, couldn't it use that information to facilitate creating bridges and wrappers?). -- Ted Swoyer 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 nothave critical date computational needs with to-the-day accuracy required. We are primarily an OS/VS COBOL (Release 2.4) shop using VSAM files in a MVS/ESA SP4.2.2 environment. I am on a team which is tasked with preparing our COBOL programs for the year 2000. A detailed plan has been prepared by our project leader and is currently being implemented. We are using simple design elements: 1. Extensive use of bridging programs for all of the reasons mentioned previously in our discussions. 2. Expansion of all years to 4 characters. 3. Our simple date computations will remain hard-coded. Most need to only be approximately correct (mainly for record retention purposes), or are only calculating fiscal year and month from calendar year and month. 4. The decision has not been finalized, but, 2 digit years may be used on most screens and reports. 5. And, of course, we are using the opportunity to reorganize our files and expand other fields! -- Richard Newbold *** 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 tho ughts on the pros and cons of the two methods - Data expansion vs. Century Derivation/procedural. It is a seminal issue. We need to give clear direction to analysts and programmers before they dive into the code. We expect to come up with the preferred instruction set in the next 3-4 weeks. Century Derivation strengths vs. Data Expansion (1) No expansion of copybooks, DBDs, working storage, etc. - except for ambiguous dates and keys in segments. (2) Can keep current century derivation logic currently in place (3) Can code, test, system test, regression test more simply - small pieces (subject to ambig. date and key date exceptions) (4) Can put into production in very small pieces (again subject to exceptions) rather than large production installs (4a) Data expansion with phased production installs implies bridges and conversion programs - again subject to exceptions. (5) No need to deal with converting archived data (6) Can create standard procedure division code or called routine which will derive century - reduces logic error probability Comment: perhaps there is a code way to get around ambiguous date - birthdate, for example - if Birth- YY <50 and Soc-sec-No > x then CC = 20 Data Expansion strengths vis a vis Century Derivation (1) No procedure division changes - except for yanking out century derivation logic where it is now (unless we choose to not expand those dates) - and except for secondary moves. (2) Easier to employ junior programmers in the program changes, perhaps even some of the detailed analysis (3) No speed degradation (3 additional LOC per derivation - meaning 6 per date comparison) (4) Probably fewer test errors - no procedure division code changes (unless we yank the century division logic) (5) Easier maintainability after it is all over (6) Less static about speed and about impurity of solution (7) Cutoff date with CD approach may differ from application to application (solution to use system date to perpetually change the pivot date plus ability to have application pass a parm which is an application specific pivot date exists - but adds to code complexity) Expected life of applications and ability to marshal resources are situational factors each co. must evaluate. -- Tom Ster 14 Feb 1996 *** Losing Sight of the Problem I read with interest Tom Ster's posting [not the one above], in which he referred to a "century derivation" approach (the process option), as opposed to changing the dates on his database (the data option). At the risk of having us both burned at the stake, let me take up his case. There has been a lot of discussion in this forum about the best date formats to make standard, and about the importance of consistency and standards for data interchange. New systems do need to be built with date standards in mind, and the external view of a system does need to meet certain standards if it is going to interface with a common world. The big problem is how to make *existing* applications run error-free as 21st century dates enter these systems. My perspective is an IBM mainframe one. Most of these systems have not encountered, and are not going to encounter a situation where 2 digit years become ambiguous. For example, in the context of a hire date, 95 always means 1995, never 1895 or 2095; in the context of a contract expiry date, 35 always means 2035 and never 1935. If the 2 digit year has become ambiguous, fix it by including the century - it has nothing to do with the millennium problem. Two digit years are not appropriate if the context and other available information does not uniquely identify the century, and this problem will show up when new ambiguous year data enter the system, no matter when. The millennium problem is that date operations and comparisons may not generate the correct results with 2 digit years, because the CODE is wrong. So, there is no need to fix the data at all. It is possible to solve the problem by modifying the code. The type of code which is wrong looks like: IF DATE1-YY < DATE2-YY THEN ... or SUBTRACT 1 FROM DATE1-YY There has been a developing assumption that the correct and best way to solve the millennium problem is to implement a 4-digit year in all data. This is a case of group-think - a syndrome which can lead to reinforcement of ill- considered solutions. I have even seen documents produced by fledgling Year 2000 groups within large organizations that impose a 4 digit year solution on all new and existing systems. They happily quote ANSI X3.30 or ISO 8601, and don't realize that they are constraining their development teams to a single, costly, and possibly inappropriate solution. Any system using 2 digit years can readily be made millennium compliant, provided the definition of millennium compliance doesn't impose 4 digit years. My definition is that date operations and comparisons will yield correct results over a range of dates including the 20th and 21st centuries. Simple as that. The "process solution" involves changing source code which contains logic errors. This may be done best by replacing bad code with common subroutine calls. It's not quite that simple though. There may be dates in keys or sort fields where you need to take a "data solution" in order for dates to be ordered correctly. Note that some sorts are just for grouping related records, and it doesn't matter that 001231 is sorted prior to 990101, so long as all the records identified by 001231 were contiguous. There may not be a need to change all dates in sort fields and keys. So, why wouldn't you choose to change to 4 digit years anyway? It sounds good. It sounds like a way to standardize to a universally acceptable system that solves the millennium issue. Ever tried it? With an existing system, you will find that you basically unglue the system. Virtually every copybook in the system will change. Virtually every program in the system will require change or be impacted by the changed data structure. (Changing the data structures doesn't make all the flawed code work, so in many cases you have to recode parts of programs, not just recompile them). Many of your sysin members will need to change for sort keys. Any hard-coded DCBs in jobs, and all your VSAM DEFINE sysins will be impacted. Do you have any user-written report queries running against databases holding derived data? All these database definitions will have to be changed e.g. RAMIS, ASIST. You have to deal with the user interface in your on-line component. Do you change these data elements on screens and force users to type in redundant digits, or put in the smart edits to build the century? OK, that's the easy part. Now that you've entirely unglued your system, and dealt with a major reworking, while maintaining your production system in parallel, you have to test the new system (that's what it is - a NEW system). You have to write conversion programs, and create converted data. You just doubled your DASD requirements. Testing this monster is a nightmare. Do you currently have an environment where you can run every job, and execute every online screen without impacting other development and production systems? Not only do you need to test it for dates in the remaining portion of the 20th century, but you need to test 21st century data, and if possible, a transition period from 1999 through 2000. When this involves testing the whole system, that's quite a large amount of work. Ungluing the system is likely to cause that flakey old undocumented batch OS/VS COBOL system to stop working altogether, particularly if there are magical components written in assembler. How does the process solution avoid these problems? Well, it may increase the amount of work required on program source code maintenance, but it saves a whole lot of work in other areas. Unless you need to change dates to 4 digit years for sorting, copybooks won't change. Programs will not be impacted purely by virtue of data changes. DCBs, sort sysins, VSAM DEFINEs and data offsets in derived data will not change. Screens will not change. (In view of the user interface, you might want to change from MM/DD/YY to DD MMMYY or use some other way to distinguish day from month from year). The greatest benefit of the process approach is that the program *bugs* can be fixed one at a time, and released into production immediately, if you so choose. To some extent, testing can be done module by module, looking for correct functioning of the piece of code that changed. (In the data approach you change data structures which impact all parts of the program, and therefore you have to test ALL functionality). Of course, you need to test the system as a whole, and you need to simulate 21st century dates in the test data and in the system date if possible, but you have significantly reduced your impact to the system, and it's much more likely to work. In this approach you are attempting to preserve the current look of the system - files, reports, databases should all look the same as before. In the data approach, you are intentionally changing the values in files, reports and databases. The Gartner Group suggests $1 a line for millennium compliance. I have seen an instance of a data solution which cost double that. I have yet to redevelop a system using a process methodology, but I'm looking forward to it, if I can convince the fledgling Year 2000 strategists to stop chasing a ghost. -- Andrew Eldridge 29 Jan 1996 *** One of the basic decisions to be made with regard to the YEAR 2000 problem is whether to convert the data or the applications. Actually, it is not an either/or situation, since data conversions still imply application changes to accommodate the new data definitions. (Even with a highly "active" data dictionary, applications may need to decide whether to automatically have all output increase to 8-digit dates.) Though one answer is certainly the "theoretically" best solution, the implementation questions show that there is still room for evaluation of the trade-offs. Perhaps determination will be based upon the nature of the application subject area. (Some applications demanded 8-digit dates from their conception years ago. Some applications may use their dates strictly for tracking purposes and will be spared the crisis that most systems will face.) ITEM FOR DISCUSSION: WHAT ARE THE ARGUMENTS FOR CONVERTING DATA VS CONVERTING APPLICATIONS. To prime the pump, I am offering the following points. Please feel free to add to this list (or elaborate upon these points). Note: These cogitations are based upon experience in administrative university computing in a mainframe environment including MVS/ESA, IMS (DB & TM), DB2, OS/VS COBOL and COBOL II, QMF, "Vision:Builder" (once known as MARK IV), etc. Hopefully, some aspects are relevant to a variety of environments. Approach #1. CONVERT THE DATA: PRO (Convert the data): a. The "ideal" solution. Will survive till "near" year 9999! b. Consistency. Not dependent upon different algorithms (or parameters) for determining the century. c. Accuracy of conversion. Single technique for all programs. d. Would require less exhaustive testing. If all dates are expanded, "boundary" type testing is minimized. e. Conversion of many programs might often simply require a recompile (& linkedit). f. Client-written ad hoc reports would not need century-determination routines. g. Selection criteria in client-written ad hoc reports would continue to work properly. CON (Convert the data): a. Requires conversion of virtually ALL programs (unless active data dictionary dynamically provides new data definitions). b. Conversion of programs and data must occur (virtually) simultaneously. (Yes, there can be a degree of phasing the conversion based upon scheduling predictions but the bulk of programs would be needed to be changed by the next morning.) c. Many of today's systems can ill afford the down-time required for such massive, simultaneous conversions. d. Due to the multitudinous interfaces between systems (foreign keys, referential integrity issues), there would either have to be one mass conversion or repetitive conversions of interfacing programs as the underlyi ng data bases are converted. e. Since programs need to be implemented simultaneously, yet it will take a long period to make the changes to the source code, keeping the converted code in sync with updates to the current code will be difficult. The alternative is to freeze all maintenance and enhancements until conversion is completed. (Can any installations tolerate that?) f. Dates will need to be truncated on output much of the time for three reasons: 1. Many screens and reports lack the available "real estate" to display the extra data. 2. Clients will probably remain comfortable with the 2-digit year format such as mm/dd/yy (or dd-mm-yy, or dd.mm.yy or whatever!). 3. It will be consistent with the 6-digit input that will be practical for most screens. g. Existing client-written ad hoc reports may suddenly expand (and experience line "wrap") forcing output formats to become jumbled. Approach #2. CONVERT THE APPLICATIONS (i.e. programs): PRO (Convert the applications): a. No data conversion. Therefore no required synchronization of data conversion and program conversion. b. Program conversion can be phased in - one program at a time. (For large- scale systems, this may be very important.) c. Some programs will require no conversion. d. Some programs will require only minor/trivial conversion. e. Some dates are used simply for tracking purposes and are always contextually recognizable. They are simply printed/displayed but are not used for selection or comparison purposes (currently!). f. Client-written ad hoc reports would have the same format as before. g. Downloaded data will remain unchanged. (However, the problem now moves to the recipient!) h. Century-determination logic (subroutines) using a "windowed" range that floats in sync with the current date would only require the system date to be an 8-digit value and thus could work "toward" the year 9999. i. Converting the applications does not preclude converting the data at some point in time. It simply relieves the time constraint, allowing data conversion to be postponed until system replacement or other major enhancements or upgrades. CON (Convert the applications): a. Some programs will require extensive code changes. (E.g. on-line programs which do not have sort capabilities or sequence-based logic that will require repositioning.) b. Does not handle cases where at least 100 year span is involved. (However, those systems would have had a need for 8-digit dates from their initial design.) c. Determination of century will vary by context (e.g. date of birth would assume the past, archival dates would assume the future). This implies "boundary" testing to insure that the determination is correct for the given field. d. Ad hoc reporting tools used by clients may not have access to the programming staff's subroutines for determining century. Their reporting techniques will have to change and will likely not be consistent. e. Selection criteria in client-written ad hoc reports might fail. f. "Derived" systems will have to incorporate century-generation logic at extract/download time, or throughout their code. IN EITHER CASE (data or application conversion): a. Some programs will require restructuring extract files and their associated job streams to accommodate the enlarged data fields. b. Date input will generally remain as 6-digit input. Clients are not going to want to code the "obvious" century portion. When stored as 8- digits, the software will usually be expected to determine the appropriate century portion of the date. c. Testing conclusively is not easy. (We may have test data bases. But is there data with the values we need for establishing correctness?) Also, simulating a system date may be difficult. If you do not have current date override capabilities already built into the code, you may have to purchase a package to "fake" a future system date. d. Finding the time and person-power will be the killer! e. This is an opportunity to simultaneously perform other tasks that we have not had the opportunity (neglected?) to do. A few examples: inventory (truly) active programs!; convert to newer release of language (e.g. OS\VS COBOL to COBOL II or COBOL/370); convert to newer language; rewrite a system!; install a package to replace an archaic one; review/enforce standards; modularize to improve maintainability; etc. (This might be another good area in which we can share ideas on what we'll do while we're in there doing whichever conversion technique we select.) -- Brian Christenson 13 Jun 1995 --------------------------------------------------------------------------- 5.3 What strategies are being considered for solving the following year 2000 problems: break point? - field expansion? - hex code? *** I am writing a subprogram on my home PC that uses break point logic to determine the century digits for a two-digit year. It subtracts 80 from the current year to get the first year in the 100-year cycle, and then bases the century digits on that cycle. For example, in 1995 the cycle runs from 1915 to 2014. A two-digit year between 15 and 99 will be converted to 1915 thru 1999, and 00 thru 14 will be converted to 2000 thru 2014. In 1996, 16 thru 99 will be converted to 1916 thru 1999, and 00 thru 15 will be converted to 2000 thru 2015. Even if you have expanded your date's year field to four digits and now your system appears to be 2000-compliant, there are several other areas that could cause problems as we approach 2000. For example: - Embedded two-digit years in serial numbers and other identifiers that may be sorted. - Dates with two-digit years that we send to banks, suppliers, and customers via mag tapes and EDI. - Dates with two-digit years passed between mainframes and PC applications such as spreadsheets and databases. -- Rick Toker --------------------------------------------------------------------------- 5.4 Why should we try to have standardized date computation routines? Why don't we ALREADY have standardized date computation routines? *** One of those hidden problems that many shops are discovering in their 2000 evaluations, is that they have anywhere from 5 to over 100 individual date routines! In larger shops, programmers that transfer from one department to another may be making such a big move that they are in essence starting a new career. If the payroll, purchasing, and production control departments are all using the same set of date routines, the "learning curve" that the transferee has to go through is just that much less traumatic. This learning curve problem is applicable not only in the transfer of people from project to project but also their movement to other platforms in a mainframe-client/server environment. Many date routines are written in BAL which is not portable across hardware platforms and is difficult to maintain. Having access to a portable, standardized date routine with consistent documentation means one less thing to worry about. Many of the existing routines in a shop are actually the same or have only minor modifications. Mostly, modifications were made ad-hoc, haven't been thoroughly tested and may not work correctly in all instances. With many differently named routines, no one is sure what the source root was which leads to problems with future modifications (sort of like playing the game of telephone where the message at the end is always significantly different than it was at the start) and maintenance problems. For example, I was recently talking with someone who found functionality that worked in one direction (forwards) but not backwards in a routine they had been using for many years. Additionally, documentation is outdated or non-existent for most routines and since there is often little control over routine development, parameterrequirements may vary from one of these routines to another creating the potential for further errors. When considering the high number of routines in the average shop, one has to wonder why they were created in the first place? Of course, we will always have the "it was interesting to write it" response but more often than not it seems that either the current "standard" routine was not documented as existing across the enterprise, documentation on how to use it was poor or missing or the routine(s) was difficult to use and not logically designed. Another reason I have heard is what I call "latent demand" (taken from my performance tuning days ). 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! Once you do that, of course, you have nothing to compare the results to. You can't do parallel testing, so ... you will have to manually verify the results! It is likely that you will make a lot of mistakes in the process of manually verifying your test results. -- Robert J. Sandler <70023.2572@compuserve.com> *** Systems must be well tested to ensure that functionality has not been changed in any program as a result of the date changes. This means a unit test of the program, a system test with a test bed of data covering all functions, a simulation test to any date in the future that may impact your system (this involves moving your data and your system date into the future), and finally, a test with historical data to make sure you can process old data through the system once changes are complete. Developing a test bed for these changes is a significant task. The testing stage represents 40% of the effort for the entire project. Organizations that have established inventories, change control procedures, and test beds of data can move quickly and efficiently through this process. For most though, these steps will form a significant part of their Year 2000 project. -- Brenda McKelvey from a report on the "Year 2000: Blueprint for Success" conference in Orlando, Florida, November 1995 --------------------------------------------------------------------------- 5.6 What are some important programming future dates for DOS system designers besides 1999 and 2000? *** I'm doing these calculations quickly so I may be off by one. 1. DOS "days-since-1900" Many DOS programs maintain the date as days-since-01-01-1900. This requires an _unsigned_ 16-bit integer. (There were a few variants of this method, e.g., to have "0" fall on a Sunday to simplify day-of-week calculations.) signed vs unsigned: 19 Sep 1989: programmers who failed to specify "unsigned" 16-bit integers had their dates suddenly change to early in the 19th Century. 07 Jun 2079: 16-bit counters will roll over 2. DOS file system times DOS has historically maintained the date in a packed integer field. It allocated 7 bits to the year field, starting in 1980. 01 Jan 2044: poorly written code may have problems with date, if bit extraction is done improperly. 01 Jan 2108: rollover BTW, many DOS/Windows proponents will gleefully point out how this range is among the best of those currently in wide use. In response, point out that the _accuracy_ of the time is only good +/- 2 seconds. Most other operating systems have +/- 1 second resolution. -- Bear Giles --------------------------------------------------------------------------- 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 willstill experience problems come 1/1/2000? I've been told by some who have already been forced to make changes, that the only systems that are really in trouble are the ones that won't hit they're event horizon until 1999 because all other systems will have already been dealt with. Also, if System A implements Fix1 instead of Fix2, does this mean System B later has to implement Fix1 also for compatibility purposes? Finally, is it possible that the immediate fixes today on System A may adversely affect other systems which depend System A either now (and the other systems don't know it yet) or after 1/1/2000? -- Brown, Capt Donald *** 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 =========================================================================== 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. ***Here is a list of companies that offer tools and consulting services. Some of the product descriptions were written by the vendors themselves, or were excerpted from the vendors' promotional material by the FAQ maintainer. Others were provided by contributors to the Year2000 mailing list. Neither the FAQ maintainer and editor, nor any of the contributors, endorse or represent any vendor, or guarantee the correctness of this information. Contact the vendors for more detailed information. ADPAC Corporation 415 777-5400, Cynthia Nisbet e-mail: adpaccorp@aol.com Product: SystemVision YEAR 2000, a mainframe based Y2K tool. SystemVision is an integrated toolset of different applications that offer comprehensive information and analysis for maintaining, enhancing and re-engineering legacy systems. Based on the proven PM/SS parser technology, SystemVision applications provide organizations with packaged solutions for issues found throughout Information Systems departments. SystemVision YEAR 2000 is the first SystemVision product, and it provides a complete solution for analyzing, planning and implementing the date conversions which are necessary for Y2K calculations, simplifying the conversion process by identifying and locating all date occurrences on a system-wide basis. It produces detailed "What-If" studies to make the changes, and then guides the programmers through the code step-by-step for insertion of ISPF edit macros to make the necessary changes. ADPAC is an independent software company (since 1964). In the 1970s, ADPAC focused its technical expertise on providing consulting services and developing productivity application tools. In the 1980s these tools were made commercially available, including PM/SS which provides the user with a powerful system-wide source code parser and analysis toolset with command driven capabilities for maintaining, re-engineering and redeveloping entire COBOL, PL/1 and Assembler applications and their JCL. It reverse engineers a systems' structure and data relationships, providing systems engineers with the understanding necessary to maintain the software. ADPAC's products run on all MVS environments using COBOL, PL/1, Assembler, JCL, SQL, DB2, IMS, IDMS, CICS, IDD and other inputs. Air System Technologies Inc (500) 448-9660 e-mail: Support@RighTime.Com Our clock correcting program, RighTime (now four years old at version 4.64), corrects the CMOS RTC Y2K problem if it is resident and running on the machine before the 1999-2000 change. It currently supports DOS and all Windows except NT. A new release is due in a few weeks. (Oct. 23, 1995) Alydaar Software Corporation 504 845-3322, Robert Gruder e-mail: alydaar@neosoft.com *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Product: SmartCode Complete solutions to year 2000 software problems. Alydaar's solutions include impact analysis, thorough and comprehensive detection, reengineering and correction of code, testing, and delivery. SmartCode, Alydaar's artificial intelligence reengineering system, can examine and understand your entire software system, identify inherited date-sensitive characteristics, evaluate date-solution opportunities and difficulties, and reengineer your software to incorporate your choices for year 2000 corrections ... synthetically. SmartCode also adapts to your software design and programming standards, understands any computer language, and permits you to continue maintaining and developing your software throughout the detection and analysis portions of the project. Founded in 1982, Alydaar has a proven record of successes using SmartCode to reengineer large, complex software systems. The solution to your year 2000 and other reengineering problems is assured because Alydaar has combined its unique and powerful technologies with the services of proven software consulting and auditing firms, such as KMPG Peat Marwick, with thousands of experts and customer support staff in hundreds of locations around the world. AMS (Automated Migration Services) 919 380-7877, Sandra R. Gareton e-mail: srgare@ix.netcom.com AMS is a services company that specializes in conversion. We have software for year 2000 impact analysis that also provides inventory lists and cross references. This software is PC-based, and you can elect to run it yourselves (1 person familiar with PCs and your applications) or have assistance from us. ASPG Inc. 800 662-6090, 813 649-1548, Lisa Hamilton e-mail: 75541.2467@compuserve.com DATE/2000 is an MVS product which assists users in testing/preparing applications (TSO/ISPF, CICS, DB2, IMS etc...) for the year 2000. Cap Gemini America 212 944-6464 ext. 232 Product: TransMillennium Services Our end-to-end methodology is supported by our integrated toolset, from assessment and strategy through renovation, validation, and implementation. Our artificial-intelligence-based ARCdrive toolset brings a high level of automated renovation to every affected application component, including programs, JCL, sort control cards, file conversions, bridging and test data. To provide a faster, better, cheaper year 2000 solution, we built the highly specialized Application Renovation Center (ARC), and engineered productivity environment, which leaves your ongoing mainframe operation safely undisturbed. Staffed by dedicated teams, supported by AI-based tools, the ARC allows the specialized focus and expert knowledge-sharing important to successful renovation. ISO9001-certified quality system. CBSI (Complete Business Solutions, Inc.) 810 488-2088 CBSI is a large U.S.-based systems development firm with proven experience in facilitating the modification of legacy applications to handle turn-of-the- century date processing efficiently. CBSI has over 1,000 consultants in project sites and offices around the world. These consultants are experts in performing large conversion projects. CBSI maintains cost-effectiveness and quality control through both off-shore and off-site conversion options. Chicago Interface Group, Inc. 312 348-8138 e-mail: 73511.3263@compuserve.com Our company specializes in Impact Analysis, and Configuration Management products, interfacing with the current change manage products such as ENDEVOR, Panvalet, and Librarian, etc. We have two commercial product offerings available. One focusing completely on Year2000 analysis and verification. We also offer analysis and consulting services in the area of Year2000 projects and general configuration management. We provide expertise, products, and 'total view' methodogy that will handle this issue from the analysis phase through the execution, verification and project management. CL Systems 513 369-5864, Mike Smith Product: VANTAGE YR2000, a converter product Computer Associates 516 342-2391, Bob Gordon e-mail: info@cai.com *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Product: CA Discovery 2000 Solution CA Discovery 2000 Solution is a unique combination of software and services to help reduce the costs and resources associated with Year 2000 processing. CA Discovery 2000 includes technology and services that provide a total Year 2000 solution. CA-Impact/2000 is a new multi-platform tool that analyzes applications and details the information needed to estimate and plan the Year 2000 initiative. It is a powerful impact analysis tool that helps organizations determine the impact and cost of converting applications for the Year 2000. CA-Impact/2000 analyzes all of an organization's COBOL and CA-Easytrieve programs and generates detailed reports that identify the affected business applications. It executes on both mainframe and desktop platforms. CA Discovery 2000 Services provide extensive assistance in the Year 2000 initiative, including impact assessments, project planning, education, and conversion techniques. They provide organizations with a phased approach to their conversion plan, enabling projects to be more manageable, productive and cost-effective. Fee-based customized services--from impact assessment through re-integration of production systems--also are available. Visit CA on the World Wide Web at http://www.cai.com. Computer Horizons Corp. 800 321-2421, David Reingold e-mail: dreingold@msn.com *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Signature 2000 is a combination of a proprietary software toolkit and CHC's proven project management expertise and methodology. It comprises five major phases: Discovery, Analysis, Construction, Testing and Implementation. The software toolkit features a Signature Analyzer, which identifies all date occurrences within a company's inventory of applications, and a Signature Replacer, which reformats appropriate data fields, updating the application code. The Signature Analyzer provides a number of standard and customizable reports of all date references and stores them in an SQL-base repository. The repository is used by CHC analysts, working with a company's technical and information systems departments, to prepare an individualized approach for updating the applications. The Signature Replacer, using the repository, provides a flexible approach to automating the implementation, using the data in the repository and the rules stored there during the analysis phase. The toolkit, which runs in both mainframe and PC environments, is currently available for COBOL, PL/1, Assembler, SQL, DB2, IDMS, IMS and CICS. Computer Horizons Corp., founded in 1969, is a diversified information technology services company specializing in system design, management and maintenance, client/server migration and network management. It employs 2,200 in its network of 33 offices throughout the United States. Computer Reserves Inc. (CRI) 800 882-0988, 201 263-9800, Bud Conner Product: Year 2000 conversion services We have developed products and offer services that will dramatically reduce the cost and scope of your year 2000 project. By utilizing automated tools we are able to reduce the amount of code that needs to be reviewed and converted. Also, this is a labor-intensive project that does not lend itself to an internal solution. We have access to a large supply of competent COBOL programmers as well as highly qualified project leaders to manage these resources. Computer Software Corporation 800 908-2000, 216 333-4420, Dan Shaughnessy Product: DateServer 2000 - calendar routines that use windowing to process two-digit years, for MVS or VSE on IBM-compatible mainframes. Also consulting services. Expertise especially in banking systems. Compuware Corp. 800 358-3048, 810 737-7300 *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Product: XPEDITER/Xchange inventories programs requesting date or time from the mainframe, then simulates date or time during testing. Compuware Corporation, headquartered in Farmington Hills, Michigan, U.S.A, is a global leader in software products for building, testing and deploying business applications and related professional services. Our customers are among the world's 15,000 largest commercial users of information technology. Data Dimensions 800 708-0675, 206 688-1000, Larry Martin e-mail: 76311.1542@compuserve.com *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Product: Year 2000 consulting and professional services. Data Dimensions furnishes a full range of year 2000 services to domestic and international owners of all computing platforms. Employing their own analysis facilities and Template 2000 (Copyright) methodology plus the latest tools, they achieve a thorough risk assessment of a given application or the management of an enterprise-wide update. Data Dimensions publishes The Millennium Journal, an always interesting and well-written monthly newsletter on various 2000 subjects. Call them at one of the numbers above for a copy. Durham Systems Management Ltd (UK) +44 (0) 191-492-0429, David S. Walton e-mail: Dave.Walton@durham.octacon.co.uk They've been interested in software maintenance issues since 1987, and offer a number of consultancy and training services. They regard Y2K as the archetypal software maintenance problem with the added ingredient of a project completion date, and eagerly await the fact that Y2K will eventually result in the recognition of maintenance as the highest priority activity in the management of a software portfolio. Edge Information Group 513 948-8906, Carl Gehr e-mail: 73424.543@compuserve.com Products: Edge Portfolio Analyzer, Bridge to the Next Century, consulting, as well as migration assessment and a migration planning class. Bridge to the Next Century simulates COBOL 85's date-related intrinsic functions for shops not yet on compilers which support them. Ernst & Young RE Products bv +31-30-2588345 e-mail: eyrep@mc.mey.nl *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Product: Cleopatra With Cleopatra, Ernst & Young RE Products bv offers a unique service for programming language conversion. Cleopatra converts PL/I programs into COBOL II fully automated. It is a proven solution for fast and reliable conversion of PL/I programs to an open environment. During the Year 2000 inventory effort, many IS organizations that primarily utilize COBOL will discover that they have a few "orphan" PL/I applications that are still operating. These organizations may discover that: - insufficient PL/I skills are available to support the century date correction effort; - few tools are available to support PL/I analysis and change activities; - they do not want to invest additional capital into applications written in a "dead-end" language. PL/I to COBOL conversion offers these organizations a way to add value to their century date conversion projects by eliminating their orphan PL/I applications. This approach offers these organizations numerous benefits: - PL/I coding skills are no longer required; - costs can be saved by eliminating the PL/I support environment; - applications can be maintained and extended in COBOL; - more choices for software tools and further migration options are available. Furthermore, the ability to use a wide variety of COBOL tools to support all phases of the century date project saves additional effort and cost over performing the change in the original PL/I version of these applications. Visit our WWW site at: http://www.mey.nl/eyrep/welcome.htm EXECOM +61-9-4811256, Tim Pearce e-mail: timp@acslink.net.au Product: Automated program conversions. The types of conversions we have done have included changes in COBOL dialects (FUJITSU, BULL, various IBM), NCR NEAT3 (Assembler) to MF COBOL, PL/I, hierarchical to relational databases and change in TP monitors. Sizes have varied from hundreds to thousands of programs for a single client. As the year 2000 approaches, more of our clients are including date changes in their conversion requirements. These requirements will be incorporated in our current tools. We are also commencing a project to prototype a specific century date conversion tool. [August 1995] Formal Systems Inc. 800 249-2222, 506 453-9823, Mike Thibodeau e-mail: Inquiry@FormalSys.Ca Formal Systems Inc. (FSI) provides high productivity tools and value-added services to support the maintenance and re-engineering of legacy software. Founded in 1990, we specialize in Natural/ADABAS and have re-engineered some 30 million lines of code. Based on NXL technology, NXL2000 is being designed to assist in identifying and correcting for Year 2000 remediation. This highly automated toolset is currently capable of providing a high level impact analysis. The results from this analysis are useful in estimating the scope of a clients Year 2000 project and creating budgets and management plans for remediation. The completed toolset will offer full impact analysis including data flow analysis and highly automated remediation of the affected source code. Global Software, Inc. (MA) 617 455-0949, David Eddy e-mail: GILES@globsoft.com Product: GILES - an MVS/ISPF large scale impact analysis tool designed to: identify complete systems across multiple application boundaries and platforms, support multiple languages (including the dead ones), require minimal human intervention, be very fast, and provide a permanent directory of components. GILES addresses the critical first step of the re-engineering process (baseline inventory & assessment) that everyone assumes is already done. The Greentree Group 214 369-7022, Bill Wachel e-mail: wmwachel@onramp.net Product: Management and technical consulting services and actual analysis and conversion of applications for year 2000 impacts. Leveraging a suite of code analysis and modification tools to identify and communicate the potential impacts of Y2K to the client's business functions as well as technical IS applications. Addressing the full of application creation and use life cycle and optimizing technology for business value. Experience working with both commercial and government clients. HCL America 408 733-0480 x219, Curt Terwilliger e-mail: twig@hcla.com Product: an automated conversion process using a suite of MVS-based tools. IBM Call local representative or 800 IBM-3333 e-mail: askibm@info.ibm.com Products: TRANSFORMATION 2000 (TM) SOLUTIONS; COMUDAS TRANSFORMATION 2000 is a comprehensive set of solutions that takes into account applications, systems software, and hardware in both centralized and distributed environments. The TRANSFORMATION 2000 approach seeks to balance Year 2000 activities with current and planned strategic initiatives. It brings together state-of-the-art techniques and technologies developed and proven through both internal and external projects for the Year 2000 and other data field expansions. This experience helps reduce both the cost and the complexity of implementing the Year 2000 change. The components of TRANSFORMATION 2000 solutions are as follows: o Assessment and Strategy -- provides a documented strategy, cost estimates, timeframes, and resources required o Detailed Analysis and Planning -- provides an in-depth analysis of each of the Year-2000 affected areas of your business o Implementation and Testing -- automates the changes required to source code and data o Year 2000 Clean Management (TM) -- protects your investment in application and data modifications COMUDAS is a common date routine that has been developed to replace all existing date routines. A CICS and an MVS version are available. With COMUDAS, you can validate, convert, and calculate dates in any format. IBS Conversions, Inc. 708 990-1999 *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Product: IBS/Solution 2000(tm) IBS Conversions has been the undisputed leader in migration methodologies and software tools for over 12 years. We are backed by Interactive Business Systems, a company of over 700 technicians, software designers, and consultants. IBS Conversions addresses migration projects in three phases: impact analysis and planning, pilot project, and implementation. This phased approach brings organization and control to the project and assures low risk and quality deliverables. Impact analysis uses automated tools to scan COBOL source code, JCL, and copy libraries to identify every occurrence of a date field that could require modification. IBS then develops application sequencing and schedules, and a preliminary project plan. The pilot project uses the preliminary project plan on a representative subset of the migration inventory. Implementation is based on the results of the pilot project. IBS has established conversion and production facilities utilizing an assembly line and factory approach to provide our clients with high levels of productivity and quality. Information Management Resources, Inc. 813 797-7080, Rajan Pandhare e-mail: rajan@imr.usa.com Product: Transform2000 and large scale consulting services. They promise a full life cycle year 2000 conversion from on-site, offsite, and offshore. IMR is a 7 year old firm headquartered in Clearwater, Florida and with operations spanning North America, UK and India. They (600 individuals) offer fixed fee applications development, legacy maintenance, and Migration (which includes year 2000) services. Year 2000 has been their specific focus for the last 14 months and to-date they have executed four large full life cycle conversion efforts for fortune 500 companies. They have also built a toolset (Transform2000), to assist in impact and conversion. Infosys Technologies Ltd. *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Infosys Technologies Ltd. is India's most respected software company offering quality software products and services in the global market. Infosys, in its 14 years of existence, has forged strategic alliances with several large U.S. and International organizations for offshore software services. Infosys has successfully executed numerous business and mission critical projects for these organizations using the offshore methodology at a fraction of the normal cost. Integrated Microcomputer Systems 301 948-4790, Joseph Yeh e-mail: joeyeh@imstech.com Web page at http://140.92.12.65/ Product: consulting? Intelecon Research & Consultancy Ltd. 604 527-7744, John C. Glover, CMC, I.S.P. e-mail: John_Glover@mindlink.bc.ca Independent Management & Technology consultants, a telecommunications and information technology consulting firm focussing on business results and workable solutions. Strengths include project management, strategic and tactical planning, and sound financial analysis. The value that we offer to the year 2000 CDC is a very firm but friendly business approach to delivering IT solutions, and strong project management experience (since 1958).Intersolv 800 547-4000 http://www.intersolv.com *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. The INTERSOLV Year 2000 Solution provides unmatched control over the entire change process -- the most critical component to solving the Year 2000 crisis. It combines the INTERSOLV Maintenance Workbench and PVCS Series to give you a clear blueprint for effective change management. And their openness lets you use any compiler, testing and debugging tool for a complete, seamless approach. Intersolv's expert ServiceDirect Consulting can provide a predefined package of standard services or customize a plan to your specific requirements. Ironsoft Marketing 800 236-0141 Product: ANALYZER 2000 Isogon Corporation (NY) 212 376-3200, Gerald Sindler e-mail: romy@telaviv.ddddf.com> Product: TICTOC (an advanced and popular MVS system date simulator). In addition to intercepting all TIME macro requests (SVC11), TICTOC is the only product to also intercept SYSPLEX timing services via the TIME LINKAGE=SYSTEM macro and the STCKSYNC macro. Both macros are documented by IBM as the recommended alternatives to using SVC11. Using another product may only cover some of the time requests your applications, high level languages, and vendor packages make. That can lead to inaccurate testing. Many assembler programs obtain the time via the STCK instruction. This is a hardware instruction that no software product on the market can intercept. However, using TICTOC's unique interception of the STCKSYNC macro call, there's an easy method to convert STCK instructions into STCKSYNC macro calls without making any changes whatsoever to your assembler source code. TICTOC takes under an hour to install. No IPL needed. TICTOC does not add noticeable overhead to your system, and does not affect file expiration dates, catalog or SMF or journal timestamps. TICTOC is fully transparent to other users on the same system who use the current date. Call for additional info. James Martin & Co. 800 248-4562, 703 715-4288, Cindy Berger Product: TSRM Blueprint is a systems redevelopment methodology, a portion of which is devoted to the Y2K date change. Mainware Inc 800 848-4912 x2965, 612 932-9154, Jerry Nelson Product: HourGlass 2000 is a tool to analyze MVS programs affected by Y2K date rollover. It's a utility to identify programs affected. Mastech Corp. 800 311-1970, 412 787-2100 Mastech Corporation, a software services firm with over 1,400 employees, serves businesses throughout North America and Southeast Asia. In early 1994, Mastech opened its offshore facilities in Bangalore, India. The 50,000- square-foot facility houses IBM and VAX mainframes, PCs, workstations, state of the art tools such as C++, PowerBuilder, VB, and Oracle, and a host of the top software specialists from India. It has direct 64 kbps data communication with the U.S. office. The offshore facility allows Mastech to download data to a parallel environment in India or to dial in to the client's facilities during evening hours. This approach means Mastech can commit larger resources to projects at significantly lower costs, and gives the client faster turnaround at significant savings over other options. Mastech also has alliances with key tool vendors that allow it to take advantage of the efficiency provided by dedicated year 2000 tools. In addition to the home office in Pittsburgh, Mastech has offices in Fairfax, Va., Toronto, Bangalore, and Singapore. Micro Focus 415 843-7070, Dwight Cornwell e-mail: dwc@mfltd.co.uk *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Product: Challenge 2000 is a suite/methodology as being propagated by Micro Focus. This methodology involves using Revolve as a tool, and therefore repositions Revolve as a year 2000 tool. Milan Data Services 619 697-1943 Product: Date analysis software. Millennium Dynamics 513 369-5864, Mike Smith e-mail: 75503.3443@compuserve.com *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Vantage YR2000 provides a comprehensive, consistent, focused process specifically designed to solve the critical problem of century date change for complex applications in legacy systems. In developing Vantage YR2000, the Millennium Dynamics, Inc. staff was able to draw upon years of experience with insurance, financial, and other complex business environments: year 2000 knowledge, building and maintaining legacy systems, tool design and development. Its comprehensive approach to century compliance consists of an application tool set, training, a process strategy, PLUS optional conversion services, resulting in a powerful and cost effective solution. Patni Computer Systems (P) Ltd. 800 486-2556, 617 354-7424 x222, M.J. Shivkumar (US) e-mail: mjs@dci.patni.com Product: Turnkey Software Conversion services from ISO 9001 certified off-shore firm, with capability to handle large projects. Use of automated procedures & conversion tools for MVS & UNIX environments and a structured test methodology to ensure a high integrity effort. Note: In India, contact Milind Padalkar at +91-22.836.1454 (x161), the Regional Manager of Patni, a large off-shore software house located in Bombay India, with offices in U.S. and U.K. Over 18 years of software experience with a cost-effective solution for those in need of year 2000 adaptations to their applications, using a suite of MVS based tools as well as C/UNIX products (all developed by Patni). Peritus Software Services, Inc. (508) 670-0800 x226, Ted Swoyer e-mail: tswoyer@peritus.com *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Peritus is a software maintenance services company. We offer outsourcing, insourcing, and custom maintenance services, specializing in Year 2000 conversions. Automate:2000(tm) is an automation-assisted service based on our unique maintenance technologies, combining our AutoEnhancer/2000(tm), a language-independent tool which uses formal mathematical techniques to automate software maintenance tasks, and our Mass Change Factory, which provides the methodology and process necessary to support a large scale transformation of code and data. Automate:2000 offers an unprecedented level of automation to your Year 2000 enhancement, and can dramatically decrease time and costs of your companies Year 2000 project. Piercom Ltd +353-61-335322, Charles Stanley-Smith e-mail: charles.stanley-smith@ul.ie Product: Year 2000 Impact Analyses Piercom provides Services and Technologies for Analysing and Documenting Legacy Applications. These services are based on a wide range of tools, which Piercom have developed and are based on over 40 man years of research and development, part-funded by the European Commission. The Services are platform and dialect independent and include: * Year 2000 Impact Analyses, Scoping and Documentation * Systems Re-Documentation - Hard Copy or On Line - Hyper Linked - giving intuitive navigation * Re-Engineering - for quality * Reverse Engineering into CASE Tools through CDIF etc. Piercom's Year 2000 Impact Analyses produces hyper-linked reports on year and date fields and their usage throughout an application. Piercom also produce counts of the occurrence of potential date and year fields into a spreadsheet, this is used to scope & segment a customer's year 2000 problems and plan the changes required. The analyses are parameter driven and can thus be used to detect the impact of other field's that should be adjusted at the same time. The analyses and reports can be customised in consultation with the customer. Visit our web pages at http://www.commerce.ie/cp/piercom/ PRINCE Software, Inc. 800 934-2022, 201 934-0022, Phil Courtney e-mail: prince@PRINCEsoftware.com, PORTAL2000@PRINCEsoftware.com *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. The PORTAL 2000 product group contains three MVS-based components to assist in a century date conversion. Each product is available for a free 30-day trial. SURVEY 2000 determines how dates are used in COBOL, Assembler, and PL/I programs. It cross-references programs, copy books, subroutines, jobs, files, CICS tables, and more and helps to determine the magnitude of a change. Search tables may be customized for any type of impact analysis. TRANSLATE 2000 is a rules-based product that helps automate century date conversion for COBOL programs. It provides three conversion techniques to perform either physical changes to programs and files, insert century window logic using standard calendar routines, or change programs while simulating file expansion. SIMULATE 2000 contains facilities for custom date simulation as well as an audit facility to identify programs that retrieve dates/times from the operating systems. A rules-based language enables testing and identification to be performed at over 100 different checkpoints. PORTAL 2000 Project Management Facility centralizes cost and project monitoring for all PORTAL 2000 products and is available with each product. With more than 20 years experience, PORTAL 2000 Professional Services can assist in the assessment, planning and complete conversion of legacy applications. Also available: - MHtran-2 to convert COBOL to OS/VS COBOL II or COBOL/370. - Translate R/W to convert IBM Report Writer programs to native COBOL. - MHtran-1 for comprehensive VSE to MVS conversions. Princeton Softech, Inc. 800 457-7060, 609 497-0205 e-mail: info@PrincetonSoftech.com *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Princeton Softech provides solutions for several specific challenges that arise when upgrading applications to be Year 2000 compliant: - Combining Year 2000 Updates with Ongoing Enhancements - Upgrading to the Year 2000 Releases of Purchased Applications - Reconciling Year 2000 Updates - Creating Relational Test Data Version Merger provides powerful facilities to reconcile Year 2000 changes with other application changes. It is a unique productivity tool that is being used by hundreds of companies to install new releases of third party applications that have been customized and to solve internal concurrent development problems. It can reduce implementation time by over 60% while significantly improving the quality of new releases. Relational Tools for DB2 greatly simplify the process of testing Year 2000 applications and verifying test results. With the Relational Tools, you can: - Build relationally-intact test data bases with only a few minutes of effort. - Transform production data as you copy it to a test data base. This facility is especially useful for generating test data that includes future dates and for Year 2000 changes that include data base modifications. - Inspect and edit related data, adding special test cases to your test data base. - Verify the accuracy of your applications by comparing "before" and "after" images of your test data base. - Refresh your test data base to ensure that your iterative tests access stable test data. - Port relational subsets of data from DB2/MVS to Oracle, Sybase, DB2 for OS2 and AIX, and XDB to enable testing in client/server environments. Quintic Systems, Inc. 800 699-1169, 708 699-1169 Product: Century Conversion Software and services. Century Conversion Software consists of two separate products. Century File Conversion automates the conversion of any file that can be produced in a sequential format. It analyzes data for the occurrence of date fields, expands fields to include a four-digit year, and adjusts record size. It can also adjust actual file data to simulate future dates to verify program accuracy. Century Source Conversion analyzes COBOL source code to identify potential date processing problem areas. It tracks all date name references, indirect and direct, until all chaining events are exhausted. In addition to licensing our software for clients' internal use, we also offer Pilot Study, Impact Analysis, and System Wide Conversion services. Reasoning Systems 415 494-6201, Lawrence Markosian e-mail: info@reasoning.com Product: A suite of software tools & services for assessment, maintenance, re-engineering and QA of existing systems: - Software Refinery - Refine/Cobol - Refine/Ada - Refine/C - Refine/Fortran Rescue 2000 Inc. e-mail: NBG01743@niftyserve.or.jp, Hiroyuki Tanemoto Rescue 2000 Inc. was organized in July 1995 to help mainframe users in Japan solve the Y2K problem. Our products, the 'RESCUE series' consist of 4 products: 1. RESCUE: Base system 2. RESCUE/2000: system for Y2K problem 3. RESCUE/DOA: system for Data Oriented Approach 4. RESCUE/RE: system for Reverse engineering RESCUE is a system for IBM mainframe system maintenance which runs under UNIX. RESCUE has a repository which contains condensed information of JCL, files, DB, DC, programs and cross references. The main functions of RESCUE are: item chasing within a program, item chasing within a job, and item chasing among jobs. For example, when I found a data field 'abc' had wrong data, then I would check how it became wrong. By using upward chasing function of RESCUE, I get visualized information of how 'abc' is made - such as MOVEs and COMPUTEs within a program and a job and among jobs. RESCUE/2000 has additional functions which semi-automatically check and correct Y2K fields and also related fields. RESCUE/DOA has DOA functions such as Data Dictionary, Business rule Dictionary. RESCUE/RE, which is under development, has reverse functions using Business rule Dictionary and information in RESCUE REPOSITORY. Note: products and product literature are in Japanese only. SATYAM Computer Services LTD 908 632-9609, Raghavendra Rao (Ragu Rao) e-mail: gr266@satyam.jvnc.net *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Product: Professional services, and they also offer an integrated year 2000 solution, involving a defined methodology and associated tools. SEEC 412 682-4991 Product: COBOL Analyst, the industry-leading PC-based technology for 21st century analysis, uses sophisticated pattern matching techniques, field analysis, and identification techniques. Application Dictionary provides ongoing value during assessment, as well as during the planning and conversion stages. SEEC is a recognized leader in PC/LAN-based COBOL maintenance and redevelopment solutions. Silverline Industries, Inc. 800 75-SILVER, 908 457-0200, 708 571-5555, 408 248-8373 e-mail: kevinmcn@silverline.com *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Silverline's Y/2000 Compliance Business Unit provides high-end solutions to the conversion concerns of our global clientele. Our structured conversion methodology stems from a Client Tuned approach, one that covers the entire project life cycle. Starting with a detailed systems impact analysis, to moving through pilot conversion, to full system conversion (including parallel runs) and support final implementation. Silverline's 550+ full-time professional employees can provide a high quality, turn-key solution. Silverline has facilities and experienced staff throughout the United States and India. Distributed development is facilitated by having the Silverline design team link your facilities through state-of-the-art satellite communications to Conversion Quality Centers located in Bombay and Madras India. Conversions performed in multiple shifts, across multiple time zones have many advantages. The bottom line? Delivery of converted systems on budget, and ahead of your best expectations. Silverline's success is based on an ISO-9001-3 accredited methodology, and more than a decade of delivering high quality commercial software products and large scale custom projects to large organizations, worldwide. Softlab Northern Europe (44) 0181 742 2277, Julie Tucker or David Gambling e-mail: 100567.1363@compuserve.com The Softlab 2000 programme is a range of services designed to assist companies plan for & implement Year 2000 projects. Utilising Maestro II, Europe's leading application development environment, we offer workshops & health checks, working with an organisation's data to establish the scope & complexity of tasks. We can scan & analyse samples of a customer's code to both prove the concepts & quantify the impact on their total system. - Inventory Management: Industrial strength, LAN-based repository holds a complete inventory of software assets. - Knowledge Capture - Intelligent scanners capture knowledge of not just Cobol, but PL1, Assemblers, AM, SQL etc. - Impact Analysis - Via on-line browsing, queries and reports identify the true scope of the changes required. - Change Management - Maestro II manages change providing instant access to required deliverables & provides automatic notification of changes to team members. - Workflow Management - Sophisticated control mechanisms direct workflow ensuring the quality & integrity of the process. - Configuration Management & Version Control - Tracks versions allowing changes to be made in manageable stages. Software Evolution Technology (SEVTEC) 703 450-6791, Robert S. Arnold e-mail: rarnold@cais.com Product: SEVTEC is a year 2000 problem methodology and re-engineering information services company, helping companies develop technically adequate plans for, and troubleshooting/tuning existing efforts for resolving the year 2000 problem. SEVTEC helps companies put together year 2000 problem solutions. It has a database of tools and services to help companies find applicable technology and providers. SEVTEC also has on-line year 2000 solution processes that can be customized. Selected tools and providers from the database can be matched to the process steps. SEVTEC helps companies review their own plans for technical adequacy, and can help them evaluate tools and services in a procurement. SEVTEC can help companies establish measurable standards for gauging the performance of a year 2000 problem removal effort. Note: To give people needed expertise in beginning and undertaking a year 2000 removal effort, SEVTEC offers seminars on year 2000 problem solutions, impact analysis, and re-engineering (led by Dr. Robert S. Arnold). Note: Robert S. Arnold is Editor of Year 2000 News, an Internet newsletter on Y2K, and the author of the January 1995 "Millennium Now" Application Development Trends article, detailing strategies and technology for resolving Y2K problems. He also writes for the Tick, Tick, Tick newsletter, and is the author of, Software Re-engineering, IEEE Computer Society (1993). SOFTWARE MIGRATIONS LTD (UK) +44 (0) 191-386-0420, Simon Grant or John Ashley e-mail: simon@sjcgrant.demon.co.uk, J.D.Ashley@durham.ac.uk Product: FermaT 2000 is a formal methods tool targeted at year 2000 analysis, particularly (but not exclusively) of IBM Assembler code. It tracks date variables through registers, scratch (and misused) variables, and offsets into memory areas. It then identifies operations carried out on, and using, dates. The output is an annotated and commented listing of the source code in machine-readable form, and a set of metrics giving a profile of the code, year 2000 problem incidence, and cost estimation. FermaT 2000 is available as a tool and a service. SPR (Systems and Programming Resources) 800 SPR-6651 Product: Recently sponsored a one-day seminar in Tulsa, OK. They offer people, software tools and methodology. Synergy 2000, Inc. Product: Balennium, to help mainframe systems tell whether '00', for example, means 1900 or 2000. Mentioned in InformationWeek, Jan. 23, 1995. TransCentury(tm) Data Systems 800 837-7989, 415 255-7082, Joe Warren (and others) e-mail: joeWar110@aol.com *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Product: Calendar Routines TransCentury Calendar Routines are not limited to the 2000 arena but can be put to immediate use in any new development or re-engineering project which involves date processing. The routines provide the most comprehensive and the largest number of totally integrated, fully documented date processing functions commercially available today. TransCentury encourages STANDARDIZED, portable date processing across the enterprise through the shipment of source code, and the availability of Enterprise-wide licensing. Using the routines will not only help ensure correct date processing results and calculations, but can also help your company exit the date programming and maintenance business (which doesn't generate new revenue for most companies). Finally, use of the routines can help lower the costs of year 2000 projects since overall testing time may be shortened due to the reliability of the routines. Once you have identified existing year 2000 date exposures, you can begin to correct the problems in a managed, incremental fashion with simple, consistent calls to TransCentury routines. Call for more info. VIASOFT 602 952-0050, Dale Vecchio e-mail: dale_vecchio@viasoft.com *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Product: ENTERPRISE 2000 VIASOFT, Inc. is a leading provider of business solutions consisting of integrated technology and specialized professional consulting services. We enable customers worldwide to optimize their software investments by substantially reducing the cost of maintaining and redeveloping existing COBOL applications and allowing programming resources to be redeployed to new initiatives, such as new application development and client/server migration. The year 2000 conversion is a specific example of a large scale maintenance project. VIASOFT's Enterprise 2000 solution not only applies our established productivity technology to this problem, but has also developed a completeprocess specific to the year 2000 for determining the size of the problem (impact), as well as the more problematic planning and conversion phases. Visionet Systems Inc 908 329-8090, Farasat Zeh e-mail: visionet@superlink.net *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Visionet offers end to end turnkey Year 2000 conversion services. We have tools & services for the needs of those with S/36, S/38, AS/400 Y2K problems/projects. We operate internationally, and specialize in AS/400 environments (yes RPG II, III, AS/400 Cobol, etc. -- no other environments). We will brief you on the Year 2000 problem, perform impact analysis, expand fields and system test the converted programs. We will then simulate effects of Year 2000 by switching the date to January 1, 2000, on your system to confirm that your business will run absolutely error free into the next millennium. Visionet will also offer a Year 2000 Warranty for a fee. With this warranty we will review your systems on a yearly basis after the conversion to ensure Year 2000 compliance. If you prefer, you can use our tools and services for impact analysis and field expansion while doing the testing and implementation yourself. Wipro Systems 408 737-6125, Anil Garg 215 465-7704, Desmond Nazareth e-mail: wiprosfo@mcimail.com, nazub@mcimail.com *** Year 2000 Information Center Sponsor *** For more information, visit the Year 2000 Information Center at http://www.year2000.com. Product: DA-TE-2000 is a proprietary toolkit for largely automated Impact Analysis, File Conversion, Cross Reference and Date Research. The specialized toolkit handles Y2K application conversions. It provides a flexible, date data driven approach to dealing with an application's Y2K problem. An enterprise wide and application specific Y2K methodology has been developed encompassing Impact Analysis, Data and/or Source Conversions Testing/Validation and Implementation, positioning us to handle a variety of onsite/offshore service requests. Wipro Systems, a division of Wipro Limited, is a premier software consultancy organization in India, offering software development, Re-engineering/Conversion, porting and maintenance services to corporate clients in USA, Europe, and the Far East. Its clients include many Fortune 500 companies and it has provided year 2000 solutions for large banks in the US. Together with its US based partner, Nazub Software, Inc., it has developing solutions in the Y2K area since 1988. XP Software, Inc 508 987-1922, Rui Gama e-mail: xpsoft@tiac.com xPress2000(tm) is a group of tools providing Hardware, Computer Language and Human Language independence. Through visual or batch interfaces, xPress2000(tm) searches potential date matches (through the use of preloaded or user added strings), using field names and date routine calls. An integrated editor allows for quick visualization and manual change of matches. An automated code modification process (after user authorization and definition) allows for quick and effortless millennium related changes. A language definition compiler allows the definition of any computer and/or human language. An evaluation copy is available. In addition, our service partners can provide the full range of millennium services. Visit our web site at http://www.xpsoft.com. --------------------------------------------------------------------------- 6.2 What role can the Internet take in the solution of the Y2K problems? *** We need to find a way to collaborate on a global basis to set standards of approach to solutions and to share every bit of knowledge as common stakeholders in the down-side impact. If we do not ... Reactions to this suggestion are 80% based on a win-lose mindset. 'Let them rot, maybe I can get out on top of this one.' This is based on an incomplete understanding of the interdependency of this problem and a paradigm that is more and more out of date. You cannot gain a competitive advantage if you have handled your Y2K problem, and your suppliers and customers have not. Some reactions (from knowledgeable people) give hope. Their approach is based on a win-win mentality and are in the spirit of organizing within the company, within the branch, sharing knowledge, and so on. My findings (so far) are that you're considered naive or overreacting (depending on your status in the company). I think it will not happen on a large scale, but that is no reason not to try. We realize that sharing knowledge with the rest of the world will help everybody more than trying to invent everything ourselves. That's why the Year 2000 mailing list is a showcase for every company where top management has not yet appreciated the value of Internet and the value of win-win solutions. -- Serge Bouwens --------------------------------------------------------------------------- 6.3 What mailing lists, news groups, archives and other Y2K references are available on the Internet? Are there any other published references on this problem? *** The Year 2000 Information Center home page on the World Wide Web is at http://www.year2000.com. The Information Center has a countdown clock, articles on various aspects of the problem, vendor information, this FAQ, and links to related information. *** There is an Internet mailing list for discussions of year 2000 computer problems. To subscribe, send e-mail to listmanager@hookup.net with SUBSCRIBE YEAR2000 as the BODY of the message. Most of the material in this FAQ comes from this mailing list. *** The current version of this Year 2000 FAQ can be obtained by selecting the hypertext link from the Archives section of the Year 2000 Information Center home page (see above), or by anonymous FTP from www.year2000.com. It is in the /pub/year2000 directory; the file name is y2kfaq.txt. *** IBM is making available to everyone a comprehensive Year 2000 resource guide, at no charge. The guide explains Year 2000 issues and helps users, vendors and customers successfully plan for and implement Year 2000 transitions. The 180- page document, entitled "The Year 2000 and 2-Digit Dates: A Guide for Planning and Introduction," is available on the World Wide Web through the IBM Software Home Page, at http://www.software.ibm.com. Customers can also obtain the guide from their IBM marketing representatives. This no-charge resource is a compilation of IBM's Year 2000 findings, recommended approaches and product listings. Also included in the guidance paper is a bibliography of other Year 2000 publications available throughout the industry. -- from IBM press release, "IBM Readies Customers, Products and Services for Year 2000 Transition," October 30, 1995 *** Year 2000 News is an Internet newsletter distributed free by e-mail. It is published by Software Evolution Technology, Inc. (SEVTEC) and edited by Dr. Robert S. Arnold, president of SEVTEC. To subscribe, send the message "SUBSCRIBE" in the SUBJECT field of your email to "news2000-request@andrew.cais.com". Omit the quotation marks in both the message and the email address. Upper and/or lower case letters are OK. Dr. Arnold is also the author of the January 1995 "Millennium Now" Application Development Trends magazine article, detailing strategies and technology for resolving the year 2000 problem. He also writes for Tick, Tick, Tick... . *** Jan de Decker maintains a collection of references to press articles about the year 2000 problem on the World Wide Web at http://www.club.innet.be/~janjedsp/y2k.htm *** The Millennium Journal is a four-page newsletter published every two months by: Data Dimensions, Inc. 777 108th Ave. NE - Suite 2070 Bellevue, WA 98004 Phone: 800 708-0675, 206 688-1000 Fax: 206 688-1099 E-mail: 76311.1542@compuserve.com, rbergeon@aol.com An always interesting and well-written monthly newsletter on various 2000 subjects. Call them for a copy. *** 2000AD, Inc. produces a quarterly newsletter called Tick Tick Tick. The cost is $75 a year. Their address is PO Box 020538, Brooklyn, NY 11202-0012, phone 1-800-643-TICK (8425), FAX 718-797-9410. *** Here is a list of articles that Ted Swoyer recommended. An * indicates a reference that he found particularly useful. Cohn, Michael B., No Need To Fear The Year 2000, source: unknown. Hayes, Brian, Waiting for 01-01-00, American Scientist, Volume 83, January-February 1995.* Arnold, Dr. Robert S., Millennium Now: Solutions for Century Date Change Impact, Application Development Trends, January 1995.* Sullivan, R. Lee, Ghosts in the Machines, Forbes, June 19, 1995. Associated Press, Troubled Time, Denver Post, May 25, 1995 (and various others across the country). Ross, Noah, The End of the Century is Nearer Than You Think, Application Development Trends, April 1995.* Furman, Jeff, Marotta, Albert, and Candiotti, Cliff, Party When It's 1999, Software Magazine, April 1995.* Fine, Doug, Companies Brace for Millennium, Infoworld, April 10, 1995. Cini, Al, System Bug of the Apocalypse, Internetwork, January 1995. Goodwin, Bill, Tick, Tick, Tick... (a newsletter), 2000AD, Inc., Brooklyn, NY. Arnold, Dr. Robert S. Resolving Year 2000 Problems in Legacy Software, a presentation at Software Quality Week, San Francisco, CA, June 1, 1995.* *** Computers in Crisis How to Avert the Coming Worldwide Computer Systems Collapse by Jerome T. Murray and Marilyn J. Murray Petrocelli Books Inc.; New York, 1984; ISBN 0-89433-223-6 Table of Contents: Preface Acknowledgments Time Measurement: A Brief Review Algorithms, Notation, Pseudocode, and Programming The 8-Digit Date Puzzle Short Interval Aging Extended Interval Aging The Translation Algorithm Date Versus Name of Day Conversion of the Neojulian Date The Algorithm for Easter The Gregorian Status Indicator The Conversion Plan Appendix A Appendix B Appendix C Appendix D References Index --------------------------------------------------------------------------- 6.4 I have to assess how much of a problem we have with legacy assembler code. Any ideas/products/vendors to facilitate the analysis? *** There is no silver bullet solution to the year 2000 problem, especially for low-level languages like Assembler. The best developers can hope for is to automate the processes of code analysis to identify date problems, and impact analysis on proposed changes. The objective is to enter testing with as high a degree of confidence as possible that errors will not be present. Year 2000 is the most timescaled project in IT history. Vendors must react quickly to the demands of the industry, yet produce high quality tools. Assembler and PL/1 are at the unfashionable end of themarket for vendors, yet they present the most complex legacy problems. *** Software Migrations Limited and Durham Software Engineering are applying the technology of their reverse engineering tool FermaT to the looming problem of the year 2000. FermaT is an easy to use formal methods tool for analysis, restructuring and migration. It has been proved in industry, notably on migration of Assembler to C and COBOL. The secret of FermaT is that it captures all the functionality of the application, and reverse engineers it to a high level specification, restructured code, or a new language. Retention of semantic equivalence is guaranteed - black box test suites remain valid. Functionality, including year 2000, can also be altered during restructuring or migration. FermaT 2000 is a version of FermaT tailored explicitly for year 2000 analysis. It tracks date variables through registers, scratch (and misused) variables, and offsets into memory areas. It then identifies operations carried out on, and using, dates. The output is an annotated and commented listing of the source code in machine-readable form, and a set of metrics giving a profile of the code and year 2000 problem incidence. Initially FermaT 2000 will handle IBM Assembler and Jovial, to be followed by other 'difficult' languages for which a demand is established - for instance PL/1, FORTRAN, CORAL, and other assemblers. Because only a subset of the full functionality of FermaT is required, it is possible for our tool development team to react quickly to market demands. FermaT 2000 is available as a tool or a service. It is the only high- capability solution available to the owners of Assembler systems. -- John Ashley , Durham Software Engineering Ltd, Durham, United Kingdom DH1 3SW *** Assembler (and other languages beside COBOL) are sticky issues for the year 2000. Most of the tools available assume COBOL and many of them assume IBM environments. There are a few tools and services, however, that are language independent and fewer that are platform independent, but you need to hunt for them. I am continually surprised at the number of languages concurrently in use in today's MIS shops. Language independent tools (like the one that facilitates the Peritus Year 2000 Enhancement Program) have an architecture that permits multiple languages to be processed, but a particular language or dialect may require customization work by the vendor. Most vendors are willing to do this if the business makes business sense. (For example, we have discussed doing an Assembler front-end but have not yet had any serious interest from a client to do so.) With respect to the companies we are talking with, Assembler seems to be a small percentage of their total code and they say they will do the assembler portions by hand. I would be interested in the sets of languages (programming, database, 4GL, etc.) that people use in their companies and what percentage of the total code is in each language. -- Ted Swoyer (tswoyer@peritus.com), Peritus Software Services, Inc. --------------------------------------------------------------------------- 6.5 What standards exist for computer representation of dates? Where can I get copies of these standards? Are they available on the Internet? As someone once said, "The great thing about standards is that there are so many to choose from." [Can anyone document the source of this quotation?] Both the American National Standards Institute (ANSI) and the International Organization for Standardization (ISO) have standards for computer representation of dates. Unfortunately, both standards allow a number of different formats, including some formats that have only two digits for the year. The ANSI standard is ANSI X3.30-1985 (R1991) "Representation for Calendar Date and Ordinal Date for Information Interchange." The ISO standard is ISO 8601:1988 "Data elements and interchange formats -- Information interchange -- Representation of dates and times." The text of ANSI and ISO standards are not on the Internet. They are copyrighted documents that you have to buy, and the prices are exorbitant. Both ANSI and ISO have on-line catalogs that you can access and search on the World Wide Web. You can get to the catalogs, and other information, from each organization's home page: ANSI - http://www.ansi.org ISO - http://www.iso.ch You can order both ANSI and ISO standards from ANSI by calling 212 642-4900 between 8:45 a.m. and 4:45 p.m. Eastern time. They accept MasterCard, Visa, and American Express. For more detail and other ways to order, see the ordering information accessible from their home page. (The ordering information seems to say that you have to have a deposit account with them to order by phone, but they do accept credit card orders.) From the ISO home page you can find out who sells ISO standards in other countries. ANSI X3.30-1985 (R1991) "Representation for Calendar Date and Ordinal Date for Information Interchange" is two pages and costs US$14 plus $4 handling. ISO 8601:1988 "Data elements and interchange formats -- Information interchange -- Representation of dates and times" is 14 pages and costs US$48 plus $5 handling. (Prices as of September 1995) --------------------------------------------------------------------------- 6.6 I'm near the beginning of my Y2K effort and I've discovered that I have compiled applications that I do not have the source code for. How can I get the source code back in order to fix it? *** I realize that missing source code is symptomatic of slack management procedures and not reserved to Y2K. We could also say that if every I/S shop had adopted better date standards none of this would be necessary. But we didn't, so how are we going to deal with it? Chris Gardner of ViaSoft may have summed it up best however when he referred to the *problem* as trying to turn a sausage back into a pig! You can try but what comes out isn't pretty! -- Mike Turgeon *** Try Jim Rahm at The Source Recovery Company (catchy name, eh?) in Atlanta at 770 785-9801 or 72604.2340@compuserve.com. My understanding is that they offer a service in which you send them what you have (load module, copybooks, listings, whatever) and they return you a working source module. According to Jim Rahm, they handle COBOL and Assembler for MVS, VM or VSE. Price seems quite reasonable. If you use them (or any similar service), please tell all of us what you think. There's clearly going to be a LOT of this in year-2000 projects. *** The applications programmers around here always think they have lost source code, because they forget that systems support takes backups. Did you remember to check your oldest backup tapes for that source data? Otherwise, I'm afraid to say that disassembling your programs is your only hope ... or you can rewrite them. *** Sometimes, even having the old source code doesn't help too much. Note that much old source no longer meets the standards of new compilers, but the generated program still runs. -- Reg Harbeck =========================================================================== 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. Michael J. Averbuch Serge Bouwens Donald Brown Brian Christenson Adrian Clark Pierre Cloutier Duncan G. Connall Mike Drabicky David Eddy Andrew Eldridge John Franciscovich Roger Gates Bear Giles Sherry L. Goncharsky Hans Goossens Reg Harbeck Francis J. Hensler Karen D. Herbert John L. Horton Ron Hunter-Duvar Lanny Jones Cliff Kurtzman Romy Leibler Gene Lynd Jacqui Macdougal Francis D. MacLellan Geoff May Bob McClenon Brenda McKelvey Pat McKeown Daniel A. McLaughlin Dick Murray David A, Negrey Richard Newbold Alf Ohlsson Mike Olsem Bill Parkinson Raghavendra Rao Dave Rybarczyk Rob Schneider Pris Sears Stan Sieler David Silver Ivan C. Smith Jens Peter Soltoft Peter Somers Tom Ster Ted Swoyer Marty Tabnik Ralph G. Taylor Randall Thomas <76646.333@compuserve.com> Rick Toker Mike Turgeon Diana van Dyk Allan E. Van Ness Steve Vogel Joe Warren Jerry Whittle Bob Wier Mike 7.2 Copyright and Permission Copyright 1995, 1996 Robert J. Sandler. All rights reserved. Contains material copyright by others. Permission is granted to copy and distribute this document by any means, provided that it is copied in its entirety, including this notice and the disclaimer below, and that no fee is charged other than the actual cost of transmission or reproduction or the standard connection-time charges on a BBS, on-line service, or Internet connection. It may not be distributed for financial gain or included in a commercial collection or compilation without prior permission from the copyright owner. Most company names and product names mentioned in this document are trademarks or registered trademarks of the respective companies. 7.3 Disclaimer While the information contained in this document is believed to be accurate, Robert J. Sandler, Peter de Jager, de Jager & Co., The Tenagra Corporation, and the contributors do not guarantee the accuracy, adequacy, or completeness of the information, and assume no responsibility for errors or omissions, nor any liability for damages resulting from the use of this information. The views and opinions expressed in this document do not necessarily reflect the position of the maintainer. Affiliations are given for identification purposes only. --------------------------------------------------------------------------- End of the Year 2000 FAQ --------------------------------------------------------------------------- Robert J. Sandler <70023.2572@compuserve.com>