Closed as canceled.
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.
Recycle the REMOTE DB2 subsystem and/or Recycle DDF at the local subsystem
Reported component name
PB LIB INFO ITE
Reported component ID
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following: