MANAGING TECHNOLOGY edited by Charles B. Lowry

The Year 2000: Millennial Implications for Libraries? by Jim Young and Vicki Slagle Johns

We are all familiar with the purpose of the florid rhetorical statements that arise from a point of view. Equally familiar is the chilling warning of disastor, a phenomenon not dispelled by modern media and certainly very much a mainstay of the public diet at least since the rise of the “Yellow Press” and muckraking in the last century. Sometimes, however, it is good to take heed. It was not that Rachel Carson was wrong when she wrote Silent Spring, but that she was listened to and that fundamental policy decisions were made based on her science. I won’t pursue the possiblities of analogy to extinction, but it is clear that a warning needs to be sounded about the concerns raised by this issue’s contributors. To make a rhetorical point, the literature of computing is full of discussion of the “year 2000” issue’s and Cobol and Fortran programmers are leav- ing retirement to work as consultants on legacy systems in peril. On the other hand, a simple search of Library Literature using “year 2000” resulted in 71 citations of which two were related to the ‘problem” and the remainder largely to “rosy predictions ” on other matters.-CBL, University of Mary- land, College Park, Maryland.

E ach decade before the dawn of a new millenium, a

fresh crop of fanatics predicts the collapse of civiliza-

tion. The year 2000 promises to be no different- except that this time around. many in the computer world have joined the ranks of doomsayers. Among other possibilities, programmers and others in the know predict that after midnight 1999, city traffic signaling systems could run amok; bank accounts may be inaccessible; credit cards will suddenly be useless; grocery stories will run low on stock; and utility com- panies’ power delivery may falter or fail completely.

No, the high tech world has not converted to some kind of millenial religious cult. Instead, their extreme pronouncements are based on a firm fact: many software programs and hardware platforms are not equipped to handle the transition to the year 2000.

DESCRIPTION OF THE PROBLEM

What is often called “The Year 2000 Problem” originated in the 1960s when programmers were developing software for the first generation of computers. At that time, when huge mainframes had far less power than today’s bottom-of-the-line

lim Young is Chief Executive Officer, Sirsi Corporation; Vicki Slag/e

lohns, Communications Specialist, Sirsi Corporation, 689 Discovery

Drive, Hun&vi//e, Alabama 35806-2801.

desktop model, very few programmers imagined how widespread the use of computers and the accompanying software would become. Certainly, few anticipated that the software programs they were writing would still be in use 40 years later. In addition, the cost of memory was far greater than it is today, meaning that using four-digit years would add significantly to the software’s total cost. For both these reasons, programmers tended to store dates in two digits: “6 1” rather than “1961.” In 2000, the date will be “00” in programs and databases that were created in this manner.

Start manipulating some data using two-digit dates and you will see the problem. After 2000, any calculation or comparison based on a two-digit dataset will come out incorrectly. For example, if you try to pay with a credit card that expires in 2004, the system may interpret that it has been expired for 96 years; if you were born in 1960, your age may be interpreted as minus 40 years old (forget buying beer!); and your state or fed- eral tax bill for 2000 might cover 99 years.

If you have stored any personal files using two-digit year fields, you may generate some confusion of your own. For example, suppose that you use a spreadsheet program to gener- ate monthly work reports for your department and you have been saving files using the last two digits of the year and the month. If you continue this convention after the year 2000 and then try to sort those reports chronologically, you’ll find that your most recent reports are placed in the “least recent” posi- tion, and vice versa. You may also have used the two-digit year file-saving convention for word processing or other desktop programs and it could cause unexpected confusion in just a few years.

