Customizing the TWS Workload with Variable Tables

Download Report

Transcript Customizing the TWS Workload with Variable Tables

Event Management for TWS for z/Os
Tivoli Workload Scheduler for z/Os 8.5
IBM Tivoli Software
Paolo Falsi
1
Purpose of this Presentation and Disclaimer
Disclaimer
The purpose of this presentation is to gather customer
feedback on enhancements of event management in
TWS for z/Os.
The content of this presentation is not committed by
IBM and may change over the course of time based on
gathered feedback and product requirements.
2
Agenda
Agenda
 Introduction to Event Management enhancements
 Using triggers to Customize the Workload:

Scenario 1: Triggers

Scenario 2: Trigger

Scenario 3:
definitions flow
on HFS file
File Dependencies on Windows and Unix
 Upgrade from 8.x, Compatibility and Coexistence
 Future Directions and Items
 Q’s & A’s
3
Introduction to Event Management enhancement
Contents:
 Limitations of TWS 8.x Event Management
 Meaning of Event Management enhancements
 The Business Value of Event Management enhancements
4
Current limitations
 Workload customization with old TWS:

Customization of triggers and deploy of them to the agent is executed
with heavy manual steps for every tracker

Defining of some triggering attribute can require SMF exit
modification

HFS at tracker side cannot be monitored

Distributed agent files cannot be simply monitored
5
EM in TWS 8.4
 EM at a glance:

Using a single job, you can define the triggering criteria for all the
trackers and build all the configuration files based on that criteria

You can make available the configuration files at tracker side using a
simple modify command at controller side.

HFS files can be used as triggers for actions to be executed at
controller side

A new “native” utility will be available for all the distributed agent
environments to test a file existence to be used as dependency for an
action.
6
The Business Value of enhance Event Management
 The business value of Event Management enhancements:

Users will save a lot of time (money) defining and deploying file
triggers located in tracker environments

You can also use as trigger a z/OS HFS (zFS) file

Easier way to introduce existency file dependencies in distributed agent
environments

Reduction of CSA storage taken versus dataset triggering
7
Scenario 1: Triggers definitions flow
Focus:
 Show how to define triggers on controller system and how to deploy
them to trackers systems
Personas:
 Jack – Bank employee
Send every day reports to Bank Information Center
 Paul – TWS Schedule Developer
Creates job streams that run periodic reports on business data
 Barbara – Business Analyst
Requires TWS to produce daily and monthly reports on business data
8
Scenario 1 – Triggers definitions flow
Paul creates an application OPCTUNA to trigger a pool of actions
(jobs) when a Dataset has been updated via FTP on a tracker system
Defining an application where operation 002 and 003 are depending on a Special Resource
named OPCDEV.FALSI.TWS. The operation 001 will set to Not Available the Special Resource
for these operations
9
Scenario 1 – Triggers definitions flow
Paul creates an event rule to trigger a special resource availability when
OPCDEV.FALSI.TWS is updated via FTP on a tracker system
Defining on controller system of event rule causing that the Special Resource named OPCDEV.FALSI.TWS will
become available when the modification of dataset OPCDEV.FALSI.TWS on the tracker at destination
“destinationX” will be completed
10
Scenario 1 – Triggers definitions flow
Paul submits the job to activate the event rule
Job creates the configuration file (basing on the XML event rule file previously described) and deploys the
configuration file to tracker
Paul chooses option 10
11
Scenario 1 – Triggers definitions flow
Paul chooses option 3
12
Scenario 1 – Triggers definitions flow
Dataset name identify the input where the XML event rules are defined. SYSIN can be used.
13
Scenario 1 – Triggers definitions flow
The job build and deploy the events configuration files (FALSI.CWSH) to trackers.
Deploy is done via modify command /F xxxx,DEPLOYCONF
Deploy can be deferred deleting the modify command in the JOB and executing it later on
using system consol
14
Scenario 1 – Triggers definitions flow
Jack send daily report
Barbara monitors the Final Report Produced
When the report arrives to tracker system the TWS job is started
to format the report. The final report produced.
15
Scenario 2: Trigger on HFS file
Focus:
 Show how to use as trigger an HFS file located in a tracker system
 Personas:
 Jack – Bank employee
Send every day reports to Bank Information Center
 Paul – TWS Schedule Developer
Creates job streams that run periodic reports on business data
 Barbara – Business Analyst
Requires TWS to produce daily and monthly reports on business data
16
Scenario 2 – Triggers definitions flow
Paul creates an application OPCTUNA to trigger a pool of actions
(jobs) when a HFS file has been updated via FTP on a tracker system
Defining an application where operation 002 and 003 are depending on a Special Resource
named /U/FALSI/TWS. The operation 001 will set to Not Available the Special Resource for
these operations
17
Scenario 2 – Triggers definitions flow
Paul creates a triggering job using the REXX EQQRXHFS to set a special resource to
available when /u/falsi/tws is updated via FTP on a tracker system
Defining at tracker side a job causing that the Special Resource named /U/FALSI/TWS becomes available when
the modification of file /U/FALSI/TWS, on the system where the tracker is running, is completed. EQQRXHFS
utility ends when the event “modification completed” is triggered
18
Scenario 2 – Triggers definitions flow
Paul submits the job to activate the HFS file monitor. The job will trigger a Special Resource availability
The Job can be also used as predecessor to trigger the start of a job when the HFS is available on the tracker system. REXHFS job
(operation 001) ends when the HFS file is available.
19
Scenario 2 – Triggers definitions flow
Jack send daily report
Barbara monitors the Final Report Produced
When the report arrives to tracker system the TWS job is started
to format the report. The final report produced.
20
Scenario 3: File Dependencies on Windows and Unix
Focus:
 Show how to define an existence file dependency on a file residing
on a TWS distributed agent on a E2E network
 Personas:
 Jack – Bank employee
Send every day reports to Bank Information Center
 Paul – TWS Schedule Developer
Creates job streams that run periodic reports on business data
 Barbara – Business Analyst
Requires TWS to produce daily and monthly reports on business data
21
Scenario 3 – File Dependencies on Windows and Unix
Paul creates an application E2EUNACENT to trigger a pool of actions (jobs) when a HFS
file has been updated via FTP on a windows machine
Defining an application where operation 001 running on Windows check is file /U/FALSI/TWS/07.04.18 is created. The presence of this file indicates that the
report handling can start and then the formatting program is started. If RC of operation 001 is equal to 0 the operation 002 is started to send through FTP
the produced report to business office.
22
Scenario 3 – File Dependencies on Windows and Unix
Paul defines operation 001 as an E2E centralized job where the file to be monitored is definded by
variables OXJOBNAM (defined in the operation panels as extended information) and the submission
data ODATA. C:/tools/formatting is the tool formatting the incoming file ........./INPUT
23
Scenario 3 – File Dependencies on Windows and Unix
Jack send daily report
Barbara monitors the Final Report Produced
When the report arrives to windows system the TWS job is started to format
the report. The final report produced.
24
Upgrade from 8.x, Compatibility and Coexistence
 TWS 8.x Data set triggering functionality still available
 New Event Management enhancement usable
contemporaneously with old Data set Triggering to avoid
traumatic migrations
25
Future Directions and Items
Contents:
 Next Step: Integration with EDWA
 Extension of Monitored Events
26
Q’s & A’s
27
EQQEVLST – Structure
Header: Version Draft and CRC
eventRule
eventCondition: MonitorType ConditionType FiltersNumber
attributeFilter: FieldInSmfRecord operator booleanOperator
value: valueLength valueOffset value
.........................
value: valueLength valueOffset value
attributeFilter: FieldInSmfRecord operator booleanOperator
value: valueLength valueOffset value
.........................
value: valueLength valueOffset value
attributeFilter:........................................
value: .........................
action: actionType actionParameters
28