[Printout | Contents | Search ]

Administrative printing: Innovative local solutions

By Valerie Glauser

More and more University offices are seeking to maintain their data centrally on the administrative mainframe while printing the information they need, when they need it, in the format they need it, on "local" printers. With the aid of University Management Information Services (UMIS) and Data Communications and Computing Services (DCCS), they are increasingly able to do so.

The right printer for the job

Curriculum Counseling staff now connect to the administrative mainframe from a desktop terminal via PennNet, then select the desired data inquiry using FOCUS software, and send the job to the desired printer through several online screens developed by UMIS using the administrative mainframe's DIALOG manager.

Today, the office of Curriculum Counseling does about 65 percent of its administrative-mainframe-data printing locally, while still sending impact printer and high-volume laser print jobs to the UMIS central printing facilities. In some instances, the Curriculum Counseling staff can request that the Job Control Language (JCL) pages of a job be printed on "greenbar" paper at the UMIS offices, while printing the remainder of the job on standard white paper on the local laser printer. "They keep a record of the job, and we save paper," comments Lynn Seng, Director of the office of Curriculum Counseling.

Seng concludes that the local printing capabilities save her office time and enable them to keep hard copy of the most up-to-date records readily available.

Transcripts and course register

Before 1990, the process of producing official transcripts varied from school to school. The Registrar requested the printing of some transcripts on the line printer at the UMIS Processing Center, where the requests, or jobs, were processed overnight. The Law School did transcripts manually, using rubber stamps for courses, instructors, and grades. The School of Social work had boxes of three-by-five cards and assembled transcripts by hand.

With the development of SRS, transcript information was brought on line centrally to the administrative mainframe. Then-Registrar John Smolen (now Executive Director of Student Information and Systems) also wanted to bring high-quality transcript printing in house. To do so, the Registrar's staff worked with UMIS and DCCS to establish a dedicated telephone-line connection via modem from the administrative mainframe to their Xerox laser printer.

Since 1989, the Registrar's office has been printing transcripts locally for all University schools, except the schools of Medicine, Dental Medicine, and Veterinary Medicine. The transcripts are printed on "safety paper" (the word "VOID" or "COPY" appears across any photocopy of a transcript) and are much less easily forged because of the differing typefaces now used on the laser printer. Transcripts can now be printed and made available to students the same day.

The Registrar's office has also simplified production of a major annual effort, the Course Register. Before SRS, the Registrar's staff had to create, maintain, update, and extract Course Register data from a dBase II system on a PS/2. They then put the resulting ASCII file through a BASIC program which inserted appropriate codes for formatting notations, such as boldface or italic type.

The BASIC program also estimated for proper page breaks, but Tad Davis, then a staff member at Student Information and Systems, says problems occurred when the estimates were inaccurate. "We couldn't detect (the inaccurate page breaks) without printing out each page in the file," says Davis. "After printing the text, if the page breaks were wrong, we would have to load it into a text editor and estimate the number of carriage returns required to wrap the text to the next page. This was, for 200 to 300 pages of copy, a trial-and-error process that would take days."

Once the Course Register information was maintained in SRS on the central administrative mainframe, Davis figured that they could use the common Microsoft word-processing capability of Rich Text Format (RTF) to create an ASCII text file with formatting commands that include codes to indicate boldfacing and italicizing. "The concept of the file was no different than the BASIC program," says Davis. "The difference was that the file could be read by an industry-standard word processor, such as Microsoft Word or WordPerfect, and that the software offered far more accurate control over page breaks."

Tusita Wijesinghe, a programmer analyst for Student Information and Systems, then developed a NATURAL program on the administrative mainframe to insert the proper RTF codes. He ran the NATURAL program on the extract file containing the Course Register information, so that when the file was transferred to a Macintosh, it was in the RTF format that a Mac word processor could read as formatted text, with little to no additional editing required. It then was printed out on an Apple LaserWriter. The end result, says Davis, is that production time, including printing of the final copy, was cut from more than four days, to about four hours.

Where to go for more information