TWS sendevent command

by Pete Meechan

TWS 8.4 introduced support for event driven scheduling. This included functionality to take an action when specific events occurred in the TWS estate including support for non-TWS events and actions. Through the Tivoli Dynamic Workload Console (TDWC) – the TWS web console, events and their corresponding actions can be defined using various sources (e.g. TWS events, file events, etc.) and actions (e.g. send an e-mail, TWS submit, etc.).

Whilst this works well for these pre-defined events, how can you deal with applications that don’t sit so comfortably within TWS? For example, a bespoke home grown or third party application, which after it has finished processing, you want TWS to submit a job stream. This can be achieved using the TWS supplied sendevent command that is installed as part of the TWS Remote Command Line (CLI) component. The TWS remote CLI can be installed on any system with or without other TWS components. The TWS remote CLI is described here TWS 8.3 and higher Command Line Client and from TWS 8.4 includes the sendevent capability.

sendevent

There are two versions of sendevent available – one that is installed as a component part of the Fault Tolerant Agent (FTA) installation and another that is installed as part of the TWS remote CLI. There are some significant differences between the two sendevent versions and it is important to understand these differences before using them in any business critical situations.

The sendevent binary/command/executable supplied as part of the FTA installation is automatically configured to send events to the TWS event server, which by default executes on the MDM. If the MDM fails over to a backup MDM and the appropriate “conman switcheventprocessor” command is issued following the “conman switchmgr” command, the FTA version of sendevent will automatically send any future events to the backup MDM. This is because the events are sent through the TWS agent hierarchy.

However, the sendevent binary/command/executable installed as part of the TWS remote CLI is configured by default to send events to the TWS event server on the MDM. This is achieved by a hard coded reference in a configuration file and consequently, if the MDM fails over to a backup MDM along with the event server, events from the TWS remote CLI version will be cached until the MDM is reinstated. For business critical applications this is not an ideal situation.

Configuring sendevent

This section is only applicable to the TWS remote CLI version of sendevent.

The default settings for the TWS remote CLI version of sendevent are held in the file <TWS_remote_CLI_home>EIFsendeventeif.templ as shown below. The MDM on my TWS test system is hosted on the server ardbeg.scotchwhisky.local and this server is automatically substituted in the reference $TWS:EIFhost when sednevent is executed. The sendeventeif.templ file read, the $TWS:EIFxxx variables replaced with actual values and the results written to the file sendeventeif.conf in the same location. Any existing sendeventeif.conf file will be overwritten.

Configuring an alternative event server

To support an alternative event server such as the event server on the backup MDM, the sendeventeif.templ file needs to be modified to include the required definitions for the backup MDM. In the example below the MDM server is hosted on ardbeg.scotchwhisky.local and the backup MDM hosted on laphroaig.scotchwhisky.local. As TWS will replace any references to $TWS:EIFhost as the MDM server host, the references should be modified to refer to explicit server names as shown in the example below. All of the required modifications to sendeventeif.templ are highlighted in red.

The above modifications add a second “channel” that will be used in the event that the first “channel” is unavailable when sendevent is executed. After a number of retries (the default is 5 I believe) if the server defined on “channel t_” is still unavailable, the second channel defined by the “channel u_” will be used. If the server defined on “channel u_” is available, sendevent processing is complete. If the server is unavailable, the event will be cached to the cache file. The cached event will remain there until the next TWS remote CLI version of the sendevent is executed, at which point, if the server on either “channel” is available the events in the cache will be sent in a FIFO order, with the current event being sent last to maintain the chronological order of the events.