PENN PRINTOUT
The University of Pennsylvania's Online Computing Magazine

PENN PRINTOUT October 1991 - Volume 8:2

[Printout | Contents | Search ]


Cooperative processing: SRS data and local systems

By Tad Davis

There is an enormous hunger for information among University administrators and faculty - information about students, courses, donors, personnel. And the appetite for that information doesn't stop at the University gates. Outside agencies want data in a form they can use - a constant stream of requests for profiles and crosstabulations of data.

Much of the raw data to satisfy this craving resides on the University's administrative mainframe. But many of the tools for analyzing the data reside on local desktop systems. The solution? Bring the two together. As many offices on campus have discovered, you can download the mainframe data to a desktop workstation; there you can supplement it with the reporting and presentation flexibility of a PC.

This is not a vision of the future; it is a daily fact of life at Penn. SRS, the University's mainframe Student Records System, is a case study in this cooperative venture. SRS has an extensive series of reports, ranging from class lists to statistical summaries of grade distribution, classroom utilization, and faculty load. But it's not enough. No matter how many reports are designed into the system, the demand for information will always outstrip them.


Filling in the blanks

In some cases, offices use the data from SRS to "fill in the blanks" of PC databases. The Student Health Service, for example, has a set of databases, written in dBASE III Plus, that handles immunization, demographic summaries, and appointments. Several times each term, the office downloads student data from SRS and updates their local files.

"Getting the data from SRS means we have the most up-to-date address and demographics," says Jeff Douthett, a systems analyst in the office of Student Information and Systems. "And the office doesn't have to key it in. The download saves a lot of data entry."

The School of Arts and Sciences followed a similar course on the Bacchae Project, where incoming freshmen were asked to read The Bacchae by Euripides. Using a PC-File database, the school assigned each freshman to a discussion group with a specific faculty advisor. Data about the freshmen was downloaded from SRS. "We've done this in the past for freshmen," says Susan Quant, a programmer in Arts and Sciences. "We've used a PC database to assign faculty and peer advisors."


Enriching the base of data

When more elaborate analysis is needed, this core of SRS data can be enriched on the desktop from a variety of sources. The Graduate School of Education, for example, has created a networked Omnis 5 database with 11 workstations. Once a month, John Irwin, director of computing services for the school, downloads data from SRS and refreshes his local version. "Education supplements SRS categories for things like subject area and major," says Irwin. "We need different groupings for internal reporting. And sometimes we add information-for example, detailed notes on a student's dissertation."

Arts and Sciences also maintains a local database of graduate students, this one in Paradox. The school adds data from a variety of sources, not all of them computerized. "We have electronic and paper input, and historical and current data," says Bill McManus, a data processing project leader for the school. "And we bring in data from central sources like financial systems, financial aid, and personnel."

There is another advantage to this process, as McManus points out. When the structure of the mainframe system changes radically-as it did with SRS-the local system can maintain a common format between the old and new systems. This can be a tremendous boon to longitudinal studies.


Leveraging access to information

Another major reason for taking the desktop route is making better use of the computer expertise in the office.

Dan Shapiro, assistant director of planning and institutional research, sees this as one of the key issues. Once a year, for example, SRS extracts data on student re-enrollment and attrition. By downloading the file and converting it to spreadsheet format, Planning can call on the expertise of a larger number of people to build statistical models. "There are lots of people here who can do spreadsheets," says Shapiro. "Once they have the data, if they have an idea for a new approach, they can just do it."

Paul Shaffer, who provides end-user support for the School of Engineering, has also been able to leverage the access to information by downloading data from SRS. He converts the downloaded data to Q&A and FileMaker Pro format. The password-protected databases are distributed by diskette.

Both database programs allow queries by users with minimal training. Shaffer offers an example: Suppose someone in the school wanted to invite all senior electrical engineering students to a picnic. "Five or ten minutes, start to finish," Shaffer estimates. "They can do the mail-merge right there and print off the labels and letters themselves. That's the whole purpose. They can ask their own questions."


Putting the best face on the data

Another reason for downloading is to take advantage of the wealth of graphic and publishing features available on the desktop.

"People react better to charts than to tables of numbers," says Shapiro. "The more professional-looking, the better." For special presentations, Planning can import downloaded data into DeltaGraph on the Macintosh and turn it into a chart or graph. It can then send the DeltaGraph files to a service bureau, which converts them directly into color slides.

The Registrar's Office follows a similar approach in preparing the annual Course Register. This 300-page book contains narrative descriptions of all the courses taught at the University. A mainframe program extracts the course descriptions from SRS and adds special formatting codes. This file is downloaded to a Macintosh, interpreted by Microsoft Word, and printed on a laser printer. The result? Camera-ready copy in four hours. "Possibly we could have produced this document on the mainframe," says Tusita Wijesinghe, a programmer/analyst in the office of Student Information and Systems. "But we would have had to write our own program for the word wrap and the page breaks."


Cooperative processing

Thus the battle between the mainframe and the desktop never materialized. What has happened instead is that each supports and extends the other. In one office after another on campus, the two worlds have found effective ways to cooperate.

"I see a time down the road," says Robin Beck, director of applications development at UMIS, "when the mainframe will become a huge data server." The downloading process can't work unless there's a central source of data, and unless that source is perceived as stable and current. "It's our job to keep that central data up-to-date and to guarantee its integrity to the rest of the University community," she says. "But beyond that, we need to make the data accessible. The goal is to empower people. They have to be able to take that raw data and turn it into information."


TAD DAVIS is Lead Programmer/Analyst for UMIS.

If you have a programmer on your staff, you can access SRS data directly; or you can request that the Registrar's staff extract the data for you. In either case, submit a request in writing to Ron Sanders, University Registrar. There are standard forms available for these requests. Call 898-2041 for more information. Once the data has been extracted from SRS, you can download it using the Kermit options in ProComm or MicroPhone II, or (if you have an Ethernet connection) by using TCP/IP.