TWS integration with TEC

Configuring the Tivoli Enterprise Console adapter

TEC logfile adapter needs to be installed on TWS server and a set of configuration steps must be performed to enable that adapter to manage the job scheduling events. For information on how to install the Tivoli Enterprise Console logfile adapter, refer to the IBM Tivoli Enterprise Console Installation Guide.

The config_teclogadapter script is used to configure the TEC logfile adapter on TWS server. Perform the following steps:

1. Set the environment variables for the Tivoli endpoint by running the lcf_env script.
2. Run the config_teclogadapterscript to configure the adapter. For example:

   config_teclogadapter [-tme] PATH [Adapter ID] [TWS Installation Path]

   where:

   -tme

   The Tivoli Enterprise Console adapter is a TME adapter.

   PATH

   Specify the Tivoli Enterprise Console adapter directory when you did not specify the -tme option. Otherwise it is the endpoint directory.

   Adapter ID

   Specify the Tivoli Enterprise Console Adapter identifier (only for Tivoli Enterprise Console 3.9 and later). If you do not specify an ID, it is ignored.

   TWS Installation Path

   Specify the path where the Tivoli Workload Scheduler you want to monitor is installed.

The script performs the following configuration steps:

After you run the script, perform a conman stop and conman start to apply the changes.

Configuring the Tivoli Enterprise Console server

As well as configuring the Tivoli Enterprise Console adapter, you need to configure the Tivoli Enterprise Console server.

The config_tecserver script enables the TEC server to receive events from the Tivoli Enterprise Console adapter. It must be run on the system where the Tivoli Enterprise Console Server is installed or on a ManagedNode of the same TME network. On the Windows platform, a TME bash is required to run the script. For example:

config_tecserver.sh { -newrb <RuleBase name=""> <RuleBase
Path=""> -clonerb <RuleBase name=""> | -userb <RuleBase
name=""> }   
<EventConsole> [TECUIServer host] USER PASSWORD

where:

-newrb

Specify a new RuleBase with the specified name and path.

-clonerb

Specify the rule base to be cloned into the new Rule base.

-userb

Customize an already existing RuleBase.

EventConsole

Specify the EventConsole to be created and configured.

TECUIServer host

Specify the host name where the Tivoli Enterprise Console UI server is installed.

USER PASSWORD

Specify the user name and password needed to access the EventConsole.

The script performs the following configuration steps:

1. If specified, creates the new RuleBase from the cloned one.
2. Adds the Tivoli Workload Scheduler baroc events definition to the specified RuleBase.
3. Adds the Tivoli Workload Scheduler rules to the RuleBase.
4. Compile the RuleBase.
5. Put the RuleBase as the Active RuleBase.
6. Configures the specified EventConsole with Tivoli Workload Scheduler filters.
7. Restarts the Tivoli Enterprise Console server.

Event formats

Table 16 lists the engine event formats.

Positional event variables

This subsection defines the positional event variables.

Re-loading monitoring data

The Configure Non-TME adapter and Configure TME® adapter commands set up the file BmEvents.conf in the TWShome directory. This configuration file determines which information the production processes (batchman and mailman) write in the TWSHome/log_source_file file, by default this file is the event.log file, and how this information is written.

You can change the name of the log file as follows:

• Modify the FILE field in the BmEvents.conf file and restart the Tivoli Workload Scheduler processes
• Modify the LogSource field in the tecad_logfile.conf file and restarting the Tivoli Enterprise Console logfile adapter.

In the BmEvents.conf file the # sign represents a comment. Remove the # sign to uncomment a line.

The contents of this file are also used by other Tivoli® applications that manage events, that IBM Tivoli Workload Scheduler can interact with, such as IBM® Tivoli NetView® and IBM Tivoli Business Systems Management.

The options you can set in the BmEvents.conf file are described below:

OPTIONS=MASTER|OFF

If the value is set to MASTER then all job scheduling events gathered by that workstation are reported. If that workstation is the master domain manager or the backup master domain manager, with Full Status option switched on, then all scheduling events for all workstations are reported.

