PK07518: SLOW PERFORMANCE BAS ADD CICSSYS TO CICSGRP ALIAS CHECKING

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Performance is very slow when adding a CICSSYS to a CICSGRP
  in a large BAS environment .  Alias checking for transactions ,
  programs, transient data queues and temporary storage for
  remote definitions can result in runtimes of several minutes
  and high cpu utilization in the CMAS address space.
  .
  Additional Symptom(s) Search Keyword(s): TRANDEF PROGDEF
  TDQDEF TSMDEF
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICSPlex/SM V3R1M0 Users                 *
  ****************************************************************
  * PROBLEM DESCRIPTION: Excessive response times may occur when *
  *                      the EUI, API, WUI, or BATCHREP is used  *
  *                      to modify Topology or BAS definitions   *
  *                      which cause FILE, PROGRAM, TDQ, or      *
  *                      TRANSACTION resources to be associated  *
  *                      with a CICS region.                     *
  *                                                              *
  *                      For example:                            *
  *                                                              *
  *                      -  adding a FILEDEF, PROGDEF, TDQDEF,   *
  *                         or TRANDEF to a RESGROUP.            *
  *                                                              *
  *                      -  adding an association between a      *
  *                         RASGNDEF and a RESDESC.              *
  *                                                              *
  *                      -  adding an association between a CICS *
  *                         system and a CICS system group.      *
  ****************************************************************
  * RECOMMENDATION: After applying the PTF that resolves this    *
  *                 APAR, all CMASes must be restarted.  Note    *
  *                 that the restarts do not need to occur at    *
  *                 the same time.                               *
  ****************************************************************
  When a Topology or BAS definition change causes a CICS resource
  to be associated with a CICS system, the BAS component in the
  maintenance point (MP) CMAS of the CICSplex the definitions are
  associated with must perform checking to ensure that the
  candidate association does not conflict with an existing
  association.  To do this, method EYU0BMRA (BMRA) compares each
  candidate association against the BAS install list, which
  contains all existing associations for all CICS resources and
  all CICS systems within the CICSplex.  Since both lists are
  sorted based upon the primary key (resource type, resource name,
  and CICS system name), BMRA normally just indexes through each
  list, performing consistency checking whenever a match is found
  on the primary key.
  
  The processing for FILEDEFs, PROGDEFs, TDQDEFs, and TRANDEFs is
  different because each of these definitions can have an alias
  resource name.  As such, it is not possible to index through the
  lists based upon primary key, since that key may change if the
  resource does have an alias.  Therefore for these resources,
  BMRA indexes through the candidate list one time for each entry
  in the existing list.  When there are a great number of entries
  in the both the candidate and existing lists, this can lead to
  excessive processing in the MP CMAS.
  

Problem conclusion

• To resolve this, BMRA has been updated to add an alternate set
  of processing for resource types that can have an alias.  Since
  there is a large amount of setup overhead associated with this
  new processing, it will only be performed if the candidate list
  for the resource type contains more than a defined maximum
  number of elements.  When this occurs, BMRA will build two
  temporary lists, one for all candidate associations for the
  resource type, the other for all existing associations for the
  resource type.  The lists will then be sorted based upon actual
  key (resource type, alias name (or real name if no alias
  exists), and CICS system name).  BMRA will then be able to index
  through both lists at the same time, like it already does for
  resource types that cannot have an alias.  After BMRA completes
  checking of the temporary lists, they will be deleted.
  

Temporary fix

•             *********
              * HIPER *
              *********
  FIX AVAILABLE BY PTF ONLY
  

Comments

• Excessive response times may occur when
  the EUI, API, WUI, or BATCHREP is used
  to modify Topology or BAS definitions
  which cause FILE, PROGRAM, TDQ, or
  TRANSACTION resources to be associated
  with a CICS region.
  
  For example:
  
  -  adding a FILEDEF, PROGDEF, TDQDEF,
     or TRANDEF to a RESGROUP.
  
  -  adding an association between a
     RASGNDEF and a RESDESC.
  
  -  adding an association between a CICS
     system and a CICS system group.
  
  
  When a Topology or BAS definition change causes a CICS resource
  to be associated with a CICS system, the BAS component in the
  maintenance point (MP) CMAS of the CICSplex the definitions are
  associated with must perform checking to ensure that the
  candidate association does not conflict with an existing
  association.  To do this, method EYU0BMRA (BMRA) compares each
  candidate association against the BAS install list, which
  contains all existing associations for all CICS resources and
  all CICS systems within the CICSplex.  Since both lists are
  sorted based upon the primary key (resource type, resource name,
  and CICS system name), BMRA normally just indexes through each
  list, performing consistency checking whenever a match is found
  on the primary key.
  
  The processing for FILEDEFs, PROGDEFs, TDQDEFs, and TRANDEFs is
  different because each of these definitions can have an alias
  resource name.  As such, it is not possible to index through the
  lists based upon primary key, since that key may change if the
  resource does have an alias.  Therefore for these resources,
  BMRA indexes through the candidate list one time for each entry
  in the existing list.  When there are a great number of entries
  in the both the candidate and existing lists, this can lead to
  excessive processing in the MP CMAS.
  
  
  To resolve this, BMRA has been updated to add an alternate set
  of processing for resource types that can have an alias.  Since
  there is a large amount of setup overhead associated with this
  new processing, it will only be performed if the candidate list
  for the resource type contains more than a defined maximum
  number of elements.  When this occurs, BMRA will build two
  temporary lists, one for all candidate associations for the
  resource type, the other for all existing associations for the
  resource type.  The lists will then be sorted based upon actual
  key (resource type, alias name (or real name if no alias
  exists), and CICS system name).  BMRA will then be able to index
  through both lists at the same time, like it already does for
  resource types that cannot have an alias.  After BMRA completes
  checking of the temporary lists, they will be deleted.
  

APAR Information

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

  PK07183

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

  UK05862

Modules/Macros

•    EYU0BMRA
  

Fix information

• Fixed component name

  CPSM CICS 3.1

• Fixed component ID

  5655M1501

Applicable component levels

• R100 PSY UK05862

     UP05/08/02 P F508

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.