Event Management for TWS for z/Os Tivoli Workload Scheduler for z/Os 8.5 IBM Tivoli Software

1. Event Management for TWS for z/Os Tivoli Workload Scheduler for z/Os 8.5 IBM Tivoli Software Paolo Falsi

2. 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.

3. Agenda • Agenda • Introduction to Event Management enhancements • Using triggers to Customize the Workload: • Scenario 1: Triggers definitions flow • Scenario 2: Trigger on HFS file • Scenario 3:File Dependencies on Windows and Unix • Upgrade from 8.x, Compatibility and Coexistence • Future Directions and Items • Q’s & A’s

4. 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

5. 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

6. 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 filesat 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.

7. 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

8. 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 employeeSend every day reports to Bank Information Center • Paul – TWS Schedule DeveloperCreates job streams that run periodic reports on business data • Barbara – Business AnalystRequires TWS to produce daily and monthly reports on business data

9. 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 Availablethe Special Resource for these operations

10. 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

11. 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

12. Scenario 1 – Triggers definitions flow Paul chooses option 3

13. Scenario 1 – Triggers definitions flow Dataset name identify the input where the XML event rules are defined. SYSIN can be used.

14. 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

15. 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.

16. Scenario 2: Trigger on HFS file • Focus: • Show how to use as trigger an HFS file located in a tracker system • Personas: • Jack – Bank employeeSend every day reports to Bank Information Center • Paul – TWS Schedule DeveloperCreates job streams that run periodic reports on business data • Barbara – Business AnalystRequires TWS to produce daily and monthly reports on business data

17. 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 Availablethe Special Resource for these operations

18. 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

19. 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.

20. 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.

21. 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 employeeSend every day reports to Bank Information Center • Paul – TWS Schedule DeveloperCreates job streams that run periodic reports on business data • Barbara – Business AnalystRequires TWS to produce daily and monthly reports on business data

22. 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.

23. 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

24. 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.

25. 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

26. Future Directions and Items • Contents: • Next Step: Integration with EDWA • Extension of Monitored Events

27. Q’s & A’s

28. 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