IZ08258: UOWWAIT STATE RETURNED FOR WORKLOAD OCCURRENCE WHEN WORKLOAD OCC URRENCE IS WAITING ON LOCK

DB2 Version 9.5 Fix Pack 3b for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 1  for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 2a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 2  for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 4  for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 4a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 5 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 6a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows

APAR status

• Closed as program error.

Error description

• In the table function
  WLM_GET_SERVICE_CLASS_WORKLOAD_OCCURRENCES, the
  WORKLOAD_OCCURRENCE_STATE column can take on a value of
  "UOWWAIT" when the workload occurrence is waiting on a lock.
  This conflicts with the documentation that describes the
  UOWWAIT state as"Workload occurrence is waiting for a request
  from the client". Also, there is no "INTERRUPTED" state to
  represent the state of a workload occurrence when it is
  interrupted.
  If the APAR is not applied, a workload_occurrence_state of
  UOWWAIT could mean either that the workload occurrence is
  waiting for a request from the client or that the workload
  occurrence is waiting on a lock. Also, there is no way to
  detect that a workload occurrence has been interrupted by
  looking only at the workload_occurrence_state.
  The symptom of the first problem is seeing a
  workload_occurrence_state of "UOWWAIT" when the workload
  occurrence is waiting on a lock. The symptom of the second
  problem is not being able to see an "INTERRUPTED" state when a
  workload occurrence is interrupted.
  

Local fix

• The workaround for both problems is to make use of the
  appl_status snapshot monitor element to determine the true
  state of the application.
  

Problem summary

• UOWWAIT STATE RETURNED FOR WORKLOAD OCCURRENCE WHEN WORKLOAD OCC
  URRENCE IS WAITING ON LOCK
  

Problem conclusion

• In the table function
  WLM_GET_SERVICE_CLASS_WORKLOAD_OCCURRENCES, the
  WORKLOAD_OCCURRENCE_STATE column can take on a value of
  "UOWWAIT" when the workload occurrence is waiting on a lock.
  This conflicts with the documentation that describes the
  UOWWAIT state as"Workload occurrence is waiting for a request
  from the client". Also, there is no "INTERRUPTED" state to
  represent the state of a workload occurrence when it is
  interrupted.
  If the APAR is not applied, a workload_occurrence_state of
  UOWWAIT could mean either that the workload occurrence is
  waiting for a request from the client or that the workload
  occurrence is waiting on a lock. Also, there is no way to
  detect that a workload occurrence has been interrupted by
  looking only at the workload_occurrence_state.
  The symptom of the first problem is seeing a
  workload_occurrence_state of "UOWWAIT" when the workload
  occurrence is waiting on a lock. The symptom of the second
  problem is not being able to see an "INTERRUPTED" state when a
  workload occurrence is interrupted.
  

Temporary fix

• The workaround for both problems is to make use of the
  appl_status snapshot monitor element to determine the true
  state of the application.
  

Comments

APAR Information

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

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

Fix information

• Fixed component name

  DB2 UDB ESE AIX

• Fixed component ID

  5765F4100

Applicable component levels

• R950 PSY

     UP