{"id":1507,"date":"2009-01-30T10:01:33","date_gmt":"2009-01-30T15:01:33","guid":{"rendered":"http:\/\/dougmcclure.net\/blog\/?p=1507"},"modified":"2009-01-30T10:01:33","modified_gmt":"2009-01-30T15:01:33","slug":"tivoli-business-service-manager-support-tip-of-the-week-3","status":"publish","type":"post","link":"https:\/\/dougmcclure.net\/blog\/2009\/01\/tivoli-business-service-manager-support-tip-of-the-week-3\/","title":{"rendered":"Tivoli Business Service Manager Support Tip of the Week #3"},"content":{"rendered":"<p>Have you ever wondered how TBSM processes events? Have you been in a situation where you&#8217;d like to see what would happen if those events would just come in again and be processed? Did you add a new rule to a template that&#8217;s been in production for some time and now want to see how the service model would respond? Ever wonder what some of those Netcool\/OMNIbus fields were used for that start with RAD_?<\/p>\n<p>TBSM&#8217;s event processing is focused on a change in the severity of Netcool\/OMNIbus events by default (see RAD_eventbroker.props for more detail).  When an incoming event arrives, it&#8217;s assigned a specific severity as it&#8217;s inserted into Netcool\/OMNIbus or by some other automated logic, correlation, etc. within Netcool\/OMNIbus or Netcool\/Impact. TBSM&#8217;s event reader continuously compares incoming events and identifies through comparison of the Severity field to the RAD_RawInputLastValue field that this event hasn&#8217;t been processed. TBSM updates the RAD_RawInputLastValue field with the actual Severity field contents as well as determines which rules are associated with this event updating the RAD_FilterIDList. <\/p>\n<p>The key fields here are the original Severity field and the RAD_RawInputLastValue field. If these are both the same value, then things are status quo based on how the rules were configured.  If the incoming event&#8217;s Severity field is updated, say from Severity 3 (Minor) to Severity 5 (Critical) then TBSM recognizes that now Severity is 5 and RAD_RawInputLastValue is still 3. This means that the TBSM will process this event and update in accordance to the specific rules in the RAD_FilterIDList and in a simple cast change the service instance from Marginal to Bad (Yellow to Red).<\/p>\n<p>The recent TBSM v4.1.1 Interim Fix 11 quietly introduced (it&#8217;s in TBSM 4.2 IF1 also which is due today!) a new RADSHELL command that allows you to reprocess all Netcool\/OMNIbus events. The command simply updates all events in Netcool\/OMNIbus by resetting RAD_FilterIDList and RAD_RawInputLastValue. This in turn will cause TBSM to reprocess all of these events. The new RADSHELL command is: <strong>replayTBSMEvent();<\/strong> .<\/p>\n<p>You get a bit of control for this command by setting a property in the RAD_SLA.props file and the sla.replayradevents option.  By default it&#8217;s set to RAD_RawInputLastValue = 6, RAD_FilterIDList = &#8221; .  This sets the RAD_RawInputLastValue to a value that&#8217;s not valid (Severity 0-5 are normal so you&#8217;d never get a Severity of 6) and blanks out the RAD_FilterIDList which causes TBSM to determine which rules match events.<\/p>\n<p>We&#8217;ve always taught our clients and IBMers that you can just use nco_sql to manually update these fields to force TBSM to reprocess events. While the new replayTBSMEvent(); will be useful for broad based event updates, manually using nco_sql, WebTop AEL or the Desktop Client offers more fine grained ability to update specific events instead of all events.<\/p>\n<p>Thanks to someone in TBSMDev for slipping that new command in!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Have you ever wondered how TBSM processes events? Have you been in a situation where you&#8217;d like to see what would happen if those events would just come in again and be processed? Did you add a new rule to a template that&#8217;s been in production for some time and now want to see how [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[116,26,105,32,38,37,109,95,39],"tags":[989,926,933,932,718,975,426,511,934],"class_list":{"0":"post-1507","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-bsm","7":"category-business-service-management","8":"category-event-management","9":"category-events","10":"category-ibm","11":"category-implementation","12":"category-netcoolomnibus","13":"category-tbsm","14":"category-tivoli","15":"tag-bsm","16":"tag-business-service-management","17":"tag-ibm","18":"tag-implementation","19":"tag-support","20":"tag-tbsm","21":"tag-tbsmv411","22":"tag-tbsmv42","23":"tag-tivoli"},"_links":{"self":[{"href":"https:\/\/dougmcclure.net\/blog\/wp-json\/wp\/v2\/posts\/1507","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dougmcclure.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dougmcclure.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dougmcclure.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dougmcclure.net\/blog\/wp-json\/wp\/v2\/comments?post=1507"}],"version-history":[{"count":4,"href":"https:\/\/dougmcclure.net\/blog\/wp-json\/wp\/v2\/posts\/1507\/revisions"}],"predecessor-version":[{"id":1511,"href":"https:\/\/dougmcclure.net\/blog\/wp-json\/wp\/v2\/posts\/1507\/revisions\/1511"}],"wp:attachment":[{"href":"https:\/\/dougmcclure.net\/blog\/wp-json\/wp\/v2\/media?parent=1507"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dougmcclure.net\/blog\/wp-json\/wp\/v2\/categories?post=1507"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dougmcclure.net\/blog\/wp-json\/wp\/v2\/tags?post=1507"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}