Tivoli Business Service Manager (TBSM) delivers the real-time information that you need in order to respond to alerts effectively and in line with business requirements, and optionally to meet service-level agreements (SLAs).

The TBSM tools enable you to build a service model that you integrate with IBM Tivoli Netcool/OMNIbus alerts or optionally with data from an SQL data source. TBSM includes optional components that let you access data from other IBM Tivoli applications such as IBM Tivoli Monitoring, and IBM Tivoli Application Dependency Discovery Manager. TBSM processes the external data based on the service model data you created in the TBSM database and returns a new or updated TBSM service event to Netcool/OMNIbus.

The TBSM console provides a graphical user interface (GUI) that allows you to logically link services and business requirements within the service model. The service model provides an operator with a view of how, second by second, an enterprise is performing at any given moment in time or how the enterprise has performed over a given time period.

TBSM Version 6.1 contains many improvements over past versions of TBSM including updates to the below features. Reference the Administrator’s Guide for additional detail.

• Visualization
• Service Tree Navigation
• Instance-Based Status Propagation
• Custom Discovery Books
• Discovery Library Toolkit API and Resource Enrichment
• Resource Reconciliation
• Discovery Library Toolkit Installation
• Netcool/Impact integration
• Import/Export commands
• DB2 database (replacing PostgreSQL)
• Netcool/OMNIbus
• Tivoli Common Reporting
• IBM Tivoli Monitoring for Energy Management Dashboard

Installing TBSM 6.1 Linux

Minimum Requirements

*The below requirements MUST be met or exceeded otherwise TBSM will not install successfully.*

• Requirements for Data server
  • 2-CPU system with 3.0 GHz (or greater) CPUs
  • 6GBRAM
  • 8GB disk space
• Requirements for Dashboard server
  • 2-CPU system with 3.0 GHz (or greater) CPUs
  • 6GBRAM
  • 6 GB disk space
