PH48358: TASK SUSPENDED WITH A TIMEOUT INTERVAL DOES NOT WAKE UP WHEN THE TIMEOUT INTERVAL EXPIRES.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• You have a task that is suspended with a timeout interval.  It
  does not resume when the timeout interval expires.
  
  This problem happens when the task has already been purged or
  forcepurged once using the CEKL transaction, and then it is
  purged or forcepurged again using the CEKL transaction, while
  the task is in a suspend with a timeout interval specified.
  
  Here are some examples of what would cause a task to be
  suspended with a timeout interval:
  1) You have a transaction defined with a DTIMOUT interval and
  SPURGE(YES). When that transaction suspends to wait on something
  DTIMOUTable (like Storage, a String, an MRO link, etc), it will
  suspend with a timeout interval.
  2) A program using the DFHDSSRX XPI call for SUSPEND or WAIT_MVS
  specifies an INTERVAL on that call.
  3) An RTIMOUT specified on the PROFILE of a TRANSACTION can
  result in a suspend with a timeout interval when a task waits
  for input from the principle facility.
  
  Here is an example flow of how this problem would take shape:
  1) Task 12345 is running too long and it is purged with a:  /f
  cicsjob,CEKL SET TASK(12345) FORCEPURGE
  2) That purge initiates an abend of task 12345.
  
  3) During abend processing, perhaps during the taking of a
  transaction dump, the task suspends with an interval specified.
  4) While in that suspend with interval, the task is purged again
  with a: /f cicsjob,CEKL SET TASK(12345) FORCEPURGE
  5) The 2nd purge does not force the task out of its suspend.
  And when the suspend timeout interval is reached, the task is
  not made active again.  The task remains suspended well passed
  the timeout time.
  6) Note that the task can still be purged or forcepurged by
  CEMT.  It is just a CEKL purge or forcepurge that is affected by
  this problem.
  
  In a dump taken later, you will find the task in a suspend.  In
  the 'DS=1' formatter, the task will have a Timeout Time that has
  long since passed.  (Note the times shown by the 'DS=1'
  formatter are in UTC, not Local.)  The DTA for this task will
  have the kill_cekl_purge_requested bit on  (this is the x'80'
  bit at +x'A2' into the DTA), or the
  kill_cekl_force_purge_requested bit on (this is the x'40' bit at
  +x'A2' into the DTA).
  
  Additional Symptoms:   ABWAIT02
  

Local fix

• Do not use CEKL to purge a task twice. Purge the task using
  CEMT.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS Users.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: A transaction is suspended with a       *
  *                      timeout interval.CEKL is used to purge  *
  *                      the transaction. The transaction enters *
  *                      another wait but never times out and    *
  *                      resumes from the suspend.               *
  *                                                              *
  ****************************************************************
  A transaction is suspended with a timeout interval on a DFHDSSRX
  XPI call from a GLUE. CEKL is used to purge the transaction.
  DFHDSDS3 routine check_executables sees the AKKD deferred abend
  for the CEKL purge of the transaction. It sets flag
  kill_cekl_purge_requested in the TAS for the transaction.
  The purge is then actioned and the transaction is redispatched.
  The GLUE disregards this purged response and issued another
  WAIT_MVS call.Since the kill_cekl_purge_requested flag remains
  set on in the TAS, this prevents subsequent CEKL purge attempts
  being actioned by check_executables. It also prevents the
  WAIT_MVS from timing out normally.
  
  Another variation of the problem is seen if a CEKL purge is
  issued against a transaction that is in a wait that is purge
  protected, such as in phase 2 of syncpoint. This purge is
  validly rejected but the transaction is left in a state that
  will never time out and resume from its suspend.
  

Problem conclusion

• DFHDSDS3 has been changed to drive the purge if an abend has
  been deferred and the corresponding CEKL flag is not yet on.
  
  DFHDSTCB has been changed to set kill_cekl_purge_requested
  and associated forcepurge and kill flags off before issuing the
  PUSH_TASK call to redispatch a transaction.
  

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:

  PH48500 UI82211 UI82212

Modules/Macros

• DFHDSDS3 DFHDSTCB
  

Fix information

• Fixed component name

  CICS TS Z/OS V5

• Fixed component ID

  5655Y0400

Applicable component levels

• R200 PSY UI82212

     UP22/09/02 P F209 ¢

• R300 PSY UI82211

     UP22/09/10 P F209 ¢

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.