TWS for z/OS end-to-end & Z centric Implementation Best Practices

1. TWS for z/OS end-to-end & Z centricImplementation Best Practices

2. The goals • Provide some best practices and suggestions related to the end-to-end features provided by TWS for z/OS: • End-to-end with fault tolerant capabilities (aka e2e) • End-to-end with Z centric capabilities (aka Z centric) • They are intended to: • Improve the performances • Provide suggestions for a more effective usage of the feature The Agenda • Overview • Z centric • Feature exploitation • Best practices • e2e • Feature exploitation • Best practices 2

3. IBM Tivoli Workload Automation end-to-end features ... From a single point of control... Heterogeneous workloads must be seen as homogeneous, and managed from a single point of control through a unified paradigm • Single point of control to minimize the administrative oversight and time • Full impact view from the point of service delivery, for better efficiency, effectiveness and alignment of IT to business • Provide flexibility to establish the single point of control from any end-point End-to-end workload automation 3

4. End-to-end with fault tolerant capabilities It is the Plan-based End-to-end, this means: • Hierarchical topology • Optional multi-level configuration • Communication layer, USS Server • Network Fault Tolerance • Distribution of plan to agents • Monitoring allowed at agent level TWS for z/OS controller ---------- ISPF ---------- z/OS Sysplex End-to-end TWS for z/OSTopology Server Open systems Domain Manager Fault Tolerant Agent Extended Agent 4

5. End-to-end with Z centric capabilities The TWS controller acts as choreographer, this means: • Flat topology • Simplified deployment and configuration • No communication layer, no Server • Fully centralized and homogeneous control • Direct control over distributed workload TWS for z/OSTopology Server TWS for z/OS controller ---------- ISPF ---------- z/OS Sysplex Z-centric Open systems Z-centric agent Extended Agent 5

6. Cross dependencies They allows to manage heterogeneous systems by: • Defining in one scheduling environment dependencies on batch activities that are managed by another scheduling environment • Controlling the status of these dependencies by navigating from a unique user interface across the different scheduling environments • It is works both for TWS and TWS for z/OS TWS 1TWS for z/OScontroller TWS 2TWS MDM Cross dep. TWS 3TWS for z/OScontroller Cross dep. 6

7. Z centric – feature exploitation (1) • The z centric feature can be easily activated, bycustomizing the controller PARM member, by: • Setting the HTTPOPTS parameters • Adding in the ROUTOPTS statement theHTTP/HTTPS parameters • It’s very easy to add, delete or modifyz centric WSs. • There is a MODIFY commanddynamically reloading thedestination definitions:/F TW1A,RFRDEST • The same Z centric agent can run workload for various TWS for z/OS controllers at the same time • This greatly simplify the infrastructure • Reduces the maintenance effort TWS for z/OS controllers Z centricAgent 7

8. Z centric – feature exploitation (2) • It is possible to define more Z centric WSs having the same destination, this: • Allows to globally act on a subset of the overall workload ran by a certain server • can be very useful if the same server runs workload related to different LOBs. • The Z centric WSs grant the same flexibility of the z/OS WSs, this means: • Open time intervals; • Alternate WSs; • Parallel servers • It is possible to use the TWS for z/OSvariables to tailor in a “centralized way” theworkload on many distributed servers. • In the example on the right the suppliedvariable related to the extended op. name,is used to parameterize the remote file name of an FTP job 8

9. TWS for z/OS controller Z centricAgent DATASETfile elaboration Filewatchfile discovery FTP file Z centric – feature exploitation (3) • The z centric agents support the filewatch feature • It’s an executable able to perform advanced file discovery • File creation, deletion, edition. An example:filewatch -condition wcr -filename C:\ftpdir\ftp.file -int 30 -deadline 0 • It is can be very usefully integrated with the FTP job executor toautomate file discovery and transfer scenarios. • Just create an application running z centric jobs where: • The first one runs the filewatch executable • Its successor run an FTP job. • Subsequent jobs perform the file content elaboration 9