• Requirements for TBSM Console
  • Intel® CoreTM2 Duo Processor at 2.40 GHz (or greater
  • 1 GB RAM
  • 150 MB (JRE plug-in and cache) disk space
• Requirements for simple installation
  • 4-CPU system with 3.0 GHz (or greater) CPUs
  • 8GBRAM
  • 12 GB disk space
• Supported operating system
  • Red Hat Enterprise Linux 5.0 (AS), Intel x86, 32-bit and 64-bit
  • Red Hat Enterprise Linux 6.0 (AS), and 6.1 Intel x86, 32-bit and 64-bit
  • SLES 10 Intel x86, 32-bit and 64-bit
  • SLES 11 Intel x86, 32-bit and 64-bit (requires pre-installation steps described below)
  • On all 64-bit operating systems, 64-bit runs on 32-bit emulation mode.
• Mozilla Firefox 3.6 (32-bit only) The IBM Java SDK/JRE 6.0.9/1.6 (Internet Explorer only) or Oracle Java SDK/JRE/JDK 6.0/1.6 are required to view the TBSM console.
  • TBSM requires that JavaScript be enabled in the browser.
  • You need to set your browser to allow pop-up windows. If you block pop-up windows, you will disable features of TBSM that require pop-up windows.
  • If you have slow connectivity, you should install an additional Dashboard server closer to the location where the browsers are being used.

Prerequisites

• TBSM requires IBM DB2 version 9.5 Fix Pack 3 or higher or version 9.7 Fix Pack 3 or higher.
• To enable and use all the active event list (AEL) tools, you must have a Perl interpreter installed on the TBSM server.
• IBM Tivoli Monitoring Version 6.2 or later is required.
• On Unix and Linux platforms, prior to installing TBSM or Netcool/Impact, ensure that there is no tmp subdirectory under the /tmp directory. Otherwise, the installation will fail.
• Kernel and C runtime library
• Current^® and all compatibility versions of the C++ runtime library
• X Windows^® libraries and runtime
• GTK runtime libraries
• Review the paging requirement for the specific operating system. Serious errors can result if the paging file size is too small.
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 5
  • Red Hat Enterprise Linux 4
  • SUSE Linux Enterprise Server 9
  • SUSE Linux Enterprise Server 10
  • SUSE Linux Enterprise Server 11

Using the Prerequisite Scanner

• IBM Prerequisite Scanner is a stand-alone prerequisite checking tool that analyzes system environments before the installation or upgrade of a Tivoli product or IBM solution. The scanner includes configuration files for TBSM.
• Download the scanner version for your operating system here.
• Extract the scanner files to a location on your TBSM host. This location is called the ips_root directory.
• Change the ips_root directory.
• Set the value for the one of the following environmental variables to True:

Option	Description
Data server installation only	TBSM_PREREQ_DATA
Dashboard server installation only	TBSM_PREREQ_DASH
Combined Dashboard and Data server installation	TBSM_PREREQ_BOTH

For example, to set the environmental variable on a Windows system and instruct Prerequisite Scanner to scan for the prerequisites required for a Dashboard server installation, enter the following command:

set TBSM_PREREQ_DASH=True

• Run the command as shown below:

root@pt850c-ora-rh5:~# ./prereq_checker.sh "BSM 06100000" detail
IBM Prerequisite Scanner
Version: 1.1.1.9
Build : 20111202
OS Name: Linux
Machine Info
Machine Name : pt850c-ora-rh5
Serial Number: VMware-42 14 d3 7c 9e b2 2d 97-a9 7e df fd dc e2 16 88
BSM - Tivoli Business Service Manager [06100000]:
Evaluation       PASS/FAIL     Result                            Expected Result
OS Version       FAIL          "CentOS release 5.4 (Final)"      "RedHat Enterprise Linux Server 5.*"
RedHat Enterprise Linux Server 6.*
SUSE Linux Enterprise Server 10 (*)
SUSE Linux Enterprise Server 11 (*)
AIX V6.1
AIX V7.1
Solaris V10 (SPARC)
Temp             PASS          6.8GB                             500MB
TOTAL ALL SPECIFIED COMPONENTS:
Evaluation       PASS/FAIL     Result                            Expected Result
/                PASS          6.80GB                            0MB
Prereq Check Overall Result: FAIL

• Possible results are as follows:
  • FAIL
    • If the target server does not meet the prerequisites specified in the cfg files, the scanner returns FAIL for the Tivoli Business Service Manager check. The failed prerequisites are displayed in the screen output. To resolve the failure, take the appropriate actions, for example, install the missing operating system packages, increase disk space and so on.
  • PASS
    • If the target server has all the prerequisite specified in the cfg files, the scanner returns PASS for the Tivoli Business Service Manager check. If the scanner returns PASS for the Tivoli Business Service Manager check you can install, configure and start the product on the target server.

Installation Process

• Install DB2 9.7 Fix Pack 3 or higher
  • Run the DB2 installation as root user only.

  [root@tbsm61rh5 aese]# ./db2setup

  • Follow the graphical wizard, entering appropriate information for desired configuration. (default values were used in this example)

  

  • Ensure that three non-root users have been created before you run the DB2 configuration utility.

  [root@tbsm61rh5 ~]# cat /etc/passwd

  Using default values will produce entries similar to the following:

  dasusr1:x:501:103::/home/dasusr1:/bin/bash
db2inst1:x:502:104::/home/db2inst1:/bin/bash
db2fenc1:x:503:105::/home/db2fenc1:/bin/bash

  • Validate DB2

  [root@tbsm61rh5 ese]# cd /opt/ibm/db2/V9.7/bin/
[root@tbsm61rh5 bin]# ./db2val
DBI1379I The db2val command is running. This can take several minutes.
DBI1335I Installation file validation for the DB2 copy installed at
/opt/ibm/db2/V9.7 was successful.
DBI1343I The db2val command completed successfully. For details, see
the log file /tmp/db2val-12_28_05:55:29.log.

• Configure DB2
  • After DB2 is installed, run the TBSM DB configuration utility (included with the TBSM media). Log on to the server and run the configuration utility as the database user.

  [root@tbsm61rh5 tbsm_media]# su - db2inst1
[db2inst1@tbsm61rh5 ~]$ sh /opt/tbsm_media/CI3B5ML/linux/DbConfig/setup-dbconfig-linux.bin

  • Follow the steps in the graphic installation wizard. Ensure that the database name and database user match the existing database instance. (created during db2 install process)

  

• Install TBSM
  • Run the TBSM installer as a non-root user that is not the database user.

  [root@tbsm61rh5 ~]# useradd medora
[root@tbsm61rh5 ~]# passwd medora
Changing password for user medora.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
[root@tbsm61rh5 ~]# su - medora


  • The setup file for console installation is in /TBSM directory or the installation package or DVD. At the command prompt, type the following command to install TBSM in console mode:

  [medora@tbsm61rh5 ~]$ /home/medora/CI3B5ML/TBSM/setup-linux.bin

  • If your machine does not have the double-byte code pages installed, the double-byte languages (Simplified Chinese, Traditional Chinese, Korean, Japanese) are corrupted in the language selection list. This issue is a display problem on the selection list and the TBSM launchpad functions normally otherwise.
  • Aside from DB2, quit other running applications and proceed through the graphical wizard as shown below. *Do not quit DB2 or this procedure will not complete.*

  

  • Specify desired install directory.

  

  • Aside from correct database information, assure a fully qualified domain name is specified for Database Hostname. *This process will fail if an unqualified domain name is specified.*

  

  • Specify a username and password for TIP administration.

  

  • Wait patiently as TBSM installs. This process can take in excess of two hours.

  

• Validate TBSM Installation
  • Configure automatic startup for TBSM. *Perform this action as root.*

  [root@tbsm61rh5 bin]# ./opt/IBM/tivoli/tbsm/bin/autostartup_enable.sh

  • Start DB2. *Perform this action as the database instance owner (db2inst1).*

  [db2inst1@tbsm61rh5 ~]$ db2start

  • Start the TBSM suite. *Perform this action as the TBSM owner (medora).*

  [medora@tbsm61rh5 ~]$ ./opt/IBM/tivoli/tbsm/bin/tbsm_suite.sh

  • Login to web console. *Perform this action as the TIP administrator (tipadmin).*

  

  • Following a successful login, the dashboard should appear as below.

  

references:

http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=%2Fcom.ibm.db2.udb.uprun.doc%2Fdoc%2Ft0008875.htm

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.installation.base.doc/info/aes/ae/tins_linuxsetup.html

https://www-304.ibm.com/support/docview.wss?rs=3120&uid=swg21472859&wv=1

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=%2Fcom.ibm.ips.doc_1.1.1.7%2Fips_ic-homepage.html

https://www.ibm.com/developerworks/wikis/display/tivolibsm/Home

http://www-947.ibm.com/support/entry/portal/All_documentation_links/Software/Tivoli/Tivoli_Business_Service_Manager

One can access C++ data members and functions using the dot (.) operator for locally created objects. To access objects on the free store, one must dereference the pointer and call the dot operator on the object pointed to by the pointer. One could access the doSomething member function as follows:

(*pObject).doSomething();

Parentheses are used to assure that pObject is deferenced before doSomething is accessed.

Because this is cumbersome, C++ provides a shorthand operator for indirect access: the points-to operator (->), which is created by typing the dash (-) immediately followed by the greater-than symbol (>). C++ treats this as a single symbol. Using the points-to notation, one could access the doSomething member function as follows:

pObject->doSomething();

reference:

http://www.cplusplus.com/doc/tutorial/structures/

The IBM Tivoli Monitoring for Virtual Environments Agent for Citrix XenServer v71, released in November 2011, includes a new optional Tivoli Enterprise Portal (TEP) based logical navigator that can be used to provide an enhanced view of multiple monitored XenServer Pool Instances. The logical navigator provides a consolidated/aggregated view of the health and availability of all monitored XenServer Pools and hypervisors within the environment.

As seen below, the default Navigator View (Physical) represents the physical hierarchy of the managed systems being monitored in the ITM environment.   A close examination reveals that each monitored Pool, represented by ITM Managed Sytem Names H1:XI and H2:XI are distinct entries in the Physical navigator.  The Physical navigator (essentially the <default> view within the TEP), out-of-the-box, does not provide any views (in TEP-speak “Workspaces” of all monitored XenServer hosts.

Before the Logical Navigator -> 16 Hosts (2 Pools) spread across two distinct ITM instances

Importing the new Logical Navigator view allows managed system data to aggregated into a single “dashboard” view that allows you to view the status of all of the monitored XenServer Pools and hosts across the enterprise.

After the Logical Navigator -> 16 Hosts (two Pools) in one consolidated TEP Workspace/view

Importing the logical navigator

• Assure the TEPS user has Custom Navigator Views ‘Modify’ permissions (Administer Users->Permissions Tab->Tivoli Enterprise Portal Authorities->Custom Navigator Views->Modify)
• Login with tacmd

C:\Users\Administrator>tacmd login -s localhost -u sysadmin -p password
Validating user...
KUIC00007I: User sysadmin logged into server on https://localhost:3661.

• Navigate to the Logical_Navigator directory (in the root of the agent installation media)

T:\agents\kxiagent\kxiagent_710\ga_refresh\CRG3WML\ITMfVE_XenServer_Application_Support\Logical_Navigator>

• Install the logical navigator:

T:\agents\kxiagent\kxiagent_710\ga_refresh\CRG3WML\ITMfVE_XenServer_Application_Support\Logical_Navigator>tacmd importnavigator -x kxi_logicalnav.xml -s localhost -u sysadmin -p password
KUICIN001I Validating user credentials...
KUICIN003I Reading XML and converting to custom navigator view...
KUICIN012I The custom navigator view "XenServer_Details" already exists on the server. Do you want to delete the existing child nodes for the custom navigator view, and import the custom navigator view "XenServer_Details" to the Tivoli Enterprise Portal Server on http://localhost:1920? Existing user assignments for the custom navigator view will be maintained.
Enter Y for yes or N for no: Y
KUICIN013I Deleting child nodes for navigator "XenServer_Details"...
KUICIN004I Writing custom navigator view to the server...
KUICIN005I Writing queries to the server...
KUICIN021I The queries for the custom navigator view were successfully imported.
KUICIN006I Writing workspaces to the server...
KUICIN022I The workspaces for the custom navigator view were successfully imported.
KUICIN020I The custom navigator view "XenServer_Details" was successfully imported from the file T:\agents\kxiagent\kxiagent_710\ga_refresh\CRG3WML\ITMfVE_XenServer_Application_Support\Logical_Navigator\kxi_logicalnav.xml to the Tivoli Enterprise Portal Server on http://localhost:1920. The navigator view import operation did not assign the imported navigator view to any users. If the navigator view already existed, the existing user assignments were preserved. The tacmd editUser command or the Administer Users dialog can be used to assign the navigator view to a user.

• Modify the permissions of the TEPS user:

tacmd edituser -u sysadmin -w password -i sysadmin -p NavigatorViews=physical,logical,XenServer_Details

references:

http://www-03.ibm.com/certify/tests/obj034.shtml

http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/index.jsp?topic=%2Fcom.ibm.tivoli.itmvs.doc_7.1%2Fxenserver%2Fimport_logical_nav.html

The new IBM Tivoli Monitoring for Virtual Environments Agent for Citrix XenApp includes a optional TEP-based logical navigator that can installed to provide greater visibility of metrics across multiple XenApp servers.

As seen below, the default Navigator View (Physical) represents the physical hierarchy of the managed systems being monitored in the ITM environment.  Since the new Citrix XenApp agent is installed locally on a per XenApp Server basis, monitoring many XenApp servers can provide some challenges:

Importing the new optional Logical Navigator views allow managed system data to be displayed and aggregated  together in other, more business-relevant ways.

Importing the logical navigator

• Assure the TEPS user has Custom Navigator Views ‘Modify’ permissions (Administer Users->Permissions Tab->Tivoli Enterprise Portal Authorities->Custom Navigator Views->Modify)
• Login with tacmd

C:\Users\Administrator>tacmd login -s localhost -u sysadmin -p password
Validating user...
KUIC00007I: User sysadmin logged into server on https://localhost:3661.

• Navigate to the Logical_Navigator directory (in the root of the agent installation media)

T:\agents\kxaagent\kxaagent_710\ga_refresh\ITMfVE_XenApp_Application_Support\Logical_Navigator>

• Install the logical navigator:

T:\agents\kxaagent\kxaagent_710\ga_refresh\ITMfVE_XenApp_Application_Support\Logical_Navigator>tacmd importnavigator -x kxa_logicalnav.xml -s localhost -u sysadmin -p password
KUICIN001I Validating user credentials...
KUICIN003I Reading XML and converting to custom navigator view...
KUICIN012I The custom navigator view "XenApp_Details" already exists on the server. Do you want to delete the existing child nodes for the custom navigator view, and import the custom navigator view "XenApp_Details" to the Tivoli Enterprise Portal Server on http://localhost:1920? Existing user assignments for the custom navigator view will be maintained.
Enter Y for yes or N for no: Y
KUICIN013I Deleting child nodes for navigator "XenApp_Details"...
KUICIN004I Writing custom navigator view to the server...
KUICIN005I Writing queries to the server...
KUICIN021I The queries for the custom navigator view were successfully imported.
KUICIN006I Writing workspaces to the server...
KUICIN022I The workspaces for the custom navigator view were successfully imported.
KUICIN020I The custom navigator view "XenApp_Details" was successfully imported from the file T:\agents\kxaagent\kxaagent_710\ga_refresh\ITMfVE_XenApp_Application_Support\Logical_Navigator\kxa_logicalnav.xml to the Tivoli Enterprise Portal Server on http://localhost:1920. The navigator view import operation did not assign the imported navigator view to any users. If the navigator view already existed, the existing user assignments were preserved. The tacmd editUser command or the Administer Users dialog can be used to assign the navigator view to a user.

• Modify the permissions of the TEPS user:

tacmd edituser -u sysadmin -w password -i sysadmin -p NavigatorViews=physical,logical,XenApp_Details

references:

http://www-03.ibm.com/certify/tests/obj034.shtml

http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/index.jsp?topic=%2Fcom.ibm.tivoli.itmvs.doc_7.1%2Fimport_logical_nav.html

Follow the below instructions to remove Windows Low Disk Space Warnings from the Task Bar. This is advantageous in situations where a recovery or maintenance partition is attached to the system and recognized as a drive.

Execute the Registry Editor

C:\Users\Administrator>regedit.exe

Navigate to HKEY_CURRENT_USER->SOFTWARE->Microsoft->Windows->CurrentVersion->Policies->Explorer

If an entry named ‘NoLowDiskSpaceChecks’ does not exist, create it.

Set the type of the entry to DWORD

Set the value of the entry to 1

Save your work

Reboot the system

Probable issues with TBSM Event Mapping may include one or more of the following deficiencies.

• EIF Event Transmission is not Descriptive
  • The EIF Event Transmission sent from the EIF Emitter on the TEMS does not contain enough information for the event to be correctly mapped to a TBSM Service Component.
  • This indicates a deficiency in the Custom Situation
  • The most probable solution to this issue is to modify each Custom Situation after better understanding the “BSM_Identity” value of the TBSM Service Component to which the event correlates.
• Incorrect EIF Probe Rules
  • The rules defined in the EIF Probe incorrectly set the value of the “BSM_Identity” field.
  • This indicates a deficiency in the kub.rules file (generated by the omnibusUpdater.sh script from the kub.baroc file).
  • The most probable solution to this issue is to include a revised copy of the kub.rules file with the ITCAM for Applications Agent.
  • Other possible solutions include modifying the kub.baroc file included with the ITCAM for Applications Agent or including a revised copy of the omnibusUpdater.sh script included with the ITCAM for Applications Agent.
• IdML Book is not Descriptive
  • The IdML Book does not contain enough information for XMLToolkit to create a unique “BSM_Identity” value for each TBSM Service Component.
  • This indicates a deficiency in the TMSDLA.
  • The most probable solution to this issue is modification the TMSDLA included with the ITCAM for Applications Agent.
• Incorrect XMLToolkit Rules
  • The XMLToolkit incorrectly sets the value of the “BSM_Identity” field.
  • This indicates a deficiency in the EventIdentifierRules.xml file.
  • The most probable solution to this issue is to discuss modification of the EventIdentifierRules.xml file with IBM’s XMLToolkit team.

references:

http://www.ibm.com/developerworks/wikis/display/tivolibsm/Enriching+IBM+Tivoli+Monitoring+%28ITM%29+Events+For+IBM+Tivoli+Business+Service+Manager+%28TBSM%29

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.tivoli.itbsm.doc/common/tbsm_c_product_architecture.html

http://publib.boulder.ibm.com/infocenter/tivihelp/v24r1/index.jsp?topic=/com.ibm.itcamt.doc_7.2/rt/User%20Guide/TBSM/tbsm_ref_omnibus.html

http://www.redbooks.ibm.com/abstracts/sg247878.html?Open

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.tivoli.itbsm.doc_4.1/bsma_evtc_tivolieifprobe.htm

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.tivoli.itbsm.doc_4.1/bsma_evtc_itm.htm

Having worked with SVN previously, switching to GIT was a pleasant change. The most noticeable difference between SVN and GIT lies in the fact that GIT is distributed whereas SVN is not. This means that Git does not depend on a centralized server, but does have the ability to synchronize with other Git repositories. Once a repository is cloned using GIT, all the commits, diffs, merges and more can be done entirely offline. I also noticed that it takes longer to type in GIT commands than it does to execute, whereas in SVN commands take longer to execute. In short, GIT makes for a much better work experience.

I found that GIT was a bit complicated to use, especially in the beginning. Even after a few months into working with it, I still find that there is a lot more to learn about GIT (evidently proven by some of the blunders I have committed), than I already know. A few important lessons I learnt while working with GIT were:

• It is always good practice to work with the latest most updated version of code, and to do so, a git pull before starting work on any branch is a must.
• Double checking the branch I was working on really helped because discovering that I was working on a wrong branch was not fun.
• Using the remove command with caution, because once files are deleted from a particular branch there is no way of getting them back, EVER, unless of course I reverted to previous commit level and re-did all my changes.
• Merging one branch into another can be very tricky. The most important thing in resolving conflicts between files during merging is knowing what caused the conflict, not to mention the patience to resolve them.
• Checking in the wrong files can cause problems, and therefore making sure that the right files are being checked in is the right way to go.
• Tagging in GIT can be very useful especially when referring to a particular commit is necessary.
• The git status command is really helpful in pointing out what files have been changed or updated.

An interesting thing I noticed about GIT is that it is an intelligent software, in the sense that it prompts for the right commands in cases where commands were misspelt. It is also interactive and helps in describing what each command does. Using GIT commands in the wrong way is common, in such cases the git help command is really useful.

Below is a list of some of the GIT commands I regularly use.

1) git clone : Creates a local git repository copy from a remote source.

git clone git@github.com:user/test.git

2) git pull : Pulls in the latest changes from the origin

