1. Run BUILDPDB with normal MXG defaults
2. Run BUILDPDB but suppress processing of CICS records
3. Run BUILDPDB but suppress processing of DB2 records
4. Run BUILDPDB but suppress processing of TYPE 74
5. Run BUILDPDB but suppress processing of DB2 and CICS
6. Run BUILDPDB but suppress processing of DB2 CICS and TYPE 74
7. Run BUILDPDB but suppress DB2ACCT
8. Run BUILDPDB but suppress CICSTRAN DB2ACCT
9. Extract one hour of CICSTRAN and DB2 data.
Test 9 will come into play later. The results of the testing in Figure 3 showed that:
• The bulk of the CPU time was being consumed by DB2ACCT (type 101 records).
• Processing of CICS transaction data wasn’t a major factor.
• Type 74 data wasn’t an issue—though in a larger environment with more than a single large Redundant Array of Inexpensive Disk (RAID) box, processing type 74 data can become onerous.
For this shop, processing type 101 and type 110 subtype 1 records in separate jobs would yield the best throughput and earliest completion of the daily jobs. But is that the best answer? Do we really need to process all that data daily or do we have options?
Thirty years ago, there was often a time in the wee hours of the morning when none of this would have mattered. The system was effectively idle between the end of the batch cycle and when the online activity began in the morning. However, in today’s world of non-stop availability with transactions coming in from around the globe, that window of opportunity has usually vanished. Reducing the system resources required for SMF processing may be critical. In the eyes of some management, it’s pure overhead.
Consider the three data types again:
• Tactical. When there are problems in DB2 or CICS, the data may be critical in finding and resolving those issues. But if a problem lasted for 15 minutes, do we need the data for the entire 24 hours or do we just need the time before, during, and after the problem? Test 9 showed that we can quickly extract the data for a one-hour period when necessary.
• Strategic. Certainly we need to keep track of DB2 and CICS transaction volumes, response time, and consumption for long-term trending. But do we need the detail data to do that or can we find another way?
• Accounting. If we’re doing detailed chargeback, it may be required that all data be processed and retained for some period. There can also be legal requirements if there’s outsourcing; only your DP auditors know for sure and there’s a good chance that if you ask, the answer will be the ever-popular but impractical “forever.” Changes in technology and the volatility of storage devices may preclude forever, but five to seven years isn’t uncommon.
The two types of transactions most problematic are Distributed Data Facility (DDF) and CICS. If we can find a way to fulfill most of the reporting/accounting needs without processing the millions of detail records, a substantial amount of system time and resources can be saved. When that processing is eliminated, the post-processing of SMF data goes back to being noise in the system.
So, what’s possible?
For DB2, there are multiple types of transactions: CICS, BATCH, DDF, and so on. In many shops, the dominant workload is rapidly becoming DDF transactions. If we know enough about the transactions, Workload Manager (WLM) will let us classify the workload based on information contained in the headers of the accounting records. Then, using a report class, we can gather the information needed to satisfy reporting needs from the Resource Management Facility (RMF) type 72 data.