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

Obtain the fix for this APAR.

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

• ****************************************************************
  * USERS AFFECTED: All TEMS users.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: SITUATION WITH EMBEDDED SITUATION(S)    *
  *                      MAY INCORRECTLY BE RAISED/OPENED.       *
  ****************************************************************
  * RECOMMENDATION: Apply the PTF.                               *
  ****************************************************************
  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 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 embedded situation expansion, 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 complete any 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.
  

Temporary fix

Comments

APAR Information

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

  IV74529

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

Modules/Macros

•    KDSFILT  KSMOMS
  

Fix information

• Fixed component name

  MGMT SERVER DS

• Fixed component ID

  5608A2800

Applicable component levels

• R630 PSY UA79950

     UP15/12/15 P F512

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.