git pull

OR

git pull origin <branchName>

3) git add : Adds new or updates files to the current branch

git add <fileName>

4) git commit : Commits all local changes

git commit -a

5) git status : Checks for files that are changed in the local directory.

git status

6) git push : Pushes local changes to the origin

git push origin <currentBranchName>

7) git branch : Gives the current working branch.

git branch

master

* new

The * here denotes the current working branch.

— To create a new branch off an old branch :

git checkout -b <newbranch> <oldbranch>

— To Switch to a different branch from the current working branch :

git checkout <differentBranch>

— To get a list of all branches:

git branch -a

— To delete a branch locally :

git branch -d <branchName>

– To delete a branch remotely

git push origin :<branchName>

8) git tag : To create a tag that refers to a particular commit

git tag <tagName>

– To push tags to the origin

git push –tags

– To delete a tag locally

git tag -d <tagName>

– To delete a tag remotely

git push origin :<tagName>

9) git revert : To revert to a specific commit

git revert <specificCommit>

10) git diff : Displays differences between two commits

git diff <oldCommit> <newCommit>

11) git log : To get a history of changes

git log

12 ) git rm : Removes files from the current working directory and branch

git rm <fileName>

13) git merge : Merges a branch into another.

Make sure to do a git pull on the branch that is being merged into and then run the git merge command.

