Game Changer for z/OS Transaction Reporting

Periodically, a change comes to an industry that introduces a completely new and improved way to accomplish an existing task that had previously been difficult, if not daunting. Netflix transformed the home movie viewing industry by offering video streaming that was convenient, affordable, and technically feasible – a change so far-reaching that it ultimately led to the closing of thousands of Blockbuster stores. We feel that IBM recently introduced a similar “game changer” for transaction reporting for CICS, IMS and DB2.

Obtaining key metrics for CICS, DB2, and IMS transactions has historically required processing massive volumes, often hundreds of millions or more, of SMF 110 records for CICS, SMF 101 records for DB2, and subsystem log records for IMS. Extracting, transmitting, and processing these enormous volumes of records has typically been a very CPU-intensive and thus expensive task, requiring many hours of elapsed time. Often, sites have been required to design special processes to ensure that the processing of the previous day’s records can be completed by the end of the current day, to avoid falling hopelessly behind. And even then, results of the previous day’s processing are not available to the performance analyst until relatively late in the business day.

Superior Solution to Obtaining Key Transaction Metrics

Perhaps unexpectedly, IBM’s introduction of workload manager (WLM) support for Mobile Workload Pricing (MWP) offers the prospect of a far more streamlined solution to obtaining key transaction metrics. I say unexpectedly because this outcome has nothing to do with participation in IBM’s MWP program and tracking mobile transactions. The WLM support implemented by IBM to enable the tracking of mobile CPU consumption has provided the very welcome “side effect” of enabling the tracking of CPU consumption for any transaction.

This tracking occurs in the RMF type 72 records and takes place at the service class or report class level. Sites can begin taking advantage of this capability by mapping transactions of interest into a set of report classes using the wide range of classification methods available in WLM. This mapping of transactions into report classes can be as granular as needed to meet the requirements at any site.

From A Hundred Million Records to Only Ten Thousand

Even if this mapping would result in many new report classes, the number of RMF records to be processed would still be a tiny fraction of the 110/101/Log transaction level records. To use an example, if one hundred separate report classes were created to map transactions, and a site uses a 15-minute RMF interval, this would generate up to 9,600 RMF type 72 records per day – less than ten thousand, compared to the likely tens or hundreds of millions of transaction level records.

Many of the widely-used transaction level metrics are available in the RMF 72 records, including transaction rate and response time, average concurrent transactions, CPU and I/O per transaction, and total CPU and I/O activity. Support for populating some of the metrics, including CPU and I/O per transaction, is provided at these software levels: z/OS 2.1 with OA47042; CICS 5.3; IMS 14 with PI46933 and PI51948.

“One of the most exciting new capabilities to come along in some time.”

I am far from being alone in considering this to be a very significant and positive advance in the z/OS performance arena. In a recent conference presentation, IBM Distinguished Engineer Kathy Walsh said she considered this to be one of the most exciting new capabilities to come along in some time. This IBM Redbook provides more details on this great new functionality.

Sites may have a requirement to continue to process some or all of their 110/101/Log transaction level records, on an ongoing or exception basis, to obtain the comprehensive subsystem-specific metrics provided there, e.g. CICS file I/O wait time. But in many environments, the ongoing transaction reporting requirements for the performance analyst and charge-back communities are likely to be satisfied by the data available in the RMF 72 records.

IntelliMagic Vision for z/OS Systems will support these transaction metrics provided in the RMF type 72 records in version 8.10 which will be generally available in March 2017. A sample report of transaction rates by service class appears below.

You can find more information about how IntelliMagic Vision shows key transaction metrics at intellimagic.com/transactions.

If you would like to see a demo of how IntelliMagic Vision has implemented transaction reporting from the type 72 records, this short video provides a demonstration.