PH52902: CICS POLICY USER TASK RULE WITH CPULIMIT 90 SECONDS DOES NOT DETECT THE LOOPING TASK.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• CICS TS 5.6
  A user application program which includes PL/I application
  program went into yeilding loop in CICS.
  Our customer was initially asking why SET TASK PURGE and
  FORCEPURGE didn't work for the looping task.
  It turns out that their PL/I application handles
  the abend AKC3 (PURGE)  and allows the looping
  task to continue.
  The next question was why doesn't the CPULIMIT user task rule
  step in to abend the looping task ?
  The CPULIMT threshold was 90 Seconds and the user task had used
  10 minutes 58 seconds in the dump.
  IP VERBX DFHPD730 'MP=3'
   MP domain shows for this task that the CPU count is
   10 mins 58 seconds which is way above the 90 second threshold
  ITEM#     COUNT            THRESHOLD
  024       00000000274392DD 00000000055D4A80
  274392DD = 10 mins 58 secs.
  55D4A80  = 90 Secs
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS users                               *
  ****************************************************************
  * PROBLEM DESCRIPTION: Policy task rule for CPU limit fails    *
  *                      to detect a looping transaction.        *
  ****************************************************************
  The customer deployed a policy task rule to abend a transaction
  if excessive CPU was being consumed.
    A transaction invoked a COBOL program, which then EXEC CICS
  LINKed to a PL1 program. The PL1 program set up a natural
  language on error routine, to handle abends and program checks.
    When the PL1 program later suspended, a purge was issued to
  abend it. The recovery routine was driven and control returned
  to the handle label and from there back to the COBOL program.
    As part of the abend processing for the purge, DFHABAB had
  disabled policy checking for the transaction to avoid potential
  further abends while abending.
    The COBOL program then entered a yielding loop back through
  CICS (and the dispatcher), but consumed considerable CPU before
  driving this each time. After a while, the policy should have
  been implemented and CICS abend the task AMPB. However, this
  never happened as CICS had disabled policy checking in DFHABAB,
  and since an EXEC CICS HANDLE was not used to recover from the
  abend, the code in DFHEIP to reenable policy checking was never
  executed in this case.
  

Problem conclusion

• DFHAPLI1 has been changed to issue DFHMPTAB FUNCTION=CLRABEND
  before returning control to the recovery routine. This reenables
  policy checking for the transaction.
  

Temporary fix

Comments

APAR Information

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

  PH52880

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

  UI91553

Modules/Macros

• DFHAPLI1 DFHAPLJ1 DFHAPLX1
  

Fix information

• Fixed component name

  CICS TS Z/OS V6

• Fixed component ID

  5655YA100

Applicable component levels

• R400 PSY UI91553

     UP23/04/26 P F304

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.