git merge <newBranch>

In conclusion, as a developer, GIT has definitely made life easier. I hope to write soon about other softwares and tools I use.

Kruthika M  Kumar

Event mapping

All the event mapping necessary to map Tivoli Enterprise Console, Tivoli NETVIEW, and Tivoli Monitoring event fields to ObjectServer fields is pre-configured in the tivoli_eif.rules file, the default rule file used by the EIF probe. The events forwarded from these sources contain the following special fields:

• The BSM_Identity field maps to a value that identifies which service the event affects. The below table shows the default mappings for the supported event sources. One can use this field’s value to help identify service-affecting events in one’s TBSM incoming status rules.
• The BSM_ClassName field is reserved for future use. For TBSM 4.1, the BSM_ClassName field is set to null.

Event Source Default Mappings:

Event correlation

Each TBSM Service Component in one’s service model can have one of more unique service identifiers. These service identifier values are assigned the BSM_Identity attribute of a Service Component. In TBSM incoming status rules, one can use the event’s BSM_Identity field value to match a Service Component’s BSM_Identity value to determine the events that affect a service. For more information on incoming status rules, see the IBM Tivoli Business Service Manager Service Configuration Guide and IBM Tivoli Business Service Manager Scenarios Guide.

The mechanism by which events are mapped to TBSM Service Components is represented in the below image.

