Linda Pratt, IST–ASD
As is so often the case, the idea seemed simple in the conception phase: Change the database engine of the Campus Accounts Receivable System (CARS) from IDMS to DB2. How hard could that be? The Administrative Systems Department (ASD) approached the CARS conversion from concept, to delivery, through the infancy period with the angst of an expectant parent.
ASD and the CARS functional owner, Business Services' Loans and Receivable Office (LRO), selected its internal team and used all the external functional and technical expertise available. This included the contracted conversion vendor Mantech Corporation, an independent consultant specializing in IDMS-to-DB2 conversions, and UC experts from Central Computing Services (CCS) and Student Information Systems (SIS). The finished product is nothing short of a miracle.
Spring 2002 marked a conversion kick-off resplendent with CARS module inventories. CCS provided Mantech with all the CARS module source code along with schema information and data field attributes. Creating DB2 tables in a database structure that replicated the IDMS data fields, records, indexes, set relationships, and schemas was the first step. We named our new production platform "CARPROD". To test the integrity of its structure, we needed to convert the IDMS data into a DB2 format and load it into the CARPROD tables. The deliverable from this phase was a data mapping agreement containing the old-to-new data field name cross reference and the CARPROD database constructed by the DB2 Database Administrators of CCS.
Mapping agreement in hand, our consultant wrote a data conversion program that ran repeatedly to improve performance, correct conversion logic errors, and ferret out flawed IDMS data. Here is where legacy CARS's dirty data was exposed. To correct it, we needed to determine what the data was intended to represent, agree with LRO on what it should look like, devise the fix, cleanse the data, and convert it again to prove that it was clean enough to be loaded into DB2. That done, we were obliged to return to IDMS and fix the process that created the defective data. We were forced to improve our data's lifestyle to promote healthier offspring. One copy of CARPROD, loaded with healthy data, was used as Mantech's Test environment, another for UC Berkeley's Quality Assurance (QA) testbed.
With data mapping and cleansing complete, the CARS programmers and LRO superusers began creating program test specifications. Each functional nuance of every online process needed to be illustrated in a series of screen prints with accompanying textual explanations of the navigation and expected results. One thousand pages of test specs, showing the business purposes of 187 online programs, were delivered to Mantech in fall 2002. Each batch program needed test input datasets, expected output samples, and execution JCL to run against QA. At final count there were 239 converted batch programs supporting CARPROD.
During this time, CARS's source program code was being pushed through Mantech's "black box" logic converter. Every online, batch, and sub program was given the treatment. Since IDMS operates with an Interactive Data Dictionary and DB2 does not, each IDD module had to be relocated — either embedded in the program from which it was called or turned into a standalone copybook callable by many programs.
All programs, modules, and copybooks were converted and operationally tested by Mantech, then "staged" to UC Berkeley. The staged source was compiled to run in QA where CARS programmers, ASD production control staff, and LRO superusers did unit and integrated system testing. UC Berkeley's testing efforts with CARPROD included:
CARPROD was designed to meet UC Berkeley security requirements on three levels using runtime security, security tailored menus, and the cashier's lockbox security. Nearly 200 problems discovered along the way were reported, cataloged, routed, corrected, restaged, retested, and reconciled. The full-term testing period took nine months to complete.
This obsessive CARPROD testing nurtured a sense of confidence. By the time the programs had been accepted by UC Berkeley, we could implement knowing the only new component to be added on conversion weekend was the freshly converted, live data from IDMS CARS. A delivery date of August 5, 2003, was scheduled for the campuswide rollout of CARPROD.
The implementation plans from July 31 to August 5 were depicted with an "Events List". Each required effort was considered an "event" and documented in order of its sequential dependency. There were 51 events, involving 26 people, encompassing six days. We conducted "go-live" meetings with the entire CARS implementation team to verify that each mandatory event had been defined, that we had an available expert to perform the service, and that the service provider would be ready, willing, and able when called to task.
The implementation events were carried out without a hitch. Each participant did a splendid job gearing up for the owner's production checkout and signoff on August 4. There was a flurry of follow-up activities that made the cutover to DB2 permanent and then the intensely stressful shakedown period that always follows a system's "birth". Each adult resource was poised and ready to apply the necessary skill should the newborn application need it, all the while fantasizing about getting a good night's sleep.
It was a successful birth; the baby is beautiful, the parents are exhausted and the extended family is proud. The University has a new Accounts Receivable application that looks like its older relative but holds much more promise for the future. CARPROD runs its batch jobs in half the time of its pokey predecessor and can be Web-enabled using standard, supported architectures unlike legacy CARS. We welcome the new generation with high hopes and expectations.
[ iNews | Search | IST | UC Berkeley Computing | UC Berkeley ]
iNews: UC Berkeley information technology news on the Internet
Copyright 2003, The Regents of the University of California