What every OMEGAMON Administrator needs to know about Self-Describing Agents
ChrisWalker 270003FTW2 Visits (1408)
If you've been following the updates of the IBM Tivoli Monitoring and OMEGAMON product family over the past year you can't have failed to notice one of the key features being promoted is “Self-Describing Agents” or SDA. Perhaps you have moved to the latest releases and have started using this enhancement (if you have, keep reading, there may be some subtle information here you may not be already aware of), or you may be in the process of planning your upgrade and have not yet considered what benefits the SDA feature will bring you as the system administrator. The SDA feature is aimed specifically those responsible for the installation, configuration and maintenance of the monitoring environment, and whilst it brings benefits to all aspects of the infrastructure, for those looking after z/OS components it can be a real time saver in terms of reducing the effort required to apply maintenance and the stress involved in ensuring every related component has been upgraded to match the applied changes. Let's take a deeper look at SDA in terms of how it works and how you can simplify the management of your environments...
How it works
As a system administrator on z/OS, you may be well aware of the complexity of upgrading OMEGAMON monitoring agents or simply just applying the latest maintenance. As well as updating the monitoring agent, you may be required to update that product's application support at the hub monitoring server (TEMS) – often requiring a restart of the server, which is a real inconvenience to end users – and the portal server (TEPS) and finally the end user's portal client (TEP client). SDA can be a real game-changer here as it can reduce this downtime through providing all required updates through the agent PTF. When the updated monitoring agent comes online and connects into the environment a check is made at the hub TEMS as to the level of application support currently installed for the given OMEGAMON product. If the updated agent is of a higher level than that currently installed and the new level has permission to install, the new application support is immediately uploaded to the hub from the agent. There is no need for manual 'seeding' as in the past, and critically - if you are using a High Availability (HA) hub on z/OS or your hub is on a distributed platform - no need to restart the hub TEMS once the updated support has been uploaded. This is a good reason if you have or are planning to deploy your hub TEMS on z/OS that you give serious consideration to configuring it as an HA hub. A conventional hub TEMS on z/OS would still require a restart.
Figure 1 - Before: The center TEMA has just been upgraded to Version n+1. All other components, including the TEMS, TEPS and TEP client have application support for Version n of the monitoring agent. If permission has been granted to upload the latest version of application to the hub TEMS, it is automatically transferred from the agent.
It even gets better in that application support for the TEPS and TEP client (browser and Java WebStart) is also uploaded from the agent to the hub and then propagated to any connected TEPS and clients. This means you can have greater confidence that all your ITM components have the latest level of support deployed, minimizing the risk of missing an update and all implemented quickly with far less downtime than under the traditional approach.
Figure 2 - After: Following a successful upload of the new (Vn+1) application support to the hub TEMS, it is propagated to all other SDA enabled components within this monitoring environment, including the TEPS which should require no recycle. If your hub is running on a distributed platform or you have configured a High Availability (HA) hub on z/OS there is no need to recycle this hub once this process completes. You can be confident that everything is up to date as planned.
An SDA-enabled agent provides the application support for the TEMS, TEPS and TEP client in a number of jar files. These are uploaded to the system running the hub TEMS where they are unpacked and applied where needed. Therefore there is a requirement for a Java Runtime Environment to be installed and on z/OS an amount of zFS directory space must be allocated (~50 MB). These requirements are covered in more detail in the product documentation and this blog post.
While the adoption of SDA agents should reduce the amount of work required to update your runtime environments, there are some important commands to understand in order to manage and control SDA. There are some subtle but important differences to SDA management between ITM V6.2.3 and V6.3 (I'll address these in detail later) however you first need to enable the SDA parameter in all applicable components to switch it on. By default, SDA is enabled in all agents plus the TEPS and TEP clients but disabled at the hub TEMS. This allows you to enable the whole process through the change of a single parameter. You can do this during the creation of the hub TEMS (if on z/OS using the PARMGEN tool) or by adjusting the settings in the environment file of an already created hub TEMS. The parameter to set is:
If the hub TEMS is already running it will need to be recycled once to pick up the changes.
The other aspect to become familiar with is the tacmd command line utility. This tool allows you to administer the TEMS and is automatically installed as part of a TEMS on a distributed platform or TEPS. The tool does not exist on z/OS so if your hub is on the mainframe you will either need to use the tool on your TEPS machine or install it separately onto your desktop machine. You can find this as the “Tivoli Enterprise Services User Interface Extensions” component on the ITM distributed installation image.
Once installed, you can log on to the hub TEMS and display the level and status of the application support installed within the monitoring environment.
HUB/RTEMS PRODUCT VERSION GRPID ID IDVER SEEDSTATE STATE STATUS GBLTMSTMP RESOURCE
M5D0HAHB:CMS CP 05100100 5655 TMS 05100100 Y IC 1016 1110825024429000 KCPJSTMS.jar
M5D0HAHB:CMS CP 05100100 5655 TPS 05100100 IC 0 1110825024612000 KCPJSTPS.jar
M5D0HAHB:CMS CP 05100100 5655 TPW 05100100 IC 0 1110825024612000 KCPJSTPW.jar
You can use the 'tacmd listappinstallrecs' command to show all the application support installed at the TEMS or filter it for a selected product. In the above example, we are showing the status for OMEGAMON XE for CICS (product code CP). The key fields to check are the VERSION (here we have 05100100, or V5.1.0 fixpack 1 installed), the ID (TMS is TEMS application support, TPS is TEPS application support and TPW is TEP client support), and the STATE which indicates the current state of the application support. If, as shown here, the value is “IC” then the application support has been updated successfully (“IC” meaning Install Complete). If the value is something else then either the support is currently installing or there has been a problem that needs investigating. Check the documentation for full list of possible values.
If it has been established that there has been a problem with the installation, then the first course of action would be to delete the application install record that is in error. This command will cause the SDA install process to restart if the agent is already connected or when it next reconnects.
KUIDIR009I: The following records are going to be deleted:
HUB/RTEMS PRODUCT VERSION ID IDVER STATE STATUS
SYSCMS1 CP 05100163 TMS 05100163 ME 1011
Are you sure you want to delete the selected records? Type Y for yes. Type N for no.
KUIDIR005I: The selected install records were successfully deleted.
Enhanced Control in V6.3
In ITM V6.3 there have been some enhancements to the SDA process that allows you to exercise greater control over what application support should be installed and also to dynamically control when SDA installation takes place. By default no SDA installation will take place until you define install records indicating what levels of the application support you will allow (there is one exception to this: for users upgrading from V6.2.3 who have their hub TEMS on z/OS, the default V6.2.3 behavior is retained).
The enhancements in V6.3 also allow the system administrator to disable SDA temporarily using the command line ('tacmd suspendsda') and enable it ('tacmd resumesda') rather than having to switch the property and recycle as before.
The following shows an example of setting install records ('tacmd adds
KUICO2054I: No configuration options were found the the specified type(s). The following options will be created:
Are you sure you want to update the selected options? Type Y for yes. Type N for no.
This is important as it would prevent an agent of V5.1.0 fixpack 2 say, to install its support onto the monitoring environment until it is approved for use. At that point the SDA install records can be updated to allow this new version to be uploaded.
Hopefully you can see that SDA gives the system administrator some powerful control over the installation and upgrade of monitoring support. Time is saved by not needing to manually patch all users systems with the latest support from fixpack images and allowing the monitoring agent to automatically provide the updates itself. Required restarts of key monitoring components is reduced (even eliminated in some cases). While the command line tool, enhanced in ITM V6.3, provides the ability to administer the deployment of these upgrades easily.
Need some more details and examples? The ITM development team has produced this video that gives step-by-step details for using SDA within and ITM V6.3 environment.