PM80092: UPDATE START(QUIECSE) COMMAND TIME OUT.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Command UPDATE DATAGRP NAME(xxx) START(QUIESCE)
  SET(TIMEOUT(300)) got time out.
  Another run works fine.
  
  When the UPDATE command with the START(QUIESCE) is issued, we
  are suppose to check the active PSTs to see if any of the PSTs
  have update intent to a quiescing database, and if so, that
  there are no uncommitted updates prior to allowing the QUIESCE
  to process.  In one path we simply check if the PST is in the
  middle of a DL/I call, and if so we WAIT the QUIESCE command
  even if the PST does not have uncommitted updates.  If the
  command is re-issued, the QUIESCE will work OK because of the
  timing and the DL/I call has completed.
  

Local fix

• N/A.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All IMS V12 Database Quiesce ( DBQ ) user    *
  *                 who issue the UPDATE DB command with         *
  *                 the START(QUIESCE) option.                   *
  ****************************************************************
  * PROBLEM DESCRIPTION: UPDATE DB START(QUIESCE) command hangs  *
  *                      and/or times out.                       *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  When the UPDATE command with the START(QUIESCE) option is
  issued, a check of all the active PSTs is suppose to be made
  to determine if any of the PSTs have uncommitted updates to the
  database that is being quiesced or if the PST uses a PSB that
  references the DB and the PST is in a DL/I call.  If either of
  the cases is true, the DB QUIESCE must wait for the PST to
  complete commit.  For the case where the PST has no uncommitted
  updates, but is in a DL/I call, the DB QUIECSE is forced to
  wait even if the PST does not have update intent on the DB
  being quiesced.  An unconditional branch at label QDQ70000 to
  label QDQDCALL was taken where a check to determine if the PST
  is in a DL/I call is made without first checking if the PST
  actually has update intent on the DB.  When the PST was in
  a DL/I call, the DB QUIESCE was forced to wait incorrectly,
  causing the UPDATE command to time out.
  

Problem conclusion

• GEN:
  KEYWORDS:
  
  *** END IMS KEYWORDS ***
  The following module has been modified to correct the reported
  problem:
  
  ************
  * DFSDBQ40 *
  ************
  New flag bit QTW3UINT has been added in flag byte QTW3 to
  indicate whether or not the PST has update intent on the
  database being quiesced.
  Code was added to set new flag bit QTW3UINT when the PST
  has update intent on the database being quiesced.  The
  flag is checked after label QDQDCALL prior to checking if
  PSTQDLIC to determine if the PST is in a DL/I call.  If both
  QTW3UINT and PSTQDLIC are set, the DB quiesce will wait until
  the PST reaches commit.  If both flag bits are not set, the
  DB quiesce process will be allowed to continue without waiting
  for commit.
  

Temporary fix

Comments

APAR Information

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

  PM79746

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

  UK91480

Modules/Macros

•    DFSDBQ40
  

Fix information

• Fixed component name

  IMS V12

• Fixed component ID

  5635A0300

Applicable component levels

• R200 PSY UK91480

     UP13/02/14 P F302

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.