IV74529: COMBINE SIT PREDICATE THAT CONTAINS EMBEDDED SIT(S)

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

APAR status

• Closed as program error.

Error description

• Customers are running into the problem where a single Situation
  can not accommodate all the required predicates necessary to
  detect some circumstance.  The assumption customers make is that
  the different criteria can be split across multiple Situations
  which are then combined within a containing Situation and that
  the events opened by this containing Situation will satisfy all
  of the criteria defined within the contained Situations.
  
  However, this is not the case:  The containing Situation opens
  events that satisfy only a subset of the contained predicates.
  
  
  Example:
  
  The customer writes a Situation with the formula :
  
  SitA = IF processName = 'abc' AND CPU% > 20 AND memoryUtil > 5
  
  As expected, this Situation will only open an event when process
  'abc' consumes more than 20% and is using more than 5MB.
  
  Now the customer splits these 3 predicates into 2 other
  Situations and combines both within a third Situation.
  [Of course, this isn't necessary in this simple example because
  the formula easily fits within a single Situation definition but
  it is sufficient to illustrate the problem].
  
  SitX = IF processName = 'abc'
  SitY = IF CPU% > 20
  SitZ = IF memoryUtil > 5 AND SitX AND SitY
  
  Although SitX is looking for process 'abc' and SitY is looking
  for a CPU utilisation of > 20% and both of these are contained
  within SitZ which is checking for memory utilisation of more
  than 5MB, SitZ will open an event if *any* process is using more
  than 5MB as long as process 'abc' is running, (regardless of its
  CPU and memory utilisation), and at least one process is using >
  20% (regardless of its name and memory utilisation).
  
  In other words, each part of SitZ is evaluated independently.
  
  Explanation:
  
  Why is there a limit on the number of predicates that can be
  stored in a Situation?
  
  The formula of a Situation is stored in the PDT column of the
  TSITDESC table.  This column can hold up to 1020 characters and
  TEP prevents a formula from being constructed that would exceed
  this limit.
  
  
  Why does SitZ operate differently to SitA?
  
  The reason for SitZ's behaviour is that Sitmon, (the TEMS
  component that oversees the operation of Situations), converts
  SitZ's formula into 3 rules: one looking at the processName,
  another at the CPU% and the third at the memory.
  These 3 rules result is 3 independent requests running at the
  agent each of which returns data when its single predicate is
  satisfied: name, CPU% or memory.
  As long as each request returns at least one row of data the
  formula for SitZ is satisfied and events will be opened.
  
  e.g. SitZ would fire if each of the 3 requests returned the
  following results:
  
    Name  CPU%  Memory
  SitX : abc  1  1
  SitY :xyz  50  1
  SitZ : def  1  6
  
  SitA, of course, would not have opened an event for process
  'abc' and in this particular case, the current operation of SitZ
  doesn't seem very useful.
  

Local fix

• There is no work-around.   An enhancement to support combining
  predicates from embedded situations into a single, combined
  predicate will be delivered per this internal, Dev APAR.
  

Problem summary

• Situation with embedded situation(s) may incorrectly be
  raised/opened. The assumption users make is that different
  criteria can be split across multiple situations which are then
  combined within a containing situation and that events opened by
   this containing situation will have satisfied all of the
  criteria defined within the contained (embedded) situations.
  
  However, this is not the case ...  the containing situation may
  open events that satisfy only a subset of the contained
  predicates.
  
  Example:
  
  The user writes a situation with the formula :   SitA = IF
  processName = 'abc' AND CPU% > 20 AND memoryUtil > 5
  
  As expected, this situation will only open an event when process
  'abc' consumes more than 20% CPU and is using more than 5MB
  memory.
  
  Now the user splits these 3 predicates into 2 other situations
  and combines both within a third situation. [Of course, this is
  not necessary in this simple example because the formula easily
  fits within a single situation definition but it is sufficient
  to illustrate the problem].
  
  SitX = IF processName = 'abc'
  SitY = IF CPU% > 20
  SitZ = IF memoryUtil > 5 AND SitX AND SitY
  
  Although SitX is looking for process 'abc' and SitY is looking
  for a CPU utilization of > 20% and both of these are contained
  within SitZ which is checking for memory utilization of more
  than 5MB,
  SitZ will open an event if *any* process is using more than 5MB
  as long as process 'abc' is running, (regardless of its CPU and
  memory utilization), and at least one process is using > 20%
  (regardless of its name and memory utilization).
  
  In other words, each part of SitZ predicate is evaluated
  independently, which is not behavior expected by user.
  
  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.
  

Problem conclusion

• Update was made to process predicate of each embedded situation
  and combined them into a single predicate for the containing
  situation.
  
  Install Actions:
  ----------------
  This corrected behavior is only in effect if the Tivoli
  Enterprise Monitoring server environment variable
  KMS_EXPAND_EMBEDDED_SIT is declared as
  KMS_EXPAND_EMBEDDED_SIT=Y.  The environment variable must be set
  for HUB monitoring server and remote monitoring servers and
  existing embedded situations must be reprocessed.  The default
  value for KMS_EXPAND_EMBEDDED_SIT is N, thus the new behavior of
  this APAR would be disabled.
  
  A set of scripts, *.sh for UNIX/Linux and *.cmd for Windows,
  have been added to standardize the procedure to enable embedded
  situation expansion.
  To enable expansion of existing embedded situations, perform the
  following steps:
  
  1) Run the setEmbeddedSitsFlag.sh or setEmbeddedSitsFlag.cmd
  script with the "enable" option on each HUB and Remote
  Monitoring Server.
  
  2) Wait until all of the setEmbeddedSitsFlag.* executions have
  completed successfully.
  
  3) Run the modifyEmbedded.sh or modifyEmbedded.cmd script ONLY
  ONE TIME.  You may run the script on any distributed HUB or
  Remote Monitoring Server.
  
  NOTE: You need to use "tacmd login" to log in to the HUB
  Monitoring Server before running the modifyEmbedded.sh or
  modifyEmbedded.cmd script.
  
  4) After these steps are completed, existing embedded situations
  will now be re-expanded when they are started.  If they are
  already running, you do not need to manually re-start them
  again.
  
  
  The fix for this APAR is contained in the following maintenance
  packages:
  
     | fix pack | 6.3.0-TIV-ITM-FP0006
  
  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:

  OA49255

Fix information

• Fixed component name

  TEMS

• Fixed component ID

  5724C04MS

Applicable component levels

• R630 PSY

     UP