«Abstract: Bradley University completed the conversion of all mainframe administrative software to a client/server environment. These mission-critical ...»
This paper was presented at CUMREC '97, The College and University
Information Services Conference. It is the intellectual property of the author(s).
Permission to print out copies of this paper is granted provided that the copies
are not made or distributed for commercial advantage and that the title and
authors of the paper appear on the copies. To copy or disseminate otherwise, or
to republish in any form, print or electronic, requires written permission from the
BACK From Mainframe to Client/Server - a Success Story Stephen Patrick - Executive Director of Information Management Services, Bradley University Ellen Watson - Associate VP, Information Services/Dean of Library, Indiana State University Bradley University, Peoria, Illinois Bradley University is an independent, privately endowed, coeducational institution. Bradley’s enrollment is about 6,000 students and offers programs in Engineering, Business, Liberal Arts, Sciences, Education, Health Sciences, Communications and Fine Arts.
Bradley University completed the conversion of all mainframe administrative software to a client/server environment. These mission-critical systems support very large databases and provide multiple users and hardware platforms with a complex array of data entry, verification and reporting options.
The presentation will review our approach to client/server administrative applications and focus on our methods of working with system owners to design the client/server applications and to solve the problems and difficulties encountered. Particular attention will be devoted to
the following issues:
• Involvement of system owners/users in client/server design and implementation
• System performance in a client/server environment
• Printing and reporting
• Integration with auxiliary applications -- DARS, SPEEDE, telephone registration
• Cross platform integration -- Mac, PC
• Remote access 1 From Mainframe to Client/Server - a Success Story Mainframe Administrative Systems at Bradley In 1990, Bradley University’s administrative systems were centralized on a mainframe computer. These systems were either locally developed, or were purchased software heavily modified by Bradley and no longer supported by the vendor. There were significant problems with these systems: The systems were not implemented in a modern data base management system; the systems were very inflexible;
design decisions made in the 1970s were causing numerous operational problems. In addition, the mainframe computer was a proprietary design manufactured by Control Data Corporation. There was a concern that we would face a difficult problem if Control Data did not succeed in the mainframe market.
Scope of Bradley’s Administrative Systems:
Advancement Alumni, Friends and Corporation reco
Preparing for the Transition to a Client/Server Environment After reviewing the existing environment and projected needs, Bradley University’s Information Resources and Technology unit developed a “Computing Initiative” to move the campus from a mainframe environment to a distributed environment. Initially, we did not target client/server as the 2 architecture of choice, since in 1990 there were limited examples of client/server architecture applied as we envisioned.
We recommended a phased implementation. The highest priority was the Advancement system, as Bradley was to begin a $100 million campaign in 1993. The Advancement staff considered the thenexisting system inadequate to support the needs of the campaign. Finance and accounting were given the second priority in part because we felt that the conversion of our in-house system to a “standard” accounting system should be relatively straightforward. Student Records and Admissions were considered the most difficult applications to convert and they were put at the end.
We initially investigated purchased systems operating in a mini-computer environment. Technical staff and the major administrative computer users examined a variety of options. None of the systems available at the time provided all services needed and the prices were too high for the perceived value of vendor-based systems.
A computer industry executive (and Bradley alumnus) recommended that we do a pilot test of the Advancement system in a client/server environment using Rapid Application Development methodology. Because this was uncharted territory for Bradley’s administrative development staff, we employed a consultant to serve as the project leader for the effort.
Design Issues We recognized from the beginning that “client” involvement -- the participation of the owners and users of the system -- would be essential to the success of system development efforts. The Rapid Application Development (RAD) methodology was integral to the success of our efforts. In prior development efforts, the time lag between system specification, coding and delivering a demonstrable product was a hindrance to our understanding the needs of the client and delivering the product. Our RAD technique used weekly meetings with our clients to involve them in the development effort. Senior administrators, office managers and front line staff were all involved in the RAD implementation. At each meeting we demonstrated the week's progress, discussing issues and setting milestones for the next meeting.
Clients saw the actual functioning of the system as we developed it. We were able to make major and minor adjustments to the system early and continuously in the development cycle.
3 A further complication was that none of us (including the client) had a clear understanding of what data was needed to support a $100 million campaign. We needed to insure that the system was flexible enough to allow for changing and emerging needs. By demonstrating the ease of program and data base modification, we all felt that we could adapt the system to meet whatever needs developed.
Experience with the Uncertainties of the Client/Server Environment
We knew that a client/server architecture would be fundamentally different from a mainframe or a mini-computer environment. When we began our project, we were not -- and could not be -- aware of the extent of the differences. Furthermore, we could not find successful implementations of client/server “bread and butter” administrative systems either to be purchased or to serve as models.
As we developed this new environment, we encountered a number of technical challenges that are worth discussion.
1. System performance in a client/server environment
2. Printing and reporting
3. Integration with auxiliary applications
4. Cross platform integration
5. Workstation configuration
6. Remote access System Performance Client/Server architectures are much more complex than host-based systems. There are many factors that impact performance (generally negatively) including the server, the network and the client computer. Also, monitoring and control of these factors is much more difficult in a client/server environment. Several application development products provide acceptable performance with small data bases, or small groups of users, but cannot provide the performance needed for a modern, complex administrative system with a large user base. Our Advancement database consisted of 70,000 records for individuals and institutions. Normalizing the data resulted in many data tables and millions of records. This environment makes the efficiency of the application development tool and the data base a critical factor. For the Advancement system, we chose a DOS (non-Windows) environment using Clarion as the development tool. At the time, we did not find any Windows based environments that provided adequate performance. The Student Records and Admissions systems are developed in a Windows environment (with some reporting tasks in DOS), again using Clarion.
Printing and Reporting Printing and reporting offer special challenges and opportunities in a client/server environment. Clients typically have a variety of printers that are incompatible with each other. Also, there exist needs for volume printing in either the user office or the computer center. At Bradley, different offices solved the problem in different manners. The Advancement unit elected to have Information Management Services (formerly Computing Services) print most reports. The Controller’s Office prints to a high volume laser printer in their office. Admissions prints most of their work on high volume laser printers, but use data center impact printers for some reporting. The Registrar’s Office uses data center printers for most output and has an office laser printer for transcripts and time sensitive reports. We found that reporting using Windows standards adds significantly to the complexity of the programming task -dealing with different sized fonts, proportional fonts, page layout vs. line layout. We chose to avoid this on the initial implementation by sticking with a DOS reporting strategy.
Executing report programs is another challenge. Most central host computers are multi-user/multitasking systems making background processing of reports a routine task. Desktop computing, 4 especially in a DOS environment, is a single tasking system, and most users do not want to “give up” the use of their systems to run a report. Also, some reports need to be scheduled for later processing.
On a positive note, integration with Word-processing and other office automation software is much easier for users to understand and use than in a centralized environment.
Because we developed the Advancement System internally, we were able to solve this problem to some extent. We have a pair of computers in Computing Services dedicated to running ad hoc reports. These computers constantly process reports placed in a report queue. Output from the report servers can be printed on any network printer or saved on a network disk for later processing. During busy times, users have the option of running these reports on their office computers. With the purchased accounting system, we did not have the ability to implement this system. Rather, we installed “extra” high performance computers in offices; clients can use these workstations to run reports without losing productivity on their “own” desktop machines. The Student Records and Admissions systems are Windows-based systems; we can multi-process reports and other tasks, though performance suffers.
Early benchmarks showed that the processing time needed for a client performing a massive batch run (for example, grade processing or census reporting) compared favorably to the same runs in the mainframe computer. Attention to the indexes and keys in the data-base has made selection and reporting significantly faster in client/server environment, particularly for small volume reports. We provide user-controlled parameters to specify the amount of resources to allocate to foreground processes, so the user retains control of the desktop. While this situation is not ideal, it is a Windows limitation that we must accommodate.
Auxiliary Applications While several of the systems must support auxiliary systems in a client/server environment, the Student
Records system has the largest number and variety of auxiliary subsystems, including:.
• Bradley University has been using voice response registration for a number of years and this feature must be supported in the new system. The voice response system communicated to the mainframe through a single serial line. While we could have written a PC program to simultaneously handle multiple conversations, we decided to do this with one UNIX system, written in C++, communicating with the application server. This requires that the client/server database management system must be able to support both personal computers and UNIX systems.
• The mainframe student records system audited degree requirements. Reprogramming a degree audit system was such a complex task that we felt it was more than the internal staff was prepared to accomplish in the time available. We purchased the DARS system from Miami University to replace our in-house degree audit system. DARS is an IBM mainframe, CICSbased, system available in COBOL or PL1. We initially thought we would build our own front end to DARS, then just execute the COBOL code to actually produce an audit. We found this another difficult challenge. We now maintain degree requirements using a CICS emulator. We devoted our resources to the actual execution of an audit in a user-friendly manner rather than devote resources to maintenance of the audit rules database. This appears to be the first client/server implementation of DARS, and we faced significant challenges making it work effectively. We plan to add DARS execution to our Web based Academic Inquiry system.
• Bradley University was an early adopter of SPEEDE for exchange of electronic transcripts. We use the Supply Tech PC based package. Because we are eliminating a step in the process -translation between the mainframe and the PC -- the resulting system is simpler than the original.
Cross Platform Integration Bradley University’s computing environment is a diverse mixture of Intel-compatible desktop computers, Macintosh computers and UNIX workstations supported by a variety of servers and networks. Our goal is to provide access to our systems from a variety of platforms. We faced two major challenges: the configuration of individual computers is critical to our success; and we wanted to offer the systems on a variety of hardware platforms. We addressed this challenge by standardizing systems and configuration in the mainstream user office (the Registrar’s Office), and providing Web access for all other users.
The Web provides several advantages over other client/server architectures:
1. Platform independence. Bradley University has a wide variety of desktop computer systems including Macintosh, PC Windows (several versions), and UNIX workstations. The Academic Inquiry system runs on Netscape versions 2.0 or higher. This is supported on nearly all desktop systems on campus. The only problems are due to obsolete computers, or lack of networking.