PH48761: CICS JVMS hang due to a deadlock during startup

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• While enabling a JVMServer, it hangs due to a deadlock.
  One thread (CJSR task) is holding the SJGLOBAL lock while a
  another thread is trying to obtain the lock.
  CICS Joblog shows:
  DFHSJ0910 10/27/2022 10:09:38 IYCKZCHW DCTEST1 JVMSERVER JVMSRV1
   has been created.
  
  Lock Manager in the dump shows one task hold an exclusive lock
  on SJGLOBAL while a second task is waiting.
  
  IPCS "Analyze All" confirmed that the IPT x'8C2388' held the
   mutex, with the child x'8A2388' waiting for it:
  
   RESOURCE #0655:
     NAME=Mutex Object ADDR=00000056259FCDB0
  
   RESOURCE #0655 IS HELD BY:
  
    JOBNAME=CICSSC50  ASID=00EA  TCB=008C2388
     DATA=MSB ADDR: 0000005627A2DEC8 SQEL ADDR: 0000000037B94010
          CAA ADDR: 0000005548408398 USER MUTEX/CV
  
  RESOURCE #0655 IS REQUIRED BY:
  
    JOBNAME=CICSSC50  ASID=00EA  TCB=008A2388
     DATA=MSB ADDR: 0000005627A2DEC8 SQEL ADDR: 000000003AD4E010
     CAA ADDR: 00000056603FEC60
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS users                               *
  ****************************************************************
  * PROBLEM DESCRIPTION: A deadlock during startup of a JVM      *
  *                      server can prevent other JVM servers    *
  *                      from starting.                          *
  ****************************************************************
  This is an obscure timing bug.
  When a JVM server is started, the IPT thread will create a new
  thread to run the Java classes and wait. If the child thread is
  delayed, the parent thread can time out and then try to cancel
  the child thread.
  In the meantime, the child thread has successfully ran the
  initial classes and then attempted to report back to the IPT
  that it had finished.
  This gets deadlocked because the IPT can't cancel the
  child thread because pthread_mutex_lock() is not a cancellation
  point, and the child thread cannot get the mutex because the IPT
  has just re-acquired it.
  

Problem conclusion

• CICS code has been changed so if the lock is already taken, the
  attempt by the child thread to obtain the lock fails rather
  than waits.
  

Temporary fix

Comments

APAR Information

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

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

  PH50715 UI90249 UI90250

Modules/Macros

• DFHSJJS  DFHSJSC  DFJ@H356 DFJ@H467 DFJ@H468
  

Fix information

• Fixed component name

  CICS TS Z/OS V5

• Fixed component ID

  5655Y0400

Applicable component levels

• R200 PSY UI90250

     UP23/01/26 P F301

• R300 PSY UI90249

     UP23/01/26 P F301

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.