Small CAUSE logoCAUSE/EFFECT

Copyright 1996 CAUSE. From CAUSE/EFFECT Volume 19, Number 4, Winter 1996, pp. 57-59. Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, the CAUSE copyright and its date appear, and notice is given that copying is by permission of CAUSE, the association for managing and using information resources in higher education. To disseminate otherwise, or to republish, requires written permission. For further information, contact Julia Rudy at CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301 USA; 303-939-0308; e-mail: [email protected]


Readers Respond

Question:

Looking ahead to the year 2000, is your institution planning to modify existing information systems to handle the new date, or are you planning to investigate the purchase or development of new applications? What steps have you taken so far to address the "Year 2000" challenge?

Our Year 2000 efforts at the University of Florida formally began in March 1996, with the assignment of a project leader. Since that time, an estimate of impact and a systems inventory has been conducted, system priorities established, a project plan developed, and an eight-member team organized. Each system is currently undergoing a detailed analysis to determine the preferred conversion approach. Approximately 4.4 million lines of code in 4,000+ programs are affected.

In older, isolated systems, a sliding window approach is usually chosen. Otherwise, we are changing the data files. Where there is enough space on the record, we are duplicating each old date with an 8-byte (YYYYMMDD) compliant date. This allows both converted and original programs to access the same file. If there is insufficient space, we are adding a single-byte century indicator for each date. As a last resort, we are expanding and reformatting the file. Our overall target completion date is December 31, 1998.

As of October 1996, four research pilots, one conversion pilot, and two regular system conversions have been successfully completed. Six separate project phases have evolved from these experiences: awareness, assessment, research & planning, conversion & testing, implementation, and monitoring.

Tom Thomas
Director of Information Systems
[email protected]



At Rollins College (Florida), we went the easy route and decided to completely replace our legacy system before that date with BANNER. We would have needed a several-year effort to rewrite the existing system just to deal with this. Hopefully, we'll feel we got off easier with the method we've chosen.

Les Lloyd
Assistant Vice President of Information Technology
[email protected]



At Humber College (Ontario, Canada) we started the process of examining the Year 2000 problem in 1994, as a part of our overall administrative system plans. We saw it as an opportunity to begin addressing technical issues and integrating systems. Essentially we are replacing two of our major trio of systems (student and human resource/payroll). We are rewriting our student system using a new application development platform (NATURAL/ADABAS/CONSTRUCT/PREDICT), which was planned ahead of time for technical reasons, with the added benefit of handling the Year 2000 problem (the old system would not handle it without programming).

For HR/payroll, we are participating in the founding of a consortium of Ontario colleges to centralize new hardware, new software (ROSS), and some services. (This will replace our old IA version.) For our financial system, which is currently SCT/IA, we will either apply the updates that should be available in 1997 or perhaps replace it, too. All other systems will be combined with our student system project, rewritten, or dropped.

The student system will roll out in the first quarter of 1997. HR/payroll is scheduled to take a year from commencement. The FRS updates are estimated to take ten weeks to apply (we still have several Canadian mods to reapply), while a replacement is still to be determined and could involve the college consortium.

Peter A. Kahn
Director, Systems Development
[email protected]



In general, the University of Wisconsin-Milwaukee is planning to modify existing information systems to handle the Year 2000. In fact, this has been a background, ongoing activity for a number of years here. We devised a method to allow us to convert programs as we have done maintenance to them. We estimate that we are about 80 percent complete at this time. Remaining programs will be converted as part of a major rehosting effort from an IBM mainframe to a UNIX platform in the next two years.

Marge Waala
Manager of Application Development
[email protected]



The University of Arizona evaluated many alternatives. Given the complexities of developing new applications, the fact that the implementation date cannot be adjusted, and having applications that already need Year 2000 dates, we are planning to modify the existing systems, although outright replacement remains an option. Some specific subprocesses of our application systems may be reengineered as an alternative.

The analysis of major systems began in 1995, and a project team was formed earlier this year to coordinate the changes to all systems. This team has been evaluating all aspects of becoming Year 2000 compliant. A project plan has been developed; an initial budget request has been submitted; vendor products for analysis, code change, and testing are being evaluated; a testing environment is being planned; and a position and recommendation paper is being finalized. Actual code changes have started where applications are currently facing Year 2000 issues. Additional personnel resources will be required to implement a full-scale, Year 2000 compliant modification process.

Bob Lancaster
Computer Operations
[email protected]



Florida Community College at Jacksonville instituted a systems development standard of "handling the Year 2000" in all new systems in 1989. It was during 1990 or 1991 that we began reviewing our long-term direction with regard to systems development tools. Our process concluded in late 1992, with the acquisition of new tools. We selected Software AG's tool set of ADABAS/NATURAL/CONSTRUCT/PREDICT, and some others.

It was our belief that we had to have tools to allow us to change systems more quickly. The growing demands for data from the Florida Legislature, as well as institutional needs, dictated requirements for adding new data elements and systems functionality in a more timely fashion. It was obvious that systems developed with COBOL and VSAM files would not meet future needs in this regard. Another factor driving our systems changes was the need to address the Year 2000 date in existing systems.

About the same time we were acquiring new tools for systems development, there were seven other community colleges that selected the same tools. In 1993 we formed a consortium to rewrite the major applications, i.e., finance, payroll/personnel, student, and facilities. The systems development process began in January 1994. The payroll/personnel system is in production at two colleges. The finance system is being installed at one college, and the student system will be installed beginning in February 1997.

With the consortium we are addressing two major institutional requirements: the Year 2000 date problem and being able to replace our legacy systems using a new tool set. The new systems are providing significant new functionality-it's not just a system rewrite. With the consortium we are able to address systems replacement significantly faster than we could have if we were rewriting these applications by ourselves. We will have all these systems in production by spring 1998. The finance system will be in production beginning July 1, 1997, the payroll/personnel system by January 1998, and the student system by April 1998.

The members of the consortium are: Florida Community College at Jacksonville, Broward Community College, Miami-Dade Community College, Palm Beach Community College, Indian River Community College, Okaloosa-Walton Community College, Tallahassee Community College, and Edison Community College.

Jack Tinsley
Associate Vice President
Information Systems and Services
[email protected]



Syracuse University is planning to replace the majority of its information systems by the Year 2000. An analysis of our legacy systems showed that a few could be modified at a reasonable cost, many should be replaced due to the high cost of modification, and a few would have to be rewritten. The decision to replace as much as possible is in line with our computing strategy, already in place, to move our information systems to newer technologies. Our replacement approach is to purchase software packages where possible, modify a few systems, and rewrite those information systems we cannot purchase. To date, we have replaced many of our smaller systems with purchased packages or in-house written applications. We have selected package replacements for alumni/development, human resources, payroll, facilities management, library, and student systems. Project teams for these areas are in various stages of the implementation process, with target dates during 1997 and 1998. Other teams are in the process of evaluating telecommunications, accounts payable, and purchasing software. Modifications to systems we expect to run after the Year 2000 are under way and will be completed before they begin to encounter problems.

Sue Borel
Director, Information Systems
[email protected]



The California State University (CSU) Office of the Chancellor has launched three IT initiatives related to impending Year 2000 date issues:

More information on these and other CSU I/T initiatives can be found at: http://its.calstate.edu/

John C. Miller
Senior Consultant
CSU Integrated Technology Strategy
[email protected]



The Board of Regents of the University System of Georgia is using a combination of approaches to meet the Year 2000 challenge. All of our current financial applications -- including payroll -- will be modified internally for Year 2000 compliance. We are currently engaged in an RFP process for new financials, but installation will not be complete in time to avoid Year 2000 implications. In addition, we are analyzing our complementary and secondary systems to find out where we need to make modifications to deal with the century change. Along with desktop systems, these are our biggest headaches. There is just that underlying concern that somewhere in there we have forgotten a minor process that will be impacted when, or before, the new century arrives.

One area where we feel confident about this transition is in our student information system, which is BANNER from SCT, and the hardware and technology that support it. SCT is providing the modifications necessary for Year 2000 compliance in BANNER. In fact, this is just a routine update as part of their Technology Currency Program. Our primary hardware vendor, Hewlett-Packard, will be providing an updated operating system; and Oracle is keeping us current to run without a hitch as we approach the Year 2000. Oracle is the database for all our centrally supported applications.

The University system is also participating with the state agencies in a collaborative effort to review and identify problem areas.

Though a challenge as all-encompassing as the Year 2000 is cause for concern, a solid strategy like the one we developed for Georgia (and vendors who take care of their customers) smooth the way for an uneventful transition. Also, because thirty-one of our thirty-four institutions are in the process of installing the BANNER software, we have the added comfort of many people collaborating to ensure our success.

Randall Thursby
Assistant Vice Chancellor for
Information Technology
[email protected]



Purdue University developed a Year 2000 solution in 1994. It consists of COBOL programs to scan and subroutines to insert, where appropriate, to solve the problem. The solution also consists of a user guide with instructions and examples.

Our solution does not expand files or fields. We continue to utilize two digits. We found this to greatly reduce the number of programs needed to modify and test.

We have approximately 10,000 COBOL programs. As of October 1996, we are approximately 54 percent completed. That includes scanning, modifying, testing, and putting back into production. Of the approximately 5,000 programs we have put through the scan, we average about a 40 percent hit rate. This means we do not have to modify about 60 percent of the programs. On average, taking into consideration all 5,000, we are averaging less than 1.5 hours per program. Over two years, we have averaged using 2-3 FTE per year to make these modifications.

We sold the distribution rights to this solution to Venture 2000, Inc. (904-731-1622). They have also translated the solution into multiple languages that run on MVS and VSE.

Jerry Smith
Director
Administrative Computing Operations
[email protected]


Editor's Note:

For lack of space we were unable to print all responses received. All responses are found in the text file at:

http://www.cause.org/ir/library/text/cem964b.txt

Also a current issues session on this topic was held at CAUSE96, and a summary of that session will be available early in 1997 as part of the online conference proceedings.


Spring 1997 Readers Respond Question

Is retention of highly skilled technical staff a problem at your institution?
If so, how are you dealing with this challenge?

Please send your response along with your name, title, e-mail address, phone, and fax numbers by electronic mail to [email protected].

...to the table of contents


[Comments] [Search] [Home]