We have had several questions lately around z/OS 1.12 and the performance benefits seen by DB2.
A customer of mine first saw a performance degradation with z/OS 1.12 and DB2 9 with a DGTT that had many indexes defined on it. Basically any query that created and dropped many temporary objects could see a CPU increase.
PM17542 was created to avoid this overhead. Unfortunately it was marked P.E., or PTF in error and several z/OS and DB2 APARs were to follow.
Today we are back with a positive story as described in PM46045 which also summarizes the APARs that should be applied to see a performance benefit in DB2.
- PM17542 – z/OS 1.12 performance enhancement for dataset open/close
- PM46045 - summarizes changes to SMF and PARMLIB settings
- APARs interactions: The following summarizes the interactions of DB2 APARs PM17542, PM46045, and z/OS APARs OA36101, OA37361, and OA37362. It is intended to help you determine when to apply DB2 and z/OS APARs, and in what order.
- 1. PM17542 only - exposed to overlay and missing SMF I/O counting at address space level. MEMDSENQMGMT irrelevent.
- 2. PM17542 with OA36101 - exposed to missing SMF I/O counting at address space level only. MEMDSENQMGMT irrelevent.
- 3. PM17542 with OA36101, OA37361 & OA37362 - no longer exposed to either problem.
- 4. PM17542 with PM46045 - S99DASUP setting now only turned on when MEMDSENQMGMT is enabled. Exposed to overlay and missing SMF I/O counting at address space level ONLY when MEMDSENQMGMT is ENABLED.
- 5. PM17542 with PM46045 & OA36101 - S99DASUP setting now only turned on when MEMDSENQMGMT is enabled. Exposed to missing SMF I/O counting at address space level ONLY when MEMDSENQMGMT is ENABLED.
- 6. PM17542 with PM46045, OA36101, OA37361 & OA37362 - no longer exposed to either problem. Performance benefits for both features introduced with PM17542 only available when MEMDSENQMGMT is ENABLED.