II14405: DB2 HANGS, THREAD HANGS DUE TO VTAM HANG

APAR status

• Closed as canceled.

Error description

• 5740XYR00 DB2DDF DB2SNA
  Defects: 00193_228_631 d00193_228_631
             00276_228_631 d00276_228_631
             17368_004_000 d17368_004_000
             57296_228_631 d57296_228_631
  The purpose of this Informational APAR is to help DB2 L2
  identify a hang condition in the DB2 distributed environment
  that can be caused by the VTAM error described by APAR OA23264.
  If this APAR is not installed, it should be installed as soon
  as possible because the error can result in many unpredictable
  symptoms, typically hangs, that are difficult to diagnose.  It
  is important that this APAR be installed on any z/OS system,
  local or remote, that may be involved.
  .
  Some external symptoms include:
  DB2 applications hang, DB2 threads hang, and some customer
  reported SQLCODE -904 returned to their applications.  Some
  customers have pointed out that the VTAM (SNA) communication
  between two DB2 subsystems hang.  Some customers may say that
  their DB2 appears hung.
  .
  The ultimate cause is that a DB2 thread, typically a DB2 system
  related thread, will hang indefinitely in a VTAM Deallocate
  call (DEALLOC ABNDUSER) after the DB2 thread incorrectly
  receives RCPRI/RCSEC (PRImary Return Code/SECondary Return Code)
  002C/0002 on a VTAM Receive.  So it's not only important to
  determine the DB2 thread that is hung in a VTAM deallocate call,
  but it's also important to determine what happened on the prior
  VTAM call (typically an Asynchronous Receive).  If the prior
  VTAM call resulted in an RCPRI/RCSEC 002C/0002, then the VTAM
  error described in APAR OA23264 may be the likely root cause.
  The DB2 LITR associated with the thread should identify the most
  recent activity.
  Look for evidence where a VTAM call, typically Async RECV,
  receives primary/secondary return code of 002C/0002
    RCPRI RPL6RCPR 002C RCPRI002C RPL6RCPR002C USF6PARM with
    RCSEC RPL6RCSC 0002 RCSEC0002 RPL6RCSC0002 USF6IVCI
  which is then followed by a VTAM DEALLOC ABNDUSER 08640000 that
  appears to hang indefinitely.
  .
  BYPASS:
  The problem can possibly be bypassed by recycling the REMOTE
  subsystem (the server subsystem), and/or by recycling DDF at
  the local subsystem.
  Issue the following commands in sequential order:
    -STOP DDF MODE(QUIESCE), wait 3 minutes
    -STOP DDF MODE(FORCE), wait 3 minutes for the operation to
     complete
    -START DDF
  Diagnostic information:
  The DB2 "DISPLAY LOCATION(*) DETAIL" and/or "DISPLAY THREAD(*)
  DETAIL" commands may help in identifying the multiple DB2 z/OS
  subsystems involved in the condition.  Console dumps should be
  obtained from all suspected DB2 subsystem environments.  Ensure
  that all DB2 address spaces, and the VTAM address space, are
  included in each console dump.
  For example:
    DUMP COMM=(ssnm DUMP)
    n,JOBNAME=(ssnmMSTR,ssnmDIST,ssnmDBM1,ssnmIRLM,VTAMxxxx),CONT
    n,SDATA=(RGN,CSA,LSQA,SQA,PSA,SWA,LPA,TRT,GRSQ,SUM,ALLNUC),END
    where ssnm is the DB2 subsystem name.
    .
    To ensure maxspace size is large enough, issue
      CD SET,SDUMP MAXSPACE 5000M
    and please also ensure the dump data set (SYS1.DUMPxx) is
  large enough.
  Please engage VTAM support to get instructions on the diagnostic
  information that may be required to diagnose the condition from
  a VTAM perspective.
  

Local fix

• Recycle the REMOTE DB2 subsystem
  and/or
    Recycle DDF at the local subsystem
  

Problem summary

Problem conclusion

Temporary fix

Comments

• Informational APAR
  

APAR Information

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

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

Fix information

Applicable component levels