Element details are as follows:

• TEMS - The Tivoli Enterprise Monitoring Server identifies situations from criteria predefined by the ITCAM for Applications Agent.
• EIF Emitter – The EIF Emitter sends a message in the “Event Integration Facility” protocol to the EIF Probe.
• EIF Event Transmission – The EIF Event Transmission sent by the EIF Emitter carries information in a set of standard fields.
• EIF Probe - The EIF Probe receives EIF Event Transmissions with standard fields and, with the help of “.rules” files, sends an Enanced EIF Event Transmission to the OMNIBUS / Netcool Object Server.
• tivoli_eif.rules - The tivoli_eif.rules file is referenced by the EIF Probe when enhancing EIF Event Transmissions. One common task of the file is to remove single quotes from strings. The file also makes reference to the kub.rules file.
• kub.rules – The kub.rules file is generated from the kub.baroc file with the help of omnibusUpdater.sh. The kub.rules file defines mappings from the EIF Event Transmission fields to the Enhanced EIF Event Transmission fields.
• omnibusUpdater.sh – The omnibusUpdater.sh script takes the kub.baroc file as a parameter and produces the kub.rules file. It also edits the tivoli_eif.rules file to include the kub.rules file.
• Enhanced EIF Event Transmission - The Enanced EIF Event Transmission sent by the EIF Probe to the OMNIBUS / Netcool Object Server carries information in a set of custom fields defined by “.rules” files.
• OMNIBUS / Netcool Object Server - The OMNIBUS / Netcool Object Server receives the Enhanced EIF Event Transmission and adds it to the Object Server database. This information is represented by a BSM Field List which can be read by TBSM.
  
