1.  Cheryl Watson’s Tuning Letter 2008 No. 2
2.  SMF Results
3.  New IBM Red Alert for DB2

1.  Cheryl Watson’s Tuning Letter 2008 No. 2

The fifty-eight page 2008 No. 2 Tuning Letter was emailed to subscribers on May 23.  You may visit our Web site at http://www.watsonwalker.comto obtain single issues for $155 each.  The following is a summary of just some of the contents of this latest Tuning Letter:

IBM Announcements
On February 26th, IBM made two important announcements.  The first was their announcement (#108-154) of the newest System z processor, the z10, which became available that day.  And the second was their expected announcement (#208-042) of z/OS 1.10, which won’t be available until September 2008.  We’ll be covering a lot more about both announcements in upcoming Tuning Letters.

In this issue, as in our most recent CPU Chart, I cover the performance aspects of the new z10, and how you need to re-evaluate your MIPS basis.  With a CPU speed that is 2.5 times faster than a z9, the z10 can provide a 60%+ increase in capacity.  The bigger CPs provide more challenges, however.  If you want to add a CP, you’ll be adding about 100 MSUs, which can increase software costs by hundreds of thousands of dollars.  You’ll want to investigate other pricing options such as VWLC (Variable Workload License Charge).

Important Topics
My major article this issue is on SMF and covers buffer size, initial results of my SMF survey, SMF intervals and synchronization (a change in my recommendations), some neat information from Barry Merrill, and a first look at the z/OS 1.9 SMF Logger.  The SMF Logger, which became available with z/OS 1.9, provides many benefits over the SYS1.MANx data sets, especially for large data centers.  But there is still some development work needed before it’s really production ready.  •  Our second article on z/OS Performance shows the results of IBM’s benchmarks for moving from z/OS 1.8 to z/OS 1.9.  z/OS 1.9 actually takes less CPU time than 1.8.  The Large Memory study shows an example of reducing CPU time by 30% and elapsed time by 64%.  That’s certainly worth assigning more memory!  •  Based on feedback from our readers and our observations at SHARE, there are more people new to z/OS than ever before.  So I’ve started a new, continuing column called z/OS 101 that will provide some basics for those new to the field. • And this newsletter covers some important items from SHARE.  I think that the section on the future of IBM documentation (Library Server) shows that it’s a significant evolution (replacing BookManager with html and searchable documents organized as topics and tasks).  I love it!  It may take awhile for IBM to migrate everything over, but I’m excited about its future.

News
There are thousands of APARs, but we pick and review the ones that we think are most important related to z/OS performance.  This News section is very extensive because of the large number of APARs reviewed (over 60).  These include New Function APARs that might not be on anyone’s radar, yet provide great performance improvements.  There are also several HIPER and performance APARs that can impact the amount of effective MIPS.  You may not want to wait for these to show up in standard maintenance.  If you haven’t been keeping up with our emails of Cheryl’s List, be sure to review the APARs mentioned in those lists as well.

2.  SMF Results

As I mentioned in previous Cheryl’s Lists, I started collecting SMF statistics in order to determine the volume of SMF data that might be processed by the new SMF Logger.  Thanks to the many people who sent me copies of the report output from their SMF dumps.  While we now have a handle on the SMF volumes, I found so many interesting things that I’m expanding my SMF analysis.  Because the information has come from Cheryl’s List readers and SHARE attendees, in addition to our newsletter subscribers, I’ll be making the results public in this list.  Here are some of the interesting things that I’ve found so far.  Please note that this is just a rough analysis, and the data represents single LPARs for a 24-hour period.

  • Volume – the great majority of LPARs analyzed produced less than 1MB per second of SMF data.  One LPAR produced about 2.2MB/second during a peak period, and a few produced about 1MB/second during a peak period.  IBM tests on SMF Logger were run at up to 10 MB/second on 2105 DASD.
  • Number of Records – Roughly one-third of the LPARs produced less than a million records per day; another third produced between 1 million and 10 million records per day; and the other third produced over 10 million records per day, with many of these in the 30-65 million range.
  • Record Size – For installations that don’t collect DB2 data, the average SMF record size is about 1000 bytes, while those that collect a lot of DB2 data produce average record sizes of around 2000 bytes.  I saw one installation with an average LRECL of 4,500 bytes.  That was due to a large volume of records that can be 20K to 30K in size:  SMF 30 (batch) and CICS 110 records.
  • DB2 Type 102 – Most installations do not collect DB2 type 102 records.  Those that do typically see that the 102 records produce between 70% and 85% of the total number of SMF records.
  • Intervals – The majority of installations collected RMF data at 15 minute intervals; many used an interval of 10 minutes; and a few used an interval of 30 minutes.  Without seeing the SMFPRMxx members, I couldn’t tell what the typical SMF interval was set to, but I suspect that it was 30 minutes, which is the IBM default.

I found this rough analysis very interesting, and plan to do a much more thorough review after I receive more input.  Thanks so much for your help.

3.  New IBM Red Alert for DB2

On June 17th, IBM issued a new Red Alert for the following item:
DB2 for z/OS V8 and V9 potential loss of data during update of fixed length rows.

A defect was introduced by APAR PK63401.  If either PTF UK35464 or UK35465 is applied, then a potential loss of data can occur in a DB2 V8 or DB2 V9 environment.  The loss may occur in a fixed length row update where the length of updated data is greater than 256 bytes.  A fixed length table is one that does not contain any VARCHAR, LONG VARCHAR or ROWID columns.  The exposure exists only if subject table space or partition is not compressed, and no EDIT procedures exist on the table.  APAR PK66997 has been created to resolve this problem.  Please refer to the APAR text for further details.

You can view all of the Red Alerts at https://www14.software.ibm.com/webapp/set2/sas/f/redAlerts/home.html.

Stay Tuned!