Friday, August 27, 2010

Getfile, Putfile, Executecommand - added in ITM 6.2.2 fp02

Enable this functionality (Check out Venkat’s earlier post)

GETFILE:
{-m|--system} SYSTEM
{-s|--source} REMOTE_FILE
{-d|--destination} LOCAL_FILE
[{-t|--type} Transfer MODE] - Either [text|bin]
[{-f|--force}] – Forces an overwrite of the file if it exists

Example:
tacmd getfile -m itmtest:LZ -s /tmp/itmtest.log -d /base_logs/itmtest_08272010.out -t text –f
--------------------------------------------------------------


PUTFILE:

{-m|--system} SYSTEM
{-s|--source} LOCAL_FILE
{-d|--destination} REMOTE_FILE
[{-t|--type} MODE] ] - Either [text|bin]
[{-f|--force}] – Forces an overwrite of the file if it exists

Example:

tacmd putfile -m itmtest:LZ -s /automationscripts/ testing.sh -d /tmp/testing.sh -t text –f

NOTE: When transferring the file, it sets the permissions of the file to “666”.

--------------------------------------------------------------


EXECUTECOMMAND:

tacmd executecommand
{-m|--system} SYSTEM
{-c|--commandstring} COMMAND_STRING
[{-w|--workingdir} REMOTE_WORKING_DIRECTORY}]
[{-o|--stdout}]
[{-e|--stderr}]
[{-r|--returncode}]
[{-l|--layout}]
[{-t|--timeout} TIMEOUT]
[{-d|--destination} LOCAL_STD_OUTPUT_ERROR_FILENAME]
[{-s|--remotedestination} REMOTE_STD_OUTPUT_ERROR_FILENAME]
[{-f|--force} FORCE_MODE}
[{-v|--view}]

Example:

tacmd executecommand -m itmtest:LZ -c "/tmp/testing.sh" -o -e -r -l –v


NOTE: You will need to parse the STDOUT from this command to get the local STDERR, STDOUT, Return Code etc…

Monday, August 23, 2010

Tivoli Common Reporting 1.3 Overview

The Tivoli Common Reporting product introduced about 3 years back now  fills in the reporting requirements for various Tivoli products. It is tightly integrated with various Tivoli products such as Tivoli monitoring, Maximo, Tivoli Provisioning manager and access manager. A new version of this product is available now called Tivoli Common Reporting for Asset and Performance Management 1.3.  
 
I personally think the version number increment is misleading. This product introduces a number of changes and features that should warrant a 2.x instead of 1.x.  Anyway, here are few notes about this TCR product.
 
Report Engine
 
The TCR 1.3 product uses two report engines for report generation. The BIRT engine (2.2.1) used by the older TCR product is continue to be available in the newer version as well.  The reports developed using TCR 1.1.x or 1.2 will work correctly.   However, this version of  TCR product also gives you additional choice to develop reports using Cognos.  There are some very cool features available in Cognos reporting such as on-the-fly report creation by end users,  browser based report studio to design reports, etc.  While the Cognos reporting is powerful, it also introduces own complexities such as separate data modeling phase and additional components for report  design and generation.
 
Distributed Installation
 
The new TCR product supports distributed installation meaning TCR components (especially Cognos related components) can be installed over multiple systems for better performance.  If you have an existing Cognos setup, TCR can be integrated with your Cognos BI setup to leverage the expertise you already have.
 
Cognos Components
 
In addition, the Cognos piece introduces quite a  few additional components such as Framework Manager for data modeling, Report and Query Studio for report and query design,  Cognos Admin page for administering Cognos report packages, etc.   Please stay tuned for an upcoming article on Cognos Reporting for more details on the Cognos BI Reporting terminology. 
 
Report Emailing and Scheduling
 
While Report Scheduling feature is available in TCR 1.2, the new version provides a report emailing feature as well. However, the feature is limited to ONLY Cognos reports. With Cognos, you can even schedule AND email the reports periodically, a very powerful and useful feature.  This feature is not available for BIRT reports but can be custom developed for BIRT reports using scripting. 
 