• BSM Field List - The BSM Field List is created by the OMNIBUS / Netcool Object Server and read by TBSM. It includes a “BSM_Identity” field.
  
• TBSM - The TBSM reads the BSM Field List provided by the OMNIBUS / Netcool Object Server and the BSM_Identity provided by XMLToolkit. The value of the “BSM_Identity” field in the BSM Field List must match that of an existing TBSM “Service Component” (provided by XMLToolkit) in order for the situation it represents to be mapped correctly.
  
• BSM_Identity – The BSM_Identity of each TBSM Service Component is provided by the XMLToolkit. Its value must be referenced by each situation that applies to it in order for correct mapping to occur.
  
• XMLToolkit - The XMLToolkit parses the IdML Book with the help of the EventIdentifierRules.xml file and provides a description of each Service Component to TBSM.
  
• LabelingRules.xml - The LabelingRules.xml is an XMLToolkit configuration file used by TBSM to give each Service Component a label.
  
• EventIdentifierRules.xml - The EventIdentifierRules.xml file defines a BSM_Identity mapping for each TBSM Service Component described by the IdML Book.
  
• IdML Book - The IdML Book describes the TBSM Service Components monitored by the ITCAM for Applications Agent. It is created from the TMSDLA with the help of the tmsdla.sh script and is read by the XMLToolkit.
  