10. Z centric – best practices • The settings defined in the EQQUX001 override the other settings. A typical error scenario: • If a job ends in error with ext. status OSUB • It may be the user submitting the job is that defined in the exit and not the right one • The TWS controller has to resolve the IP addrs of the z centric agents and vice versa. A typical error scenario: • The TWS for z/OS user interface shows a jobs in “started” status • The job has been really submitted on the server hosting the z centric agent • In this case setting the HTTPOPTS HOSTNAME keyword can solve the issue. • Consider that the TWS controller tries to connecta Z centric agent only when it has to run the firstdaily job. • Check on the real status of the agent by scheduling a TSO WSSTAT command, i.e.WSSTAT SUBSYS(TW1A) WSNAME(ZAGT) STATUS(A) • This can be very useful for agents running workload during the night 10

11. DM TWS domain FTA1 FTA2 E2E – feature exploitation (1) • If an FTA is NOT a backup DM than always set CPUFULLSTAT(OFF), this: • Greatly reduces the network traffic • Reduces the number of events the activeDMs have to manage • Always use the mailman servers by setting the CPUSERVER keyword when defining an FTA or a standard agent. This: • Increases the event handling speed performed by the DMs • Make the e2e network more robust in case of network problems • Always keep the agents running jobs linkedby predecessor-successor dependencies in the same domain, this: • Reduces the network traffic • Increases the fault tolerance level 11

12. E2E – feature exploitation (2) • When designing e2e applications consider they will be “mirrored” in Symphony Job streams. Take in consideration the main “mirroring” rules: • The jobs defined on FTWS are present in theSymphony file • Just the direct predecessors of those jobs (even if they are not scheduled on FTWS) are present inthe Symphony file as well. • Designing the applications so to have smallerSymphony Job streams grant various positive effects: • Reduce the DP batch duration thanks to the shorter time needed to create the Symphony file • Increase the performances when e2e applicationsare dynamically added in the CP • Increase the performance of the TWS agents especially when they runs not centralized scripts MasterDomain ManagerOPCMASTER Current Plan Domain ManagerDOM1 Symphony FTAFTW2 FTAFTW1 Symphony Symphony 12

13. 5 10 10 10 15 5 255 10 30 20 255 15 25 35 15 15 255 30 20 E2E – feature exploitation (3) • It can be useful adding a dummy predecessoron NON REP WS (see op. 15) • The Symphony file can contain unconnected operations, so creating applications whosejobs are connected just by a dummy successorcan make smaller Symphony job streams(see ops. 30 and 20) z/OS Plan App1 App4 App5 App1 Symphony App2 App2 App3 App3 13

14. E2E – best practices (1) • Consider to increase the size of the datasets EQQTWSCS, EQQTWSIN EQQTWSOU • Event loss could occur if thy are note well sized • Especially if a lot of dynamic additions are performed • Take in consideration the evtzise cmd to increase the max reachable size of the event files (such as Mailbox.msg or Intercom.msg) • This works both for the files present in the e2e server work directory and for the TWS agents • The manual “Scheduling End-to-end with Fault Tolerance Capabilities” documents this command usage. • In case of server maintenance take in considerationto set the CPUREC parameter CPUAUTOLNK(OFF) • It makes “manual” the TWS agent initialization • No time is wasted in trying to initialize it • A Symphony renew is sufficient to activate it 14

15. E2E – best practices (2) • The workload throughput of the agent can be globally managed by using the CPUREC CPULIMIT parameter. • This is very useful if a server hosting a TWS agent seems to be too much stressed • By setting it to 0 it’s possible to keep the agent active avoiding the job submission • The parameter can be changed: • by submitting a symphony renew • In dynamic way, by using the TWS agent admin. CLI conman(i.e.: “conman lc FTA1; 0” ) • If different kind of workloads have to be run on the same server (i.e. they refer to different LOBs) • It’s NOT needed the installation of moreagents (this could stress the server) • Some agents could be “simulated” by using local UNIX extended agents • This is possible just on UNIX servers 15

16. 16