PH55794: CPSM AICA ABEND METHOD EYU0WNAL. GOAL MODE IN USE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• You are using CPSM WLM to manage routing of transactions in your
  CICSplex. You have selected GOAL mode for your routing
  algorithm, and experience an AICA abend (CICS purging task for
  runaway situation.) CPSM intercepts and produces an SVC dump
  with messages in the job output similar to the following:
  
  EYUXL0900I Starting Environment Recovery
  EYUXL0905E applid AICA IN WNAL, OFFSET 00000800
             PSW=078D5000 AB173948 LEVEL=UI77845 PFX=CJJ
  EYUXL0905E INTC=000B ILC=2 TXCP=2740C800 SCODE=S???? TRAN=abcd
             TASK=0012345
  EYUXL0905E Methods=WNAL,WASV,WDTR,XLOP
  EYUXL0905E BEAR=00000000, OFFSET=????????
  
  CPSM also produces a list of registers at the time of the error
  under the message number EYUXL0907I. In that output, GPR0
  (Register 0) may have a very large number, with the high order
  bit turned on. This is actually a negative number, and what has
  led to the looping condition.
  Additional Symptom(s) Search Keyword(s): KIXREVPAD
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICSPlex SM Users using percentile GOAL  *
  *                 mode.                                        *
  ****************************************************************
  * PROBLEM DESCRIPTION: When running a workload in percentile   *
  *                      goal mode you can experience abend      *
  *                      AICAs or excessive CPU utilisation in   *
  *                      multiple MASes.                         *
  *                                                              *
  *                      EYUXL0905E applid AICA IN WNAL,         *
  *                                 OFFSET 00000800              *
  *                                 PSW=078D5000 AB173948        *
  *                                 LEVEL=UI77845 PFX=CJJ        *
  *                      EYUXL0905E INTC=000B ILC=2              *
  *                                 TXCP=2740C800 SCODE=S????    *
  *                                 TRAN=abcd                    *
  *                                 TASK=0012345                 *
  ****************************************************************
  * RECOMMENDATION: Apply the fix to all CMASes & MASes.         *
  *                 This can be done in any order.               *
  ****************************************************************
  New, more efficient, floating point logic was used at V5R6M0
  when processing transaction response times. However this allowed
  some negative results to be produced for tasks with a response
  time between 35 and 71 minutes.
  This was unexpected and later code could not cope with negative
  values leading to high CPU usage and AICA abends.
  

Problem conclusion

• At route terminate for a transaction, EYU0WDIN running in the
  routing region adds the transaction response time, held as a
  TOD delta value, to the cumulative response times of all
  transactions held in WGSC_CUR_TRESP. During the calculation the
  transaction response TOD value is held in a 32bit GPR in
  microseconds, allowing a maximum value of 71mins.
  
  The EYUQWCNV MAKEFL macro, changed at v5.6, treats this as a
  32bit signed number so times between 35 and 71 minutes are
  converted to negative floating point values.
  
  Every 10 seconds EYU0WMSC, in the CMAS, summarises this data.
  There are several places where it can't cope with negative
  values. The issues start with WGSC_PI being negative and leads
  to other fields being negative too, including WSGC_PCTAORS.
  
  Subsequent route select requests have problems in
  EYU0WNAL. WSGC_PCTAORS becomes TDA_SCOPE_PERCENT in EYU0WTCL.
  Because TDA_SCOPE_PERCENT is negative the EYU0WNAL code assumes
  that not positive equals zero and some initialisation is not
  performed.WCEC_BEST_COUNT is not initialised and is then used
  as the counter in a BCT R1 loop at SET_BEST_SIGNIFY. This causes
  a large amount of CPU to be consumed or an abend AICA to happen,
  depending on the ICVR value.
  
  This was resolved by using the 64 bit macro EYUQWCNV MAKEFLG
  instead of the 32 bit version, EYUQWCNV MAKEFL, in EYU0WDIN.
  We now never get a negative value and the existing logic works
  as expected.
  

Temporary fix

Comments

APAR Information

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

  PH55404

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

  UI92962

Modules/Macros

• EYU0WDIN EYU0WMSC
  

Fix information

• Fixed component name

  CICS TS Z/OS V6

• Fixed component ID

  5655YA100

Applicable component levels

• R40M PSY UI92962

     UP23/08/02 P F308

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.