• tmsdla.sh – The tmsdla.sh script uses the TMSDLA to create the IdML Book which describes the TBSM Service Components monitored by the ITCAM for Applications Agent.
• ITCAM for Applications Agent - The ITCAM for Applications Agent includes the TMSDLA, the kub.baroc file, defines the Custom Situation, and monitors TBSM Service Components.
  
• TMSDLA - The TMSDLA contains standards regarding how the TBSM Service Components monitored by the ITCAM for Applications Agent should be represented in the IdML Book.
  
• Custom Situation - The Custom Situation is described by the ITCAM for Applications Agent and defines the values of the fields sent by the EIF Emitter.
  
• kub.baroc - The kub.baroc file is included in the ITCAM for Applications Agent. It is used by the omnibusUpdater.sh script to generate the kub.rules file.
  

references:

http://www.ibm.com/developerworks/wikis/display/tivolibsm/Enriching+IBM+Tivoli+Monitoring+%28ITM%29+Events+For+IBM+Tivoli+Business+Service+Manager+%28TBSM%29

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.tivoli.itbsm.doc/common/tbsm_c_product_architecture.html

http://publib.boulder.ibm.com/infocenter/tivihelp/v24r1/index.jsp?topic=/com.ibm.itcamt.doc_7.2/rt/User%20Guide/TBSM/tbsm_ref_omnibus.html

http://www.redbooks.ibm.com/abstracts/sg247878.html?Open

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.tivoli.itbsm.doc_4.1/bsma_evtc_itm.htm

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.tivoli.itbsm.doc_4.1/bsma_evtc_tivolieifprobe.htm

There are several rules that I tend to follow while writing tests.  Hopefully they will help.

