PH58162: NEW FUNCTION FOR DB2 FOR Z/OS

Obtain the fix for this APAR.

APAR status

• Closed as new function.

Error description

• e9040
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All Db2 13 for z/OS users.                   *
  ****************************************************************
  * PROBLEM DESCRIPTION: Db2 utilizes storage in ECSA for the    *
  *                      IWM Work Manager and Delay Monitoring   *
  *                      Services Performance Blocks (IWMPBs)    *
  ****************************************************************
  As Db2 for z/OS is initializing, Db2 acquires a set of 1000
  IWMPBs and another set of IWMPBs based on the current MAXDBAT
  value. These control blocks are approximately 1.1KB in size
  and are allocated by WLM in the ECSA for Db2's use. The
  storage used by these WLM control blocks is not reflected in
  a Db2's thread use of ECSA.
  The purpose of these control blocks is for Db2 to reflect its
  various delays in MVS Resource Manager Facility monitoring
  capabilities while threads are performing application
  requests. Another purpose was for Db2 threads to indicate to
  WLM their delays due to bufferpool misses, so that when the
  bufferpool was defined with AUTOSIZE(YES), WLM would
  automatically request Db2 to alter the AUTOSIZEd bufferpool
  based on Db2 threads' performance goals and the number
  of bufferpool delays that WLM found had been indicated by
  those Db2 threads while accessing AUTOSIZEd bufferpools.
  However, only the following capabilities of this support has
  ever performed correctly:
  - CICS/IMS threads would have their Db2 delays monitored in
    RMF information and their bufferpool delays could trigger
    WLM bufferpool adjustments
  - DBAT server threads could only have their bufferpool delays
    triggering possible WLM bufferpool adjustments
  - all other attaching threads would not have their Db2 delays
    monitored in RMF information and their bufferpool delays
    could not trigger bufferpool adjustments
  

Problem conclusion

Temporary fix

Comments

• Db2 13 has been changed to request WLM acquire any IWMPBs
  for Db2 within the HVCOMMON area of MVS address space
  storage. These WLM control blocks will no longer reside in
  the ECSA. With these changes, ALL local attach threads as
  well as ALL distributed server threads (DBATs) will now
  have their Db2 delays monitored in RMF information and
  their bufferpool delays will now trigger WLM bufferpool
  adjustments.
  
  During DB2 initialization, Db2 will now only request the
  allocation of 250 IWMPBs. This set of IWMPBs, referred to
  as the "local attach pool", will only be used by local
  attach threads. If the request to allocate the IWMPBs fails,
  CSECT DSNVDBPM will issue message DSNL044I specifying that
  the MVS macro, IWM4MCRE, failed with the displayed return
  and reason codes. Processing of local attach threads will
  continue but local attach thread delays will not be
  reflected in the RMF Monitoring information and buffer
  pool delays will not trigger possible WLM buffer pool
  adjustments.
  
  During DDF initialization, Db2 will request the allocation
  of the minimum value of MAXDBAT and 1000 IWMPBs. If MAXDBAT
  is 0 initially, Db2 will request the allocation of 100
  IWMPBs. This "DDF" set of IWMPBs, referred to as the "DBAT
  pool", will only be used by DBATs. If the request to
  allocate the IWMPBs fails, CSECT DSNLSSST will issue
  message DSNL044I specifying that the MVS macro, IWM4MCRE,
  failed with the displayed return and reason codes.
  Processing of DBATs will continue but DBAT delays will not
  be reflected in the RMF Monitoring information and buffer
  pool delays will not trigger possible WLM buffer pool
  adjustments.
  
  During the allocation of a local attach thread to Db2, a
  preallocated "local attach pool" IWMPB is assigned to the
  thread for its use. Db2 will request the allocation of an
  additional 100 IWMPBs into the "local attach pool" as the
  number of available, preallocated, IWMPBs in the pool
  decreases due to an increase in the concurrency of the
  active local attach threads. If the request to allocate
  additional IWMPBs fails, CSECT DSNVDBPM will issue message
  DSNL044I specifying that the MVS macro, IWM4MCRE, failed
  with the displayed return and reason codes. Processing of
  local attach threads will continue but local attach thread
  delays will not be reflected in the RMF Monitoring
  information and buffer pool delays will not trigger
  possible WLM buffer pool adjustments. When a local attach
  thread deallocates, the IWMPB assigned to it will be
  returned to the "local attach pool" of available IWMPBs.
  Eventually, the total number of allocated IWMPBs in the
  "local attach pool" could reach the current value of
  CTHREAD. This "local attach pool" of IWMPBs will not be
  deleted until Db2 is stopped.
  
  During the allocation of a distributed server thread
  (DBAT), a preallocated "DBAT pool" IWMPB is assigned to
  the DBAT for its use. Db2 will request the allocation of
  an additional 100 IWMPBs into the "DBAT pool" as the number
  of available, preallocated, IWMPBs decreases due to an
  increase in the concurrency of the active DBATs. If the
  request to allocate additional IWMPBs fails, CSECT DSNLAGN2
  will issue message DSNL044I specifying that the MVS macro,
  IWM4MCRE, failed with the displayed return and reason codes.
  Processing of DBATs will continue but DBAT delays will not
  be reflected in the RMF Monitoring information and buffer
  pool delays will not trigger possible WLM buffer pool
  adjustments. When a DBAT deallocates, the IWMPB assigned to
  it will be returned to the "DBAT pool" of available IWMPBs,
  if the number of IWMPBs in the pool has not exceeded 1000.
  Otherwise, the IWMPB will be deleted. This "DBAT pool" of
  IWMPBs will not be deleted until Db2 is stopped.
  
  If you are still running z/OS 2.4, or, z/OS 2.5 and above
  without APAR OA66064 applied, delay buckets SYSP and REMT
  in the STATE SAMPLES BREAKDOWN (%) WAITING FOR block of
  the subsystem data section in the RMF WLMGL Service Class
  Period report will be switched. With APAR OA66064 applied
  to z/OS 2.5 and above, all delay buckets are correctly
  reported.
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UI98213

Modules/Macros

• DSN3CT30 DSN3CT80 DSNLAGNT DSNLCAIA DSNLCRTD DSNLCTRC DSNLDTML
  DSNLIAAC DSNLIDDC DSNLIIN2 DSNLIINI DSNLIRCA DSNLIRTR DSNLISDA
  DSNLITRM DSNLJTIN DSNLQCTL DSNLQINA DSNLSSRB DSNLSSST DSNLTACC
  DSNLTACT DSNLTSTR DSNLTZCH DSNLVAAC DSNLVCNS DSNLVDDC DSNLVRCA
  DSNLVSCA DSNLVSDA DSNLVSEA DSNLVSRC DSNTSTRT DSNTTNOT DSNVAI
  DSNVDBPM DSNVRMIM DSNVSDC0 DSNVSRRX DSNVSRX  DSNX9SPI DSNX9SPS
  DSNX9WCA DSNXECPD DSNXERD  DSNYASCP DSNYASTR
  

Fix information

• Fixed component name

  DB2 OS/390 & Z/

• Fixed component ID

  5740XYR00

Applicable component levels

• RD10 PSY UI98213

     UP24/09/06 P F409  

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.