Please stay tuned for more articles related to TCR 1.3 and Cognos.

Wednesday, July 28, 2010

BIRT Tip: Dependent Parameters in your reports

In BIRT, using report parameters is the highly powerful (and easy!) way to customize the report according to the end user needs. Report parameters provides runtime values such as start and end dates for reports, specific item for which report needs to be run, etc based on the user input. While this is very useful, some of the reports may need multiple parameters that have dependent relationship among them. For example, if your report needs to list Customers in a specific state in a specific country, the "regular" report parameter will not meet your requirements because you will need to "dynamically" adjust the list of states available for selection based on the Country that the user chooses. How can you do this in BIRT? Read on.


In BIRT, you will need to use the "Cascading Parameters" to define the relationship between the parameters. Continuing the above example, let us take the CUSTOMERS table in BIRT CLASSICMODELS sample database.






  1. Create a new dataset called COUNTRIES to select all unique Country information. e.g. A sample SQL is "SELECT distinct COUNTRY from CUSTOMERS".

  2. Create a new dataset called StatesInCountry to select all unique State information for a given country. e.g. A Sample SQL is "SELECT distinct STATE from CUSTOMERS WHERE COUNTRY = ?". Leave the parameter binding for the first parameter (param_1) to NONE for now. We will change it later.

  3. Create a new Cascading Parameter Group called "paramStates". Choose "Multiple Dataset" option as we will have to select information from two datasets created above.

  4. Click on Add Button on the "New Cascading Parameter" dialog to add a new Cascading parameter. Enter the name for the cascading parameter as "paramCountries", choose COUNTIRES dataset created in Step1 as the dataset and select the "COUNTRY" fields for value and display text.

  5. Click on Add button again to add the state cascading parameter. Enter the name for the cascading parameter as "paramStatesInCountry", choose the StatesInCountry dataset created in Step 2 as the dataset and select the "STATE" field for value and display text.

  6. Click Ok to close "New Cascading Parameter" dialog. Please see the attached screenshot containing the Cascading Parameter Group information.


  7. Now edit the StatesInCountry dataset created in step 2, goto Parameters section, edit the param_1 parameter binding and set the LinkedToReport Parameter value to the "paramCountries" cascading parameter created in step 4. Click ok to save the changes.

Now your reports are ready to use the cascading paramters. If you run the report now, whenever you change the COUNTRY in the parameter selection, the available STATE selection also changes accordingly. The attached screenshots show the State information for USA and Australia.




PS: It is easier to do these things in BIRT than telling how to do them. I have tried my best to describe the steps involved. If you have questions or need clarifications on the above steps, please feel free to write to me.

Wednesday, July 14, 2010

5 Things You Didn't Know About Java series from Developerworks

This is part 2, on Performance Monitoring. It's dealing with newer releases, so it won't be directly applicable to all environments, but I think it's very useful information:



Tuesday, June 29, 2010

Create a virtual data center with POWER7 and IBM Tivoli Provisioning Manager

 
 

Sent to you by Frank Tate via Google Reader:

 
 


Have you ever wondered how to bundle together data center resources? Do you ever have to manually deploy and configure your servers, operating systems, middleware, applications, storage and networking devices? They can be managed as a single entity using physical and virtual IBM servers. In this article, you will learn what a virtual data center is, how to create one using POWER7 VMControl and IBM Tivoli Provisioning Manager, and how to use a virtual data center to manage your IT systems and virtualization technologies as a single point of control access. In the process, we'll show you an example of how you can use the Tivoli product for patch management, which is one of the most difficult tasks to manage in a large server farm.

 
 

Things you can do from here:

 
 

5 things you didn't know about ... Java performance monitoring, Part 1

 
 

Sent to you by Frank Tate via Google Reader:

 
 


Blaming bad code (or bad code monkeys) won't help you find performance bottlenecks and improve the speed of your Java applications, and neither will guessing. Ted Neward directs your attention to tools for Java performance monitoring, starting with five tips for using Java 5's built-in profiler, JConsole, to collect and analyze performance data.

 
 

Things you can do from here: