U of Arkansas Little Rock Upgrades for Learning Solutions

• By Linda L. Briggs
• 07/19/05

When the University of Arkansas Fayetteville recently installed PeopleSoft’s student module, it suddenly needed a job control system that could handle multiple platforms and applications across a distributed system.

With more than 17,000 students and 840 faculty members, the UALR is a nationally competitive, student-centered research institution based in Fayetteville, Arkansas. The bulk of the school’s hefty administrative computing work was handled by a mainframe running IBM’s DB2 UDB database.

The University of Arkansas Fayetteville is using modules within the PeopleSoft (now Oracle) Learning Solutions software suite for a number of administrative processes, including registration, admissions, financial aid, student accounts, student records, and student demographics.

With the new PeopleSoft module in place, the school wanted to maintain its mainframe environment, along with a distributed system that would include a Sun Solaris Unix platform running PeopleSoft and an SAS data warehouse, and some Windows/Intel systems.

“Before PeopleSoft,” explains Associate Director of Computing Services El Orwig, “everything was primarily the MVS mainframe operating system for job scheduling and control. We had some Unix and Wintel jobs out there. But with the PeopleSoft student module, we needed something that was multi-platform, to go between Unix, our mainframe, and our Windows environment.”

Although the job scheduling function runs quietly behind the scenes for the most part, it’s an important part of keeping the university’s computing system running smoothly. Technical staff and administrators run up to 1,400 jobs a day around the clock, including backups and recoveries, the weekly payroll, grade processing, financial aid information, and much more—including pulling data from the school’s SAS data warehouse.

In selecting a new job scheduler, the university did its homework carefully, conducting three separate vendor proofs of concept. In the end, Orwig and his team selected UC4:global from UC4 Software as its job scheduling solution. One big point in UC4’s favor: When the school conducted its proof of concept with UC4, the new job scheduler was up and running in a matter of days.

In the end, UC4 proved able to run with or without the previous mainframe scheduler, IBM Control M. “We were able to function either way,” explains Orwig. “They met all our criteria for multi-job platform scheduling.”

Another key deciding factor was that UC4 includes an interface for both the IBM DB2 UDB database currently underlying the school’s PeopleSoft system, and for an Oracle database. “That was our biggest [problem] with other vendors,” Orwig says. “They didn’t support [both] Oracle and DB2.” The university is considering a move to an Oracle database in the near future, an interface that UC4 will be able to integrate smoothly. “We’ll just link our various executors to point at Oracle instead of DB2,” Orwig says.

UC4 also handles jobs on the university’s SAS data warehouse, which runs on the Sun Solaris platform. Previously, to ensure that jobs ran successfully, Orwig’s technical staff wrote special code to jump between the Unix system and the mainframe—code that involved a significant amount of work. UC4 now moves easily between Unix and the mainframe, eliminating the need for those sorts of patches.

The project’s return on investment can largely be measured in time saved and a reduction in errors, Orwig says. UC4:global works by creating plans, laying out which jobs can run together or must run sequentially. Because the product divides jobs into objects, it can schedule multiple job streams to run concurrently. That means large batch processing no longer has to happen in a window between 6 p.m. and 6 a.m. Also, the school sees fewer errors because of file locks or similar problems. “It’s really about staff time saved,” Orwig says.

Allowing multiple job streams to run at the same time helps to reduce overall time, which reduced the nightly batch processing window by several hours. Also, each job in UC4 can have a "pre" or "post" processing requirement, and includes a place for supporting documentation.

“Because UC4:global divides jobs into objects, turn-around time is faster since the job plans are better handled,” Orwig says.

One challenge in a very smooth implementation, he says, was negotiating the learning curve as the production control staff expanded from using the familiar mainframe Control M job scheduler, to running on Unix. “My production control staff was primarily mainframe,” Orwig says. “JCL [for the] mainframe is a lot different than JCL in the Unix world, so we did have to adjust to a different mindset.”