If the value is set to OFF, the job scheduling events are reported only if they relate to the workstation where the file is configured.

If commented, it defaults to MASTER on the master domain manager workstation, and to OFF on a workstation other than the master domain manager.

LOGGING=ALL|KEY

Disables or enables the key flag filter mechanism.

If set to ALL then all events from all jobs and job streams are logged.

If set to KEY the event logging is enabled only for those jobs and job streams that are marked as key. The key flag is used to identify the most critical jobs or job streams. To set it in the job or job stream properties use:

• The keywords KEYSCHED (for job streams) and KEYJOB (for jobs) from the Tivoli Workload Scheduler command line interface.
• The job Is Monitored Job check box and job stream In Monitored Job Stream check box from the IBM Tivoli Workload Scheduler Job Scheduling Console.
  

SYMEVNTS=YES|NO

If set to YES it tells the production process, batchman, to report the jobs and job streams status events immediately after having generated the new production day plan. This key is valid only if LOGGING=KEY.

If set to NO, no report is given.

The default value is NO.

CHSCHED=HIGH|LOW

Indicates which events are to be sent during the job stream lifetime.

During the lifetime of a job stream its status can change several times depending on the status of the jobs it contains.

By using the CHSCHED option you choose how the job stream status change is reported.

If you set it to HIGH, during the job stream lifetime an event is sent any time the status of the job stream changes. Because the intermediate status of the job stream can change several times, several events can be sent, each reporting a specific status change. For example, a job stream may go into the READY state several times during its running because its status is related to the status of the jobs it contains. Each time the job stream goes into the READY state, event 153 is sent.

If you set it to LOW, during the job stream lifetime until the final status is reached, only the initial job stream state transaction is tracked. In this way the network traffic of events reporting job stream status changes is heavily reduced. When the CHSCHED value is set to LOW these are the events that are sent only the first time during the job stream life time:

Table 23. CHSCHED event filtered

Event number	Event Class	Description
153	TWS_Schedule_Started	Job stream started
156	TWS_Schedule_Submit	Job stream submitted
158	TWS_Schedule_Ready	Job stream ready
159	TWS_Schedule_Hold	Job stream hold
160	TWS_Schedule_Extern	Job stream external
162	TWS_Schedule	Job stream properties changed

For final status of a job stream, regardless of the value set for CHSCHED, all events reporting the final status of the job stream are reported, even if the job stream has more than one final status. For example, if a job contained in the job stream completes with an ABEND state, event 151 is sent (Job stream abended). If that job is then rerun and completes successfully, the job stream completes with a SUCC state and event 154 is sent (Job stream completed).

The default value for CHSCHED is HIGH.

EVENT=n[ n ...]

Identifies which events to report in the log_source_file. Event numbers must be separated by at least one space. If omitted, the events reported by default are:

51 101 102 105 111 151 152 155 201 202 203 204 251 252 301

If the EVENT parameter is included, it completely overrides the defaults. To remove only event 102 from the list, for example, you must enter the following:

EVENT=51 101 105 111 151 152 155 201 202 203 204 251 252 301

Note:

Event 51 is always reported each time mailman and batchman are restarted, regardless of the filters specified in the EVENT parameter. If you do not wish to notify this event to the TEC event console, you must manually edit the maestro.fmt file or, for Windows® environments, the maestro_nt.fmt file and comment out the following section:

// TWS Event Log
      FORMAT TWS_Reset
      1 %s %s %s*
      event_type 1
      hostname DEFAULT
      origin DEFAULT
      agent_id $1
      software_version $2
      msg PRINTF("TWS has been reset on host %s",hostname)
      severity HARMLESS
      END  

When this section is commented out, the TEC adapter will not send event 51 to the TEC event console.

FILE=filename

This option is used specifically when interacting with the Tivoli Enterprise Console. Set it to the path and file name of an ASCII log file. Job scheduling events are written to this ASCII log file which is truncated whenever the batchman and mailman processes are restarted, for example at the end of each production day.

or

FILE_NO_UTF8 =filename

Use this option instead of the FILE option when you want job scheduling events written in the local language file specified by this parameter.

scheduling events

After performing the configuration steps described in the Configuring the Tivoli Enterprise Console adapter, use the events gathered from the Tivoli Workload Scheduler log file using the Tivoli Enterprise Console logfile adapter to perform event management and correlation using the Tivoli Enterprise Console in your scheduling environment.

This section describes the events that are generated by using to the information stored in the log file specified in the BmEvents.conf configuration file stored on the system where you installed the Tivoli Enterprise Console logfile adapter.

An important aspect to be considered when configuring the integration with the Tivoli Enterprise Console using event adapters is whether to monitor only the master domain manager or every IBM Tivoli Workload Scheduler agent.

If you integrate only the master domain manager, all the events coming from the entire scheduling environment are reported because the log file on a master domain manager logs the information from the entire scheduling network. On the Tivoli Enterprise Console event server and TEC event console all events will therefore look as if they come from the master domain manager, regardless of which IBM Tivoli Workload Scheduler agent they originate from. The workstation name, job name, and job stream name are still reported to Tivoli Enterprise Console, but as a part of the message inside the event.

If, instead, you install a Tivoli Enterprise Console logfile adapter on every IBM Tivoli Workload Scheduler agent, this results in a duplication of events coming from the master domain manager, and from each agent. Creating and using a Tivoli Enterprise Console that detects these duplicated events, based on job_name, job_cpu, schedule_name, and schedule_cpu, and keeps just the event coming from the log file on the Tivoli Workload Scheduler agent, helps you to handle this problem. The same consideration also applies if you decide to integrate the backup master domain manager, if defined, because the log file on a backup master domain manager logs the information from the entire scheduling network. For information on creating new rules for the Tivoli Enterprise Console refer to the IBM Tivoli Enterprise Console Rule Builder's Guide. For information on how to define a backup master domain manager refer to IBM Tivoli Workload Scheduler: Planning and Installation Guide.

Figure 4 describes how an event is generated. It shows the Tivoli Enterprise Console logfile adapter installed on the master domain manager. This is to ensure that all the information about the job scheduling execution across the entire scheduling environment is available inside the log file on that workstation. You can decide, however, to install the Tivoli Enterprise Console logfile adapter on another workstation in your scheduling environment, depending on your environment and business needs.

The logic that is used to generate job scheduling events is the following:

• The information logged during the job scheduling process has an event number for each type of logged activity or problem.
• Each item of information marked with an event number that appears in the EVENT field of the BmEvents.conf file is written into the log file specified in the FILE field of the BmEvents.conf file.
• The Tivoli Enterprise Console logfile adapter reads this information inside the log file, formats it using the structure stored in the FMT file (maestro.fmt for UNIX, maestro_nt.fmt for Windows) and forwards it to the TEC event server, using the TEC gateway defined on the managed node of the Tivoli environment.
• On the TEC event server, the structure of the formatted information is checked using the information stored in the BAROC files and, if correct, is accepted. Otherwise a parsing failure is prompted.
• Once the event is accepted by the TEC event server, a check on possible predefined correlation rules or automatic responses for that event number is made using the information stored in the RLS files.
• If defined, the correlation rules and/or automatic responses are triggered and the event is sent to the TEC event console to be displayed on the defined Event Console.

For some error conditions on event informing that the alarm condition is ended is also stored in the log file and passed to the TEC event server via the Tivoli Enterprise Console logfile adapter. This kind of event is called a clearing event. It ends on the TEC event console any related problem events.

The following table describes the events and rules provided by Tivoli Workload Scheduler.

The text of the message that is assigned by the FMT file to the event is shown in bold. The text message is the one that is sent by the Tivoli Enterprise Console logfile adapter to TEC event server and then to the TEC event console. The percent sign (%s) in the messages indicates a variable. The name of each variable follows the message between brackets.

Default criteria that control the correlation of events and the automatic responses can be changed by editing the file maestro_plus.rls (in UNIX environments) or maestront_plus.rls (in Windows environments) file. These RLS files are created during the installation of Tivoli Workload Scheduler and compiled with the BAROC file containing the event classes for the Tivoli Workload Scheduler events on the TEC event server when the Setup Event Server for TWS task is run. Before modifying either of these two files, make a backup copy of the original file and test the modified copy in your sample test environment.