• Write the test
  

  @Test
  public void realRealWinner() throws Throwable {
    Winner target = new Winner();
    AssertTrue(“Winner did not win”, target.isWinner());
  }

  UT-OH! This does not compile, because java requires that the reference to the class you are testing exists :( Let’s Fix it!

---

• Fix the broken compilation by creating the class and the current method we are testing.
  

  Public Class Winner {
  	public Boolean isWinner() {
  		//  The  body of the function is step 3
  	}
  }

---

• Hold on there… You might be thinking to yourself “why is this it’s own step, it’s just a method body right?” Well, you are exactly correct, but the thing I want to portray here is that if you were to put any type of return in the function to make the test pass (initially) could potentially poison expected results. For instance if you were to return false, and then were to step away for a moment, or better yet hand the keyboard off to your pair, and context is lost, there could be a resulting failure point in your implementation. I strongly urge that you do the following:
  

  Public Class Winner {
  	public Boolean isWinner() {
  		throw new NotImplementedException(); // golden nugget
  	}
  }

  The reason I do this is so that if this were to slip into production, or if I were to walk away, there is a clear statement that this method/section of code is indeed “NOT IMPLEMENTED YET”

---

• Make the test pass.
• Repeat steps one through four until you are finished with the current class / unit.

Hope this helped,
Jeremy Rowe

What is TCR?

Tivoli Common Reporting is a business tool utilized by Tivoli products to show key metrics such as CPU, memory, disk usage, and network I/O for a product. For more information on what TCR is visit: https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/communityview?communityUuid=9caf63c9-15a1-4a03-96b3-8fc700f3a364

This blog will highlight the TCR reports just released to compliment the Agent for Citrix XenServer v6.2.3. These reports can be downloaded here:

http://www-304.ibm.com/software/brandcatalog/ismlibrary/details?catalog.label=1TW10TM9U

Why Use TCR?

Although Tivoli Monitoring Agents do a great job of representing data, they can be more powerful with a compliment like TCR. The XenServer Agent collects data and represents it in the Tivoli Enterprise Portal Desktop (TEPD) in a number of ways (i.e graphs, tables) but creating custom workspaces can become advanced. Tivoli Common Reporting is a tool a customer can use to create reports that have the same or even more capabilities than a TEPD workspace. The reports for the Agent for Citrix XenServer v6.2.3 aim to increase the power of an agent by extending its capabilities.

XenServer 6.2.3 TCR Highlights

One of the reports included in the TCR package is named “XenServer Hypervisor Heat Chart”. This report shows percentages of memory and CPU utilization in a cross-tab.The cross-tab contains colors that correspond to a number the user inputs in the prompt page. If the metric inside the cross-tab is below the threshold it will appear in that color. As the threshold statuses increase to ‘critical’, the color inside the cross-tab becomes red. In an actual environment, this report will alert a user to hypervisors that may be running critically high on memory or hypervisors that are being under-used. See Figure 1 For an example report.

Another report bundled with the TCR package is named “XenServer Top Or Bottom Workload Consumers”. This report shows the top or bottom hypervisors in terms of key metrics such as CPU utilization, memory utilization, and network I/O. One feature of this report is the top/bottom option. This allows a user to choose if they want to view the key metrics by most utilized or least utilized. Additionally, a user can choose if they want to display percentages or real numbers. For example, they can view memory used as a number (MB) or as a percentage. Another feature of this report is it allows a user to filter the number of results that are displayed. For example, they can see the top five hypervisors by cpu utilization or the bottom ten hypervisors by percentage of memory used. All the features of this report make it flexible. It is essentially over ten reports packaged into one. See figure 2 for an example report.

Reports can also be run against virtual machines. One of the reports packaged with the 6.2.3 reports is “XenServer Top N VM CPU Utilization Report”. A user may select one, many, or all of the available hypervisors. Then, a list is generated of all the virtual machines on those hypervisors. Once again, a user may select any number of those virtual machines. Next, the user must enter a number (n) of virtual machines to display. The report will run and display the number of  virtual machines that use the most CPU. The unique feature of this report is that it contains a “drill-through”. A drill-through is a relationship between two reports. It runs another report based off of information passed from the current report. The drill-through for this report occurs when a user clicks on a virtual machine name. Another packaged report “XenServer Virtual Machine Daily CPU Trend” will then be run for the virtual machine that was clicked. This allows a customer to really scope in on a virtual machine’s CPU utilization. This dynamic allows a user the option to view more general trends of a virtual machine or focus on one week or even one day.

All of these reports contain prompt pages where a user can specify parameters to run the report. All of the reports contain some of the same parameters. One is date range, a user can run the report for a number of date ranges including today, yesterday, last week, last month, or even a specified date range, down to the hour.

The Future

Currently, reports are being developed for the Citrix XenServer 7.1 agent. Some features added to these reports:

• Pool centered reports
• Running reports for only peak hours
• More advanced filtering
• What-If Analysis reporting
• Workload Forecasting

Figure 1:

Figure 2:

If you have any questions/comments, please e-mail me at: ryan.abel@bluemedora.com