In programs and systems that do not have the year 2000 problem, dates are commonly stored in one of two ways. The first is to use four-digit fields to signify the year: “1997” and “2007” rather than “97” and “07.” The second is to use Julian- style dates, which reflect the amount of time elapsed since a fixed starting date. In “Challenges and Legal Aspects of the Year 2000” (http://www.wsrcg.com/), Consultant Warren S. Reid points out that the year 2000 problem may actually occur a year in advance in some long-running programs or systems. He explains that some developers, designers, and programmers may have used “99” to signify either “end of program” or “delete file,” in which case some programs may fail or experi- ence critical errors at the beginning of 1999.

THE YEAR 2000 PROBLEM: EFFECT ON THE LIBRARY INDUSTRY

Pick up your favorite computer magazine or do a Web search and you will quickly see how many industries and

January 1998 53

organizations are affected by the year 2000 problem. For example, a May 15, 1997 report issued by the U.S. Office of Management and Budget (http:Nwww.cio.fed.gov/ ydkrev.htm) states that only 21 percent of 7,649 mission- critical federal systems are already Year 2000 compliant. The report estimates the cost of bringing non-compliant systems up to date will be approximately $2.9 billion. A March 16, 1997 UK Sunday Times article (http://www.compinfo.co.ukly2W scotwid.htm) reports that the UK insurance firm Scottish Widows is disposing of its investments in all non-compliant companies. A May 9, 1997 statement and press release from the Federal Financial Institutions Examination Council (FFIEC) to insured financial institutions (http:Nwww.fdic.govl banknews/fils/l997/fl9750.html) included instructions for assessing Year 2000 readiness. A June 2, 1997 Information Week article (http:l/www.techweb.cornlsel directlink.cgi?IWKl9970602S0065) predicts that as much as 25 percent of installed call center equipment may need to be replaced with Year 2000-compliant equipment.

The year 2000 may or may not have much of an effect on your library’s operations, depending on the readiness of the sys- tem or systems that you use. However, it is wise to consider all the different areas that could be affected should your system have a problem handling the date transition. One obvious con- cern is circulation. Suppose your library cards are normally issued for two years. So throughout the year of 1999, you may issue cards that expire on various days during 2001. However, if your circulation system uses a two-digit-year system, all 1999-issued cards will expire on the first day of 2000. However lengthy your circulation lines may have been previously, this scenario would see them snaking out the door.

Due dates on materials would be similarly affected. In a sys- tem that only handles two-digit years, a book checked out on December 20,1999 and due on January lo,2000 might become 99 years overdue on January 1,200O. If your system simply does not recognize a “00” date field, it is also possible that the book will never come due. The same problem would also crop up in renewal dates and in fine dates.

In acquisitions and serials, automatic claims and cancella- tions could go seriously awry. If the claim or cancellation period spans the century change and your system is unable to handle the transition, on January 1 you may find that it is gen- erating a flurry of claim and cancellation notices well in advance of the actual cutoff date. On the other hand, if “00” is unrecognizable to your system, claim and cancellation notices may never be generated. Whether you end up paying for a sec- ond copy that you do not need or not claiming a copy that you truly did not receive, the bottom line will be a significant loss of funds.

You may experience a sudden surge in cancellations of interlibrary loan requests if the “date needed by” falls after the beginning of the year 2000. In what might be the ultimate library nightmare, you might find yourself unable to reconstruct your database should your system go down. If your audit trails of database transactions contain only two-digit years, it will be impossible for the system to restore them in the correct chrono- logical order. Instead, your latest transactions-those made in the year 2000-would be restored first. While it is improbable that you would not have backup tapes that would prevent such a dramatic failure, it is still wise to think about how your audit trails are stored.

Even if the system or systems you use to handle library func- tions are year 2000 compliant, the software that you use for such functions as payroll, accounting, and word processing may not be. In addition, it is important to consider how different library service suppliers might be affected by the year 2000 issue. In the following sections, we will describe how a sub- scription service, a book vendor, and a cataloging service are preparing for the year 2000 transition. We will also provide var- ious librarians’ perspectives on the year 2000’s potential effect on their library’s operations.

SUBSCRIPTION SERVICE: PLANNING AHEAD FOR ON-TIME DELIVERY

At the subscription agency we interviewed, primary year 2000 issues were the potential effect on electronic invoicing of customers and multi-year orders to publishers. For example, an invoice or an order for a three-year period placed to begin in 1998 could be disrupted if the date field allowed for only a two-digit year entry. The agency had already analyzed its systems for year 2000 compliance and needed to change and test almost 50,000 lines of code resident on its mainframe and PC systems. All core business portions of its internal systems are now year 2000 compliant, with internal-use display portions scheduled for completion by spring 1998.

However, internal systems were not the only concern. The agency also had to ensure that every customer who used an inte- grated library system to electronic invoices could be assured by the agent and their system vendor that their invoices would load correctly and that every vendor to whom it sent electronic orders was equipped to handle orders with four-digit dates. These vendors included publishers as well as fulfillment cen- ters. Because of its concern about the impact on libraries’ multi- year orders, this subscription service moved aggressively early in 1997 to contact all vendors concerned and spent the year test- ing modified programs.

CATALOGING SERVICE: PREVENTING A DOMINO EFFECT

The cataloging service we contacted noted that its billing and accounting systems were experiencing problems that it described as “typical of any business where the year 2000 problem is concerned.” One library-related concern was disruption of the service’s interlibrary loan system. When users need a specific title, the request may be sent to up to five different potential lenders. Each potential lender has the request for four days; if there is no response, the request is automatically sent to the next lender. The software used to handle this process must be year-2000 compliant; otherwise, requests made in the last few days in December, 1999 will not progress correctly into January, 2000.

The cataloging service had already tested both its cataloging and interlibrary loan systems by setting the system clock for Dec. 3 1, 1999 and allowing it to run past midnight, 2000. It found that most of its software was year-2000 compliant. How- ever, some year fields were still being displayed in two digits. Those fields are currently being changed to display in four dig- its, and all systems are expected to perform correctly through the date transition.

However, one of the most significant issues in cataloging is external. Currently, the LCCN in MARC records uses a two- digit year field. However, sometime after 2000, the LCCN will be restructured with a four-digit year field. In addition to repro-

54 The Journal of Academic Librarianship