IV74758: UNABLE TO USE TWO DISTINCT DISPLAYITEM FOR SIT W/ UNTIL

IBM Tivoli Monitoring 6.3.0 Fix Pack 6 (6.3.0-TIV-ITM-FP0006)

APAR status

• Closed as program error.

Error description

• Environment: TEMS 6.30, platform independent
  
  
  Problem Description:
  'Sit_A is TRUE UNTIL Sit_B is TRUE' where Sit_A and Sit_B each
  have a DisplayItem declared, it is required that the
  attrGroup.attrName be the same, unique attribute declared by
  Sit_A and Sit_B definitions.
  
  For example, given Sit_A and Sit_B  and given two attribute
  groups named attrGrp_1 and attrGrp_2 and given that there is a
  attribute called myFavoriteAttr that is defined in each of the
  two attribute groups, the following construct is NOT supported
  ==>
  
  Sit_A is TRUE using DisplayItem attrGrp_1.myFavoriteAttr
       UNTIL Sit_B is TRUE using DisplayItem
  attrGrp_2.myFavoriteAttr
  
  ... not supported because attrGrp_1.myFavoriteAttr and
  attrGrp_2.myFavoriteAttr are different attributes declared for
  the respective DisplayItems.
  
  This draws focus to the fact that an attribute is not unique per
  the naked attribute name, i.e. myFavoriteAttr;  rather a unique
  attribute must be fully qualified by the combination of
  attribute group plus attribute name, i.e.
  attrGrp_1.myFavoriteAttr .
  
  Detailed Recreation Procedure:
  This was replicated in Linux OS Agent with the base situation
  against two processids KLZ_Process.Process_ID, same displayitem
  is the same. The until situation was against
  KLZ_Process_User_Info.Process_ID for a one of the process ids.
  The result were that the single Until result closed both the
  base results.
  
  Related Files and Output:
  

Local fix

• No local fix
  

Problem summary

• Given a situation that contains UNTIL and Display Items, for
  example 'Sit_A is TRUE UNTIL Sit_B is TRUE' where Sit_A and
  Sit_B each have a DisplayItem declared, but Display Item for
  Sit_A is from different attribute group than Sit_B's Display
  Item.
  
  When Sit_B becomes TRUE for any one open instance of Sit_A then
  all opened Sit_A's will be closed, though user expects only that
  one opened Sit_A instance to close.
  
  In order for this APAR to be properly implemented in your
  environment, a new environment variable has been added. See the
  "Install Actions" section of the APAR conclusion for more
  details.
  
  Here is a detailed description and example of the undesired
  behavior that occurs without adopting this APAR fix.
  
  For example, given Sit_A and Sit_B  and given two attribute
  groups named attrGrp_1 and attrGrp_2 and given that there is an
  attribute called myFavoriteAttr that is defined in each of the
  two attribute groups, the following construct is NOT supported
  ==>
  Sit_A is TRUE using DisplayItem attrGrp_1.myFavoriteAttr
  UNTIL Sit_B is TRUE using DisplayItem attrGrp_2.myFavoriteAttr
  
  The above is not supported because attrGrp_1.myFavoriteAttr and
  attrGrp_2.myFavoriteAttr are different attributes declared for
  the respective DisplayItems.
  
  This draws focus to the fact that an attribute is not unique per
  the naked attribute name, i.e.  myFavoriteAttr; rather a unique
  attribute must be fully qualified by the combination of
  attribute group plus attribute name, i.e.
  attrGrp_1.myFavoriteAttr .
  
  
  This was recreated in Windows OS Agent with a base situation
  against two ProcessID values per attribute NTPROCESS.IDPROCESS;
  the DisplayItem is Process Name, per NTPROCESS.INSTCNAME.
  
  IF #'NTPROCESS.IDPROCESS' == 4 OR #'NTPROCESS.IDPROCESS'== 4320
  
  The UNTIL situation was against WTPROCESS.IDPROCESS for just one
  of the ProcessID values;
  The DisplayItem is Process Name, per WTPROCESS.INSTCNAME.
  
  Note, WTPROCESS is different Attribute Group from base Sit's
  NTPROCESS.
  
     IF #'WTPROCESS.IDPROCESS' == 4320
  
  So we have an attribute, Process Name, that is being used from
  two separate Attribute Groups.
  
  Assuming processes are running with ProcessIDs of 4 and 4320,
  the Base Situation is correctly opened for each ProcessID.  When
  the UNTIL situation is evaluated, the opened Base Situation for
  ProcessID 4320 will be correctly closed.   However, the opened
  Base Situation for ProcessID 4 will incorrectly be closed - it
  should have remained open since the UNTIL situation is not TRUE
  for ProcessID equal to 4.
  

Problem conclusion

• Changes were made in code to support the above scenario,
  specifically adding support of a DisplayItem defined in a Base
  situation and DisplayItem defined in the UNTIL situation that
  are the same attribute, but from different Attribute Groups.
  
  Install Actions:
  In order to enable this new behavior the user must declare the
  new monitoring server environment variable
  KMS_ALLOW_DIFF_SIT_ATOMS as:   KMS_ALLOW_DIFF_SIT_ATOMS=Y
  
  This declaration must be set on hub and remote monitoring
  servers.  The default value of KMS_ALLOW_DIFF_SIT_ATOMS is N,
  thus this new behavior is disabled by default.
  
  The fix for this APAR is contained in the following maintenance
  packages:
  
    | fix pack | 6.3.0-TIV-ITM-FP0006
  

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:

  OA49269

Fix information

• Fixed component name

  TEMS

• Fixed component ID

  5724C04MS

Applicable component levels

• R630 PSY

     UP