PH21012: JVM SERVER LEFT IN INCONSISTENT STATE AFTER RUNAWAY CONDITION

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• You received the following message in the region
  log:
  
  DFHSJ1009 W 01/01/2020 13:37:56 JVMSERVER XXXXXXXX IS
  BEING DISABLED AND RESTARTED BY CICS BECAUSE A TASK RUNNING IN
  A JVMSERVER HAS TRIGGERED A RUNAWAY CONDITION, LEAVING THE
  JVMSERVER IN AN INCONSISTENT STATE.
  DFHSJ0918 01/01/2020
  13:37:59 JVMSERVER XXXXXXXX IS BEING DISABLED DUE TO A PHASEOUT
  REQUEST.
  
  Your JVM server then remains in a disabling PHASEOUT
  state for a significant amount of time. Your JVM server is not
  disabled and enabled again until after the following message is
  seen in the region log:
  
  DFHSJ0918 01/01/2020 20:37:50
  JVMSERVER XXXXXXXX IS BEING DISABLED DUE TO A PURGE REQUEST.
  
  
  The message(s) following the purge request may be AKC3
  abends. After this point the JVM server is enabled and ready
  for use.
  
  The transaction you have configured to run in the
  JVM may be an intentionally long running transaction with a
  RUNAWAY value configured.
  
  When a task running Java
  experiences a runaway interval condition, the JVMSERVER
  intercepts the condition and triggers a DISABLE PHASEOUT. New
  work is prevented from entering the JVM and existing work is
  left to drain. Subsequently, should the task complete its
  processing, the JVMSERVER re-enables and becomes available for
  new requests. In many cases if a task running Java exceeds the
  runaway interval value, it is likely to be a bad application,
  such as a tightly looping application and prevents successful
  PHASEOUT/RECYCLE of the JVMSERVER. When an application is
  detected, the runaway timer triggers again after another
  interval and the JVMSERVER DISABLE PHASEOUT is escalated to a
  JVMSERVER DISABLE PURGE. Remaining tasks are subject to PURGE
  processing and in most cases are terminated. If further runaway
  intervals are exceeded, the JVMSERVER DISABLE escalates to
  FORCEPURGE and ultimately KILL - until all running tasks are
  forcefully terminated. The JVMSERVER recycles back to the
  ENABLED state ready for new requests. If the JVMSERVER had to
  escalate as far as a DISABLE KILL request, it is prudent to
  recycle CICS at the earliest opportunity.
  
  When a task runs in
  a JVM and triggers a RUNAWAY condition, the task is not purged,
  but rather the state of the JVM itself is affected. The task is
  left alone while the state of the JVM changes in an attempt to
  allow the transaction to resolve itself without harming other
  work that is running on the same JVM.
  
  This behavior may not
  be desirable for an intentionally long running transaction.
  

Local fix

• For an intentionally long running transaction running in a JVM,
  consider increasing the RUNAWAY limit of the transaction: https:
  //www.ibm.com/support/knowledgecenter/en/SSGMCP_5.2.0/com.ibm.ci
  cs.ts.resourcedefinition.doc/resources/transaction/dfha4_attribu
  tes.html
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS Users.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: JVMSERVER left in being disabled after  *
  *                      a runaway task has been detected.       *
  ****************************************************************
  A long running task in a JVMSERVER triggers a runaway condition
  and then continues without triggering another one.
  Due to the runaway condition the JVMSERVER will have been called
  to DISABLE with the PHASEOUT option. However because the long
  running task is still in the system the JVMSERVER remains in a
  disabling state. This remains the case until the long running
  task ends, or there is manual intervention or another runaway
  condition is encountered.
  
  JVMSERVER runaway relies on the task triggering subsequent
  runaway conditions to escalate the PHASEOUT call up through
  PURGE, FORCEPURGE and KILL.
  

Problem conclusion

• CICS has been changed to escalate JVMSERVER disable after a
  runaway condition is detected to ensure the JVMSERVER is
  recycled.
  
  The JVMSERVER option PURGE_ESCALATION_TIMEOUT can be used to
  configure the escalation interval. After each timeout CICS
  escalates to the next disable action.
  

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:

  UI70712 UI70713 UI70714 UI70715

Modules/Macros

• DFHSJJS
  

Fix information

• Fixed component name

  CICS TS Z/OS V5

• Fixed component ID

  5655Y0400

Applicable component levels

• R000 PSY UI70712

     UP20/07/25 P F007

• R100 PSY UI70713

     UP20/07/24 P F007

• R200 PSY UI70714

     UP20/07/24 P F007

• R300 PSY UI70715

     UP20/07/24 P F007

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.