Abstract
As a large and technologically-dependent institution, Dartmouth College is vulnerable to Y2K-related problems in many aspects of day-to-day functions. In this paper we survey the effect of the Y2K problem on the College and attempt to provide insight into the process by which Dartmouth is tackling the problem as a whole. After some background on Dartmouth's general approach, we analyze issues relating to infrastructure, including water and sewer, electricity and heat, voice network, data network, and security. Next, we discuss the Y2K problem's impact on Dartmouth's academics, focusing on research issues, student computing, and its three professional schools. We conclude with an overview of Y2K issues related to the College's administrative systems, which include systems maintained by Administrative Computing, Informational Systems, Technical Services, and Telephone Systems. In each section, we explain Dartmouth's approach to these issues in terms of past, present, and future efforts to identify and remediate Y2K problems.
Contents
1. Introduction
2. Background
3. Infrastructure
4. Academic Functions
5. Administrative
Functions
6. Summary
7. Acknowledgements
8. Questions
9. References
As arguably the "Most Wired" College in America, Dartmouth College has substantial Y2K compliance issues with which to grapple. Efforts to avert Y2K problems have gone on for several years within many different parts of the Dartmouth hierarchy, and countless personnel have spent much time analyzing and quantifying the problem on campus. Dartmouth's efforts to identify and remediate Y2K problems can best be broken up into issues related to infrastructure, academic functions, and administrative functions. To that end this paper is divided into three sections, each enumerating the efforts and issues attributed to its respective Dartmouth organizations. In Section 3 we discuss the impact of Y2K on Dartmouth's infrastructure, including such services as water and sewer, electricity and heat, voice network, data network, and security. In Section 4 we discuss Y2K issues within the academic functions of the College, including research issues, non-research computing, and an overview of the professional schools. In Section 5 we discuss Y2K issues as the affect Dartmouth's administrative functions, including systems maintained by Administrative Computing, Informational Systems, Technical Services, and Telephone Systems. We believe this functional organization to be in keeping with Dartmouth's own effort to characterize its Y2K issues as a whole.
Unlike the plans of many institutions, no true top-down attack on the problem exists at Dartmouth; no special workers have been hired and no large consulting firms have been taken on. The College has imposed no explicit deadlines or requirements on its departments. Dartmouth instead relies on its existing administrative structure--including its normal internal auditing system--to deal with Y2K.
Less than a year ago, a committee on Y2K was formed. There was no higher edict calling for the committee's existence; those administrators most affected by Y2K simply decided it was time to get together on the issue in a more formal way. Some members of the committee even prefer not to call it a committee at all, referring to it instead as an "informal group" or task force. The titular heads of the committee are Lawrence Levine and Terry Keane [LKh]. As Director of Computing Services, Mr. Levine has an obvious stake in ensuring Y2K compliance in all aspects of computing at Dartmouth [LKh]. Ms. Keane, as Director of Audit and Advisory Services, performs her usual role as a caretaker of the integrity and accountability of the institution as a whole, which includes computer- and non-computer-related issues [LKh]. This informal committee also includes representatives from such units as Facilities, Operations and Management and the graduate schools, though the entire group has never met at one time [Kea]. It is important to note that while the committee is less than a year old, many of its principal players have been communicating independently about Y2K for a long time. For example, Ms. Keane and Bill Barry, Director of Administrative Computing, have discussed Y2K issues off and on over the past two years [Kea].
During committee meetings, those present discuss what stage of Y2K preparedness they appear to have achieved: what they have done, what they are doing, and what is planned to be done. Ms. Keane believes the meetings are productive and that a given group can always find one thing that should be worked on next. This process is not unlike other auditing efforts at Dartmouth, though it is a more universal problem than most issues are. At this point in the process, each organization represented on the committee is preparing a spreadsheet reporting the status of their progress. [Kea]
The reports from each agency will eventually be compiled into one document by the auditing office, for the next Trustees' Audit Subcommittee meeting in May 1999. Y2K has been discussed at each of the past few meetings [Kea]. The Trustees' early discussions centered mostly on administrative functions of the College, including such systems as payroll, admissions, and student meal plans, without which many students and employees would be seriously inconvenienced. For example, many employees and their families would be adversely affected in the event of a two-week delay in issuing paychecks. But as the unfinished work in those administrative areas progressively lessened, more concern has been expressed over infrastructure and research issues at Dartmouth, which are considered to be areas requiring the most resources in the remaining months [Kea]. The importance of infrastructure is quite obvious; Dartmouth would simply cease to function without such services as power, heat, water and sewer. The potential impact of Y2K on Dartmouth research is perhaps more subtle. A substantial amount of Dartmouth's funding comes from research-related grants, many of which could be in danger in the event of Y2K-related research project catastrophes. As a result, research computing is considered one of Dartmouth's greatest risk areas [LKh].
Computers rely on electricity, scientific research may rely on access to water and, whether it be a phone call or an e-mail, both may rely on communication. It is this basic and widespread reliance on infrastructure that makes it's function one of the most crucial in the Dartmouth community. This considered, it is especially unfortunate that we were not able to gather much information about this subject. Despite our repeated efforts, FO&M, the department in charge of the majority of Dartmouth's infrastructure, was almost wholly unwilling to provide us with information, whether by phone, e-mail, or formal interview. Terry Keane, Director of Audit and Advisory Services, because she deals with FO&M and has limited knowledge of their status, was helpful in providing us with some information. The remainder was provided by the Hanover Group of Eric Jenkins, Lillie Ng, and Michelle Cavallaro with respect to issues that affected Dartmouth, through their effects on the town of Hanover, and company web pages, where outside vendor were concerned. In response to one of our early e-mails suggesting a meeting time within the next couple of weeks, Michael Getter, Director of FO&M tersely replied, "I am sorry but our information is not in a state where it can be easily distributed at this time. Nor will it be by next week" [Cav]. Terry Keane believes there is an explanation for this, though it is by no means sufficient. She writes, "FO&M is in the midst of compiling a spreadsheet to document the areas they have reviewed. That is not complete yet and I suspect that is why Mike Getter is holding off disclosing it." In other words, additional effort required to deal with us, even minimally, is not warranted.
Thankfully, Charlie Wilber, Director of Telephone Services (separate from FO&M), and W. Punch Taylor, Director of Computing Services (separate from FO&M), were more than helpful in providing information concerning Dartmouth's voice and data networks, respectively. Thus, with regard to these subjects we feel our information is complete. Regarding Water and Sewer, Electricity, Heat, and Security Systems, we hope we have acquired enough information to reach informed conclusions as to their current Y2K status as well as their performance come January 1st, 2000.
Though Dartmouth is self-sufficient in many ways, one thing for which it must rely on external support is the water and sewage system. The town of Hanover provides the lead link into Dartmouth system of pipes and so Dartmouth's ability to function in this respect is dependent on Hanover's. Some effort has been made to contact town representatives but they have not yet provided Dartmouth with a clear picture as to their progress on Y2K related issues. According to Terry Keane, Directory of Audit and Advisory Services, the minutes to the meetings the town provided were "a little sketchy" [Kea] in terms of their progress so far as well as their plans for the future. Dartmouth plans to send a group of engineers to the next Y2K meeting to get a better sense of the town's preparedness. Currently however, "we just don't know where they're at" [Kea]. Thanks to information provided to us by the Hanover Group [Ng] however, we do know where they're at.
Not much concern has arisen in Hanover over the water system with respect to its Y2K compliance, specifically because "the water system is operated by manual pumps, with no flow control done by computers... The same [can be] said of the waste water treatment process" [Ng]. The only concern lies in the fact that the accounting software is not yet compliant, but this in no regard will affect the ability of water to flow or the treatment plant to process sewage and so, we have no reason to be concerned [Ng]. Peter Kulbacki, the Director of Public Works for the Town of Hanover, has given his assurance that "Water will flow" [Ng].
With respect to electricity and heat, Dartmouth is better prepared than most institutions. Dartmouth owns and operates a steam plant which, when running at full power, would be capable of heating and powering all college facilities including dormitories. The plant generator works by heating oil, stored in large reserve tanks, to produce steam. This steam is used to turn generators, providing electricity, and the excess steam provides heat for the campus. The oil tanks are topped off three times daily and when full, could supply enough fuel to heat and power the entire campus for a week to ten days. Provided we have access to an oil supplier, "we [could] last indefinitely" says Ms. Keane. Dartmouth has contacted their suppliers and expects such access.
Dartmouth's plant typically provides only between thirty and fifty percent of Dartmouth's power. The remaining amount is provided by an outside vendor, Granite State Electric, through the town of Hanover [Ng]. While their compliance is unsure and our efforts to contact FO&M regarding this issue yielded little, in the event that they are unable to provide power, Dartmouth can rely entirely on its own plant.
With respect to the compliance of Dartmouth's plant, it is one of the oldest in the country and, as such, is not heavily dependent on computer technology. Some recent "upgrades" however, have incorporated computers and though none of the embedded logic is thought to be problematic, tests are planned for a period between Summer and Fall terms. Overall, Dartmouth expects it will have no problem providing the campus with electricity [Kea].
Beginning in 1988, when unreliable phone service and a profit incentive prompted Dartmouth to purchase the underlying telephone infrastructure from its previous owner and administrator, NYNEX, Dartmouth has owned and maintained the entire intra-campus telephone system [Wil1]. Thus, Dartmouth is in a position unique among colleges in that it will not be forced to rely on the compliance of external systems for intra-campus telephone service. Dartmouth is vulnerable however, as is the case with all but the largest of corporations, in terms of both local, and more problematically, long distance telephone service. For these services Dartmouth relies on Bell Atlantic and AT&T, respectively. Especially in times of crisis, such as the situation that may arise this coming New Year, the functioning of the phone system, as a means for instant, interactive communication, will be crucial in fixing most problems.
Not only is the proper functioning of Dartmouth's telephone system crucial to intra-campus phone service, but, as all outgoing calls must pass through the intra-campus network, it is crucial to all local and long distance service as well [Wil1]. So the Y2K compliance of Dartmouth's system is extremely important.
Akin to routers, which govern the paths of data connections on a computer network, a phone switch governs the paths of all incoming and outgoing telephone connections on a voice network. As it is the only intelligent piece of hardware in the network it is the only hardware vulnerable to the Y2K bug. The phone switch Dartmouth employs is a fairly recent digital model by Ericsson. While the operating system it runs currently is not the latest release, Ericsson has promised a Y2K patch, due to be released shortly, and a patch to remedy the leap year bug due later this year. Though neither patch has yet been obtained, head of Telephone Services, Charlie Wilber, is confident they will be delivered in time [Wil1].
Bell Atlantic provides Dartmouth's local telephone service. Mr. Wilber has inquired and been told there should be no problems, but could not obtain assurance in writing [Wil1]. For specific information on Bell Atlantic's Y2K status we consulted their web page. We found the statement, " Bell Atlantic's goal is to have its network and other mission critical systems Year 2000 compliant by June 30, 1999" [BA]. This date is only three months from present and no indication of current status was given. Bell Atlantic did, in fact, provide a link to updates on the status of their network but the page, which contained no information whatsoever, was "Under Construction" [BA].
AT&T, which provides Dartmouth's long distance telephone service, "had a target of December 31, 1998 for the completion of assessment, revision, and testing of those systems and network elements that directly impact our customers... we achieved 100 percent assessment, 100 percent repair, and more than 99 percent of the testing of these systems and network elements by year-end 1998" [ATT]. These results are very assuring. That both Bell Atlantic and AT&T are in an industry with fierce customer competition and high turnover rates provides them incentive to do their best to prevent any problems resulting form Y2K. In addition, the large size of these companies assures that they have, at least, the resources to undertake this effort.
Overall, telephone services is in "pretty good shape" according to Mr. Wilber. He expects that all systems "will be 100% compliant as far as [Dartmouth's] software and hardware." If any problems were to arise, the telephone system, which is self monitoring, would alert either him or another employee and in past, response times have been between five and ten minutes [Wil1]. We must consider though, that these problems have been such that he and his team could handle them. A Y2K related software glitch would not be something he or his team could remedy, especially not quickly.
With respect to testing of its own network, Dartmouth is relying entirely on the vendors, specifically Ericsson. Because the system is theirs, they are best suited to handle any unit testing, and as far as system testing, Mr. Wilber believes it is unnecessary. Avoiding a disruption of service, which such testing would require, during a term when many students utilize the telephone network to contact prospective employers, outweighs the avoidance of problems he believes will not arise. He suggested summer term as a time when such testing might occur, but as of yet, no definite plans exist [Wil1].
The outlook is promising for Dartmouth's own network and reasonably promising for both local and long distance service. We are helped by the fact that, in emergency situations, both local and long distance calls could travel either network. So, as long as one of our outside providers can function come January 1st, we will not have lost contact with the outside world.
Dartmouth's Network is administered by W. Punch Taylor, Director of Technical Services. According to him, the only hardware/software devices that are date sensitive are the network routers. They utilize times and dates to determine the proper ordering or the information they receive. If a router recognized something sent after midnight of December 31st as earlier than something sent before that time, the information would not be passed on in the proper order and so the data would be corrupted. The two brands of routers currently in use at Dartmouth are Cisco and Bay. Both of these companies provide Y2K patches which are scheduled to be installed some time in the near future. Given the limited impact of Y2K on this system and the preparedness of the vendor companies, Mr. Taylor is reasonably certain that we can rely on Dartmouth's network through the year 2000 [Tay1].
The data network faces a problem similar to the voice network in that is must rely on outside compliance for full functionality. Specifically, if Dartmouth's ISP (Internet Service Provider) can not function, though our internal network may be fine, we would have no external Internet connection. Dartmouth's ISP is Frontier/Global Center. We recently switched to this company in an effort with the University of New Hampshire to provide high speed Internet access at a reduced cost. This, as well as telephone service, is an industry with a high customer turnover rate and so hopefully, this will be incentive enough to assure their compliance [Tay1].
This area was one about which FO&M was understandably tight lipped. Hundreds of thousands of dollars would be at risk if these systems do not function. Because of this, FO&M is likely to have given special consideration to securing these systems.
The central security computers are made by Honeywell. Though the current system is not yet compliant, upgrades are ready and scheduled to be installed in spring of this year.
Regarding individual, specialized security systems such as those in the Hood and Sudikoff (Card Access), both are said to be complaint. Though we have little information, the general importance of all security systems virtually assures the majority will be made complaint.
Overall, in term of infrastructure, Dartmouth seems well prepared. We can be almost certain that we will have power and heat, a working security system, and water and a functioning sewer system. This is something many can not say. With respect to outside communications such as telephone and Internet we can feel no more secure than the average individual, as the compliance of these systems is in the hands of outside vendors. Most probably, large corporations such as these, which constitute the backbone of our country's economy, will be well prepared to deal with the new year. And so, the outlook overall for Dartmouth's infrastructure is promising.
The late John Sloan Dickey's famous welcome to incoming students, "your business here is learning," is just as true at Dartmouth in 1999 as it was half a century ago. Dartmouth's business is learning, and to that end its academic functions are the heart of the College: its administration and infrastructure exist only to further its academic functions.
While Dartmouth computing covers many academic functions, clearly the main academic impact of Y2K at Dartmouth is on research. In fiscal 1998 Dartmouth received $79 million in research grants [Ves2]. With that kind of money at stake, research-related issues dwarf the Y2K issues in many other aspects of academic computing. As a result, Section 4.1 deals primarily with research issues, the efforts of Research Computing, and a few case studies. In Section 4.2, we then offer a brief treatment of non-research computing (including Dartmouth's status as a Macintosh-based campus), a look at public machines in the Department of Computer Science, and assorted other topics, such as the "smart" classrooms and the Dartmouth Cable TV Network. Finally, we overview in Section 4.3 the effect of Y2K on Dartmouth's three professional schools.
One of the chief ways that Y2K can affect colleges and universities is in the area of research. A Y2K-related failure of a research system might mean a harmless nuisance for researchers or the contamination of six months of data. For instance, even if prior data is backed up, experiments which rely on data acquired at fixed intervals will be ruined if no data is acquired for some period around the clock rollover. Just as foreboding as the fear of lost data is the threat of losing grants from the government and other organizations, which are the chief source of funding for most research conducted at Dartmouth.
External funding sources have made it quite clear that they delegate Y2K-related responsibility to the individual researchers and respective institutions. For example, in June 1997 the National Science Foundation issued Important Notice (IN) No. 120 to "Presidents of Universities and Colleges and Heads of other NSF Grantee Organizations to remind NSF awardees of their responsibilities under NSF grants and cooperative agreements" [KM]. The notice has two major points:
2.NSF should be notified as soon as possible if a recipient concludes that the Year 2000 problem is likely to have a significant impact on its ability to carry out a funded activity. [NSF]
The National Institutes of Health issued a similar notice of responsibility in April 1998:
The notice also applies a project-relative deadline for compliance of all NIH-funded programming projects. "If an application deals with dates, that application must be Year 2000 compliant before the first use of dates beyond December 31, 1999" [NIH]. Furthermore, NIH imposed a deadline for notifying NIH of foreseen Y2K problems. "The National Institutes of Health should be notified by September 1998 if an awardee concludes that the Year 2000 will have significant impact on its ability to carry out an NIH-funded activity" [NIH].
While there was no explicit mention in either notice of penalties imposed on researchers whose work is not considered compliant, it is evident that current and future funding would be at risk. A researcher who discovers in late 1999 that her research equipment needs to be replaced may receive little sympathy from the NIH, since the NIH requested notification by Fall 1998. These agencies and many others have adapted such measures to help educate and motivate grant-holders, and the impact of these policies is felt strongly at Dartmouth. Were a current project ruined by a Y2K-related failure, it seems unlikely that such agencies as the NSF and NIH would fund the project a second time. Of course Dartmouth researchers want their projects to run smoothly regardless, but the threat of losing funding is taken seriously. Moreover, the impact of such funding goes beyond the work of any particular researchers. Under Dartmouth's current funding formula, a researcher needing $100,000 would actually request around $161,000, the $61,000 going to the institution to cover the indirect costs shouldered by the institution [Bot]. Thus a loss of research grants would hurt the College financially as well. Beyond the funding issues, the hard-earned reputations of individual researchers and Dartmouth as a whole could be also affected, perhaps even influencing the decisions of perspective students and faculty.
Dartmouth's effort to educate researchers and potentially assist in correcting non-compliant research systems is spearheaded by Research Computing, a group within Academic Computing headed by Associate Director of Computing Gurcharan Khanna. Research Computing has a role in much--but nowhere near all--of the computer system-based research projects at Dartmouth:
The Research Computing group supports and develops computing applications and information resources with primary focus on support of research. Its efforts focus on computing applications that employ UNIX systems or other server architectures in order to achieve high performance, support distributed computing efforts, or to run specialized applications. [DCAC]
Because of this role, and because research funding is considered such a major Y2K issue, Research Computing is and will be one of the most important players in achieving Y2K compliance for research-related technology. The group itself will not have a problem achieving compliance because its central research machines have been replaced or added to over the years [LKh], though in some case patches will need to be installed before January [DCStat]. Instead, their problem has become dealing with the unknown number of computers, sprinkled around campus in offices and laboratories, which perform research functions. Because departments buy whatever they want without contacting Research Computing, decentralized systems are not kept track of in any one location. Finding machines and identifying those responsible for them is a real problem.
Research Computing is not designed to support all research at Dartmouth; as a result, Mr. Khanna and his colleagues simply do not have the resources to find every researcher and project, let alone analyze their systems for Y2K problems. Instead, the strategy has been one of education and cooperation with individual faculty members. The hope is that these researchers will self-identify Y2K issues or at least come forward for help if they are not able to make that determination. In recent months Research Computing worked with Dartmouth's Office of Grants & Contracts to develop a list of researchers, or "principal investigators," and research account holders. A mass e-mail was then sent to approximately 1000 people, including approximately 250 faculty receiving government funds and around 800 users of the research systems. The letter included a summary of the problem as it might affect research, as well as pointers to the Dartmouth Y2K web site, the new blitz bulletins, and Research Computing contacts. So far there have only been a few responses to the e-mail, and no confirmed Y2K problems have been brought forward from that process as of yet. While Research Computing realizes they have not caught everyone, they expect to do more mailings, expand their contact list, and potentially make other lists as more information come forward. They will provide those who ask for help with advice and tools to find and fix problems. [LKh]
Another complicating issue affecting research labs more so than other areas of Dartmouth computing is that in many cases, graduate students developed the software independently for particular faculty projects. In some cases, non-compliant code can be partially blamed on the fact that many of these grad students were not qualified as software engineers; in other cases, students were simply trying to finish their assignments on time and did not think the code would be used for this long [Bar]. Now those students have graduated and moved on, and the faculty researcher left with the system may have no idea where to find or how to fix the original source code.
The following case studies are examples of some of the researchers with whom we spoke.
The Y2K bugs affecting Dartmouth research are not always straightforward cases of upgrading operating systems. In some cases, the problems have to do not only with technological issues, but also with geography. Associate Professor James LaBelle of the Physics Department has been using ground-based radio receiving equipment to investigate Auroral Radio Emissions since 1992 [DCPhys]. His research equipment includes some older DOS-based machines that are known to be Y2K noncompliant [LKh]. Since Professor LaBelle's equipment is located in such locations as Alaska, Greenland, and Antarctica, even the installation of several software patches and upgrades, which might not be considered much of a hassle for equipment located on campus, could become quite a nuisance.
Fortunately for Professor's LaBelle's research, the need for precise timing mechanisms in recording data required that supplementary clock cards be installed in the field machines long ago; the machines now keep time better than a normal computer's clock. As a by-product, it appears the clock cards solve the Y2K problem for those machines; there are likely only a few machines that could be vulnerable, and Professor LaBelle has not yet looked at those machines [Lab].
Perhaps quite surprisingly to many non-computer science students, the Sudikoff building has only a few research laboratories, despite the $1.3 million in research funding it received in 1998 [Ves2]. One laboratory in the computer science department which has a considerable amount of hardware is the Dartmouth Robotics Lab, directed by Assistant Professor Daniela Rus. Though she has admittedly not thought much about Y2K since none of her research is time-sensitive, Professor Rus believes that the existing infrastructure will take care of her lab; much of her equipment uses configurations identical to that of the Department of Computer Science or the Department of Engineering, which she believes will be fine. Much of her remaining equipment is under maintenance contract, and even the oldest computers are only 3-4 years old, so she feels the lab is in good shape. No research will likely be going on in the Robotics lab in late December regardless of Y2K. Moreover, she believes that there will not be a substantial Y2K impact on Dartmouth and that the manner in which researchers are reacting to Y2K has a lot to do with their personalities, whether a given researcher is more laid-back or more worrisome. Professor Rus cannot recall being contacted by anyone regarding Y2K, despite being a principal investigator under grants from NSF and several other funding sources. [Rus]
Several other lab-based researchers we contacted felt that Y2K did not affect them much, usually because they relied on Macintosh computers for much of their work. (See discussion of Macintosh issues in Section 4.2.1.) But what will researchers do in the event that something does go wrong? Of course, many research projects have data backups and other contingency planning already in place. But in general, more detailed contingency planning for Y2K would be a good idea for most researchers, since the normal support chain may not be there for them in the event of a large-scale Y2K problem (for instance, a prolonged power outage or loss of phone lines). Minimally, it is expected that researchers will make a full backup before going home for the weekend of January 1, 2000. [Kea]. Further provisions for more delicate experiments, such as those involving temperature control, will likely be formulated. For example, FO&M will be talking to leaders of delicate projects, such as those in the Thayer School and the Medical School, regarding minimal temperature levels in relevant labs [Kea]. (See Section 4.3.3 for a discussion of Thayer's safety-related planning.) Other contingency plans will be developed as needed by individual researchers.
The impact of Y2K on Dartmouth's non-research, academic computer systems is much smaller than that of many colleges and businesses of similar size. The far majority of Dartmouth students and faculty use Macintoshes and UNIX machines, which are generally prepared for Y2K. Though the number of Windows computers on campus is growing, most are recent purchases that should be Y2K compliant after patches and upgrades. Thus the far majority of personal computers and their users will not be affected at all; instead, the challenge is to identify users and machines that are not Y2K compliant and will require assistance [Kea].
While the Help Desk in Kiewit offers Dartmouth students and faculty assistance with computing tools and resources, it is not considered a primary resource for Y2K education or assistance. Help desk consultants point users with questions to the Dartmouth Y2K web site, while in-depth inquiries are redirected to Gurcharan Khanna or Bill Barry, depending on whether the question relates more to academic or administrative computing [Bro]. Questions about desktop computers and operating systems are referred to vendor statements, including the Y2K pages for Apple and Microsoft [Bro].
Macintosh computers in general do not have a Y2K problem; Apple hardware and software does not rely on the use of two-digit date comparisons, so the machines and their operating systems should be fine. In that way, public Macintoshes are considered completely Y2K safe. On the other hand, improper use of Macintosh software could still lead to a Y2K issue. A researcher who has been typing two-digit dates into Excel or Filemaker will not be compliant without somehow correcting those dates. If non-compliant data from before the rollover will not be used in conjunction with post-Y2K data, then there may be no reason to make such data compliant.
In general, few Macintosh users will have Y2K problems. Since it is still a considerably Mac-based campus, Dartmouth's student and faculty computing is much better off than many institutions which might need to replace DOS-based machines distributed around the campus. Though institutions such as Dartmouth generally replace machines fairly rapidly, the fact that so much of the campus is Mac-based basically prevents even the need for an assessment of Y2K for a good deal of the Dartmouth population.
To the layperson, the Department of Computer Science, so dependent on computing, might seem to be a part of Dartmouth particularly susceptible to Y2K. Of particular interest to students are the public Sudikoff labs made available to students 24 hours a day, as well as the public server Tahoe. These public student machines are currently running either DIGITAL UNIX or SGI's IRIX. An e-mail from Wayne Cripps, the department's Systems Manager for UNIX, made it clear how he sees Y2K's impact on the Department's machines:
I could answer your question quite simply. I am doing nothing. I don't have mainframes with old accounting software, I don't have old pc's with bios hardware problems. The unix clock doesn't run out for 30 more years. Some of my computers will simply get turned off and discarded if they don't make it into the last year of the millennium. [Cri]
Mr. Cripps' feelings seem indicative of the pervasive public attitude about UNIX, that the operating system is inherently compliant. Due to conflicting reports from different sources however, we decided to research specific flavors of UNIX further, leading to some interesting findings.
A quick survey of the public machines in Sudikoff 001, the SGI Indy lab, showed that as of early March 1999, seven were running IRIX 5.3 and eight were running IRIX 6.5. SGI's Y2K disclosure site explains that version 6.5 is "is Y2K compliant and is the recommended solution for Year 2000 compliance. . . . All Silicon Graphics applications within IRIX 6.5 are Year 2000 compliant" [SGI]. While some obscure Y2K errors exist in prior releases, "[m]ost customers would not encounter any of these errors in the course of their normal operations" [SGI]. Though SGI recommends all users upgrade to 6.5, SGI has issued free Y2K patches for IRIX 5.3, 6.2, 6.3, and 6.4. Versions prior to IRIX 5.3 will not be supported (or rigorously tested for Year 2000 compliance) in the year 2000, and "IRIX 4.0.5 is known to have significant Year 2000 bugs and should not be used after the end of 1999" [SGI]. At any rate, the machines in 001 are running newer operating systems which are compliant now or will be compliant upon the installation of the 5.3 patch (if it has not been installed already).
A similar survey of the UNIX machines in Sudikoff 005 revealed that seven of the machines were running Digital UNIX 4.0B, the same version running on Tahoe. Further investigation of DIGITAL UNIX revealed that the last two major releases, 4.0B and 4.0D, both require a patch. While Compaq's Y2K disclosure site specifically says, "Version 4.0D is warranted to be Year 2000 ready" [DECUNIX], its disclaimer for Version 4.0B is not as reassuring:
The disclaimer statement goes on to urge an upgrade. "You should plan to upgrade to Version 4.0D or a later release in sufficient time to test your environment and to make necessary changes prior to the start of the year 2000" [DECUNIX]. It is unclear which of these functions would affect Dartmouth and its users, but according to the Compaq disclaimer, half of Sudikoff's student machines and Tahoe are not supported for Y2K by Compaq.
Clearly the Department of Computer Science will be compliant by January 2000; Mr. Cripps will make sure of that. But the Y2K disclaimer for Digital UNIX 4.0B by Compaq is an interesting example of a larger trend. Compaq makes no warranty as to its 2000 compliance, but is 4.0B completely adequate for the Department's needs? Or is Mr. Cripps planning to upgrade these systems before January for non-Y2K reasons? (Mr. Cripps had not yet responded to such follow-up questions at the time of this paper's completion.) Regardless of how this situation works out for the Department of Computer Science, the fact that different flavors of UNIX have varying degrees of Y2K compliance and warranties is and will continue to be a point of confusion for UNIX users and researchers. The simple answer that "nothing" needs to be done seems to be an oversimplification of the issue.
Instructional Services, headed by Director Michael Beahan is the part of Computing Services which offers audiovisual and media-resources support to the Dartmouth community [DCIN]. Specifically, Mr. Beahan and his staff manage such distributed academic resources as SMART classrooms and the Dartmouth Cable TV. Mr. Beahan recognizes a number of areas which should be checked by his staff of engineers before January. One example of interest is the system for steering five of Dartmouth's six satellite disks; the receivers controlling them are three to five years old and might not be compliant. Were those to fail, Dartmouth would lose such services as its Foreign Language programming. Because Instructional Services has just completed substantial efforts to provide cable access in the dorms, Mr. Beahan expects he and his staff will now have more time to investigate the current equipment's Y2K status, possibly during spring term 1999. [Bea]
In the area of classroom support, many of the computer-supplied classrooms have recently been upgraded to G3's, so it is unlikely that many computer systems will have to be replaced for Y2K. Instructional Services does support some Windows machines, so there will be investigation in that area as well. The classroom-control systems--which allow one-stop access to VCR, computer, lights, etc.--are fairly new, and Mr. Beahan does not expect a problem with those systems, though they will be checked. Nonetheless, it would be embarrassing for the lights not to work in such "smart" classrooms at the beginning of winter term. These are not critical systems, and it seems unlikely that any Y2K-related incident would lead to anything more than a nuisance, especially since classes begin several days after the rollover.
Dartmouth's three professional schools-- the Amos Tuck School of Business Administration, the Dartmouth Medical School, and the Thayer School of Engineering--have some properties which make their Y2K problem different than that of the undergraduate college. Because the schools are considerably smaller than the rest of the campus, it is perhaps easier for their respective administrators to get their hands around the problem [Kea]. In the following subsections, we discuss issues particular to the respective professional schools, focusing on material which does no overlap with discussions of the rest of the College.
An interview with Tuck's Director of Information Technology Stanley Pyc instantly revealed that Tuck computing is entirely unique when compared to other areas of the College. At first glance its most noticeable distinction is its heavy reliance on Windows computing; while its administration staff uses Macintoshes, approximately 70% of its faculty currently use Windows-based PC's. Unlike some areas of the College, however, Tuck keeps even its student computing on a rapid upgrade schedule. There are currently 600-700 computers in use by Tuck's 360 students and 35 faculty. Maintaining this number of computers would be daunting without Tuck's automated system; three to four times each year, upgrades are performed remotely on all machines [Pyc]. As a result, it is not expected that upgrading the Windows 95 and 98 machines will be a problem, even if Y2K patches and upgrades were to come out late in the year.
Though Tuck is well-known for leading-edge financial research, Tuck received only $350,000 in grant money in fiscal 1998 [Ves2], a small number compared to many Dartmouth departments. Since less funding is at stake and most research is based less on data acquisition (in which a missed time interval could adversely affect results) than manipulation and post-processing of financial databases [Pyc], the impact of Y2K on Tuck research could be extremely small. Even if researchers have been entering information into Excel spreadsheets or Filemaker databases which are not compliant, there may not be a need to fix the information if it will be used exclusively on one side of the millennium.
Overall, Tuck's small size coupled with its comprehensive IT organization seem to make Tuck less vulnerable to Y2K problems than much of the College.
The Medical School has been working closely with Terry Keane, FO&M, and Research Computing for some time regarding its Y2K compliance. From the College's standpoint, DMS has a high amount of Y2K risk associated with it, specifically because it relies so heavily on outside funding [Kea]. Though in many cases DMS systems are not required to use the same vendors as the rest of the College, the School's own facilities administrators tend to choose vendors dealing with the rest of the College, [Kha], a trend that has made Y2K investigative efforts easier as well. The main Y2K issue for the Medical School is research compliance; DMS alone received $58 million in research funding during fiscal 1998 [Ves2].
In an interview with Rehan Khan and David Harris of the Medical School staff, Mr. Khan estimated that he and his colleagues have been discussing Y2K seriously since Fall 1998. DMS faces many of the same administrative and facilities issues as the rest of the College; for example, the DMS phone system was upgraded for Y2K reasons. In general, Mr. Khan's group, which supports DMS in administration beyond the normal undergraduate systems, is currently in a process of checking, modifying, and testing internally-developed code. Mr. Khan says his staff is concentrating on making sure old code is compliant rather than carrying out its normal development, but the group should have everything ready well before the rollover at little expense. [Kha]
Many research labs in DMS contain similar equipment; as a result, there has been a concerted effort to share resources and knowledge in documenting systems as Y2K ready. Mr. Harris also explained that academic institutions like Dartmouth are much more able to share information and be open about their current status than private companies. One resource of which DMS plans to take advantage is a Y2K-compliance compilation of medical-equipment vendors. Put together by the Howard Hughes Foundation and distributed to Dartmouth through the Association of American Medical Colleges, the compilation has charts of vendors listed alphabetically with classifications for each of its products as compliant, non-compliant, or requiring upgrade. The book also includes vendor letters of compliance or non-compliance, effectively removing a substantial part of the legwork involved in contacting each vendor individually. Mr. Khan and Mr. Harris plan on posting this information to a web site soon, along with any other compliance information not found in the Hughes resource but relevant to DMS researchers. [Kha]
One interesting strategy explained to us by Mr. Khan and Mr. Harris was one indirect way that the DMS hierarchy has tried to contact its researchers. While they hope researchers will read their e-mail, they realize some may fall through the cracks. To that end they spoke to DMS business managers, many of which have a lot to do with inventory and knowing who is responsible for what equipment. In turn, many of these business managers have spoken to lead technicians within individual laboratories. Though a researcher might be thoroughly involved in the research itself, sometimes these lead technicians are more knowledgeable about particular equipment used by a given lab. By making more Y2K contacts down the chain, the chances of a researcher ignoring e-mails and not making Y2K preparations decrease considerably [Kha].
Overall, DMS knows that it has much at stake and appears well-positioned in its efforts to deal with Y2K-related hazards.
The Thayer School is also in a substantially different situation than the rest of Dartmouth's campus. Efforts to mitigate the Y2K bug's effect on Thayer computing are being led by Ted Cooley, Thayer's Director of Computing, who has been reporting to Thayer's Board of Overseers on the problem for some time. Compliance related to research funding is a major priority [Coo1], especially since Thayer received $6.5 million in research grants in fiscal 1998 [Ves2].
There are currently 12 to 15 LINUX machines used primarily for research in Thayer alongside another 30 PC's running Windows 95 or later. Most applications are vendor-specific software packages; for example, the purchase of a scanning electron microscope included the software to run it. Professor Cooley does not consider most of these applications date-dependent. [Coo1]
Thayer also has a good deal of non-research computers. While Thayer has been predominantly Macintosh-based for many years, it has long owned assorted PC's. Today a mix of machines running Macintosh, Windows, UNIX, and Linux operating systems comprises the approximately 330 computers found in Thayer. The number of Intel-based PC's in the building has skyrocketed of late, but because most of the Intel machines are so new, they mainly run Windows 98 or NT and are not considered at high risk for Y2K problems. Nonetheless, the time required to install operating system upgrades and patches has dominated the labor spent so far on the problem [Coo1]. Many of the updates have not been performed exclusively because of Y2K but rather to achieve some other functionality [Coo1], e.g., compatibility with a newly purchased monitor. But unlike usual practice, Professor Cooley and his two staff members are now maintaining records of operating system versions on the individual machines to ensure all are brought up to compliance by January. Since lack of resources is currently the limiting factor, Professor Cooley expects the machines will likely be upgraded during the summer when there are fewer responsibilities [Coo1]. Testing on some machines has already been performed by setting system clocks forward and observing normal use of the machine [Coo1].
While ensuring Y2K preparedness on the newer user machines is a hassle, there are two more significant issues in preparing Thayer for Y2K: 1) older hardware which is not capable of running new Y2K-compliant operating systems; and 2) legacy research software, some of which is written in FORTRAN [Coo1]. While there is no specific timetable for upgrading these systems, most of them are not used for databases or acquisition but rather for analysis and interpretation of results. This problem would not be as damaging because analysis could be redone. While the servers will be kept up and running, it is likely that non-critical machines of specific concern will be shut down over New Years' weekend and dealt with later [Coo1].
Doug Fraser runs the Thayer School's digital instruction lab, which houses several PC's for use in designing circuits. His greatest concern is that his weekly automated tape backups might not occur properly. While he plans on installing the necessary service paks for Y2K compliance, he feels there is not enough of a threat to warrant a lot of testing, since losing the machines now would be just as much a problem as losing their functionality in January. If there is a problem, he would rather deal with it then [Fra].
Assistant Professor Chris Levey runs Thayer's Microengineering Lab and is Thayer's safety contact. He is closely involved with avoiding accidents and catastrophes in both instructional labs and research labs, even though not all labs are officially included in his duties. Such potential dangers as gas release, exposure to X-rays, and potential problems with fume hoods inspired Professor Levey to keep Y2K in mind as he was doing inventory in Fall 1998. Professor Levey's plan is to speak to those researchers and technicians whose labs he thinks might need to be investigated, talking to post-docs and graduate students where appropriate. Professor Levey feels that waiting until 1999 was not a mistake, since it would not have been time effective to contact many of these companies two years ago before they had established substantial Y2K information resources. Furthermore, such equipment will likely not be in use on New Year's Eve and simply closing manual safety valves before heading home would eliminate the potential for even the unlikeliest of disaster scenarios over the millennium rollover. [Levey]
One particularly interesting example of a safety concern in Thayer is the Microengineering Lab itself. The lab features a tightly-controlled--and therefore extraordinarily powerful--temperature and humidity control system. The lab's pump has access to high temperature steam; when the room was first installed, an accident allowed the room to fill with steam. Luckily, the room was empty and no one was hurt. Today the lab is filled with dangerous gas canisters; were the room to fill with steam, the potential exists for dangerous explosions causing many thousands of dollars worth of damage to the facility and possibly even injury. Though such an event is quite unlikely, Professor Levey plans to update his normal contingency planning with FO&M, expanding his instructions on what to do in the case of a loss of power or steam. The potential for some of these problems is further mitigated by Thayer's own emergency generator. [Levey]
While Professor Cooley and other Thayer staff still have a good deal of work to do, they have a good sense of where the work needs to be done and are attacking it as they have time. Beyond that, Professor Cooley has been approached for help by some other personnel and has endeavored to be a resource for those with issues similar to his own [Coo1].
Due to the decentralized nature of research, it will be extraordinarily difficult to put a price tag on preparing Dartmouth research for Y2K. In many labs which will require Y2K remediation, Y2K-related upgrades will fall on technicians and graduate students who will simply shoulder the extra load; the College will likely not be able to estimate the loss of productivity of these efforts. While Dartmouth does have a substantial amount of research, outside funding is less important to Dartmouth than to many of its research university competitors. In this case, it pays to be primarily a liberal arts college.
There are numerous divisions of the College that deal with issues pertaining to administrative functions. The only centralized department responsible for administrative systems is Administrative Computing, directed by William Barry. This department controls systems such as the Human Resources system, the Facilities, Operations and Management work order system, and the Accounts Receivable system. Although other groups--Information Systems and Technical Services--are responsible for multiple systems or projects, none of them are as far-reaching or as important as Administrative Computing. In addition, some other groups, including Telephone Services, maintain their own systems. In this section we take a look at how Y2K has affected these groups and the administrative systems they maintain (Figure 1).
Figure 1: Profile of
Major Institutional Administrative Information Systems
[BarProf]
(as of February 18, 1998 except Non-student Accts
Receivable)
|
System |
Vendor |
Used Since |
Software |
Prognosis |
|
General Ledger |
Info Assoc. |
early 1980s |
COBOL & Oracle |
replaced in 2-4 years |
|
Budget Management |
in-house |
late 1980s |
Excel |
replaced soon |
|
Purchasing |
Oracle |
1993 |
Oracle |
may be replaced in 2-4 years |
|
Accounts Payable |
Oracle |
1993 |
Oracle |
may be replaced in 2-4 years |
|
Student Accounts Receivable |
Info Assoc. |
late 1980s |
COBOL |
replaced soon |
|
Non-Student Accounts Receivable |
Info Assoc. |
late 1980s |
COBOL |
modified; replaced within 2 years* |
|
Human Resources |
SCT |
mid 1980s |
COBOL |
replaced in 2-4 years |
|
Endowment Accounting |
in-house |
1992 |
Oracle |
continued use |
|
Student Information System |
SCT |
1997 |
Oracle |
implementation still in progress |
|
Library Card Catalog |
in-house |
1990 |
C++ & BRS Database |
continued use |
|
Campus Card |
Griffin |
1983 |
C++ |
continued use |
|
FO&M Work Order |
Prism |
1997 |
Oracle |
expanded use |
|
Student Telephone Billing |
Bitek |
late 1980s |
n/a |
continued use |
According to Mr. Barry, Administrative Computing has been thinking about the Y2K problem since as early as 1991. In 1993, Mr. Barry published an article in a computer services newsletter on the potential impact of this issue on computing in the academic environment. Since then, Administrative Computing has tried to take Y2K into consideration when upgrading all its systems. As a result of this approach, it has, for the most part, managed to avoid upgrading its systems only for Y2K reasons. [Bar]
In part, this early start was mandated by the way Dartmouth keeps track of the class year of its students [Bar]. Instead of classifying students by relative year (freshman, sophomore, junior, senior), the tradition is to keep track of them by their expected date of graduation. Thus, the systems needed to be ready to correctly store "00" four years before the new millennium. The correction of this problem on systems that were developed in-house took only a few person-weeks to complete [Bar], however, fixes to systems purchased from third-party vendors were not as simple and some are discussed below.
Recently, Administrative Computing has been in contact with the consulting firm PricewaterhouseCoopers (PWC) regarding Y2K issues. PWC's recommendation is for all systems to be tested fully so that all potential problems can be ascertained. However, Mr. Barry has chosen not to take this course of action because the tests would take a long time and occupy a large portion of the department's resources. He feels that the benefits of this course of action would not be worth the costs because the vendors themselves are performing similar and more comprehensive tests. He believes that his systems will be fine for the most part, and that the consultants have raised unnecessary fear amongst the Trustee Audit Subcommittee members. [Bar]
The Human Resources (HR) system is a vendor system supported by Systems Computer Technology Corporation (SCT) and has been in use since the middle 1980s [BarProf]. This system is in constant use by the College's administration to maintain personnel information of employees and keep track of payroll information. According to Mr. Barry, fixing this system is a high priority because missing a payroll could lead to a public relations "disaster" [Bar]. To assure compliance, Administrative Computing has been in contact with SCT for a number of years. For several of these years, SCT claimed that compliance would be reached in version 4.0 (the currently installed version), but recently they reneged on their past assurance and promised compliance in version 4.1. Since a full upgrade from 4.0 to 4.1 would take approximately 1.5 man-years, Administrative Computing put pressure on SCT to fulfill their initial promise of compliance in version 4.0. As a result of this effort and pressure exerted by other clients, SCT promised to release a set of patches to version 4.0 to make it Y2K compliant. Installation of these patches is expected by May or June of this year, in time for the new fiscal year beginning in July. [Bar]
Since SCT has over 3000 employees [SCT], it is one of the larger vendors with which Administrative Computing does business [Bar]. Mr. Barry described the approach taken with SCT's system as typical of the way in which Administrative Computing deals with systems from large vendors [Bar]. The vendor is contacted in an attempt to assure compliance, and in most cases, the vendor claims their product is compliant or will be compliant by a future date. In these kinds of situations, there is not much that Administrative Computing can do to assure that the vendor is or will be true to its word. The system can be tested, but, because many of these systems are large and complex, testing would take a significant amount of time and resources. Instead, Administrative Computing counts on the vendors to perform full tests on their systems because they have more resources available [Bar]. Also, any non-compliance discovered through tests would have to be fixed by the vendors themselves. In the end Administrative Computing has to rely on the vendors to worry enough about their reputation to make their products compliant [Bar].
The Facilities, Operations and Management (FO&M) work order system (known as FAMIS) has been in place since 1997 and is supported by Prism, Inc. [BarProf]. This system is used to keep track of the services provided by FO&M. Although it is not as essential to running the College as the HR system, it is important to scheduling FO&M's day-to-day functions. According to Prism's Y2K statement, the current version of FAMIS is not fully compliant but the next version will be [Prism]. Administrative Computing plans to have this upgrade installed by April 1999 [Bar].
Unlike SCT, Prism is not a large company, and Mr. Barry expressed some worry that the upgraded system will not be fully compliant. Thus, he intends to assign some of Administrative Computing's in-house programmers to test the system after installation of the upgrade. Mr. Barry thinks that Prism's small size makes it less able to properly remediate Y2K problems. Despite this apparent pessimism, he believes the potential problems to be less serious because newer systems like FAMIS are more likely to have special fields for dates than are older systems written in COBOL (like the HR system). [Bar]
The Non-Student Accounts Receivable System has been in use since the late 1980s [BarProf] for processing and organizing payments to the College from non-student sources. Although it was provided by Software Information Systems (SIS) [BarProf] the system was so heavily modified to customize for the Dartmouth Plan that SIS can no longer be counted on for support [Bar]. Since the SIS system was not Y2K compliant, Administrative Computing decided to move to a new system, however, when the Bursar's Office evaluated it, it found the system to be inadequate [Bar]. Since the old system was no longer supported by SIS, an upgrade could not be obtained without a large amount of re-customization [Bar]. Thus, the Administrative Computing was faced with three options: (1) use the new system until a better one was found, (2) find another system before the new millennium, or (3) modify the old system to make it compliant [Bar]. Since there was not enough time left to find another system and since Administrative Services already had in-house staff trained in COBOL (the language used to build the SIS system), modification of the existing system was chosen as the most appropriate alternative [Bar].
The main modification performed was the addition of modules to
filter dates being sent into and out of the system. This filtering
was accomplished using two common Y2K remediation techniques: time
shifting (e.g. adding 28 before input and subtracting 28 upon output)
and windowing (e.g. interpreting two-digit dates from 00 to 30 to
belong to the 20th century and 31 to 99 to belong to the 21st
century). The modified system is expected to be used for no longer
than 18 months before a new, better system is found to replace it.
[Bar]
Another department of Dartmouth Computing affected by Y2K is Information Systems. The main responsibilities of this department are maintenance of systems related to library and information resources. According to Robert Brentrup, Director of Information Systems, the department has been preparing for Y2K for the past 18 months [Bre1]. Although some upgrades have been performed on Information Systems' systems, Mr. Brentrup believes that these would have been done independently of Y2K [Bre1].
By far the most important system which Information Systems is responsible for is the INNOPAC system, purchased from Innovative Interfaces, Inc.(III) [Bre1]. This system controls almost all aspects of operation of Dartmouth's library including acquisitions, cataloging, circulation control, and serial control [Bre2]. Since problems with this system can cause major havoc with all aspects of the library, it is a high priority for assuring Y2K compliance [Bre1]. According to III's Y2K statement on their web site, the most recent version of INNOPAC is fully compliant as long as it is being run on a compliant operating system (OS) [IIIY2K]. Both the vendor system and OS upgrades are scheduled to be completed by March 1999 [Bre1].
Another important information resource run by Information Systems jointly with the library is the Dartmouth College Information System (DCIS). This system was built in-house starting in 1990 "to provide information access to the entire spectrum of campus users" [DCIS]. The system allows users to obtain a variety of information ranging from student telephone numbers and addresses to texts of famous literature. Since DCIS was developed in-house and already stores information about books published in previous centuries, Y2K compliance is not expected to be a significant problem [Bre1].
The OVID database of periodicals is yet another system run by Information Systems. This system is provided by OVID Technologies, Inc. and allows researchers from the College to access the abstracts and full texts of periodicals from a variety of databases including MedLine, BIOSIS, CINAHL, and HealthSTAR [OVID]. Although this system is not yet compliant, the vendor has released a new version which is fully compliant on a compliant OS [OVID]. Information Systems plans to complete these upgrades in the near future, but it is not particularly worried about Y2K problems with this system [Bre1]. Though researchers may miss the convenience it provides, it is not a critical system. One interesting issue to consider is that, although OVID claims the system will be fully compliant, the system outputs dates differently in the new version; thus, scripts run on data from the OVID database may require modification [OVID].
The department of Technical Services, directed by William Taylor, is responsible for a variety of systems and services that are used by both Administrative and Academic Computing. This most important of these are the network infrastructure mentioned above, campus-wide applications like BlitzMail and Fetch, and the machine room located in Kiewit Computation Center.
BlitzMail is the proprietary e-mail system used by the vast majority of the Dartmouth campus since 1988 [DCBli]. Until recently, the widely-used version of BlitzMail was not Y2K compliant [Tay1]. Specifically, there existed a cosmetic bug in the date sorting routines that would have caused dates in 2000 to be sorted incorrectly relative to dates in 1999 [Tay1]. Since BlitzMail was developed completely at Dartmouth, fixing this bug was a minor issue and was performed in version 2.5.3, released in March 1999 [Mat, Tay1].
Because the BlitzMail client was until recently a Macintosh-only application, OS compliance is not a serious concern. The Windows client released recently was developed at the Dartmouth Hitchcock Medical Center; although Mr. Taylor is not aware that it is being maintained or Y2K compliant, version 2.5.3 was released soon after the Macintosh version. In addition, both the operating system used to run the server software and the server software itself are already fully compliant. [Tay1]
Fetch, another Macintosh application developed at Dartmouth, provides a user-friendly interface to the File Transfer Protocol (FTP). In 1997, Technical Services asserted that Fetch was fully Y2K compliant [DCFet]. Since then, some groups outside of Dartmouth licensing the software have asked for legally binding Y2K certification [Tay1]. In their response, the developers of Fetch said that Fetch was fully compliant, they refused to provide any legally-binding documents [Tay1]. In addition, Technology Services provides the following disclaimer: "Dartmouth College provides Fetch 3.0 'AS IS', without any warranty or promise of technical support, and disclaims any liability of any kind for any damages whatsoever resulting from use of Fetch" [DCFetLis]. Interestingly enough, this is similar to the way in which many vendors have dealt with Dartmouth's requests for legally binding certification.
The Kiewit print queue manages the print jobs sent to the Kiewit public printers so that they are printed in the proper order. Although, Technology Services has identified a Y2K bug in the print queue software, there are no plans to fix it. The bug is such that when the date rolls over from 1999 to 2000, the ordering of the jobs in the queue will get scrambled. Thus, print job sent before midnight may be printed after a job sent after midnight. Not only is this a non-critical system whose failure would only inconvenience students and faculty (especially at midnight and in-between academic terms), but the problem will disappear once all the jobs from 1999 are printed. [Tay1]
The machine room in Kiewit houses many of the computers that run the systems maintained by Administrative Computing as well as numerous other important administrative systems. The computers in this room are of all kinds including Macintoshes, DEC stations running VMS, and UNIX machines running Digital UNIX, AIX, and other UNIX variants. According to Mr. Taylor, not all platforms in this room are Y2K compliant but for nearly all of them, upgrades or patches are available or expected to be released in the near future. [Tay1]
Of particular note are two systems which will not survive the millennium. Coos, the general purpose machine providing access for over 2000 users to a variety of services, is running Digital ULTRIX [DCUNIX]. Although Digital is offering patches to make Ultrix Y2K compliant [DECULT], it is an outdated system and thus Coos will be replaced before 2000 [Tay1]. Dartmouth College Time Sharing 1 (D1) is another system which will not outlive the millennium [Tay1]. D1 was developed at Dartmouth as a mainframe OS to enable the running of multiple jobs at once and was scheduled to be eliminated in 1996 [DCD1] but somehow survived until now. The few administrative applications still running on it are not mission critical and will be ported by Technical Services to UNIX or VMS [Tay1].
Telephone Services maintains their systems separately from the administrative systems mentioned above. In addition, Charles Wilber, the Telephone System Manager, has not been in contact with the Y2K committee headed by Larry Levine and Terry Keane. However, he has been leading his own Y2K efforts for the past two to three years and, amongst other efforts, has "participated in a number of discussion groups and mailing lists that deal with the issue." [Wil2]
According to Wilber, the phone billing system is even "more of a concern" than the potential phone line problems discussed above in the infrastructure section [Wil1]. This system was purchased from Bitek, Inc., and has been in use since the late 1980s [BarProf]. It is used "exclusively for call accounting and staff and student billing" [Wil2]. In 1997, Telephone Services contacted Bitek regarding Y2K compliance and were told that no problems were expected [Wil1]. However, one year later when a written guarantee was requested, Bitek responded that several issues still needed to be addressed [Wil1]. These issues were that the UNIX and LINUX platforms running the system needed to be upgraded and that a custom software upgrade was required [Wil1]. With these upgrades, Wilber commented that "[t]he worst that can happen is that you'd...get free calls for a while" [Wil1].
Many of Dartmouth's peer institutions have had to deal with much more serious Y2K issues with administrative systems than Dartmouth's. Princeton University, for example, has had costly problems because of short-term thinking and poor planning. The University has identified that not only are 18 applications on their mainframe noncompliant, but the mainframe itself is noncompliant due to changes made to it [PU]. Princeton has decided to replace the mainframe, but the noncompliant mainframe applications "will not be able to be replaced before the problems occur" [PU]. So not only is this an expensive process, but a serious loss of functionality is expected [PU]. The estimate to directly fix Y2K problems is $5 million while the estimate to replace the mainframe and other costs associated with Y2K is closer to $50 million [BU]. Other universities are spending even more than this to completely replace all their systems, as much as $100 million, in the case of Stanford University (Figure 2) [BU].
Figure 2: Peer Institution Spending on Y2K [BU]
|
University |
Spending |
|
Brown University |
$4 million |
|
Cornell University |
$80 million |
|
Harvard University |
$50 million |
|
Princeton University |
$50 million |
|
Stanford University |
$100 million |
As a result of their proactive approach, Administrative Computing and the other groups have been able to avoid purchasing extra products, upgrades, or consulting services. Thus, they have remained within their previous budgets and the dollar figure attached to Y2K in administrative systems is effectively zero. However, resources have been spent in a variety of ways as part of Y2K remediation. A significant amount of time has been spent on upgrading the vendor systems for Y2K compliance and fixing Y2K-related bugs within in-house systems. Although the majority of the systems have not been tested, a lot of employee time and resources have been spent analyzing the extent of the problem and deciding on the appropriate remediation methods. So, although technically no money has been spent fixing Y2K problems of administrative systems, there is an actual but indeterminable cost attributable to Y2K. [Bar, Bre1, Wil1, Tay1]
According to Mr. Levine, there are no critical bugs of which Computing Services is aware [LKh], however, the different groups are, for the most part, dependent on vendors to make their systems compliant. Although some of the systems are maintained by in-house developers, most systems are provided by vendors which, because Dartmouth has done basically no testing, must be trusted to be both truthful and accurate as to the compliance of their systems. If any of these vendor systems fails in 2000, Administrative Computing and the other groups cannot do much else than wait for the vendor to release patches. For almost all administrative systems, vital information is backed up anyway so resurrection after system crashes is possible. However, this strategy is useless in the case of extended computer logic, electric grid, or network failures. In some cases, such as the Financial Aid Office and Registrar functions, records are kept on paper, so all is not lost in this kind of drastic computer failure. One interesting contingency plan that Mr. Barry mentioned was to have a New Year's eve staff party at the workplace on the night of December 31, 1999 so that the staff would be on hand should problems occur. [Bar, Bre1, Tay1]
It is apparent that Dartmouth's approach to dealing with the Y2K problem has been notably different from that of many organizations throughout society. Dartmouth has no Y2K czar, no consultants overseeing its compliance, and no deadlines other than the millennium rollover. The College instead relies on its existing employees and administrative process to deal with Y2K issues. Although some groups within the College have been thinking about Y2K for several years, only recently have they met to coordinate their efforts in a informal group.
In areas in which Dartmouth has less external dependence than other organizations, such as power production and in-house developed software, it can be reasonably sure that any major problems will be remedied before the new millennium. In most other circumstances, however, Dartmouth must rely on the preparedness of outside organizations. In addition, many of the vendors that provide systems used by Dartmouth are only willing to offer their word as assurance. When different groups within the College ask for legal certification of compliance, they have, for the most part, been met with responses full of useless legal jargon or previously unidentified problems. Essentially, these institutions have no desire to suffer legal ramifications for potential noncompliance of their products or services. As Terry Keane put it:
Some of letters we get back aren't very meaningful because everybody's got their lawyers involved. You can only say certain things, they don't want to you to commit to anything. They don't want you to acknowledge that you have a problem, even if you know you have a problem. We have to really think about how much weight to put into those letters you get back from the vendors. [Kea]
Ironically, Dartmouth is in the same situation regarding compliance of one of its software products. Requests of certification for Fetch from other institutions have been categorically rejected.
Because of this large reliance on external factors, it is not easy to make predictions about what will happen at Dartmouth come the year 2000. It is possible that everything on which Dartmouth relies fails completely; it is also possible that everything works perfectly, however, the most likely outcome is that sparse and partial failures will occur. Although Dartmouth has been unable to elicit guarantees of compliance on most systems and services on which it is dependent, the different groups working on the problem have made sure that the situation is in good hands. They have worked to assure that these systems and services are being provided by organizations that have a large stake in ensuring their success.
In conclusion, Dartmouth has been working on Y2K longer than the majority of other institutions affected by the problem, and it seems well poised to survive the coming of the new millennium with minor disruptions.
We would like to thank the following people for taking the time to
meet with us to discuss Y2K issues related to their work: Bill Barry,
Mike Beahan, Bob Brentrup, Ted Cooley, Doug Fraser, Dave Harris,
Terry Keane, Rehan Khan, Gurcharan Khanna, Chris Levey, Larry Levine,
Stan Pyc, Daniela Rus, Punch Taylor, and Charles
Wilber. In addition, we would like to thank the following people for
providing us with information via e-mail: Larry Battis, Thomas
Bickel, Christine Bothe, Malcolm Brown, Michelle Cavallaro, Wayne
Cripps, Robert Gross, Greg Husband, Jim LaBelle, Lillian Ng,
Elizabeth Vesley, and Marty Vona.
We would be happy to answer any questions about information in this paper or forward them, if necessary.
|
AT&T. Year 2000. Available at http://www.att.com/year2000/. Visited on March 14, 1999. | |
|
Bell Atlantic.Year 2000 Readiness. Available at http://www.bellatlantic.com/year2000/. Visited on March 14, 1999. | |
|
Barry, William. Personal interview. February 18, 1999. | |
|
Barry, William. Profile of Major Institutional Administrative Information Systems. February 18, 1998. | |
|
Beahan, Michael. Personal interview. February 24, 1999. | |
|
Bothe, Christine. "Re: quick questions." E-mail to one of the authors. March 11, 1999. | |
|
Brentrup, Robert. Personal interview. February 18, 1999. | |
|
Brentrup, Robert. "Re: More y2k questions." E-mail to one of the authors. March 10, 1999. | |
|
Brown, Malcom. "Re: Y2k Questions." E-mail to one of the authors. February 16, 1999. | |
|
Brown University. Millenial millions. Available at http://www.brown.edu/Research/Unix_Admin/y2000/GSJ_box.html. Visited on February 22, 1999. | |
|
Cavallaro, Michelle. "Y2K Water." E-mail to one of the authors. March 15, 1999. | |
|
Cooley, Edmond. Personal interview. February 18, 1999. | |
|
Cooley, Edmond. "Re: Y2K clarification." E-mail to one of the authors. March 9, 1999. | |
|
Cripps, Wayne. "Re: Y2k Questions." E-mail to one of the authors. February 16, 1999. | |
|
Dartmouth College. Academic Computing. Available at http://www.dartmouth.edu/comp/ac/org.html. Visited on February 21, 1999. | |
|
Dartmouth College. BlitzMail. Available at http://www.dartmouth.edu/pages/softdev/blitz.html. Visited on March 14, 1999. | |
|
Dartmouth College. Dartmouth College Time Sharing 1. Available at http://www.dartmouth.edu/artsci/physics/labs/d1.html. Visited on March 14, 1999. | |
|
Dartmouth College. Fetch. Available at http://www.dartmouth.edu/pages/softdev/fetch.html. Visited on March 14, 1999. | |
|
Dartmouth College. Fetch Licensing. Available at http://www.dartmouth.edu/netsoftware/fetchhelp/Licensing.html. Visited on March 14, 1999. | |
|
Dartmouth College. Instructional Services. Available at http://www.dartmouth.edu/comp/insvcs/wedo.html?254,7. Visited on March 14, 1999. | |
|
Dartmouth College. Dartmouth College Information System. Available at http://www.dartmouth.edu/~library/infosys/dcisproject/DCIS_Project.html. Visited February 21, 1999. | |
|
Dartmouth College. Space Physics Experiments. Available at http://www.dartmouth.edu/~spacephy/experiment.html. Visited on February 21, 1999. | |
|
Dartmouth College. Computer Software Y2K Status. Available at http://www.dartmouth.edu/comp/y2k/software.html. Visited on February 21, 1999. | |
|
Dartmouth College. Dartmouth Systems Y2K Status. Available at http://www.dartmouth.edu/comp/y2k/dartmouthsystems.html. Visited on February 21, 1999. | |
|
Dartmouth College. Computer Systems Y2K Status. Available at http://www.dartmouth.edu/comp/y2k/systems.html. Visited on February 21, 1999. | |
|
Dartmouth College. UNIX at Dartmouth. Available at http://www.dartmouth.edu/~unix/classes/unix1/slides/u1.slide05.html. Visited on March 14, 1999. | |
|
Dartmouth College. The Year 2000. Available at http://www.dartmouth.edu/~y2k/. Visited on February 21, 1999. | |
|
Digital Equipment Corporation. ULTRIX and UWS Year 2000 Overview. Available at http://www.unix.digital.com/unix/year2000/overview.html. Visited on March 14, 1999. | |
|
Digital Equipment Corporation. Tru64 UNIX Year 2000 Readiness. Available at http://www.unix.digital.com/unix/year2000/whitepaper.html.Visited March 14, 1999. | |
|
Fraser, Doug. Personal interview. February 17, 1999. | |
|
Innovative Interfaces, Inc. INNOPAC modules available from Innovative. Available at http://www.iii.com/screens/iiiinfo.html. Visited on February 21, 1999. | |
|
Innovative Interfaces, Inc. Y2k Compliance Information. Available at http://www.iii.com/screens/y2k.html. Visited on February 21, 1999. | |
|
Keane, Terry. Personal interview. February 19, 1999. | |
|
Khan, Rehan, and Harris, Dave. Personal interview. March 10, 1999. | |
|
Kull, Joseph, and Massaro, Linda. National Science Foundation. Y2k Compliance Letter. Available at http://www.nsf.gov/pubs/1998/nsf98y2k/nsf98y2k.htm. Visited on February 21, 1999. | |
|
LaBelle, James. "Re: Y2K at Dartmouth". E-mail to one of the authors. February 16,1999. | |
|
Levine, Lawrence. Dartmouth College. Y2k Compliance Letter. Available at http://www.dartmouth.edu/comp/y2k/compliance.html. Visited on February 21, 1999. | |
|
Levey, Chris. Personal interview. March 3, 1999. | |
|
Levine, Lawrence, and Keane, Terry. Dartmouth College. PI Letter. Available at http://www.dartmouth.edu/comp/y2k/PI-letter.html. January 14, 1999. | |
|
Levine, Lawrence, and Khanna, Gurcharan. Personal interview. February 12, 1999. | |
|
Matthews, James. Dartmouth College. "Mac Blitmail 2.5.3 available." BlitzMail bulletin in "Computing - BlitzMail." March 5, 1999. | |
|
National Institutes of Health. NOTICE REGARDING THE YEAR 2000 COMPUTER PROBLEM. Available at http://www.nih.gov/grants/guide/notice-files/not98-046.html. April 3, 1998. | |
|
Ng, Lillie. "Water for Ted." E-mail to one of the authors. March 15, 1999. | |
|
National Science Foundation. Responding to Important Notice 120. Available at http://www.nsf.gov/oirm/y2k/responding.htm. Visited on February 21, 1999. | |
|
Ovid Technologies, Inc. A Summary of Y2K Changes and Issues. Available at http://www.ovid.com/dochome/release/rel78mil/y2kover.htm. Visited on March 14, 1999. | |
|
Prism, Inc. Year 2000 Readiness Disclosure. Available at http://www.prismcc.com/news/. Visited on February 21, 1999. | |
|
Princeton University. Year 2000 Status. Available at http://www.princeton.edu/~p2000/year2000.htm. Visited on February 22, 1999. | |
|
Pyc, Stan. Personal interview. February 24, 1999. | |
|
Rus, Daniela. Personal interview. March 8, 1999. | |
|
Systems & Computer Technology Corporation. Recruitment Information. Available at http://www.sctcorp.com/Corp/newdesign/cjoinus2.htm. Visited on February 21, 1999. | |
|
Silicon Graphics Inc. IRIX Year 2000. Available at http://www.sgi.com/tech/year2000/irix.html. Visited on March 14, 1999. | |
|
Taylor, William. Personal interview. February 18, 1999. | |
|
Taylor, William. "Re: Y2k Questions." E-mail to one of the authors. March 7, 1999. | |
|
Vesley, Elizabeth. "Re: quick questions." E-mail to one of the authors. March 11, 1999. | |
|
Vesley, Elizabeth."Re: quick questions." E-mail to one of the authors. March 11, 1999. | |
|
Wilber, Charles. Personal interview. February 19, 1999. | |
|
Wilber, Charles. "Re: Y2k Questions." E-mail to one of the authors. March 7, 1999. |
Note: the reference style we have chosen to follow is to place
the reference within the period if it refers just to that sentence
and to place it after the period of a paragraph to refers to the whole
paragraph.