For example, in the last event described in the table you can change the n value, the number of seconds the job has to be in ready state to trigger a new message, by modifying the rule job_ready_open set for the TWS_Job_Ready event class.

rule: job_ready_open : ( 
     		description: 'Start a timer rule for ready',

			event: _event of_class 'TWS_Job_Ready'
   					where [

								 status: outside ['CLOSED'],
								 schedule_name: _schedule_name,
								 job_cpu: _job_cpu,
								 job_name: _job_name
						],
			reception_action: (
						set_timer(_event,600,'ready event')
			)
		).

For example, by changing the value from 600 to 1200 in the set_timer predicates of the reception_action action, and then by recompiling and reloading the Rule Base you change from 600 to 1200 the number of seconds the job has to be in ready state to trigger a new message.

Refer to Tivoli Enterprise Console User's Guide and Tivoli Enterprise Console Rule Builder's Guide for details about rules commands.

scheduling events format

The integration between Tivoli® Workload Scheduler and Tivoli Entreprise Console (TEC) provides the means to identify and manage a set of predefined job scheduling events. These are the events that are managed using the Tivoli Enterprise Console logfile adapter installed on the scheduling workstations. These events are listed in the following table together with the values of their positional fields. These positional fields are the ones used by the FMT files to define the event structure which, once filled up with the information stored for that specific event number in the log file, is sent by the Tivoli Enterprise Console logfile adapter to the TEC event server. For additional information, refer to Job scheduling events.

Integration with TWS 8.2

There are some new IBM Tivoli Workload Scheduler events produced in IBM Tivoli Workload Scheduler Version 8.2 that did not exist before. This is to reflect some new features of IBM Tivoli Workload Scheduler only available in Version 8.2. Some of these events are:

Default criteria that control the correlation of events and the automatic responses can be changed by editing the file maestro_plus.rls (in UNIX environments) or maestront_plus.rls (in Windows environments) file. These RLS files are created during the installation of Tivoli Workload Scheduler and compiled with the BAROC file containing the event classes for the Tivoli Workload Scheduler events on the TEC event server when the Setup Event Server for TWS task is run. Before modifying either of these two files, make a backup copy of the original file and test the modified copy in your sample test environment.

For example, in the last event described in the table you can change the n value, the number of seconds the job has to be in ready state to trigger a new message, by modifying the rule job_ready_open set for the TWS_Job_Ready event class.

rule: job_ready_open : ( 
     		description: 'Start a timer rule for ready',

			event: _event of_class 'TWS_Job_Ready'
   					where [

								 status: outside ['CLOSED'],
								 schedule_name: _schedule_name,
								 job_cpu: _job_cpu,
								 job_name: _job_name
						],
			reception_action: (
						set_timer(_event,600,'ready event')
			)
		).

For example, by changing the value from 600 to 1200 in the set_timer predicates of the reception_action action, and then by recompiling and reloading the Rule Base you change from 600 to 1200 the number of seconds the job has to be in ready state to trigger a new message.

Refer to Tivoli Enterprise Console User's Guide and Tivoli Enterprise Console Rule Builder's Guide for details about rules commands.

scheduling events format

The integration between Tivoli® Workload Scheduler and Tivoli Entreprise Console (TEC) provides the means to identify and manage a set of predefined job scheduling events. These are the events that are managed using the Tivoli Enterprise Console logfile adapter installed on the scheduling workstations. These events are listed in the following table together with the values of their positional fields. These positional fields are the ones used by the FMT files to define the event structure which, once filled up with the information stored for that specific event number in the log file, is sent by the Tivoli Enterprise Console logfile adapter to the TEC event server. For additional information, refer to Job scheduling events.

NEWS CONTENTS

• 190313 : IBM - Installing the TWS PLUS Module for TWS v8.2.x ( IBM - Installing the TWS PLUS Module for TWS v8.2.x, )

Old News

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

Disclaimer: