IZ27001: A Policy whose Workflow is triggered by a ManagedSystem-based Situation, (i.e. one that reads the Hub's Node Status table),

APAR status

• Closed as program error.

Error description

• Severity: 3
  Approver: MS
  Compid: 5724C04MS
  
  Abstract: A Policy whose Workflow is triggered by a
  ManagedSystem-based Situation, (i.e. one that reads the Hub's
  Node Status table), does not respond to Off-line events for
  agents that are connected to an RTEMS.
  
  Environment:
  
   Policies consisting of a situation going true which triggers an
  event (in this case SNMP event) is not occurring when the
  situation is distributed to *HUB
   and the policy is distributed to MSL on a RTEMS.
  
  Problem Description:
  
  When an agent connects to the HTEMS, Sitmon at the Hub is
  notified and it remembers that the Policy is distributed to it.
  So, even if the agent subsequently switches to another TEMS,
  when it goes off-line again, the event will trigger the Policy.
  
  BUT, if the HTEMS is recycled ... the agents must be reconnected
  to it and then reconfigured back to their usual RTEMS.
  
  Two issues:
  
  1) When *HUB was added to the Policy's distribution list,
  Sitmon may have removed the distribution to the System MSL
   *OS400_OM.
  
  2)  Policies that use Node Status-based Situations, the HTEMS's
  Sitmon's Access List cache needs to include all of
  the agents to which the Policy is distributed, and not only
  those that are directly connected to the HTEMS.
  (Or, at least, it needs to include all of the agents to which
  the Node Status-based Situation is distributed).
  
  
  Circumvention:
  
  Perhaps the KA4 agents can be reconfigured to the HTEMS
  semi-permanently until a fix is available.
  
  Detailed Recreation Procedure:
  
  This is the crucial detail in client's scenario.
  
  And it is relevant because such Situations are unique.
  
  They are unique because the "ORIGINNODE" value in the Situation
  Event RESULTS, (i.e. the source of the data), can be an agent
  that is not connected to the Hub.
  
  (Ordinarily, in fact in all other cases, the ORIGINNODE of a
  Situation Event will be an agent that is directly connected to
  the TEMS that is receiving the data).
  
  This is significant because:
  
  a) A Policy ignores events from sources that are not in its
  Sitmon Access List cache.
  b) Sitmon's Access List cache only includes entries for agents
  that are attached to the TEMS where that Sitmon is running.
  
  So, as all the KA4 agents are attached to an RTEMS, there are no
  Sitmon Access List cache records for the Policy at the Hub.
  So, when the "Off-line" Situation fires at the Hub and sends
  data to the Policy running within Sitmon at the Hub, the data
  are ignored because the Policy "thinks" that, based on the
  Access List cache, they are not relevant.
  
  The fix entails modification to FA and/or IB so that for a
  Policy that depends on a "ManagedSystem"-based Situation, events
  are honoured for any agent in the Policy's distribution,
  regardless of the TEMS to which those agents are attached.
  
  A secondary research issue concerns the observation that when
  the customer added *HUB to their Policy's distribution, the log
  contains evidence that we attempted to delete the *OS400_OM
  System-MSL from the TOBJACCL table.
  
  Adding *HUB to the distribution of the Policy has, as expected,
  resulted in the Policy running at the HTEMS as desired.
  And it is receiving the off-line events from the :KA4 agents.
  
  The Policy is throwing the events away:
  
  
  Mon Jul 14 12:11:35 2008
  0675-ED8:ko4pcy.cpp,1499,"Policy::filter") origin <CELLO:KA4>
  skip <1>
  Mon Jul 14 12:11:35 2008
  0684-ED8:ko4pcy.cpp,1499,"Policy::filter") origin <icscdev:KA4>
  skip <1>
  
  "skip <1>" from Policy::filter means that the Policy is ignoring
  the event.
  
  The reason for skip is here ...:
  
  Mon Jul 14 12:11:35 2008 013F-E04:kdssqprs.c,624,"PRS_ParseSql")
  DELETE FROM O4SRV.TOBJACCL WHERE
  SYSTEM.PARMA("QIBCLASSID","5535",4) AND  OBJCLASS = "5130" AND
  SYSTEM.PARMA("QIBUSER","KDOLD",5) AND OBJNAME =
  "OS400_Agent_Offline" AND (NODEL = "*OS400_OM")
  
  This is happening as a side-effect of adding "*HUB" to the
  Policy's distribution and it is removing the *OS400_OM MSL from
  the distribution.
  
  Because *OS400_OM has been removed, when we get events from an
  agent in that list, the filtering code, throws it out.
  
  The basic idea behind the code is to remove any distributions
  for any object, (Situation or Policy), that don't apply to a
  given TEMS.
  
  As mentioned before, there are no KA4 agents attached to the
  HTEMS so an object distributed only to that MSL should not run
  at the Hub; (that is why we distributed the Policy to *HUB).
  
  Now, it maybe that we just have some holes when it comes to
  Policies that use Node Status-based Situations; (such Situations
  generate events at the Hub even for agents that aren't attached
  to the Hub).
  
  But I'm not sure that this code really applies to the HTEMS at
  all, at least in its entirety.
  
  For example, Sitmon at the Hub should never be issuing a request
  to delete records from the Hub's TOBJACCL, (Access List). That
  is really only something that should be done at an RTEMS.
  
  
  
  Related Files and Output:
  
   ECUREP
  

Local fix

• Move agent from RTEMS to HTEMS
  

Problem summary

• Managed System based policy does not trigger for offline events.
  
  A Policy whose Workflow is triggered by a ManagedSystem-based
  Situation, (i.e. one that reads the Hub's Node Status table),
  does not respond to Off-line events for agents that are
  connected to an RTEMS.
  

Problem conclusion

• Bypass filtering for managed system based policies.  This will
  ensure the policy will fire for agents going offline that are
  connected to an RTEMS and therefore do not have access list
  records for the remote host.
  
  The fix for this APAR is included in the following maintenance
  vehicle:
      | interim fix | 6.1.0.7-TIV-ITM-IF0002
  
  Note: Search the IBM Technical support web site for maintenance
  package availability
  

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:

  OA26218 OA26799

Fix information

• Fixed component name

  TEMS

• Fixed component ID

  5724C04MS

Applicable component levels

• R610 PSY

     UP