Mainframe Migration - 5
throughput of a system. Since 1993, the TPC-C (See TPC, 2002 in the Resources section below) online transaction processing benchmark has been used to demonstrate the effectiveness of hardware platforms, database systems and transaction systems. One problem with the benchmark has been its popularity: it is now featured in Wall Street Journal advertisements when new records are reached. Over the years this popularity has led TPC-C to become a highly tuned benchmarking vehicle to demonstrate a hardware or software vendor’s effectiveness of their product. The record-setting performances often no longer reflect real world (mainframe) workload environments. However, the roots of the TPC-C specification lie in classic mainframe data processing needs of a company that must manage, sell or distribute a product or service (such as car rental, food distribution, parts supplier, etc.).
We developed a COBOL implementation of the TPC-C business logic complete with embedded SQL statements that are handled by SQL preprocessors. In this mainframe migration environment, as on the mainframe itself, the screen interface is handled through the use of 24-line, 80-column terminal screen (3270 terminal) used for data entry and report generation. It is the responsibility of Micro Focus Enterprise Server with the Mainframe Transaction Option to provide the commit coordination to the database management system through an XA-compliant interface. The benchmark simulates data entry errors which cause transactions to fail about 1 percent of the time.
The benchmark was run on an IBM mainframe with the zOS operating system, CICS transaction system and DB2 database system. The COBOL remained unchanged when it was moved to Windows Server 2003, Micro Focus Enterprise Server with the Mainframe Transaction Option and the IBM DB2 UDB 8.1 database system. The database in the Windows environment allowed certain optimizations that are typical in IBM environments to be employed in the mainframe migration environment. For example, SQL statements removed from the COBOL source by a precompiler are entered into a DB2 package for faster execution. Database locking table size, buffer sizes and database growth characteristics were the same in both environments, as was the layout of data types, tables and index structure of both systems.
The TPC-C benchmark was chosen for these scalability tests largely because it is well documented and tested and that it models the historical trend in IBM CICS COBOL business transaction systems. IBM researchers in the IBM Systems Journal (See Characteristics, 2001 in the Resources section below) found that TPC benchmarks fall reasonably within the range of real world behavior in some areas; in other areas, they were not representative. For example, the IBM researchers found that the transactions were longer and contained fewer read-only transactions than in production workloads. They also had collisions with other transactions in the mix. TPC-C was found to have fewer transaction types and hold locks longer than production CICS workloads
The IBM researchers found that the TPC-C differs from production CICS workloads in what they call burstiness (or large variability) of I/O activity, due to the fact that an application’s use of the I/O system varies widely. In production, there are often cases of large amounts of I/O (batch) jobs intermingled with online transaction processing workloads. The ability of mainframe systems (such as job schedulers) to take advantage of system idle time to balance a workload over a period of time is key to overall system throughput.
Despite these differences between production CICS workloads and an artificial benchmark workload such as TPC-C, we found that running the exact same COBOL application with CICS transaction APIs and SQL database statements
WinHEC 2005 Version - April 20, 2005