Year 2000: Best Practices for Y2K Millenium Computing
Authors: Dick Lefkon
Venue:  (1998)

From the Book:PREFACE: Preface If you are 35 and reading this book at midnight of 1999, you will suddenly qualify for retirement on some pension systems. And if you're 82 or 83 years old at that time, some college selection computers will be eager to bring you in as a standard age first-year student. In a nutshell, that's the Year 2000/Y2K/Millennium computing crisis: Because most mainframe programs and machines—from Eisenhower through Clinton—stored and used only a two-digit year (97, not 1997), the year after O99 is O00. Take your age, subtract it from 00 and use a sign-free number, and you'll see how the example just described makes sense. If you don't believe me, how do you account for the 104-year-old woman in Minnesota who recently was sent a letter inviting her to join a pre-school there? Your core Y2K mission is to make your computer systems run right and make their external interfaces conform to (probably) the new FIPS and ANSI date standards reproduced in the first chapter of this book. Your non-IS people will learn to replace non-conformant embedded chips, so that, in March of this “surprise” leap year, your security systems won't automatically seal off the entryways every Friday, thinking it is a Saturday. Many goofy and amusing stories, often true, can be told about Year 2000 Computing. But it is very serious business. The cost of making the world's information systems work right will rival the cost of the U.S. Savings and Loan debacle—slightly smaller if you consider just the fixes, but larger if you include the damage and displacement costs to those who don't fix. Asingleparts factory shutdown recently stopped all General Motors manufacturing for months, so don't suppose that you can fix your systems and ignore whether or not your business partners fix theirs. And offsite code conversion has its savings limits, as you'll expend greater effort setting the inventory, baselining it onsite with confidential data, and retesting. Can a company change its systems to be Year 2000 conformant? Mostly, yes! I reported on having done this in 1984, and others may have done it earlier and just not reported it. (Having a non-production “time machine” test computer helped.) That company-wide change was in the securities business, and we treated the Y2K need as though it was an inflexible regulatory requirement with noncompliance penalties in both cash and reputation. So should you. Have organizations known about Y2K for a long time? Most certainly. For instance, attendees at my 1991 Y2K awareness paper presentations at the “Safe Computing” and “National Computer Security” conferences later told me they'd carried the alert back to their own companies, agencies and armed service branches. Is there a lot of time left? Unfortunately not, and two precedents come to mind. After AIDS was recognized as a general-population threat in 1985, it took eleven years of significant funding to bring forth medicines that can reduce its virus concentrations in the human body. But the U.S. metric conversion—of cost to manufacturing similar to Year 2000 for computing—was never completed, even though given a generous 20 years deadline. Year O00 is approaching much faster, and most suggest you finish before O99. Should conducting this Millennium war be left entirely to the “soldiers?” Probably not. Programmer/analysts generally reserve highest professional respect for those of greatest expertise, but several of the Y2K gurus gossiping over the Internet don't just want systems to work right and interfaces to carry a four-digit year: They won't rest —until every man, woman and child around the globe— also says “1998” instead of OO98. Should, then, techies be excluded from the deliberations? Again, no. The CIO sets the strategic course, the Y2K manager devises and executes the plan, but the house expert and soldier programmer/analysts should all also be involved in the planning phases for two reasons: (1) Collectively, they know most skeletons and closets; no outsourcing will as quickly catch dates passed in FILLER fields. And (2) morale must be one of your centerpieces or you'll find skeleton/closet expertise peeling away as each new month adds another dollar or two onto Y2K coder and manager hourly rates. This book truly represents the state of the art, both for do-it-yourself and for choosing a vendor to help if that's your desire. IBM, GUIDE, SIM, IMF, IMC, ACM, IEEE, AITP/DPMA, and nearly every recognized top professional in this field have permitted their best Y2K work to be reprinted here so that your corporation or agency will have available the knowledge to accomplish this organization-survival mission. These pages contain at least half the information you'll need to make decisions and take action. Once you absorb respectively the sections for CEO/CIO-expert-manager, you'll know how to obtain any further information needed. You'll also be able to defend yourself from vendors who truly believe they have another solution. You'll also be better at separating hard data from fluff at www sites such as dod.mil, gsa.gov, y2klinks.com, and year2000.command limiting your (212) 539-3072 Editor's Advice inquiries. If you had the extra millions or billions, you might be tempted to ignore and outsource the whole issue. Unfortunately, this is not a standard oranges-and-tangerines order, and it won't work just to throw three darts at a vendor list and select the best bid. that's because the solution paths (both outsourced and in-house) differ markedly from each other, and you can't choose if you don't know. For each application, you'll need to decide among date expansion, “smart” century, century, window, date shift in code or data, dropping/replacing the app, or not fixing it this century. Most technical and management books present one consistent approach. Even where excellent, that viewpoint will work only accidentally for your Y2K effort because of the diversity of distinct cures. The present volume lays out at least three different well-stated solutions to each Y2K issue. To enable this, we ran a four-month public competition for “Year 2000 Best Practices” papers. To publicize its completion, we are presenting a series of two-day Y2K conference free to user organizations, ever since the first edition was published in autumn of 1996. Even before being revised and expanded, that book was welcomed into the personal libraries of most Year 2000 practitioners; was heavily cited and excerpted in well-known Year 2000-related publications; was the technology resource for expert testimony to joint hearings of the U.S. House of Representatives Subcommittees on Science/Technology and Government Management; and contained material explicitly cited in expert testimony before the U.S. Senate Banking Committee. With this “final report” in hand, you'll see that Y2K isn't Nobel Prize stuff—just a prohibitively large set of familiar tasks. The best way to use this compendium is to get people bearing the titles CEO/CIO-expert-manager into a room for a series of meetings. Except for the start-up, all the planning meetings follow your usual format; but at the first meeting, each job title takes on the commitment to absorb a roughly equal slice of this book and at the next meeting to distribute/discuss a typed summary of aspects of our content which are specific to your organization. For most solutions, running this management-intensive effort under your established successful process will be a good way to proceed: You'll have the ongoing ability to triage nonessential conversions away from critical ones. And, when the inevitable bulge arises, you can divert reliable resources from non-Y2K efforts—not be forced to start inventing the wheel near the scheduled end of your path. Large organizations without an established “funnel” will want to set up a distinct (Y2K) project office. Remember that AITP used to be named DPMA, Data Processing Management Association. Our task as IS management is — literally — to rescue our organizations. All the co-authors and editors, including the initial project sponsors at AITPOs Special Interest Group for Mainframe Computers, want you to succeed! Dick Lefkon