0% found this document useful (0 votes)

123 views117 pages

TWS8.5 Overview

Uploaded by

bravichandra24

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

123 views117 pages

TWS8.5 Overview

Uploaded by

bravichandra24

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 117

Tivoli Workload Automation

Version 8.5

Overview

SC32-1256-07
Tivoli Workload Automation
®

Version 8.5

Overview

SC32-1256-07
Note
Before using this information and the product it supports, read the information in “Notices” on page 95.

This edition applies to version 8, release 5 of IBM Tivoli Workload Automation (program numbers 5698-A17,
5698-WSH, and 5698-WSE) and to all subsequent releases and modifications until otherwise indicated in new
editions.
This edition replaces SC32-1256-06.
© Copyright International Business Machines Corporation 1991, 2008.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . v Role of the scheduling manager as the focal point 20
Role of the operations manager. . . . . . . 21
About this publication . . . . . . . . vii A powerful tool for the shift supervisor . . . . 21
Role of the application programmer . . . . . 21
What is new in this release . . . . . . . . . vii
Console operators . . . . . . . . . . . 21
What is new in this publication . . . . . . . vii
Workstation operators . . . . . . . . . . 21
Who should read this publication . . . . . . . vii
End users and the service desk . . . . . . . 22
What this publication contains. . . . . . . . viii
Summary . . . . . . . . . . . . . . . 22
Publications . . . . . . . . . . . . . . viii
Accessibility . . . . . . . . . . . . . . ix
Tivoli technical training . . . . . . . . . . ix Chapter 4. Tivoli Workload Automation
Support information . . . . . . . . . . . ix and ITUP . . . . . . . . . . . . . . 23
How to read the syntax diagrams . . . . . . . ix The ITUP processes. . . . . . . . . . . . 23
Service execution and workload management . . . 23
| Chapter 1. Summary of enhancements . 1 Managing workload with Tivoli Workload
| New Tivoli Workload Scheduler and Tivoli Dynamic Automation . . . . . . . . . . . . . . 24
| Workload Console features . . . . . . . . . 1
| Installation improvements . . . . . . . . . 1 | Chapter 5. Who performs workload
| Variable tables . . . . . . . . . . . . . 2 | management . . . . . . . . . . . . 27
| Workload Service Assurance . . . . . . . . 3
| Problem determination and troubleshooting Chapter 6. A business scenario . . . . 29
| enhancements . . . . . . . . . . . . . 5
The company . . . . . . . . . . . . . . 29
| Enhanced integration features . . . . . . . 5
The challenge. . . . . . . . . . . . . . 31
| New Tivoli Dynamic Workload Console features . . 5 The solution . . . . . . . . . . . . . . 32
| Tivoli Workload Scheduler for Applications features 5 Typical everyday scenarios . . . . . . . . 36
| Support for Internet Protocol version 6 (IPv6) . . 6
Managing the workload . . . . . . . . 37
| New installation launchpad . . . . . . . . 6
Monitoring the workload . . . . . . . . 39
| Displaying and rerunning of SAP process chains . 6
Managing the organization of the IT
| Balancing of SAP workload using server groups . 6
infrastructure . . . . . . . . . . . . 40
| Exporting of SAP factory calendars . . . . . . 6
The benefits . . . . . . . . . . . . . . 41
| Definition of internetwork dependencies and
| event rules based on SAP events. . . . . . . 7
| Definition of event rules based on IDoc records. . 7 Chapter 7. Tivoli Workload Scheduler 43
| Summary of product enhancements for Tivoli Overview . . . . . . . . . . . . . . . 43
| Workload Scheduler for z/OS . . . . . . . . 8 What is Tivoli Workload Scheduler . . . . . 43
The Tivoli Workload Scheduler network . . . . 44
Manager and agent types . . . . . . . . . 45
Chapter 2. Interoperability notes . . . . 11
Topology . . . . . . . . . . . . . . 45
Interoperability of the components. . . . . . . 11
Networking . . . . . . . . . . . . . 46
| Interoperability tables . . . . . . . . . . . 12 Tivoli Workload Scheduler components . . . . 47
Tivoli Workload Scheduler scheduling objects . . 48
Chapter 3. Overview of Tivoli Workload The production process . . . . . . . . . 50
Automation . . . . . . . . . . . . . 15 Scheduling . . . . . . . . . . . . . . 51
The state-of-the-art solution . . . . . . . . . 15 Defining scheduling objects . . . . . . . . 51
Comprehensive workload planning . . . . . 16 Creating job streams . . . . . . . . . . 51
Centralized systems management . . . . . . 16 Setting job recovery . . . . . . . . . . 51
Systems management integration . . . . . . 16 Integration with Tivoli Enterprise Data
Automation . . . . . . . . . . . . . 18 Warehouse. . . . . . . . . . . . . . 52
Workload monitoring . . . . . . . . . . 18 Running production . . . . . . . . . . . 52
Automatic workload recovery . . . . . . . 19 Running the plan . . . . . . . . . . . 52
Productivity . . . . . . . . . . . . . 19 Running job streams . . . . . . . . . . 53
Business solutions . . . . . . . . . . . . 19 Monitoring . . . . . . . . . . . . . 54
User productivity . . . . . . . . . . . . 19 Controlling with IBM Tivoli Monitoring . . . 54
Growth incentive . . . . . . . . . . . . 19 Reporting . . . . . . . . . . . . . . 55
How Tivoli Workload Automation benefits your Auditing . . . . . . . . . . . . . . 55
staff . . . . . . . . . . . . . . . . . 20 | Using event-driven workload automation . . . 56

© Copyright IBM Corp. 1991, 2008 iii

Options and security . . . . . . . . . . . 56 | Chapter 10. Tivoli Dynamic Workload
Setting the Tivoli Workload Scheduler options . . 56 | Console . . . . . . . . . . . . . . 79
Setting security . . . . . . . . . . . . 57
Secure authentication and encryption . . . . 57
Work across firewalls . . . . . . . . . 57
Chapter 11. Tivoli Job Scheduling
Centralized security mechanism . . . . . 58 Console . . . . . . . . . . . . . . 81
Using time zones . . . . . . . . . . . 58 Overview . . . . . . . . . . . . . . . 81
Using extended agents. . . . . . . . . . . 58 Tivoli Workload Scheduler for z/OS tasks . . . . 82
Scheduler tasks . . . . . . . . . . . . 82
Chapter 8. Tivoli Workload Scheduler Working with job streams . . . . . . . 82
Working with jobs . . . . . . . . . . 82
for z/OS . . . . . . . . . . . . . . 61 Working with workstations . . . . . . . 83
How your production workload is managed . . . 61 Working with resources . . . . . . . . 83
Structure . . . . . . . . . . . . . . 61 Operator tasks . . . . . . . . . . . . 83
Concepts . . . . . . . . . . . . . . 61 Working with job stream instances. . . . . 83
Using Plans in Tivoli Workload Scheduler for Working with job instances . . . . . . . 83
z/OS . . . . . . . . . . . . . . . 64 Working with workstations in the plan . . . 84
Long-term planning . . . . . . . . . 64 Working with resources in the plan . . . . 84
Detailed planning . . . . . . . . . . 64 Tivoli Workload Scheduler tasks . . . . . . . 84
Automatically controlling the production Scheduler tasks . . . . . . . . . . . . 84
workload . . . . . . . . . . . . . . 65 Working with job streams . . . . . . . 85
Automatic workload submission . . . . . 66 Working with jobs . . . . . . . . . . 85
Automatic recovery and restart . . . . . . 66 Working with calendars . . . . . . . . 85
z/OS automatic restart manager support . . 68 Working with prompts . . . . . . . . 85
Workload Manager (WLM) support . . . . 68 Working with parameters. . . . . . . . 85
Automatic status checking . . . . . . . 68 Working with domains . . . . . . . . 86
Status reporting from heterogeneous Working with workstations . . . . . . . 86
environments . . . . . . . . . . . . 69 Working with workstation classes . . . . . 86
Status reporting from user programs . . . . 69 Working with resources . . . . . . . . 86
Additional job-completion checking . . . . 69 Working with users. . . . . . . . . . 86
Managing unplanned work . . . . . . . 69 Operator tasks . . . . . . . . . . . . 87
Interfacing with other programs . . . . . . 69 Working with job stream instances. . . . . 87
Manual control and intervention . . . . . . 69 Working with job instances . . . . . . . 87
Status inquiries . . . . . . . . . . . 70 Working with workstations . . . . . . . 87
Modifying the current plan . . . . . . . 70 Working with domains . . . . . . . . 88
Management of critical jobs . . . . . . . . 71 Working with file dependencies . . . . . 88
Security . . . . . . . . . . . . . . 71 Working with prompt dependencies . . . . 88
Audit trail . . . . . . . . . . . . . 71 Working with resource dependencies . . . . 88
System authorization facility. . . . . . . 72 Common tasks . . . . . . . . . . . . . 88
Protection of data and resources . . . . 72
Data integrity during submission . . . . 72
Configurations of Tivoli Workload Scheduler for
Chapter 12. End-to-end scheduling . . 91
z/OS . . . . . . . . . . . . . . . . 72 How end-to-end scheduling works . . . . . . 91
The controlling system . . . . . . . . . 72 Distributed agents . . . . . . . . . . . . 93
Controlled z/OS systems . . . . . . . . . 73 Benefits of end-to-end scheduling . . . . . . . 93
Remote systems . . . . . . . . . . . 74
Remote panels and program interface Notices . . . . . . . . . . . . . . 95
applications . . . . . . . . . . . . . 74 Trademarks . . . . . . . . . . . . . . 96
Scheduling jobs that are in Tivoli Workload
Scheduler . . . . . . . . . . . . . . 74 Index . . . . . . . . . . . . . . . 99

| Chapter 9. Tivoli Dynamic Workload

| Broker . . . . . . . . . . . . . . . 75

iv IBM Tivoli Workload Automation: Overview

Figures
1. The Fine Cola company integrated workload 5. How extended agents work . . . . . . . 59
solution . . . . . . . . . . . . . . 32 6. Automatic recovery and restart . . . . . . 67
2. Integration between Tivoli Workload Scheduler 7. Production workload restart and hot standby 68
and Tivoli Dynamic Workload Broker . . . . 34 8. Security . . . . . . . . . . . . . . 71
3. How to satisfy SLA response time during peak 9. Tivoli Workload Scheduler for z/OS
oeriods using Tivoli Workload Scheduler and configurations. . . . . . . . . . . . 73
Tivoli Dynamic Workload Broker . . . . . 39 10. End-to-end configuration . . . . . . . . 92
4. This Tivoli Workload Scheduler network is
made up by two domains . . . . . . . . 44

© Copyright IBM Corp. 1991, 2008 v

vi IBM Tivoli Workload Automation: Overview
About this publication
IBM® Tivoli® Workload Automation Overview describes the suite of Tivoli Workload
Scheduler and its enterprise workload management functions. This publication
provides introductory information about the following products. It does not
provide detailed technical explanations about how they work.
v Tivoli Workload Scheduler
v Tivoli Dynamic Workload Broker
v Tivoli Workload Scheduler for Applications
v Tivoli Workload Scheduler for z/OS®
v Tivoli Dynamic Workload Console
v Tivoli Job Scheduling Console

This publication describes:

v The structure of the product
v Where it fits in single-host and multiple-host systems
v Major functions
v How it works with other products

What is new in this release

For information about the new or changed functions in this release, see Chapter 1,
“Summary of enhancements,” on page 1.

For information about the APARs that this release addresses, see the Tivoli
Workload Scheduler Download Document at http://www.ibm.com/support/
docview.wss?rs=672&uid=swg24018908.

What is new in this publication

This section describes what has changed in this publication since version 8.4.

Note: Changed or added text with respect to the previous version is marked by a
vertical bar in the left margin.

| The following changes were made:

| v Chapter 1, “Summary of enhancements” lists the product enhancements
| available in this version.
| v Chapter 2, “Interoperability notes,” on page 11 is updated to document
| interoperability between version 8.5 and previous versions.
| v Chapter 5, “Who performs workload management,” on page 27 provides an
| updated description of the professionals typically involved with scheduling.
| v Chapter 9, “Tivoli Dynamic Workload Broker,” on page 75 and Chapter 10,
| “Tivoli Dynamic Workload Console,” on page 79 are new.

Who should read this publication

This publication is intended for:

© Copyright IBM Corp. 1991, 2008 vii

Who should read this publication

v Data processing (DP) operations managers and their technical advisors who are
evaluating the product or planning their scheduling service
v Individuals who require general information for evaluating, installing, or using
the product.

What this publication contains

This publication contains the following chapters:
v Chapter 1, “Summary of enhancements”
Describes the product enhancements available in this version.
v Chapter 2, “Interoperability notes,” on page 11
Contains interoperability and coexistence information for the Tivoli Workload
Automation products and their versions.
v Chapter 3, “Overview of Tivoli Workload Automation”
Provides an overall description of the Tivoli Workload Automation.
v Chapter 4, “Tivoli Workload Automation and ITUP”
Positions the Tivoli Workload Automation within the IBM Tivoli Unified Process
(ITUP).
| v Chapter 5, “Who performs workload management”
| Describes the professionals who are typically involved with job scheduling.
v Chapter 6, “A business scenario”
Describes how an enterprise can use Tivoli Workload Scheduler to improve its
production flow.
v Chapter 7, “Tivoli Workload Scheduler”
Describes the features of Tivoli Workload Scheduler.
v Chapter 8, “Tivoli Workload Scheduler for z/OS”
Describes the features of Tivoli Workload Scheduler for z/OS.
| v Chapter 9, “Tivoli Dynamic Workload Broker”
| Provides an overview of the Tivoli Dynamic Workload Broker.
| v Chapter 10, “Tivoli Dynamic Workload Console”
| Provides an overview of the Tivoli Dynamic Workload Console.
v Chapter 11, “Tivoli Job Scheduling Console”
Provides an overview of the Tivoli Job Scheduling Console and of its features.
v Chapter 12, “End-to-end scheduling”
Provides an overview of how you can use Tivoli Workload Scheduler and Tivoli
Workload Scheduler for z/OS jointly to schedule jobs both in the host and
distributed environments.

Publications
Full details of Tivoli Workload Scheduler publications can be found in Tivoli
Workload Automation: Publications. This document also contains information on the
conventions used in the publications.

A glossary of terms used in the product can be found in Tivoli Workload Automation:
Glossary.

Both of these are in the Information Center as separate publications.

viii IBM Tivoli Workload Automation: Overview

Accessibility

Accessibility
Accessibility features help users with a physical disability, such as restricted
mobility or limited vision, to use software products successfully. With this product,
you can use assistive technologies to hear and navigate the interface. You can also
use the keyboard instead of the mouse to operate all features of the graphical user
interface.

For full information with respect to the Job Scheduling Console, see the
Accessibility Appendix in the Tivoli Workload Scheduler: Job Scheduling Console User’s
Guide.

For full information with respect to the Tivoli Dynamic Workload Console, see the
Accessibility Appendix in the Tivoli Workload Scheduler: User's Guide and Reference.

Tivoli technical training

For Tivoli technical training information, refer to the following IBM Tivoli
Education Web site:

http://www.ibm.com/software/tivoli/education

Support information
If you have a problem with your IBM software, you want to resolve it quickly. IBM
provides the following ways for you to obtain the support you need:
v Searching knowledge bases: You can search across a large collection of known
problems and workarounds, Technotes, and other information.
v Obtaining fixes: You can locate the latest fixes that are already available for your
product.
v Contacting IBM Software Support: If you still cannot solve your problem, and
you need to work with someone from IBM, you can use a variety of ways to
contact IBM Software Support.

For more information about these three ways of resolving problems, see the
appendix on support information in Tivoli Workload Scheduler: Troubleshooting Guide.

How to read the syntax diagrams

Throughout this publication, syntax is described in diagrams like the one shown
here, which describes the SRSTAT TSO command:

SRSTAT ' resource name '

OPCA
SUBSYS( subsystem name )
MSTR

KEEP KEEP
AVAIL( RESET ) DEVIATION( amount )
NO RESET
YES

About this publication ix

How to read syntax diagrams

KEEP YES
QUANTITY( amount ) CREATE( NO )
RESET

0
TRACE( trace level )

The symbols have these meanings:

򐂰򐂰─────
The statement begins here.
──────򐂰
The statement is continued on the next line.
򐂰──────
The statement is continued from a previous line.
─────򐂰򙳰
The statement ends here.
2 right arrow heads at beginning of line
The statement begins here.
1 right arrow head at end of line
The statement is continued on the next line.
1 right arrow head at beginning of line
The statement is continued from a previous line.
One right arrow head, one left arrow head at end of line
The statement ends here.

Read the syntax diagrams from left to right and from top to bottom, following the
path of the line.

These are the conventions used in the diagrams:

v Required items appear on the horizontal line (main path):

STATEMENT required item

v Optional items appear below the main path:

STATEMENT
optional item

v An arrow returning to the left above the item indicates an item that you can
repeat. If a separator is required between items, it is shown on the repeat arrow.

STATEMENT repeatable item

v If you can choose from two or more items, they appear vertically in a stack.
– If you must choose one of the items, one item of the stack appears on the
main path:

x IBM Tivoli Workload Automation: Overview

How to read syntax diagrams

STATEMENT required choice 1

required choice 2

– If choosing one of the items is optional, the entire stack appears below the
main path:

STATEMENT
optional choice 1
optional choice 2

– A repeat arrow above a stack indicates that you can make more than one
choice from the stacked items:

STATEMENT
optional choice 1
optional choice 2
optional choice 3

STATEMENT required choice 1

required choice 2
required choice 3

v Parameters that are above the main line are default parameters:

default
STATEMENT
alternative

v Keywords appear in uppercase (for example, STATEMENT).

v Parentheses and commas must be entered as part of the command syntax as
shown.
v For complex commands, the item attributes might not fit on one horizontal line.
If that line cannot be split, the attributes appear at the bottom of the syntax
diagram:

STATEMENT required choice 1

option 1 option 2
required choice 2
required choice 3

option 1

default
optional choice 1( alternative )

About this publication xi

How to read syntax diagrams

option 2

default
optional choice 2( alternative )

xii IBM Tivoli Workload Automation: Overview

| Chapter 1. Summary of enhancements

| This chapter includes:
| v An overview of the new features provided with version 8.5 of Tivoli Workload
| Scheduler and Tivoli Dynamic Workload Console
| v A summary of the enhancements included in Tivoli Workload Scheduler for
| Applications version 8.4 Fix Pack 1
| v A summary of the product enhancements released by PTF for Tivoli Workload
| Scheduler for z/OS version 8.3
|
| New Tivoli Workload Scheduler and Tivoli Dynamic Workload Console
| features
| This section describes the features introduced with Tivoli Workload Scheduler
| version 8.5:
| v “Installation improvements”
| v “Variable tables” on page 2
| v “Workload Service Assurance” on page 3
| v “Problem determination and troubleshooting enhancements” on page 5

| Installation improvements
| The installation process is significantly improved by the following enhancements:
| Common shared architecture for Tivoli Workload Scheduler and Tivoli Dynamic
| Workload Console
| Tivoli Workload Scheduler and Tivoli Dynamic Workload Console are from
| this version capable of reciprocal discovery. When one of them is found
| already installed, the installer, while setting up the other, is given the
| option to optimize the installation and have a shared middleware and
| common installation layout. If this option is selected, the two components
| will share the same embedded WebSphere application server. The result is
| that disk space and memory consumption is greatly optimized and access
| to the administration tools to browse and collect administration
| information is highly simplified.
| The installation interfaces for the two components now share the same
| look and feel. The consistency in messages and labels for these two
| components is greatly improved. In addition, all the log and trace files will
| be located in the same directory. Problem determination and
| troubleshooting are greatly simplified by this and by the possibility to
| share the same tools to manage the installed middleware.
| The revised Planning and Installation Guide now includes all the installation
| documentation for both Tivoli Workload Scheduler and Tivoli Dynamic
| Workload Console, including installation troubleshooting and messages.
| Enhanced installation launchpad
| The installation launchpad is an alternative way to install or upgrade
| Tivoli Workload Scheduler and Tivoli Dynamic Workload Console, or
| install Job Scheduling Console and Tivoli Enterprise Console. It is a
| powerful tool that guides you through the installation process by
| providing information about the shared infrastructure and simplifying

© Copyright IBM Corp. 1991, 2008 1

Summary of enhancements

| choice-making during the deployment and configuration phases. It

| provides a graphical representation of a typical network topology layout
| for a small and medium business environment making the selection of the
| components to deploy more intuitive. You can also use it to familiarize
| yourself with the product documentation and access the following sources
| of information:
| v Downloadable documentation
| v IBM Tivoli Information Center
| v IBM Publications Center
| Automatic response file generation during the Tivoli Workload Scheduler and
| Tivoli Dynamic Workload Console installation and upgrade processes
| You now have the option, during the installation process, to require that a
| response file is generated with the selections made during the process. The
| generated response file can then be used to clone the installation on a
| number of other systems, greatly simplifying the product deployment
| process. Thus, the initial installation can be verified in a test environment
| and, once passed and tuned, can be replicated in a production
| environment, reducing the risk of failures and inconsistencies.
| Addition of diagnosis and resume of a failed Tivoli Dynamic Workload Console
| installation
| In the same way as Tivoli Workload Scheduler, also Tivoli Dynamic
| Workload Console can automatically detect a number of specific failing
| points during installation, so that you can correct the problem and rerun
| the steps in error.
| Fix pack Rollback Function for Tivoli Dynamic Workload Console
| Automatic upgrading from previous versions is now possible. In addition,
| a rollback function is available for when a fix pack is applied.

| Variable tables
| Variable tables are new scheduling objects that can help you to reuse job and job
| stream definitions.

| In Tivoli Workload Scheduler version 8.5, what were previously called global
| parameters are referred to as variables. You can now place your defined variables
| into variable tables which are simply collections of variables. You can define
| variables with the same name and different values and save them in different
| tables. You can then use such tables in job stream and workstation definitions and
| in run cycles to provide different input values according to which table is in use.

| In job definitions, variables are now referenced in the form:

| variable_table_name.variable_name

| You can use variable tables in the definitions of run cycles, job streams, and
| workstations. This means that you can specify a table to be used for resolving
| variables when workload instances are generated from these objects. Likewise, you
| can specify the variable_table_name.variable_name combination in submit
| operations.

| There is one default variable table and this is where all the variables previously
| defined in the database are included upon migration from previous versions. If
| you choose not to use variable tables, all the variables you define are nevertheless

2 IBM Tivoli Workload Automation: Overview

Summary of enhancements

| included in the default variable table. The default table is used for the resolution of
| variables if no other tables are defined or specified together with the variables in
| the job definitions.

| The benefit of using variable tables is that you can more easily replace variable
| input data in job definitions used as templates for jobs running in more than one
| job stream. This is explained by the following examples:
| v You run the same job stream on Mondays and Fridays, but on Mondays it uses
| different input files from Fridays, because the same work is run on different
| data. To do this, you create a single job stream with two run cycles, referencing
| two different variable tables. You then define file dependencies on jobs using
| variables, forcing instances generated on Mondays to use different variable
| values from the instances generated on Fridays.
| v For security reasons, a job must run in a specific job stream with restricted
| permissions compared to the ones that are normally applied to the same job in
| other job streams. An easy way to accomplish this, when specifying the user
| logon in the job definition, is to use a variable name and then set the
| unrestricted user value for that variable name in the default table, while setting
| the user with restricted permissions as a value for the same variable name in a
| separate table. By assigning this table to the job stream that needs to run the job
| with restricted permissions, you can address the problem without having to
| create a duplicate job definition for that specific job stream.
| v A number of jobs use the SQLPLUS utility to run SQL reports on Oracle databases.
| Jobs that run on different workstations might need to find SQLPLUS in different
| installation paths. Hard-coding the path to the Oracle instance in the task string
| of each job would bind each job to a workstation and require a change in the
| task string if the job definition is moved from one workstation to another. You
| can define a specific variable table to each workstation on which Oracle is
| installed, define a variable for the Oracle installation path, and use that variable
| in the task string of each job that runs SQLPLUS. At plan time, each task string is
| be determined after resolving the Oracle installation path against the variable
| table that is assigned to the workstation on which each job runs.
| v You want to test the scheduling workload on production machines without
| running real jobs, but just test ones. To do this, you use variables in the
| definition of the task string of each job, and then set up two different variable
| tables: one with the real tasks and one with test tasks. When you set the first
| table as default and you extend the plan with JnextPlan, you are actually
| creating the production plan. When you set the second table as default, at the
| next plan extension you are creating the test plan. By having the ability to
| manage different tables of variables, you no longer need to change all values in
| job definitions, and do not lose the values to be restored when you decide to
| switch back to the production plan.

| Workload Service Assurance

| Workload Service Assurance increases Job scheduling personnel's confidence in
| their ability to meet their service level agreements. Using Workload Service
| Assurance, Job schedulers can flag mission critical jobs for privileged processing
| throughout the scheduling process. At plan runtime the Workload Service
| Assurance components, Time Planner and Plan Monitor, dynamically monitor that
| the conditions for the timely completion of mission critical jobs are met and
| automatically promote these jobs or their predecessors if they are late.

| Job schedulers can use the Tivoli Workload Scheduler command line or the Tivoli
| Dynamic Workload Console to flag jobs as mission-critical and specify their

Chapter 1. Summary of enhancements 3

Summary of enhancements

| deadlines. A critical job and all its predecessors make up what is called a critical
| network. At planning time, Tivoli Workload Scheduler calculates the start time of
| the critical job and of each of its predecessors starting from the critical job deadline
| and estimated duration. While the plan runs, this information is dynamically kept
| up-to-date based on how the plan is progressing. If a predecessor, or the critical job
| itself, is becoming late, Tivoli Workload Scheduler automatically prioritizes its
| submission and promotes it to get more system resources and thus meet its
| deadline.

| Within a critical network, Tivoli Workload Scheduler dynamically identifies the

| path of predecessors that is potentially most at risk; this is called the critical path.
| Tivoli Workload Scheduler calculates the level of risk that each critical job has of
| missing its deadline; a high risk indicates that the estimated end of the critical job
| is after its deadline while a potential risk indicates that some predecessors of the
| critical job have a warning condition, for example are late or in error.

| The Tivoli Dynamic Workload Console provides specialized views for tracking the
| progress of critical jobs and their predecessors. Job schedulers and operators can
| access the views from the Dashboard or by creating Monitor Critical Jobs tasks.

| The initial view lists all critical jobs for the engine, showing the status: normal,
| potential risk, or high risk. From this view, an operator can navigate to see:
| v The hot list of jobs that put the critical deadline at risk.
| v The critical path.
| v Details of all critical predecessors.
| v Details of completed critical predecessors.
| v Job logs of jobs that have already run.

| Using the views, operators can monitor the progress of the critical network , find
| out about current and potential problems, release dependencies, and rerun jobs.

| For example:
| 1. To flag a critical job and follow it up, the Job scheduler opens the Workload
| Designer on the Tivoli Dynamic Workload Console, marks the specific job as
| critical, and sets the deadline for 5 a.m.
| When JnextPlan is run, the critical start dates for this job, and all the jobs that
| are identified as its predecessors, are calculated.
| 2. To track a specific critical job, the operator proceeds as follows:
| a. The operator checks the dashboards and sees that there are critical jobs
| scheduled on one of the engines.
| b. He clicks the link to get a list of the critical jobs.
| The specific job shows a Potential Risk status.
| c. He selects the job and clicks Hot List to see the predecessor job or jobs that
| are putting the critical job at risk.
| One of the predecessor jobs is listed as being in error.
| d. He selects the job and clicks Job log.
| The log shows that the job failed because of incorrect credentials for a
| related database.
| e. After discovering that the database password was changed that day, he
| changes the job definition in the symphony file and reruns the job.

4 IBM Tivoli Workload Automation: Overview

Summary of enhancements

| f. When he comes back to the dashboard, he notices that there are no longer
| any jobs in potential risk. Also, the critical jobs list that was opened when
| clicking on the potential risk link no longer shows the critical job after the
| job is rerun.
| g. The job is now running after being automatically promoted, getting higher
| priority for submission and system resources.
| h. No further problems need fixing and the critical job finally completes at
| 4.45 a.m.

| Problem determination and troubleshooting enhancements

| The IBM Support Assistant (ISA) and Log Analyzer tools are integrated in a single
| tool under the common Eclipse framework. This considerably simplifies problem
| analysis and determination for Tivoli Workload Scheduler. In addition, the new
| Log Analyzer provides an updated Symptom Catalog DB built upon the most
| significant Tech Notes and PMRs. In this way the tool, by parsing and correlating a
| set of log files, can automatically identify and show the related Tech Note that
| addresses and solves a problem traced by the log files. The Symptom DB is
| periodically updated when new significant and valuable Tech Notes are published.

| IBM Support Assistant can be downloaded for free from the IBM software support
| Web page.

| Enhanced integration features

| Tivoli Workload Scheduler version 8.5 supports new integration with:
| v Tivoli Dynamic Workload Broker version 1.2
| v Tivoli Storage Manager version 5.4 and later

| See IBM Tivoli Workload Scheduler: Integrating with Other Products for information on
| how Tivoli Workload Scheduler integrates with these and other products.
|
| New Tivoli Dynamic Workload Console features
| Tivoli Dynamic Workload Console version 8.5 includes modeling and topology
| functions. You can now use a single graphical user interface to model and monitor
| your workload environment.

| A Workload Designer was added for modeling, covering all the use cases related to
| creating and maintaining the definition of the automation workload, such as jobs,
| job streams, resources, variable tables, workstation classes, and their dependencies.

| You can now use the Tivoli Dynamic Workload Console to define Tivoli Workload
| Scheduler topology objects, covering all the use cases related to the definition and
| maintenance of the scheduling environment, such as workstations and domains.
|
| Tivoli Workload Scheduler for Applications features
| This section describes the features introduced with Tivoli Workload Scheduler for
| Applications version 8.4 Fix Pack 1:
| v “Support for Internet Protocol version 6 (IPv6)” on page 6
| v “New installation launchpad” on page 6
| v “Displaying and rerunning of SAP process chains” on page 6
| v “Balancing of SAP workload using server groups” on page 6
| v “Exporting of SAP factory calendars” on page 6
Chapter 1. Summary of enhancements 5
Summary of enhancements

| v “Definition of internetwork dependencies and event rules based on SAP events”

| on page 7
| v “Definition of event rules based on IDoc records” on page 7

| Support for Internet Protocol version 6 (IPv6)

| The product supports Internet Protocol version 6 (IPv6) in addition to legacy IPv4.
| Support to IPv6 is provided only on the z/OS extended agent with the following
| software requirements:
| v Tivoli Workload Scheduler version 8.4, or later
| v TCP/IP on IBM 3.1, or later

| New installation launchpad

| A new launchpad is available for installing any or all of the following on both
| UNIX and Windows systems:
| v One or more access methods to interact with Oracle E-Business Suite, Peoplesoft,
| SAP R/3, and z/OS.
| v The Option Editor, a graphical tool to help you configure your environment.
| v One or more Tivoli Workload Scheduler for Applications language packs.

| The launchpad must be accessed with one of the following Web browsers:
| v Mozilla, version 1.7 and later
| v Firefox, version 1.0 and later
| v Microsoft Internet Explorer Version 5.5 and later (for Windows operating
| systems only)

| Displaying and rerunning of SAP process chains

| Using the Tivoli Dynamic Workload Console, now you can:
| v Display details about an SAP process chain that you scheduled as a Tivoli
| Workload Scheduler job, and any local subchains it contains.
| v Rerun a Tivoli Workload Scheduler job that submits an SAP process chain,
| choosing among the following behaviors:
| – Submitting a new process chain instance.
| – Rerunning the original process chain from the failed processes.
| – Restarting a specific process of the original process chain.
| – Updating the status and details of the original process chain.

| Balancing of SAP workload using server groups

| With SAP Basis version 6.10 and later, application servers can be assigned to server
| groups. Now, with Tivoli Workload Scheduler for Applications you can assign a
| server group to a job. In this way, when a job is launched, the SAP system runs it
| on an application server that belongs to that group, balancing the workload among
| the various application servers. If the application servers defined in a group are
| modified in the SAP system, the job defined as belonging to that server group is
| not affected and does not need to be modified. The batch execution targets are
| reorganized in the SAP system without having to change job definitions in Tivoli
| Workload Scheduler for Applications.

| Exporting of SAP factory calendars

| To keep the Tivoli Workload Scheduler and SAP calendar definitions synchronized
| and avoid duplicating data maintenance in the two environments, you can export
| SAP factory calendars into a format that can be processed by the Tivoli Workload

6 IBM Tivoli Workload Automation: Overview

Summary of enhancements

| Scheduler composer command line. As a consequence, you can import the calendar
| definitions from SAP into the Tivoli Workload Scheduler database, with the result
| that the Tivoli Workload Scheduler calendars becomes synchronized with the
| existing SAP factory calendars.

| Definition of internetwork dependencies and event rules

| based on SAP events
| Using the Tivoli Dynamic Workload Console or composer command line, you can
| define SAP events as internetwork dependencies that must be satisfied before a
| Tivoli Workload Scheduler job or job stream can start. In response to an
| internetwork dependency, the SAP extended agent checks for the occurrence of the
| SAP event specified in the dependency. As soon as the SAP event is raised, the
| SAP extended agent commits the event and instructs Tivoli Workload Scheduler to
| resolve the corresponding internetwork dependency.

| To define SAP events as internetwork dependencies, XBP versions 2.0 and 3.0 are
| supported, with the following differences:
| XBP version 2.0
| SAP events can release Tivoli Workload Scheduler internetwork dependencies
| only if the dependencies are created or checked before the SAP event is raised.
| An event history is ignored, therefore an SAP event raised before the
| internetwork dependency is created is not considered.
| XBP version 3.0 (supported by SAP NetWeaver 7.0 with SP 9, or later)
| Only the SAP events stored in the SAP event history table are considered by
| Tivoli Workload Scheduler to check for internetwork dependencies resolution.
| As a prerequisite, the SAP administrator must create the appropriate event
| history profiles and criteria on the target SAP system.

| You can also create event rules based on one or more SAP events, to define a set of
| actions that are to run when specific event conditions occur. The definition of an
| event rule correlates events and triggers actions. Whenever you define an event
| rule based on an SAP event in your Tivoli Workload Scheduler plan, that event is
| monitored by Tivoli Workload Scheduler.

| Monitoring SAP events is allowed only if you use XPB version 3.0, or later. Tivoli
| Workload Scheduler monitors two types of SAP event:
| Events defined by the SAP system
| The events that are triggered automatically by system changes, for example
| when a new operation mode is activated. This type of event cannot be modified
| by the user.
| Events defined by the user
| The events that are triggered by ABAP or external processes, for example when
| a process triggers an SAP event to signal that external data has arrived and
| must be read by the SAP system.

| Definition of event rules based on IDoc records

| You can monitor Intermediate Document (IDoc) records in SAP systems and
| forward events to the Tivoli Workload Scheduler’s event integration framework.
| Using the Tivoli Dynamic Workload Console or composer command line, you
| define an event condition that contains the criteria that the IDocs must match to be
| forwarded to Tivoli Workload Scheduler. When the event condition occurs, the
| action you associated with it (for example, running a job) is performed.

Chapter 1. Summary of enhancements 7

Summary of enhancements

|
| Summary of product enhancements for Tivoli Workload Scheduler for
| z/OS
| This section lists the product enhancements released by PTF for Tivoli Workload
| Scheduler for z/OS version 8.3 since March 2007.
| PK40356 - End-to-end Password Encryption
| This fix enhances the way security is handled for Tivoli Workload
| Scheduler end-to-end users scheduling on Windows workstations. This
| enhancement provides two ways to avoid having the Windows password
| in plain text when defining the USRPSW parameter of the USRREC
| initialization statement for scheduling on Windows workstations:
| Centralized management of users and passwords for Windows
| workstations
| An encryption utility encrypts any user password specified in the
| USRREC definitions. The new EQQBENCR member in the SEQQSAMP
| library provides a JCL sample to run the utility.
| Handling of users and passwords locally on the Windows workstation
| You can select this solution by using the LOCALPSW(YES) parameter
| of the TOPOLOGY initialization statement. It enables the fault-tolerant
| agent to look for users and passwords in a local file, at run time.
| Use the new users Windows utility to create and manage Windows
| users’ credentials locally.
| PK40969 - Using TCP/IP connection among components
| This fix provides TCP/IP support for the communication between the
| following product components:
| Controller and tracker
| Provides new parameters in the ROUTOPTS and TRROPTS initialization
| statements to define TCP/IP destinations.
| Controller and data store
| Provides new parameters in the FLOPTS and DSTOPTS initialization
| statements to define TCP/IP destinations.
| Remote dialog and server
| The EQQXLUSL panel flow allows users to define the remote host
| name and port number of a server that specifies PROTOCOL(TCP) in
| the SERVOPTS initialization statement.
| Programming Interfaces (PIF) and server
| With the INIT initialization statement and INIT PIF request, users
| can define the remote host name and port number of a server that
| specifies PROTOCOL(TCP) in the SERVOPTS initialization statement.
| The TCP/IP connection support includes Batch Command Interface
| Tool (BCIT), Operation Control Language (OCL), and Batch Loader.
| PK41519 - Tivoli Workload Scheduler for z/OS Reporting
| This fix provides back-end support for the Tivoli Dynamic Workload
| Console reporting feature, collecting historical workload data and archiving
| it in dedicated tables in a DB2 database. The console process retrieves the
| archived data and returns it using the Business Intelligent Report Tool
| (BIRT) Report Viewer.

8 IBM Tivoli Workload Automation: Overview

Summary of enhancements

| Using Reporting with Tivoli Workload Scheduler for z/OS, you archive
| historical data about jobs and workstation workloads in the DB2 database.
| The historical data consists of old current plan data collected at daily
| planning time.
| For example, you can extend or replan your current plan more than once a
| day but decide to run the archiving process only once, selecting the new
| ARCHIVE option from the daily planning dialog. This triggers the
| submission of a batch job that archives the historical data in the DB2
| database, using Java Data Base Connectivity (JDBC) services.
| PK46296 - Virtual workstation
| This fix improves the scheduler workload balancing and monitoring of
| system availability. It automatically directs the submission of workload to
| different destinations removing the need to associate a workstation to a
| specific destination. You can define a list of destinations for the submission
| of workload and the scheduler distributes the workload to
| automatically-selected active destinations, according to a round-robin
| scheduling approach.
| You can activate this new capability by specifying the new virtual option at
| workstation definition level. This option is allowed for computer
| workstations with the automatic reporting attribute, and is supported by
| all the interfaces available to define, modify, and monitor workstations.
| Using virtual workstations the scheduler distributes the workload across
| your trackers evenly, thus avoiding bottlenecks when submitting or
| running jobs. In fact, the scheduler splits the workload among the available
| destinations, so that the Job Entry System (JES) and Workload Manager
| (WLM) do not find overloaded input queues when selecting jobs for their
| action.
| PK46532 - NOERROR improvement
| This fix improves the NOERROR specification rules by extending the set of
| conditions that determine whether a job is to be treated as not in error.
| It provides the following new capabilities:
| v Extended format for the error code entry, both in the NOERROR statement
| and in the NOERROR parameter of the JTOPTS statement. In particular, you
| can:
| – Specify a range of conditions rather than a single condition.
| – Use relational operators in the specified conditions.
| v A new extended status operation, that indicates that the job error code
| matched a NOERROR condition.
| v Listing the currently active NOERROR statements using the new LSTNOERR
| option for the MODIFY command which modifies the scheduler.
| PK58520 - Dynamic critical path support
| This fix provides the dynamic handling of the critical path calculated by
| the daily planning batch jobs process.
| The critical path is the path, within a network of jobs, with the least slack
| time.
| The slack time, in a critical job predecessor path, is the amount of time that
| processing of the predecessor jobs can be delayed without exceeding the
| deadline of a critical job. It is the spare time calculated using the deadline,
| input arrival, and duration settings of predecessor jobs.
| The new capabilities include:

Chapter 1. Summary of enhancements 9

Summary of enhancements

| v Monitoring of critical job predecessors that are late, long running, or

| ended with an error. This process uses the same internal logic that the
| scheduler applies to monitor alert conditions.
| v Monitoring of the paths that are consuming their slack time, becoming
| more critical than the paths calculated at plan generation.
| v Enhanced critical jobs monitoring, using ISPF dialog flows.
| v Back-end support for new views available using the Tivoli Dynamic
| Workload Console.
| PK71280 - JCL variables and directives improvement
| This fix improves automatic job tailoring by extending the including and
| excluding JCL function. It provides the following new capabilities:
| v Enhanced SETVAR directive:
| – New SUBSTR parameter that can be used to define the value of a
| temporary variable as the substring of another variable.
| – More accurate MO option handling.
| – Set a temporary variable to a specific value or to an expression
| composed of other temporary variables.
| v Substring fields available when specifying the independent variable in
| the dependency value list panel.
| v The possibility to remove JCL directives at job submission phase by
| specifying the REMOVEJCLDIRECTIVES parameter in the OPCOPTS
| initialization statement.
| v The possibility to specify the NOP directive to accomplish the same
| result as issuing the NOP command for an operation in the current plan.

10 IBM Tivoli Workload Automation: Overview

Chapter 2. Interoperability notes
This chapter describes the interoperability of Tivoli Workload Scheduler version
8.5. It includes the following information:
v “Interoperability of the components”
v “Interoperability tables” on page 12

Interoperability of the components

This section describes the interoperability among different versions of the
distributed components of Tivoli Workload Scheduler and also the interoperability
with components of other products in the Tivoli Workload Automation portfolio.

| All domain managers and agents of Tivoli Workload Scheduler, version 8.5 can
| coexist with the following:
| v All domain managers and agents of Tivoli Workload Scheduler, version 8.2, 8.2.1,
| 8.3, and 8.4
| v Tivoli Workload Scheduler for z/OS, versions 8.1, 8.2, and 8.3
| v Tivoli Workload Scheduler for Applications, versions 8.2, 8.2.1, 8.3, and 8.4
| v Tivoli Workload Scheduler for Virtualized Data Centers, version 8.2
| Notes:
| 1. Basic interoperability is provided with the GA versions of 8.2, 8.2.1, 8.3, and 8.4
| but to get full interoperability apply the latest fix packs to these versions to
| take advantage of the improvements in functionality and performance that they
| provide.
| 2. Any new features in version 8.5 that require information from another node
| might not work correctly if the other node is not at version 8.5. However, the
| planning and modeling features provided with the version 8.3 master domain
| manager can be immediately implemented in a mixed network without
| requiring an upgrade of the version 8.2 and 8.2.1 agents to version 8.3 and
| later.
| 3. The change in the job stream instance naming convention, introduced with
| Tivoli Workload Scheduler version 8.3, imposes the following restrictions when
| issuing command-line commands against a plan generated on a master running
| Tivoli Workload Scheduler version 8.3 and later from Tivoli Workload
| Scheduler version 8.2, or 8.2.1 agents:
| v You must use the @ (at) symbol as the first character for the job stream
| instance identifier. For example, the job stream running on workstation CPU1
| with identifier 0AAAAAAAAAAAAY3 must be identified in the conman command
| line as follows:
| CPU1#@AAAAAAAAAAAAY3
| v You cannot use the follows keyword when you add a dependency to a job
| or a job stream when you submit a command or a file as a job.
| v You cannot use the into keyword to specify the job stream where the job
| must be added when you submit a command or a file as a job.
| For example, to display the information about the job2 job included in the
| job stream instance having 0AAAAAAAAAAAAT1 as identifier and running on
| workstation CPU1, run the following command on Tivoli Workload Scheduler
| version 8.2, or 8.2.1 agents:

© Copyright IBM Corp. 1991, 2008 11

Interoperability notes

| sj CPU1#@AAAAAAAAAAAAT1.job2
| These changes will also be seen in reports, logs, and any other places where job
| stream names are printed or displayed.
| 4. In mixed environments, the dumpsec utility must not be used on a version 8.2
| or 8.2.1 agent with a version 8.5 security file, because it causes a core dump. If
| you need to dump the security file to a flat file, do it on a version 8.5 agent.

| Table 1 provides details on interoperability among the Tivoli Workload Automation

| Note: Tivoli Workload Scheduler and Distributed connector versions must always
| be aligned to the fix pack level.

12 IBM Tivoli Workload Automation: Overview

Interoperability notes

| Table 2 provides details on interoperability among the Tivoli Workload Automation

| distributed products if you use Tivoli Dynamic Workload Console as the graphical
| interface.
| Table 2. Interoperability table for Tivoli Workload Automation distributed products from the
| Tivoli Dynamic Workload Console.
| Tivoli Workload
| Scheduler and Tivoli Workload
| Tivoli Dynamic Distributed Scheduler for Tivoli Dynamic
| Workload Console connector Applications Workload Broker
|| 8.5 v 8.5 v 8.4.01 1.1, 1.2
| v 8.4.02 and later v 8.3.02
| version 8.4 fix
| packs
| v 8.3.05 and later
| version 8.3 fix
| packs
|| 8.4 v 8.4 and all version v 8.4 1.1
|| 8.4 fix packs v 8.4.01 (requires
| v 8.3.03 (with APAR Tivoli Dynamic
| PK47309 installed) Workload Console
| and later version version 8.4.02
| 8.3 fix packs
| 8.3 8.3.02 and later not supported not supported
| version 8.3 fix packs
|

| Note: Tivoli Workload Scheduler and Distributed connector versions must always
| be aligned to the fix pack level.

Chapter 2. Interoperability notes 13

Interoperability notes

| Table 3. Interoperability table for Tivoli Workload Scheduler for z/OS (continued)
| Tivoli Workload Scheduler Tivoli Job Scheduling Tivoli Dynamic Workload
| for z/OS z/OS connector Console Console
| 8.3 8.3.02 and later (8.3.04 8.3.02 and later 8.5, 8.4, 8.3
| is required to work Note: The new functions Note: Version 8.3 of the
| with Tivoli Dynamic of Tivoli Workload scheduler is used in
| Workload Console Scheduler for z/OS compatibility mode with 8.2.
| version 8.5) version 8.3 are supported This means that even though
| only on versions 8.3.02 Tivoli Workload Scheduler for
| and later. z/OS version 8.3 is installed,
| only the version 8.2 functions
| can be used.
|| v 8.3 + APAR PK41519 8.3.03 and later (8.3.04 8.3.02 and later 8.5, 8.4, 8.3
| is required to work Note: The new functions Note: The features added with
|| v 8.3 + APAR PK46296
with Tivoli Dynamic of Tivoli Workload APARs PK46296 (Virtual
| Workload Console Scheduler for z/OS workstations) and PK41519
| version 8.5) version 8.3 are supported (Reporting) are supported only
| only on versions 8.3.02 on versions 8.4 and later.
| and later.
| 8.3 + APAR PK58520 8.3.04 and later 8.3.02 and later 8.5, 8.4, 8.3
| Note: The new functions Note: The Dynamic Critical
| of Tivoli Workload Path (Workload Service
| Scheduler for z/OS Assurance) feature added with
| version 8.3 are supported APAR PK58520 is supported
| only on versions 8.3.02 only on versions 8.4.01 and
| and later. later.
|

| Note: Tivoli Dynamic Workload Broker and Tivoli Workload Scheduler for
| Applications can be accessed from Tivoli Workload Scheduler for z/OS in
| end-to-end configurations with Tivoli Workload Scheduler.

14 IBM Tivoli Workload Automation: Overview

Chapter 3. Overview of Tivoli Workload Automation

Tivoli Workload Automation is the state-of-the-art production workload manager,
designed to help you meet your present and future data processing challenges. Its
scope encompasses your entire enterprise information system, including
heterogeneous environments.

Pressures on today’s data processing (DP) environment are making it increasingly

difficult to maintain the same level of service to customers. Many installations find
that their batch window is shrinking. More critical jobs must be finished before the
morning online work begins. Conversely, requirements for the integrated
availability of online services during the traditional batch window put pressure on
the resources available for processing the production workload. Increasing by 7
days a week, 24 hours a day is not only a DP objective but a requirement.

Users and owners of DP services are also making more use of batch services than
ever before. The batch workload tends to increase each year at a rate slightly below
the increase in the online workload. Combine this with the increase in data use by
batch jobs, and the end result is a significant increase in the volume of work.

Furthermore, there is a shortage of people with the required skills to operate and
manage increasingly complex DP environments. The complex interrelationships
between production activities, between manual and machine tasks, have become
unmanageable without a workload management tool.

Tivoli Workload Automation simplifies systems management across heterogeneous

environments by integrating systems management functions. There are three main
components to the portfolio:
v Tivoli Workload Scheduler for z/OS
The scheduler in z/OS environments
v Tivoli Workload Scheduler
The scheduler in distributed environments
| v Tivoli Dynamic Workload Console
| A Web-based, graphical user interface for both Tivoli Workload Scheduler for
| z/OS and Tivoli Workload Scheduler

| The Job Scheduling Console is being replaced by Tivoli Dynamic Workload

| Console as the Tivoli Workload Automation graphical user interface. Although it is
| still included in Tivoli Workload Automation, no new functions have been added
| since version 8.4.

The state-of-the-art solution

The portfolio provides leading-edge solutions to problems in production workload
management. It can automate, plan, and control the processing of your enterprise’s
entire production workload, not just the batch subset. The portfolio works as an
“automatic driver” for your production workload to maximize the throughput of
work, and optimize your resources, but also allows you to intervene manually as
required.

© Copyright IBM Corp. 1991, 2008 15

Overview

When the portfolio interfaces with other system management products, it forms
part of an integrated automation and systems management platform for your DP
operation.

Comprehensive workload planning

The portfolio forms operating plans based on user descriptions of the operations
department and its production workload. These plans provide the basis for your
service level agreements and give you a picture of the production workload at any
precise time.

Good planning is the cornerstone of any successful management technique.

Effective planning also helps you maximize return on your investments in
information technology.

Centralized systems management

The portfolio automates, monitors, and controls the flow of work through your
enterprise’s entire DP operation on both local and remote systems. From a single
point of control, the portfolio analyzes the status of the production work and
drives the processing of the workload according to installation business policies. It
supports a multiple-end-user environment, enabling distributed processing and
control across sites and departments within your enterprise.

Systems management integration

Solutions to today’s systems management problems require an integration of
application programs and processes. The portfolio offers you integration with the
following:
v Agents for controlling the workload on non-z/OS platforms
v Other systems management applications and architecture environments.

The portfolio interfaces directly with some of the z/OS products as well as with a
number of other IBM products to provide a comprehensive, automated processing
facility and an integrated approach for the control of complex production
workloads.

NetView. NetView is the IBM platform for network management and automation.
You can use the interface for Tivoli Workload Scheduler for z/OS with NetView to
pass information about the work that is being processed. The portfolio lets you
communicate with NetView in conjunction with the production workload
processing. Tivoli Workload Scheduler for z/OS can also pass information to
NetView for alert handling in response to situations that occur while processing
the production workload. NetView can automatically trigger Tivoli Workload
Scheduler for z/OS to perform actions in response to these situations using a
variety of methods. Tivoli Workload Scheduler/NetView is a NetView application
that gives network managers the ability to monitor and diagnose Tivoli Workload
Scheduler networks from a NetView management node. It includes a set of
submaps and symbols to view Tivoli Workload Scheduler networks
topographically and determine the status of job scheduling activity and critical
Tivoli Workload Scheduler processes on each workstation.

Workload Manager (WLM). WLM controls the amount of system resources

available to each work unit in host environments. Tivoli Workload Scheduler for
z/OS works in concert with WLM to detect critical jobs and move them to a
higher-performance service class. In addition with WLM, critical jobs receive more
system resources and complete more quickly.

16 IBM Tivoli Workload Automation: Overview

Overview

Resource Object Data Manager (RODM). RODM provides a central location for
storing, retrieving, and managing the operational resource information needed for
network and systems management. You can map a special resource to a RODM
object. This lets you schedule the production workload considering actual resource
availability, dynamically updated.

Tivoli Decision Support for z/OS (Decision Support). Decision Support helps you
effectively manage the performance of your system by collecting performance data
in a DATABASE 2 (DB2®) database and presenting the data in a variety of formats
for use in systems management. Decision Support uses data from Tivoli Workload
Scheduler for z/OS to produce summary and management reports about the
production workload, both planned and actual results.

Output Manager for z/OS. Helps customers increase productivity and reduce the
costs of printing by providing a means for storing and handling reports in a z/OS
environment. When a dialog user requests to view a job log or to automatically
rebuild the JCL for a step-level restart, Tivoli Workload Scheduler for z/OS
interfaces with Output Manager. This interface removes the requirement to
duplicate job log information, saving both CPU cycles and direct access storage
device (DASD) space.

Tivoli Information Management for z/OS. Supports the administration of the

systems management process of an enterprise’s hardware, software, and related
resources. An interface with Tivoli Information Management for z/OS is provided
for reporting problems detected while processing the production workload.

Resource Access Control Facility (RACF®). RACF is the IBM product for data
security. You can use RACF as the primary tool to protect your Tivoli Workload
Scheduler for z/OS services and data at the level required by your enterprise. With
RACF 2.1 and later, you can use a Tivoli Workload Scheduler for z/OS reserved
resource class to protect your resources.

Tivoli System Automation for z/OS (SA z/OS). SA z/OS initiates automation
procedures that perform operator functions to manage z/OS components, data
sets, and subsystems. SA z/OS includes an automation feature for Tivoli Workload
Scheduler for z/OS. You can define an automation workstation in Tivoli Workload
Scheduler for z/OS to handle system automation operations with a specific set of
options.

Data Facility Hierarchical Storage Manager (DFHSM). Tivoli Workload Scheduler

for z/OS catalog management functions invoke DFHSM to recall migrated data
sets during data set cleanup for a failed or rerun job.

CICS® and IMS™ (Computer Information Control System and Information

Management System). Tivoli Workload Scheduler for z/OS lets you schedule the
starting and stopping of started tasks. Because Tivoli Workload Scheduler for z/OS
tracks the status of started tasks, you can serialize work, such as backups of your
transaction databases, according to the status of your CICS or IMS subsystems.

Tivoli Business Systems Manager. Tivoli Business Systems Manager provides

monitoring and event management of resources, applications, and subsystems with
the objective of providing continuous availability for the enterprise. Using Tivoli
Business Systems Manager with the portfolio provides the ability to manage
strategic applications from a unique business systems perspective. Tivoli Business
Systems Manager monitors batch-related applications and operations represented

Chapter 3. Overview 17
Overview

by the portfolio and seamlessly integrates these objects with all other business
objects monitored by Tivoli Business Systems Manager.

Tivoli Enterprise Console®. The Tivoli Enterprise Console is a powerful,

rules-based event management application that integrates network, systems,
database, and application management. It offers a centralized, global view of your
computing enterprise while ensuring the high availability of your application and
computing resources. Tivoli Enterprise Console acts as a central collection point for
alarms and events from a variety of sources, including those from Tivoli
applications. Tivoli Workload Scheduler runs a Tivoli Enterprise Console adapter
that reads events from the Tivoli Workload Scheduler log file.

Besides these IBM products, there are many products from other software vendors
that work with or process data from the portfolio.

Automation
By automating management of your production workload with the portfolio, you
can minimize human errors in production workload processing and free your staff
for more productive work. The portfolio helps you plan, drive, and control the
processing of your production workload. These are important steps toward
automation and unattended operations. Whether you are running one or more
systems at a single site, or at several distributed sites, the portfolio helps you
automate your production workload by:
v Coordinating all shifts and production work across installations of all sizes, from
a single point of control
v Automating complex and repetitive operator tasks
v Dynamically modifying your production workload schedule in response to
changes in the production environment (such as urgent jobs, changed priorities,
or hardware failures) and then managing the workload accordingly
v Resolving workload dependencies
v Managing utilization of shared resources
v Tracking each unit of work
v Detecting unsuccessful processing
v Displaying status information and instructions to guide operations personnel in
their work
v Interfacing with other key IBM products to provide an integrated automation
platform

The portfolio lets you centralize and integrate control of your production workload
and reduces the number of tasks that your staff need to perform.

Workload monitoring
Besides providing a single point of control for the production workload across
your systems, the portfolio:
v Monitors the production workload in real time, providing operations staff with
the latest information on the status of the workload so that they can react
quickly when problems occur.
v Provides security interfaces that ensure the protection of your services and data.
v Enables manual intervention in the processing of work.
v Reports the current status of your production workload processing.

18 IBM Tivoli Workload Automation: Overview

Overview

v Provides reports that can serve as the basis for documenting your service level
agreements with users. Your customers can see when and how their work is to
be processed.

Automatic workload recovery

The portfolio enables processing production workload to continue even when
system or connection failures occur. If one system fails, the portfolio can restart the
processing on another system. When the controlling system is running in a z/OS
system complex (sysplex), a hot standby function can automatically transfer control
of the production workload to another system in the sysplex. Because the portfolio
continues to manage the production workload during failures, you can maintain
the integrity of your processing schedules and continue to service your customers.

In Tivoli Workload Scheduler, a switchmanager function provides the possibility to

replace a failing master domain manager or domain manager workstation with an
appropriately configured backup fault-tolerant agent or domain manager .

Productivity
The portfolio represents real productivity gains by ensuring fast and accurate
performance through automation. Many of today’s automation solutions quote
unrealistic productivity benefits. Some of the tasks automated should never be
performed, or certainly not as often as they are by automation. Because of this, it is
difficult to correlate real productivity benefits to your enterprise.

The tasks the portfolio performs not only have to be performed, but have to be
performed correctly, every time, and as quickly as possible. Many of these tasks,
traditionally performed by DP professionals, are tedious and as a result prone to
error. With the portfolio, your DP staff can use their time more efficiently.

Business solutions
The portfolio provides business solutions by:
v Driving production according to your business objectives
v Automating the production workload to enhance company productivity
v Providing you with information about current and future workloads
v Managing a high number of activities efficiently.

User productivity
Your DP staff and end users can realize significant productivity gains through the
portfolio’s:
v Fast-path implementation.
v Immediate response to dialog requests for workload status inquiries. Users are
provided with detailed real-time information about production workload
processing so that they can detect and promptly correct errors.
v Automation of operator tasks such as error recovery and data set cleanup.
v Job Scheduling Console with its easy-to-use graphical user interface and
sophisticated online help facilities.

Growth incentive
As you implement automation and control you can manage greater production
workload volumes. The portfolio brings growth within your DP operation by
providing:

Chapter 3. Overview 19
Overview

v Ways of absorbing the increasing batch workload without increasing operations

personnel
v An open interface for submitting and tracking the workload on a variety of
operating systems
v Interfaces with other systems management application programs
v An open interface for, and communicating with, programs on other platforms
v Management of current and future production workload volumes
v Simulation facilities to forecast future workloads

How Tivoli Workload Automation benefits your staff

In a typical enterprise, many people contribute to the implementation and
operation of Tivoli Workload Automation:
v Scheduling manager
v Operations manager
v Shift supervisor
v Application programmer
v Console operators
v Workstation operators, such as print operators, job setup staff, and login
receptionists
v End users
v Service desk

This section describes how the portfolio can directly benefit your DP staff.

Role of the scheduling manager as the focal point

Tivoli Workload Automation makes it possible for the scheduling manager to
maintain current and future production processing across your enterprise. The
portfolio benefits the scheduling manager in the following ways:
v Automatically scheduling all production workload activities.
v Automatically resolving the complexity of production workload dependencies
and driving the work in the most efficient way.
v Supporting the simulation of future workloads on the system. The scheduling
manager can evaluate, in advance, the effect of changes in production workload
volumes or processing resources.
v Giving a real-time view of the status of work as it flows through the system so
that the scheduling manager can quickly:
– Respond to customer queries about the status of their work
– Identify problems in the workload processing.
v Providing facilities for manual intervention.
v Managing many workload problems automatically. The production-workload-
restart facilities, hot standby, automatic recovery of jobs and started tasks, and
data set cleanup provide the scheduling manager with comprehensive
error-management and disaster-management facilities.
v Providing a log of changes to the production workload data through the
audit-trail facility. This assists the scheduling manager in resolving problems
caused by user errors.
v Managing hard-to-plan work.

20 IBM Tivoli Workload Automation: Overview

Overview

Role of the operations manager

The reporting, planning, and control functions can help the operations manager do
the following:
v Improve the efficiency of the operation
v Improve control of service levels and quality
v Set service level agreements for end-user applications and for services provided
v Improve relationships with end-user departments
v Increase the return on your IT investment
v Develop staff potential.

A powerful tool for the shift supervisor

The portfolio is important for the shift supervisor, especially in multisystem
complexes, where local and remote systems are controlled from a central site. The
portfolio can help the shift supervisor do the following:
v Monitor and control the production workload through multisystem complexes
v Control the use of mountable devices
v Separate information about work status from system and other information
v Provide end users with status information directly
v Manage the workload if a system failure occurs
v Make changes to the current plan in response to unplanned events, such as
equipment failures, personnel absences, and rush jobs.

Role of the application programmer

The user-authority checking functionality enables application development groups
to use all the planning and control functions in parallel with, but in isolation from,
production systems and services.

The portfolio can be a valuable tool for application development staff when they
are doing the following:
v Packaging new applications for the production environment
v Testing new JCL in final packaged form
v Testing new applications and modifying existing ones

Console operators
The portfolio can free console operators from the following time-consuming tasks:
v Starting and stopping started tasks
v Preparing JCL before job submission
v Submitting jobs
v Verifying the sequence of work
v Reporting job status
v Performing data set cleanup in recovery and rerun situations
v Responding to workload failure
v Preparing the JCL for step-level restarts.

Workstation operators
The portfolio helps workstation operators do their work by providing the
following:
v Complete and timely status information
v Up-to-date ready lists that prioritize the work flow
v Online assistance in operator instructions.

Chapter 3. Overview 21
Overview

End users and the service desk

Your end users often need to be informed about the status of workload processing.
They can use the Tivoli Dynamic Workload Console to check the status of the
processing of their job streams themselves from a personal workstation. End users
can make queries using the Tivoli Dynamic Workload Console without having to
be familiar with the portfolio, ISPF, or TSO, and without having to be logged on to
a local system.

The help desk can use the Tivoli Dynamic Workload Console in the same way to
answer queries from end users about the progress of their workload processing.

Summary
Tivoli Workload Automation communicates with other key IBM products to
provide a comprehensive, automated processing facility and an integrated solution
for the control of all production workloads. Here are the benefits that the portfolio
offers you:
Increased automation
Increases efficiency and uses DP resources more effectively, resulting in
improved service levels for your customers.
Improved systems management integration
Provides a unified solution to your systems management problems.
More effective control of DP operations
Lets you implement change and manage growth more efficiently.
Increased availability
Is made possible by automatic workload recovery.
Opportunities for growth
Are made possible by your ability to manage greater workload volumes.
Investment protection
Is made easier by building on your current investment in z/OS and
allowing existing customers to build on their existing investment in
workload management.
Improved customer satisfaction
Is achieved thanks to higher levels of service and availability, fewer errors,
and faster response to problems.
Greater productivity
Results because repetitive, error-prone tasks are automated and operations
personnel can use their time more efficiently.
Integration of multiple operating environments
Provides a single controlling point for the cooperating systems that
comprise your DP operation.

The portfolio is more than just a batch scheduling tool: it is a production

management system with the capability to schedule all the work running on any
system.

22 IBM Tivoli Workload Automation: Overview

Chapter 4. Tivoli Workload Automation and ITUP
This chapter explains where Tivoli Workload Automation is placed within the IBM
Tivoli Unified Process (ITUP).

The IBM Tivoli Unified Process provides detailed documentation of IT Service

Management processes based on industry best practices, to help users to
significantly improve their organization’s efficiency and effectiveness. ITUP helps
users to easily understand processes, the relationships between processes, and the
roles and tools involved in an efficient process implementation.

The processes described in ITUP are strongly aligned with the Information
Technology Infrastructure Library (ITIL) which is based on best practices observed
within the IT industry. ITIL provides high-level guidance of what to implement,
but not how to implement. ITUP contains detailed process diagrams and
descriptions to help users understand processes and their relationships, making
ITIL recommendations easier to follow.

ITUP is based on the IBM Process Reference Model for IT (PRM-IT), which was
jointly developed by IBM Global Services and Tivoli. PRM-IT provides detailed
process guidance for all activities that fall under the office of the CIO, including,
but not limited to, IT Service Management.

The ITUP processes

ITUP describes a comprehensive set of processes within an IT organization. Each
process is defined by:
Tool Mentors that describe best practice use of IBM tools in a process context
Tool mentors help users identify which IBM products and solutions can be
used to perform specific process activities and details their appropriate use.
By following this guidance users can reduce time, effort, and errors, and
get the maximum value out of their investments.
Role definitions, responsibilities, and resources
ITUP describes the roles and responsibilities of all actors in the process
model. Users can identify their roles and understand the activities they
need to perform and the tools available to help them.
Work products and other information
ITUP describes all work products, often referred to as artifacts, produced
as output or required as input by processes and activities. Other
information such as key terms and concepts are also defined.
Scenarios describing common problems and best practice solutions
Scenarios help users understand how real world problems can be
addressed with process improvement and integration, proper tool use, and
defined roles and responsibilities.

Service execution and workload management

Among the processes supported by Tivoli Workload Automation, service execution
is one of the key IT processes described by ITUP. Its mission is to deliver
operational services to the IT infrastructure and to the enterprise.

© Copyright IBM Corp. 1991, 2008 23

Tivoli Workload Scheduler and ITUP

The main service execution activities supported by Tivoli Workload Automation

are:
v Deliver service
v Manage delivery resources
v Manage workload

Workload management has the target to maximize the utilization of task execution
resources and to minimize the total time that is required to deliver the output of
task processing. This activity operates at both a macro-level and micro-level to
prepare work schedules and to pre-process work items where necessary so that the
delivery resources can be matched to the demands of the flow of work in an
optimal fashion.

The objectives of workload scheduling focus on:

v Managing the execution of activities according to business calendars, time
constraints, and resource availability.
v Managing activities that have interactions between each other and have
dependencies with each other and external entities and events.
v Enabling integration with business application environments like SAP R3 and
PeopleSoft., and managing the running of activities in those environments.
v Managing the life cycle for defining the activities to run and their running.
v Enabling monitoring and control on the running of these activities and collecting
results and historical running data.

Managing workload with Tivoli Workload Automation

Tivoli Workload Automation is a portfolio of products provided by IBM to
automate all workload management tasks. The scheduling features of Tivoli
Workload Automation help you plan every phase of your workload production.
During the processing period, the production control programs manage the
production environment and automate most operator activities. The schedulers
prepare jobs for running, resolve interdependencies, and launch and track jobs.
Because jobs start running as soon as their dependencies are satisfied, idle time is
minimized, and throughput improves significantly. Jobs never run out of sequence,
and, if a job fails, the schedulers can handle the recovery process with little or no
operator intervention.

Workload management is based on a database that contains the definitions of the

scheduling objects. There are two versions of the scheduling objects database
depending on the placement of the main workload controller: it can be based on a
mainframe computer (in this case, z/OS) or on a distributed platform. Some of the
scheduling objects can exist in both of the databases, some apply only to the
distributed platform, and others might apply only to the mainframe platform.

The minimum set of object definitions that are required to produce a workload
consists of a workstation, a job, and a job stream. Other required scheduling objects
might be predefined and exist by default.

A workstation is a definition that represents a computer system or another entity

that is capable of running specific tasks, and that has the ability to report the status
of task execution to the scheduler. With the Tivoli Workload Automation interfaces,
you can identify the physical resources associated with the workstations.

24 IBM Tivoli Workload Automation: Overview

Tivoli Workload Scheduler and ITUP

A job is the representation of a task (an executable file, program, or command) that
is scheduled and launched by the scheduler. The job is run by a workstation and,
after running, has a status that indicates if the run was successful or not. A job
definition can specify information on what to do whenever its run was not
successful. Jobs not included in a job stream do not have any attribute for running,
and are only the description of a task with a definition on how to perform it in a
form that is known to the specified workstation.

A job stream represents a container for related jobs and organizes them, in terms of
run time, sequencing, concurrency limitations, repetitions, assigning priority or
resources, and so on. Job streams are the macro elements of the workload that you
manage.

The scheduling plan is the to-do list that tells Tivoli Workload Scheduler or Tivoli
Workload Scheduler for z/OS what jobs to run, and what dependencies must be
satisfied before each job is launched. Tivoli Workload Scheduler or Tivoli Workload
Scheduler for z/OS builds the plan using the elements that are stored in the
scheduling database.

The running of a plan requires tracking to identify possible problems that can
impact the effective delivery of the work products. It is possible to perform the
tracking from a Web-based Java interface, the Tivoli Dynamic Workload Console,
on either of the platforms (z/OS and distributed). As an alternate interface to the
Tivoli Dynamic Workload Console on the z/OS platform you can also use the ISPF
panel interface, and on the distributed platforms you can use the command-line
interface.

See Chapter 6, “A business scenario,” on page 29 which describes a possible

implementation of workload management based on Tivoli Workload Automation.

Chapter 4. Tivoli Workload Automation and ITUP 25

26 IBM Tivoli Workload Automation: Overview
|

| Chapter 5. Who performs workload management

| The primary roles most directly responsible for workload management are:
| The IT administrator
| Is the general IT administrator of all the hardware and software used by
| the company. He is in charge of installing, supporting, and maintaining
| servers or other computer systems, and planning for and responding to
| service outages and other problems.
| He installs and maintains the job scheduling tool.
| The Tivoli Workload Scheduler IT administrator
| A good deal of his time is focused on keeping job scheduling running
| smoothly. He rarely does any actual scheduling himself, but instead acts as
| the person in the background who supports those who do. The Tivoli
| Workload Scheduler IT administrator:
| v Defines and maintains the security for the job scheduling tool.
| v On certain occasions does a minimal amount of tuning and
| customization of the job scheduling tool.
| v Guarantees that the job scheduling tool environments are up and
| running all of the time, and if something goes wrong he needs to
| quickly resolve the problem.
| v Monitors the health status of the job scheduling tool infrastructure. Uses
| tools that alert him (usually via email or pager) and create alerts or
| automatically open a trouble-ticket to alert the responsible person when
| there is a problem.
| v Occasionally spends his time helping to fix job scheduling problems that
| the job schedulers cannot understand.
| v Generates and uses reports.
| v Occasionally documents major problems and work-arounds on the
| community Web site.
| v Interacts mainly with fellow team members, programmers, and job
| schedulers.
| v Sometimes makes suggestions to management about capacity planning
| and IT software purchases.
| The job scheduler
| Is the primary actor in workload management and needs to easily create
| and maintain a plan containing the company workload. He is responsible
| for modeling the company workload, and for designing, fixing, and
| maintaining schedules. His main responsibilities are to:
| v Manage workload complexity and dependencies.
| v Optimize schedule efficiency, flexibility, resiliency.
| v Analyze and fix modeling issues.
| v Look proactively for the schedule's integrity.
| The scheduling operator
| Is responsible for performing all operational processes and procedures,
| ensuring the business continuity of the workflow. His main responsibilities
| are to:
| v Monitor critical events and perform first analysis of problems.

© Copyright IBM Corp. 1991, 2008 27

Who performs workload management

| v Manage and coordinate the resolution of issues.

| v Ensure that operations continue.
| He is usually not dedicated to monitoring job scheduling alone.
| The Scheduling and Operations manager
| He:
| v Does not use job scheduling tools himself; but is interested in the
| operational data from the tools, such as reports on long and late running
| jobs and service level agreement status.
| v Makes sure his team has the knowledge and tools they need to schedule
| and manage jobs efficiently.
| v Is always looking for ways to reduce cost in his organization by making
| his team more efficient.
| v Believes that process is the key to IT management and also thinks that
| his team’s job scheduling process can be improved. He is familiar with
| ITUP of which his IT organization has implemented the basic aspects of
| change management. Consequently, his team follows this process.

28 IBM Tivoli Workload Automation: Overview

Chapter 6. A business scenario
The purpose of the following scenario is to show how the choice of the correct
workload scheduling product, together with process improvement and integration,
and well-defined roles and responsibilities, can improve the business of a
manufacturing enterprise.

The company
Fine Cola is a medium-sized enterprise that produces and distributes soft drinks to
retailers across the country. It owns a production plant and several strategically
located distribution centers. The primary customers of Fine Cola are foodstore
chains and the quantity and size of their orders is usually regular and stable.
Order quantities, however, peek in the warmer season and during holidays.
Moreover, in the mid term, Fine Cola wants to increase its business by gaining
market in other countries. Fine Cola's sales people are always keen to place new
orders and increase the customer portfolio. These characteristics determine Fine
Cola's production and distribution processes. Production and distribution can be
broken down into ongoing subprocesses or phases which are constantly interlocked
with each other. They are:
Inventory
Underlays the entire production process. The raw materials database is
sized on the production levels supplemented by minimum safety levels.
The production levels are in turn based on the order quantity for the
specific period.
Ordering
Raw material quantity levels must be available to production according to
the preset production levels. Orders must be planned and issued in
advance to take into account delivery times by third-party suppliers.
Production
General production levels are planned for well in advance based on
customer orders. Production is regularly increased by an additional five
percent to provide the capability to honor unplanned-for orders.
Supply
From the production plant the soft drinks are transported to the
distribution centers according to the customer delivery schedules.
Delivery
The last phase of the process. Fine Cola sodas are delivered from the
distribution centers to the customer shelves.

Inventory, ordering, and production take place in the production plant. Supply
takes place from the production plant to the distribution centers. Delivery takes
place from the distribution centers to the end destinations.

These phases are tightly bound to each other. While each soda placed on the shelf
might be regarded as the outcome of a specific sequence that starts with inventory
and terminates with delivery, all phases are actually constantly interwoven. In fact,
the same data is shared in one way or another by all or most phases, and
applications are designed to carry on the daily operations and set up future ones.

© Copyright IBM Corp. 1991, 2008 29

A business scenario

Fine Cola uses the following databases for running the above-mentioned
subprocesses:
Customer Orders
Contains all orders for the upcoming period from Fine Cola's customer
base. Provides input to:
v Inventory
Raw Materials
Contains the quantities in stock of the raw materials required to produce
Fine Cola's sodas. From here, orders are dispatched to suppliers when
stock levels reach a pre-set minimum. Receives input from:
v Production Volumes
Production Volumes
Contains the quantities of sodas that are to be produced daily according to
order volumes. Provides input to:
v Inventory
v Raw Materials
Receives input from:
v Inventory
Inventory
Contains the quantities in stock of the finished product. Is monitored to
verify that the quantities in stock are sufficient to honor the orders of a
specific time interval. Provides input to and receives input from:
v Production Volumes
v To Supply
To Supply
Contains the quantities of sodas that must be sent periodically from the
manufacturing plant to the distribution centers to satisfy foodstore orders
for the upcoming period. Provides input to:
v Inventory
v To Deliver
To Deliver
Contains the quantities that are to be delivered from each distribution
center to the foodstores in its area. Provides input to:
v Customer Orders
Receives input from:
v To Supply

The company workload is both application oriented, such as accounting, payroll,

supplier and utility payments, purchasing, ordering, fulfillment, and
system-oriented, such as data backup, migration, export, transfer or load
operations. Typically, the workload processes multiple data items such as accounts,
orders, transactions, database records, at the same time.

These core applications are highly relevant for the profitability of the company and
also directly influence customer satisfaction.

To create added value and exceed customers expectations, the company must
strengthen integration with business applications and provide complete scheduling
capabilities and tighter integration with enterprise applications.

30 IBM Tivoli Workload Automation: Overview

A business scenario

The challenge
Currently the databases are not automatically integrated with each other and need
continual human intervention to be updated. This affects Fine Cola’s operations
because:
v The process as a whole is onerous and prone to error.
v The interfaces between phases are slow and not very efficient.

The company realizes it needs to better integrate with the distribution centers
because processing is extremely low during the regular office hours in the warmer
seasons and during holidays. Users experience applications freezing, often taking
considerable time before being available for them to use again. This lack of
integration is causing problems for the organization in terms of lost productivity,
while applications come back online. This is a problem because the interruption of
important processing is not acceptable when the company wants to expand the
business. The response time for service level agreements (SLAs) must continue to
be met if a resource goes down, a workstation breaks, or there is urgency for
maintenance, and even more during peak periods even if the resources are
geographically distributed. On the other hand the company does not want to buy
new IT resources (hardware, software, applications) because this would not be
used during the other periods of the year.

Fine Cola realizes that their main weakness lies in their processing. They need to
implement a solution that:
v Integrates the data behind their processing workflow from inventory to
distribution. This makes it possible to automatically trigger the daily operations
without much need for human intervention. It also gives Fine Cola complete
control over the entire business process, reducing human intervention only to
exception handling.
v Integrates external data coming from third parties, such as selected customers
and raw material suppliers, into their process flow. Such data is provided to Fine
Cola in several formats and from different applications and should be integrated
into Fine Cola's databases in a seamless manner.
v Enables daily backups of their data as well as subsequent reorganization of the
DB2 database with as little impact as possible on their processes. Processing of
data collected online during the previous day is the next step.
v Optimizes capacity across the IT infrastructure and runs a high workload, much
more than before, using shared resources, even if the resources are
geographically distributed.
v Ensures 24x7x365 availability of critical business services. Disaster recovery
plans are no longer sufficient because the business requires recovery within a
couple of hours, not days. Recovering from last night tapes and recapturing lost
transactions after a system or application failure is no longer a viable option for
the company in a highly competitive market.
v Has very low probability of failure leading to maximum system reliability.

The main company goal at this time is to obtain an integrated workload solution
that can entirely choreograph its business application tasks. This means solutions
that optimize capacity across the IT infrastructure and run a tremendous workload,
much more than before, using less resources. For example, if the company has a
problem and a primary server does not process the workload, the company wants
to automate the quick redistribution of system resources to process workloads and
scale up or down for flawless execution. In this way the company reduces costs
because it speeds recovery time, no matter what the source. The goal is to have a

Chapter 6. A business scenario 31

A business scenario

view of the best available resources across this dynamically shifting

cross-enterprise pool.

Company goal
Obtain an integrated workload
solution that can choreograph
business application tasks

12
11 1

12
10 2 11 1
12
11 1 12
11 1 10 2
9 3
10 2
10 2 3
8 4 9
9 3
7 5 9 3
8 4
6
8 4
8 4 7 5
6
7 5
6 7 5
6

Job1 Job 2 Job 3 Job 4 Job 5 Job 6

Customer Pains

The databases are not

integrated with each other.

The response time for service

level agreements (SLAs) is not
guaranteed if a resource is not
available, a computer breaks,
or during peak periods.

The capacity across the IT

infrastructure is not optimized
so they are suffering slow
processing during regular office
hours.

Integrated Workload System

Inventorying Ordering Supply On the Shelf

Figure 1. The Fine Cola company integrated workload solution

The solution
Fine Cola decides that one important step toward improving their process
execution is to adopt a solution based on automatic and dynamic workload
scheduling. The solution is based on a choice that strengthens integration with
business applications to run the following tasks:
v Read data from one database to update other databases.
v Read data from external applications, process it, and add it to the appropriate
databases.
v Provide the information necessary for the operation of every phase.
v Trigger some of the phases when predetermined thresholds are reached.
v Back up their data without interrupting production.

32 IBM Tivoli Workload Automation: Overview

A business scenario

v From a capacity management perspective, understands the size of an application

and what resources it requires, models that against the existing resources and is
able to predict and forecast the capacity that the new application needs as it is
defined in the enterprise.
v From an availability management perspective, use the resources available in the
environment to support the application and understand out how to work to
effectively schedule, monitor, and manage that application as it is submitted.
Then if the resources are not available, interact with the change management
and provisioning processes to dynamically allocate the necessary resources.
v Have a business management process monitoring all the various policies and
driving a consistent view of the policies for the application.

After analyzing the workload management products available on the market, Fine
Cola has chosen to use IBM Tivoli Workload Scheduler together with IBM Tivoli
Dynamic Workload Broker, because they can:
v Optimize and automate the tasks to process their applications and dynamically
adapt their processing in response to changes in the environment.
v Plan, choreograph, and schedule required changes to applications to minimize
the impact of changes on critical production workloads, and ensure that
workload processes are updated to reflect changes throughout asset life cycles.
v Minimize the total amount of time that is required to deliver the output of the
task resolution processes.
v Handle dependencies between tasks, data, and external applications so that the
entire workload can be managed homogeneously in the same process flow.
v Create a policy-based view of workflow automation, not just workload
automation, but cross-enterprise workflow, and direct that workflow across the
enterprise while planning, scheduling, managing, and monitoring all these
things. Dynamically tuning the cross-enterprise capacity to support this dynamic
view of workloads.
v Automatically transfer entire workloads across multiple platforms, and update
policies across multiple platforms.
v Balance between the ability to provide sophisticated planning, testing,
choreographing, monitoring, and adaptation of workload processes with fault
tolerance and redundancy for high availability of the scheduling infrastructure,
while minimizing server and network resource requirements.
v Perfectly integrate with each other.
Tivoli Workload Scheduler operates at both a macro-level and micro-level to
prepare work schedules and to preprocess work items where necessary so that the
delivery resources can be matched to the demands of the flow of work in an
optimal fashion.

Tivoli Dynamic Workload Broker dynamically routes workload to the best available
resources based on application requirements and business polices. Moreover it
optimizes the IT computing resource use according to SLAs.

Fine Cola's applications are mapped to what in Tivoli Workload Scheduler

terminology are units of work called jobs. Some of these jobs are statically
allocated to dedicated resources to run (static job definition in Tivoli Workload
Scheduler), others are dynamically allocated to physical or virtual resources
according to the job importance, requirements, scheduling policies, and based on
the environment resource characteristics, relationships, availability, load, and
performance (dynamic job definition in Tivoli Dynamic Workload Broker). They
drive the resource allocation to meet the job SLA and the resource optimization.

Chapter 6. A business scenario 33

A business scenario

Jobs that run as a unit (such as a weekly backup application), along with times,
priorities, and other dependencies that determine the exact order of the jobs are
grouped into job streams.

Fine Cola's job streams are collections of jobs that are grouped for organizational
purposes. The jobs of any particular job stream are related because they:
v Operate toward the completion of related tasks. For example, the jobs of
Jobstream100 run tasks designed to convert incoming customer orders into
operational data.
v Might be dependent on each other. Some jobs might have to wait for the
completion of predecessor jobs before they can start running. The jobs are
usually laid out in a sequence where the outcome of a predecessor is fed to a
successor job.
v Share the same programs, applications, and databases.
v Share the same timeframes within the planning period.

Figure 2 shows how to connect Tivoli Workload Scheduler and Tivoli Dynamic
Workload Broker.

Master
Domain
Manager

Tivoli
Workload Scheduler
Database
Job Scheduling Tivoli Dynamic
Console Workload Broker
Tivoli Dynamic Web Console Client
Workload Broker
Server

Tivoli Dynamic
Workload Broker
Domain Database
Manager

Tivoli Workload Tivoli Workload

Scheduler Scheduler agent
Agents plus
Common agent
and
Workload agent

Common agent Common agent

and and
Workload agent Workload agent

Common agent
and
Workload agent

Figure 2. Integration between Tivoli Workload Scheduler and Tivoli Dynamic Workload Broker

Using Tivoli Workload Scheduler, Fine Cola's business process is structured in the
following way:

34 IBM Tivoli Workload Automation: Overview

A business scenario

1. At the start of each day, Jobstream100:

a. Extracts the new incoming orders from the Customer Orders database.
b. Checks an external application where a number of selected customers can
place unforeseen orders. If there are orders, they are extracted and merged
with the other data.
c. Copies the consolidated orders into a separate database view.
d. Sorts them by due delivery date and by quantity and makes a report.
2. As soon as the report is available, Jobstream200 extracts the numbers from the
report and compares them with relevant data in the Inventory database. The
goal is to determine the production volume required in the next production
cycle to satisfy the orders.
3. Jobstream300 extracts the production volume data and updates the Production
Volumes database with the quantities of each type of soda that is to be
manufactured in the next cycle.
4. Jobstream400 reads the data in the Production Volumes database and:
a. Calculates the quantities of raw materials required to run the upcoming
production cycle.
b. Flags these quantities as allocated to next cycle in the Raw Materials
database.
c. Checks the quantities to see if they have reached the minimum stock levels
and triggers orders to Fine Cola's raw material suppliers if necessary.
5. Jobstream500 reads the report with upcoming due orders from the Customer
Orders database and:
a. Produces the transportation schedules and destinations.
b. Updates the To Supply database.
c. Sends the delivery schedules to the distribution centers.
6. Jobstream600 reads the distribution center databases and:
a. Extracts the orders that have been filled.
b. Updates the Customer Orders database so that invoices can be prepared
and sent.
7. Jobstream700 makes a backup of every database.

Fine Cola sets up a long term plan that encompasses the entire workload, spanning
job streams that run on a daily basis and job streams that have other reoccurrences.
From the long term plan, a current plan is extracted at the beginning of every time
unit. The time period of the current plan can be chosen to vary from some hours to
several days. Fine Cola has chosen to set their current plan on a daily basis. At the
start of every day a new daily plan is built by their workload scheduling software:
data is taken from the long term plan and from the daily plan of the previous day
to include any jobs that might not have completed.

The company must also ensure that during peek periods the jobs in the critical
path are run in the required time frame. To ensure this they converted some jobs
from static definition to dynamic definition to manage the extra orders using Tivoli
Dynamic Workload Broker. With Tivoli Dynamic Workload Broker the company
can:
v Manage the automatic discovery of available resources in the scheduling
environment with their characteristics and relationships.
v Assign to the job the appropriate resources for running based on the job
requirements and on the administration polices.

Chapter 6. A business scenario 35

A business scenario

v Optimize the use of the resources by assigning to the job the required resources
based on the SLA.
v Manage and control the resource consumption and load.
v Dispatch jobs to target resources that meet the requirements to run the job.

The Tivoli Workload Scheduler relational database contains the information related
to the jobs, the job streams, the workstations where they run, and the time
specifications that rule their operation. On the other hand, the Tivoli Dynamic
Workload Broker database contains information about the current IT environment,
the resource real time performance, and load data. It also stores the job definitions
and keeps track of resources assigned to each job.

In this way, Fine Cola's scheduling analyst can create and change any of these
objects at any time and Fine Cola's IT administrator can dynamically assign the
best set of resources to match allocation requests based on the defined policies,
without any impact on the business.

He can also ensure the correct concurrent or exclusive use of the resources across
the different jobs according to resource characteristics. If the resource request
cannot be immediately satisfied the IT administrator, using Tivoli Dynamic
Workload Broker, can automatically queue the resource until changes in the
resource utilization or in the environment cause it to be satisfied it.

The workload scheduling plan can be changed as quickly and dynamically as the
business and operational needs require. The scheduling analyst makes full use of
the trial and forecast planning options available in the scheduler to adjust and
optimize workload scheduling and, as a consequence, Fine Cola's line of
operations.

To respond to any unexpected and unplanned-for demands, individual jobs can be

added ad hoc to the scheduling plan at any time.

Moreover using Tivoli Dynamic Workload Broker the company can rapidly adapt
to the increase of workload during peak periods driving the requirement for
workload virtualization, that is the ability to manage and control the workload so
that it can be slit, routed to appropriate resources and capacity, and dynamically
moved around in logical resource pools.

If a resource is not available, the SLA defined continues to be met because the job
processing is restarted from the point where the failure happens.

Typical everyday scenarios

This section describes roles and responsibilities of Fine Cola’s IT staff and everyday
scenarios they might face on any typical day. Fine Cola’s IT staff, involved in
workload scheduling are:
v The scheduling analyst. He is in charge of modeling the company workload, and
for designing, fixing, and maintaining schedules. His main responsibilities are:
– Managing Fine Cola's workload complexity and dependencies.
– Optimizing the schedule's efficiency, flexibility, and resilience.
– Analyzing and fixing modeling issues; look pro-actively for the schedule's
integrity.
v The operations analyst. His main responsibilities are:
– Monitoring critical events and performing first analysis of problems.

36 IBM Tivoli Workload Automation: Overview

A business scenario

– Managing and coordinating the resolution of issues.

– Ensuring that operations continue.
v The IT infrastructure administrator. His main responsibilities are:
– Fulfilling the need to assign physical or virtual resources to jobs according to
the job importance, requirements, scheduling policies, and based on the
environment resources characteristics, relationships, availability, load, and
performance.
– Managing the advanced reservation or provisioning of required resources.
– Drive the resource allocation to meet the job SLA and the resource
optimization data without service disruption, and possibly transparently for
the end users.
– Backing up the schedule daily with no impact on operations.
– Ensuring high availability of the infrastructure. If a resource goes down or a
workstation is not available there is urgency for maintenance the SLA defined
availability must continue to be met.
– Defining and maintaining the environment topology.

Managing the workload

Together with the IT infrastructure administrator and other staff, the scheduling
analyst agrees on a change in the application workflow that should go into
production in a month. The change impacts Jobstream100 and includes:
v Defining a new job and replacing some job dependencies in the job stream.
v Defining two Jobstream100 instances to run twice a day for a week and during
the summer season. He must therefore:
– Define a run cycle for each of the two instances. The first run cycle has the
expected start time of 9 a.m. The second is scheduled to start at 5 p.m.
– Agree with the IT infrastructure administrator the pool of resources that
satisfy the job SLA in terms of RAM and microprocessors.
He then proceeds in the following way:
1. He reviews the new stream logic and sets a plan. He wants to design the
changes, test them over three days, and have a first automatic test run within
a week.
2. He proceeds to apply the changes to Jobstream100. While he does this, he
realizes that the application specialist must modify the tasks (scripts)
contained in some of the jobs.
3. For this reason he leaves the job stream in draft state while the work is still in
progress, so that it is not included in the plan generated every day.
4. To apply the changes he operates directly using the job stream editor available
with Fine Cola's scheduling product: defining a new job by renaming an
existing job definition and adding a new dependency.
5. After he has finished drafting the changes, he saves the job stream with a
validity date set to tomorrow and active status on the test system.
6. Before launching the plan containing the modified job stream, he generates a
trial plan to verify that the dependencies are correctly resolved.
7. When the trial plan ends, he analyzes job statistics and finds that a different
design of dependencies could improve total elapsed time.
8. He applies the changes, sets the new dependencies, and creates a plan
extension. The job stream is rescheduled and run in a test environment
correctly and timely.

Chapter 6. A business scenario 37

A business scenario

9. He meets the IT infrastructure administrator to verify that all the resources

involved in the running of the new plan are available on the following days.
10. The IT infrastructure administrator, after analyzing the plan of availability of
the IT resources, warns him that one of the required resources will not be
available the next week.
11. The IT infrastructure administrator asks the scheduling analyst to run a
forecast plan.
12. He then runs a forecast plan, which contains the scheduled activities for next
week, to verify that the unavailability of the resources will not cause any
major problem.
13. He finds that the unavailability of the resources will cause a decrease in
performance because the other resources become overloaded.
14. He notifies the IT infrastructure administrator of the potential problem.
15. The IT infrastructure administrator analyzes the availability of resources
between departments and realizes that the resources belonging to another
department meet the requirements to run the job definition.
16. Using the Tivoli Dynamic Workload Broker, the scheduling analyst can
automatically move the workload from static to dynamic resource allocation
by routing workloads to the best available systems by matching load
requirements and business policies to available resource capacities.
17. He identifies the jobs in the critical path and moves them from the control of
Tivoli Workload Scheduler to the control of Tivoli Dynamic Workload Broker
to be run dynamically.
18. He finally sets a date to run the new plan in the production environment and
notifies the IT infrastructure administrator.

Figure 3 on page 39 shows how the Fine Cola company can dynamically manage
its workload using Tivoli Workload Scheduler and Tivoli Dynamic Workload
Broker and satisfying the SLA response time.

38 IBM Tivoli Workload Automation: Overview

A business scenario

Company goal SLA

Satisfy the SLA response time
during peak periods Response time <10s

Availability 99.00%

All orders available

by 5 p.m.

Policy
Maximize resource
utilization

Tivoli Dynamic
Workload Broker
12
11 1

12
10 2 11 1
12
11 1 12
11 1 10 2
9 3
10 2
10 2 3
8 4 9
9 3
7 5 9 3
8 4
6
8 4
8 4 7 5
6
7 5
6 7 5
6

Job1 Job 2 Job 3 Job 4 Job 5

Static way
Dynamic way
If an unplanned order
arrives, the SLA for the Automatically discovers
job cannot be met the available resources

During peak periods The SLAs for the jobs

some resources will continue to be met
become overloaded
The jobs are automatically
If new resources are assigned to any available
added the jobs must be resource that matches
reconfigured the job requirements

Figure 3. How to satisfy SLA response time during peak oeriods using Tivoli Workload
Scheduler and Tivoli Dynamic Workload Broker

Monitoring the workload

While the operations analyst monitors the automated workload on a typical work
day, he realizes that Job306, which is in the critical path of the schedule, is in the
abend status. Because of this, Jobstream300 does not complete in the necessary time
frame, causing a negative effect on the rest of the schedule. The consequent delay
in running the plan might cause problems to Fine Cola's daily operations. With the
help of the Tivoli Job Scheduling Console he then:
1. Analyzes the job and error logs in the current plan and finds that the error
occurred for an unmanaged exception. The error might occur again and he
cannot simply restart Job306.
2. Identifies the application specialist who is responsible for Job306 and opens a
problem ticket containing all the information concerning the job.
3. Queries the status of depending jobs, exports the list in Comma Separated
Variables (CSV) format, and attaches it to the ticket so that it can be viewed
with a spreadsheet. Requests that the ticket be answered with high priority.

Chapter 6. A business scenario 39

A business scenario

After an internal analysis, the application specialist finds that there is a broken
execution path that must be fixed. The expected time for resolution is three hours,
including a hot fix and a regression test.

One hour later, however, the operations analyst realizes that even if the application
support team works overtime, the fix will not be completed before the end of the
day and it will be impossible to close the daily processing today. He checks the
status of the depending jobs and sets a target time to have the hot fix loaded into
production during the night.

Then, sometime during the night:

1. The application team releases the hot fix and notifies the scheduling analyst
who loads the new job into the production system, and notifies the operations
analyst.
2. The operations analyst connects to the scheduling system from home to restart
the job stream.
3. The operations analyst restarts Job306. The fix works and the job completes, as
expected, one hour too late to complete the depending jobs before the next
daily plan extension.
4. Early next morning the plan for the day is created. Because of the functionality
of the latest version of Tivoli Workload Scheduler, the jobs depending on
Job306, that could not complete in time, are now simply moved to run today,
keeping their name and all their active file dependencies.
5. The operations analyst monitors the process remotely. When he arrives at work
in the morning, he checks the actual completion of the daily workload.
Everything completed successfully and he closes the ticket.

Managing the organization of the IT infrastructure

Two weeks before Christmas, the IT infrastructure administrator receives a
notification from the scheduling analyst that an unplanned order adds so many
tasks to a job stream in the critical path that its completion is delayed by a day.
This causes a delay also in the completion of the plan scheduled to run the week
before Christmas. The scheduling analyst advises him that he has already run the
forecast plan and verified that with this addition the SLA for the job stream cannot
be met and also the resources will become overloaded. To avoid this, concurrent
jobs that need to use the same resource will need to wait until the requested
quantity is available causing delay in the delivery of the order.

To find a solution to the potential problem and achieve the goals set for workload
processing, without buying additional resources, using Tivoli Dynamic Workload
Broker, he proceeds in the following way:
1. He performs an automatic discovery of the resources available in the
scheduling domain with their characteristics and relationships.
2. He finds a pool of resources in the Inventory department that meet the SLA to
run the jobs. These resources have the required RAM, microprocessor, operating
system, and application environments to run the new job stream and will be
used at half their capacity during Christmas.
Without Tivoli Dynamic Workload Broker he could not dynamically adapt the
new workload processing to match load requirements with business policies
and priorities, and resource availability and capacity. The only way to solve the
problem would be to buy new hardware to run the added job streams
increasing the cost of IT management infrastructure without optimizing the use
of the existing resources.

40 IBM Tivoli Workload Automation: Overview

A business scenario

3. He determines, based on the policies and jobs dispatching, how many new
resources are required to run the new job stream.
4. He manages the definition of business-oriented performance goals for the entire
domain of servers, provides an end-to-end view of actual performance relative
to those goals, and manages the server resource allocation and load to meet the
performance goals.
5. He identifies the required resources and finds an agreement with the Inventory
department manager, to share the required resource between the two
departments.
6. He defines a new logical resource in which he outlines the machines that are
shared between the departments.
7. He communicates to the Ordering department the new agreement with the
resource optimization.
8. Now he can guarantee the running of jobs within the time frame according to
policies, rules, and resources planned availability. In this way he can also
satisfy the optimization policy to maximize resource utilization.
9. The scheduling analyst now builds a feasible production plan.
Using Tivoli Dynamic Workload Broker he met the constraints imposed by
rules and policies and achieved SLA goals, optimizing execution time,
throughput, cost, and reliability.

The benefits
By adopting a workload scheduling strategy, and in particular by using Tivoli
Workload Scheduler and Tivoli Dynamic Workload Broker, Fine Cola is
experiencing significant and immediate benefits, such as:
v The successful integration of all its manufacturing and distribution processes.
Because of how Fine Cola implemented their new processing flow, every
customer order is active from the time a customer service representative receives
it until the loading dock ships the merchandise and finance sends an invoice.
Now orders can be tracked more easily, and manufacturing, inventory, and
shipping among many different locations can be coordinated simultaneously. If
an unplanned order arrives it can be easily managed in the new dynamic IT
infrastructure.
v The standardization and speeding up of the manufacturing process.
Tivoli Workload Scheduler has helped to automate many of the steps of Fine
Cola's manufacturing process. This results in savings in time and increase in
productivity.
v Reduce inventory
The manufacturing process flows more smoothly, and this improves visibility of
the order fulfillment process inside the company. This can lead to reduced
inventory of the raw materials used, and can help better plan deliveries to
customers, reducing the finished goods inventory at the warehouses and
shipping docks.
v Optimize IT infrastructures
The dynamic allocation of the IT resources maximizes the workload throughput
across the enterprise reducing costs, improving performance, and aligning IT
with business needs and service demands.
v Guarantees Fault Tolerance and High Availability
Tivoli Dynamic Workload Broker can recover from server, agent, and
communication failures and it can restart from the point where the failure

Chapter 6. A business scenario 41

A business scenario

happened. No status information will be lost due to failure events. Moreover if a

computer breaks, its workload is automatically routed to another computer that
can guarantee the SLAs.

In conclusion, this solution provides business value because it:

v Delivers service response times according to service level objectives.
v Understands dependencies on services for each line of business.
v Accommodates unpredictable use patterns with predictive logic.
v Understands service relationships to each other and to the IT infrastructure and
business process layers.
v Provides network fault tolerance and high availability of the scheduling
infrastructure.
v Reduces system and operational complexity and leverages IT staff skills and
knowledge.
v Integrates systems quickly and easily, with minimal disruption to existing
business processes.

42 IBM Tivoli Workload Automation: Overview

Chapter 7. Tivoli Workload Scheduler
Tivoli Workload Scheduler’s scheduling features help you plan every phase of
production. During the plan processing period, the Tivoli Workload Scheduler
production control programs manage the production environment and automate
most operator activities. Tivoli Workload Scheduler prepares jobs for execution,
resolves interdependencies, and launches and tracks each job. Because jobs start
running as soon as their dependencies are satisfied, idle time is minimized, and
throughput improves significantly. Jobs never run out of sequence, and, if a job
fails, Tivoli Workload Scheduler handles the recovery process with little or no
operator intervention.

Overview
The next sections provide an outline of Tivoli Workload Scheduler.

What is Tivoli Workload Scheduler

Tivoli Workload Scheduler is composed of three parts:
Tivoli Workload Scheduler engine
The scheduling engine. It runs on every computer of a Tivoli Workload
Scheduler network. During installation, the engine is configured for the
role that the workstation will play within the scheduling network, such as
master domain manager, domain manager, or agent.
| Tivoli Workload Scheduler Connector
| It maps Tivoli Dynamic Workload Console and Job Scheduling Console
| commands to the Tivoli Workload Scheduler engine through the embedded
| version of WebSphere Application Server. The Tivoli Workload Scheduler
| connector usually runs on the master and on any of the fault-tolerant
| agents (FTAs) that you plan to use as backup machines for the master
| workstation.
| A graphical user interface
| Two graphical user interfaces are currently distributed with the product:
| The Tivoli Dynamic Workload Console
| Is Web-based, light, powerful, and user friendly. It can be used on
| any computer that has a Web browser and provides access to all
| the current Tivoli Workload Scheduler functions. It is the strategic
| graphical user interface for the entire Tivoli Workload Automation
| portfolio.
| The Tivoli Job Scheduling Console
| Is Java™-based and can be used on any computer that has a
| TCP/IP link with the computer running the Tivoli Workload
| Scheduler connector. It is being replaced by the Tivoli Dynamic
| Workload Console and, although still in maintenance, it is not
| planned to support new Tivoli Workload Scheduler functions
| beyond those of version 8.4.

| With either interface you can manage all Tivoli Workload Scheduler plan
| and database objects.

© Copyright IBM Corp. 1991, 2008 43

Tivoli Workload Scheduler

The Tivoli Workload Scheduler network

A Tivoli Workload Scheduler network is made up of the workstations, or CPUs, on
which jobs and job streams are run.

A Tivoli Workload Scheduler network contains at least one Tivoli Workload

Scheduler domain, the master domain, in which the master domain manager is the
management hub. Additional domains can be used to divide a widely distributed
network into smaller, locally managed groups.

Figure 4. This Tivoli Workload Scheduler network is made up by two domains

Using multiple domains reduces the amount of network traffic by reducing the
amount of communication required between the master domain manager and other
computers.

In a single domain configuration, the master domain manager maintains

communication with all of the workstations in the scheduling network.

In a multi-domain configuration, the master domain manager communicates with

the workstations in its domain and with the subordinate domain managers. The
subordinate domain managers, in turn, communicate with the workstations in their
domains and with their subordinate domain managers. Multiple domains also
provide fault-tolerance by limiting the problems caused by losing a domain
manager to a single domain. To limit the effects further, you can designate backup
domain managers to take over if their domain managers fail.

Every time the production plan is created or extended the master domain manager
creates a production control file, named Symphony. Tivoli Workload Scheduler is
then restarted in the network, and the master domain manager sends a copy of the
new production control file to each of its automatically linked agents and
subordinate domain managers. The domain managers, in turn, send copies to their
automatically linked agents and subordinate domain managers.

Once the network is started, scheduling messages like job starts and completions
are passed from the agents to their domain managers, through the parent domain
managers to the master domain manager. The master domain manager then
44 IBM Tivoli Workload Automation: Overview
Tivoli Workload Scheduler

broadcasts the messages throughout the hierarchical tree to update the production
control files of domain managers and fault tolerant agents running in Full Status
mode.

Manager and agent types

Primarily, workstation definitions refer to physical workstations. However, in the
case of extended and network agents, the workstations are logical definitions that
must be hosted by a physical Tivoli Workload Scheduler workstation.

Tivoli Workload Scheduler workstations can be of the following types:

Master domain manager (MDM)
The domain manager in the topmost domain of a Tivoli Workload
Scheduler network. It either contains or connects to the relational database
that stores the scheduling object definitions. It creates or updates the
production file when the plan is created or extended and distributes it in
the network. It performs all logging and reporting for the network.
Backup master
A fault-tolerant agent or domain manager capable of assuming the
responsibilities of the master domain manager for automatic workload
recovery.
Domain manager
The management hub in a domain. All communications to and from the
agents in a domain are routed through the domain manager.
Backup domain manager
A fault-tolerant agent capable of assuming the responsibilities of its
domain manager.
Fault-tolerant agent (FTA)
A workstation capable of resolving local dependencies and launching its
jobs in the absence of a domain manager.
Standard agent
A workstation that launches jobs only under the direction of its domain
manager. It is not fault-tolerant.
Extended agent
A logical workstation definition that helps you launch and control jobs on
other systems and applications, such as Peoplesoft, Oracle Applications,
SAP, and MVS™.
Network Agent
A logical workstation definition for creating dependencies between jobs
and job streams in separate Tivoli Workload Scheduler networks.

Topology
A key to choosing how to set up Tivoli Workload Scheduler domains for an
enterprise is the concept of localized processing. The idea is to separate or localize
the enterprises’s scheduling needs based on a common set of characteristics.

Common characteristics are things such as geographical locations, business

functions, and application groupings. Grouping related processing can limit the
amount of interdependency information that needs to be communicated between
domains. The benefits of localizing processing in domains are:
v Decreased network traffic. Keeping processing localized to domains eliminates
the need for frequent interdomain communications.

Chapter 7. Tivoli Workload Scheduler 45

Tivoli Workload Scheduler

v Provides a convenient way to tighten security and simplify administration.

Security and administration can be defined at, and limited to, the domain level.
Instead of network-wide or workstation-specific administration, you can have
domain administration.
v Network and workstation fault tolerance can be optimized. In a multiple domain
Tivoli Workload Scheduler network, you can define backups for each domain
manager, so that problems in one domain do not disrupt operations in other
domains.

Networking
The following questions will help in making decisions about how to set up your
enterprise’s Tivoli Workload Scheduler network. Some questions involve aspects of
your network, and others involve the applications controlled by Tivoli Workload
Scheduler. You may need to consult with other people in your organization to
resolve some issues.
v How large is your Tivoli Workload Scheduler network? How many computers
does it hold? How many applications and jobs does it run?
The size of your network will help you decide whether to use a single domain
or the multiple domain architecture. If you have a small number of computers,
or a small number of applications to control with Tivoli Workload Scheduler,
there may not be a need for multiple domains.
v How many geographic locations will be covered in your Tivoli Workload
Scheduler network? How reliable and efficient is the communication between
locations?
This is one of the primary reasons for choosing a multiple domain architecture.
One domain for each geographical location is a common configuration. If you
choose single domain architecture, you will be more reliant on the network to
maintain continuous processing.
v Do you need centralized or decentralized management of Tivoli Workload
Scheduler?
A Tivoli Workload Scheduler network, with either a single domain or multiple
domains, gives you the ability to manage Tivoli Workload Scheduler from a
single node, the master domain manager. If you want to manage multiple
locations separately, you can consider the installation of a separate Tivoli
Workload Scheduler network at each location. Note that some degree of
decentralized management is possible in a stand-alone Tivoli Workload
Scheduler network by mounting or sharing file systems.
v Do you have multiple physical or logical entities at a single site? Are there
different buildings, and several floors in each building? Are there different
departments or business functions? Are there different applications?
These may be reasons for choosing a multi-domain configuration. For example, a
domain for each building, department, business function, or each application
(manufacturing, financial, engineering, etc.).
v Do you run applications, like SAP R/3, that will operate with Tivoli Workload
Scheduler?
If they are discrete and separate from other applications, you may choose to put
them in a separate Tivoli Workload Scheduler domain.
v Would you like your Tivoli Workload Scheduler domains to mirror your
Windows domains?
This is not required, but may be useful.
v Do you want to isolate or differentiate a set of systems based on performance or
other criteria?

46 IBM Tivoli Workload Automation: Overview

Tivoli Workload Scheduler

This may provide another reason to define multiple Tivoli Workload Scheduler
domains to localize systems based on performance or platform type.
v How much network traffic do you have now?
If your network traffic is manageable, the need for multiple domains is less
important.
v Do your job dependencies cross system boundaries, geographical boundaries, or
application boundaries? For example, does the start of Job1 on CPU3 depend on
the completion of Job2 running on CPU4?
The degree of interdependence between jobs is an important consideration when
laying out your Tivoli Workload Scheduler network. If you use multiple
domains, you should try to keep interdependent objects in the same domain.
This will decrease network traffic and take better advantage of the domain
architecture.
v What level of fault-tolerance do you require?
An obvious disadvantage of the single domain configuration is the reliance on a
single domain manager. In a multi-domain network, the loss of a single domain
manager affects only the agents in its domain.

Tivoli Workload Scheduler components

Tivoli Workload Scheduler uses several manager processes to efficiently segregate
and manage networking, dependency resolution, and job launching. These
processes communicate among themselves through the use of message queues.
Message queues are also used by the Console Manager (conman) to integrate
operator commands into the batch process.

On any computer running Tivoli Workload Scheduler there are a series of active
management processes. They are started as a system service, or by the StartUp
command, or manually from the Job Scheduling Console. The following are the
main processes:
Netman
The network management process that establishes network connections
between remote mailman processes and local Writer processes.
Mailman
The mail management process that sends and receives inter-CPU messages.
Batchman
The production control process. Working from Symphony, the production
control file, it runs jobs streams, resolves dependencies, and directs jobman
to launch jobs.
Writer The network writer process that passes incoming messages to the local
mailman process.
Jobman
The job management process that launches and tracks jobs under the
direction of batchman.

In addition, Tivoli Workload Scheduler uses two command line interfaces:

Composer
The command-line program used to define, manage, and store scheduling
objects in the Tivoli Workload Scheduler database. The composer
command-line program can be installed and used on any computer
connected through TCP/IP to the system where the master domain
manager is installed. It does not require the installation of a Tivoli

Chapter 7. Tivoli Workload Scheduler 47

Tivoli Workload Scheduler

Workload Scheduler workstation as a prerequisite. It communicates

through HTTP/HTTPS with the master domain manager where the
relational database management system (RDBMS) is installed. The
HTTP/HTTPS communication setup and the authentication check are
managed by the WebSphere Application Server - Express infrastructure.
The composer uses edit files to update the scheduling database.
Conman
The console manager. It is the user interface for plan running activities by
means of the command line interface or of the Job Scheduling Console.
Conman writes information that is received by either the local netman or
mailman processes.

Tivoli Workload Scheduler scheduling objects

Scheduling with Tivoli Workload Scheduler includes the capability to do the
following:
v Schedule jobs across a network.
v Group jobs into job streams according, for example, to function or application.
v Set limits on the number of jobs that can run concurrently.
v Create job streams based on day of the week, on specified dates and times, or by
customized calendars.
v Ensure correct processing order by identifying dependencies such as successful
completion of previous jobs, availability of resources, or existence of required
files.
v Set automatic recovery procedures for unsuccessful jobs.
v Forward incomplete jobs to the next production day.

Starting from version 8.3, the Tivoli Workload Scheduler scheduling objects are
stored in a relational database. This results in a significant improvement, in
comparison with previous versions, of how objects are defined and managed in the
database. Each object can now be managed independently without having to use
lists of scheduling objects like calendars, parameters, prompts and resources. The
command syntax used to define and manage these objects has also become direct
and powerful.

Tivoli Workload Scheduler administrators and operators work with these objects
for their scheduling activity:
Workstation
Also referred to as CPU. Usually an individual computer on which jobs
and job streams are run. Workstations are defined in the Tivoli Workload
Scheduler database as a unique object. A workstation definition is required
for every computer that executes jobs or job streams in the Tivoli Workload
Scheduler network.
Workstation class
A group of workstations. Any number of workstations can be placed in a
class. Job streams and jobs can be assigned to execute on a workstation
class. This makes replication of a job or job stream across many
workstations easy.
Job A script or command, run on the user’s behalf, run and controlled by
Tivoli Workload Scheduler.
Job stream
A list of jobs that run as a unit (such as a weekly backup application),
along with run cycles, times, priorities, and other dependencies that
determine the exact order in which the jobs run.

48 IBM Tivoli Workload Automation: Overview

Tivoli Workload Scheduler

Calendar
A list of scheduling dates. Each calendar can be assigned to multiple job
streams. Assigning a calendar to a job stream causes that job stream to run
on the dates specified in the calendar. A calendar can be used as an
inclusive or as an exclusive run cycle.
Run cycle
A cycle that specifies the days that a job stream is scheduled to run. Run
cycles are defined as part of job streams and may include calendars that
were previously defined. There are three types of run cycles: a Simple run
cycle, a Weekly run cycle, or a Calendar run cycle (commonly called a
calendar). Each type of run cycle can be inclusive or exclusive. That is,
each run cycle can define the days when a job stream is included in the
production cycle, or when the job stream is excluded from the production
cycle.
Prompt
An object that can be used as a dependency for jobs and job streams. A
prompt must be answered affirmatively for the dependent job or job
stream to launch. There are two types of prompts: predefined and ad hoc.
An ad hoc prompt is defined within the properties of a job or job stream
and is unique to that job or job stream. A predefined prompt is defined in
the Tivoli Workload Scheduler database and can be used by any job or job
stream.
Resource
An object representing either physical or logical resources on your system.
Once defined in the Tivoli Workload Scheduler database, resources can be
used as dependencies for jobs and job streams. For example, you can
define a resource named tapes with a unit value of two. Then, define jobs
that require two available tape drives as a dependency. Jobs with this
dependency cannot run concurrently because each time a job is run the
tapes resource is in use.
| Variable and variable table
| A variable can be used to substitute values in scheduling objects contained
| in jobs and job streams; that is, in JCL, log on, prompts dependencies, file
| dependencies, and recovery prompts. The values are replaced in the job
| scripts at run time. Variables are global (that is, they can be used on any
| agent of the domain) and are defined in the database in groups called
| variable tables.
| Parameter
| A parameter can be used to substitute values in jobs and job streams just
| like global variables. The difference is that a parameter is defined on the
| specific workstation where the related job is to run and has no global
| effect, but only on that specific workstation. Parameters cannot be used
| when scripting extended agent jobs.
User On Windows workstations, the user name specified in the Logon field of a
job definition must have a matching user definition. The definitions
provide the user passwords required by Tivoli Workload Scheduler to
launch jobs.
Event rule
A scheduling event rule defines a set of actions that are to run upon the
occurrence of specific event conditions. The definition of an event rule
correlates events and triggers actions. When you define an event rule, you
specify one or more events, a correlation rule, and the one or more actions
that are triggered by those events. Moreover, you can specify validity
dates, a daily time interval of activity, and a common time zone for all the
time restrictions that are set.

Chapter 7. Tivoli Workload Scheduler 49

Tivoli Workload Scheduler

You can control how jobs and job streams are processed with the following
attributes:
Dependencies
Conditions that must be satisfied before a job or job stream can run. You
can set the following types of dependencies:
v A predecessor job or job stream must have completed successfully.
v One or more specific resources must be available.
v Access to specific files must be granted.
v An affirmative response to a prompt.
Time constraints
Conditions based on time, such as:
v The time at which a job or job stream should start.
v The time after which a job or job stream cannot start.
v The repetition rate at which a job or job stream is to be run within a
specified time slot.
Job priority
A priority system according to which jobs and job streams are queued for
execution.
Job fence
A filter defined for workstations. Only jobs and job streams whose priority
exceeds the job fence value can run on a workstation.
Limit Sets a limit to the number of jobs that can be launched concurrently on a
workstation.

The production process

Tivoli Workload Scheduler production is based on a plan that runs in a production
period. The production period is defined by the user when creating or extending
the production plan. It can span from a few hours to some days (by default it is a
24 hours period). Before the start of each production period, Tivoli Workload
Scheduler executes a program that creates the production plan starting from the
modeling data stored in the database and from an intermediate plan called
preproduction plan. Then another program includes the uncompleted schedules from
the previous production period into the current plan and logs all the statistics of
the previous production into an archive.

All of the required information for that production period is placed into a
production control file named Symphony. During the production period, the
production control database is continually being updated to reflect the work that
needs to be done, the work in progress, and the work that has been completed. A
copy of the Symphony file is sent to all subordinate domain managers and to all
the fault-tolerant agents in the same domain. The subordinate domain managers
distribute their copy to all the fault-tolerant agents in their domain and to all the
domain managers that are subordinate to them, and so on down the line. This
causes fault-tolerant agents throughout the network to continue processing even if
the network connection to their domain manager is down. From the graphical
interfaces or the command line interface, the operator can view and make changes
in the current production by making changes in the Symphony file.

Tivoli Workload Scheduler processes monitor the production control database and
make calls to the operating system to launch jobs as required. The operating
system runs the job, and in return informs Tivoli Workload Scheduler if the job

50 IBM Tivoli Workload Automation: Overview

Tivoli Workload Scheduler

completed successfully or not. This information is entered into the production

control database to indicate the status of the job.

Scheduling
Scheduling can be accomplished either through the Tivoli Workload Scheduler
command line interface or one of the two graphical interfaces.

Scheduling includes the following tasks:

v Defining and maintaining workstations
v Defining scheduling objects
v Defining job streams
v Starting and stopping production processing
v Viewing and modifying jobs and job streams.

Defining scheduling objects

Scheduling objects are workstations, workstation classes, domains, jobs, job
streams, resources, prompts, calendars, variables and variable tables, parameters,
and event rules. Scheduling objects are managed with the Composer program and
are stored in the Tivoli Workload Scheduler database. To create or modify an
object, you can use either the Tivoli Workload Scheduler command line interface or
one of the graphical interfaces.

Creating job streams

The primary processing task of Tivoli Workload Scheduler is to run job streams. A
job stream is an outline of batch processing consisting of a list of jobs. Job streams
can be defined using either the command line interface or one of the graphical
interfaces. Using either graphical interface you can easily create and modify job
streams. You can use their job stream editors to work with the jobs and the
follows dependencies between the jobs, as well as the job stream run cycles. You
can also easily specify time restrictions, resource dependencies, file dependencies,
and prompt dependencies at the job stream level.

Job streams can be defined as draft. A draft job stream is not considered when
resolving dependencies and is not added to the production plan. It becomes actual
only after the draft keyword is removed from its definition, and the JnextPlan
command is run to add it to the preproduction plan and so to the production plan.

Setting job recovery

When defining a job, consider that in some instances it might not complete
successfully. The administrator can define a recovery option and recovery actions
when defining the job. The following recovery options are available:
v Do not continue with the next job. This stops the execution of the job stream and
puts it in the stuck state. This is the default action.
v Continue with the next job.
v Run the job again.

Optionally, a recovery prompt can be associated to the job. A recovery prompt is a

local prompt to display when the job completes unsuccessfully. Processing does not
continue until the prompt is answered affirmatively.

Chapter 7. Tivoli Workload Scheduler 51

Tivoli Workload Scheduler

Another option is to define a recovery job that can be run in the place of the
original job if it completes unsuccessfully. The recovery job must have been
defined previously. Processing stops if the recovery job does not complete
successfully.

Integration with Tivoli Enterprise Data Warehouse

When your environment contains many products and services that manage and
monitor your IT enterprise, storing this data, generating reports, and analyzing the
data becomes a complex task. Tivoli Enterprise Data Warehouse helps you collect
this data in one place, a central data warehouse, and helps you construct an
end-to-end view of your enterprise and view its components. Tivoli Workload
Scheduler provides a Tivoli Enterprise Data Warehouse enablement pack to
consolidate scheduling data in the Tivoli Enterprise Data Warehouse database.

Running production
Production consists of taking the definitions of the scheduling objects from the
database, together with their time constraints and their dependencies, and building
and running the production control file.

Running the plan

The production plan contains information about which jobs to run, on which
fault-tolerant agent, and what dependencies must be satisfied before each job is
launched. Tivoli Workload Scheduler creates the production plan starting from the
modeling data stored in the database and from an intermediate plan called the
preproduction plan. The preproduction plan is automatically created and managed
by the product. To avoid problems, the database is locked during the generation of
the plan and is unlocked when the generation completes or if an error condition
occurs. The preproduction plan is used to identify in advance the job stream
instances and the external follows job stream dependencies involved in a specified
time period.

You use the JnextPlan command on the master domain manager to generate the
production plan and distribute it across the Tivoli Workload Scheduler network.

To generate and start a new production plan, Tivoli Workload Scheduler performs
the following steps:
1. Updates the preproduction plan with the objects defined in the database that
were added or updated since the last time the plan was created or extended.
2. Retrieves from the preproduction plan the information about the job streams to
run in the specified time period and saves it in an intermediate production
plan.
3. Includes in the new production plan the uncompleted job streams from the
previous production plan.
4. Creates the new production plan and stores it in a file named Symphony.
5. Distributes a copy of the Symphony file to the workstations involved in the
new product plan processing.
6. Logs all the statistics of the previous production plan into an archive.
7. Updates the job stream state in the preproduction plan.

The copy of the newly-generated Symphony file is used starting from the top
domain’s fault-tolerant agents and domain managers of the child domains and
down the tree to all subordinate domains.

52 IBM Tivoli Workload Automation: Overview

Tivoli Workload Scheduler

Each fault-tolerant agent that receives the production plan can continue processing
even if the network connection to its domain manager goes down.

At each destination fault-tolerant agent, Tivoli Workload Scheduler performs the

following actions to manage job processing:
1. Accesses the copy of the Symphony file and reads the instructions about which
job to run.
2. Makes calls to the operating system to launch jobs as required.
3. Updates its copy of the Symphony file with the job processing results and
sends notification back up the tree to the master domain manager and to all
full status fault-tolerant agents. The original copy of the Symphony file stored
on the master domain manager and the copies stored on the backup master
domain managers, if defined, are updated accordingly.

This means that during job processing, each fault-tolerant agent has its own copy
of the Symphony file updated with the information about the jobs it is running (or
that are running in its domain and child domains if the fault-tolerant agent is
full-status or a domain manager), and the master domain manager (and backup
master domain manager if defined) has the copy of the Symphony file that
contains all updates coming from all fault-tolerant agents. In this way the
Symphony file on the master domain manager is kept up-to-date with the jobs still
to run, the jobs running, and the jobs already completed.

After the production plan is generated for the first time, it can be extended to the
next production period with the JnextPlan command. The Symphony file is
refreshed with the latest changes and redistributed throughout the network.

Running job streams

Depending on their run cycle definition, job streams are taken from the Tivoli
Workload Scheduler database and automatically inserted into the current
production plan.

While the job stream is in the plan, and has not completed, you can still modify
any of its components. That is, you can modify the job stream properties, the
properties of its jobs, their sequence, the workstation or resources they use, and so
on, to satisfy last-minute requirements.

You can also hold, release, or cancel a job stream, as well as change the maximum
number of jobs within the job stream that can run concurrently. You can change the
priority previously assigned to the job stream and release the job stream from all
its dependencies.

Last minute changes to the current production plan include the possibility to
submit jobs and job streams that are already defined in the Tivoli Workload
Scheduler database but were not included in the plan. You can also submit jobs
that are being defined ad hoc. These jobs are submitted to the current plan but are
not stored in the database.

Starting from version 8.3, you can create and manage multiple instances of the
same job stream over a number of days or at different times within the same day.
This new feature introduced the possibility to have in the same plan more than
one instance of the same job stream with the same name. Each job stream instance
is identified by the job stream name, the name of the workstation where it is
scheduled to run, and by the start time defined in the preproduction plan.

Chapter 7. Tivoli Workload Scheduler 53

Tivoli Workload Scheduler

Monitoring
Monitoring is done by listing plan objects in either graphical user interface. Using
lists, you can see the status of all or of subsets of the following objects in the
current plan:
v Job stream instances
v Job instances
v Domains
v Workstations
v Resources.
v File dependencies
v Prompt dependencies.

You can use these lists also to manage some of these objects. For example, you can
reallocate resources, link or unlink workstations, kill jobs, or switch domain
manager.

Additionally, you can monitor the daily plan with Tivoli Business Systems
Manager, an object-oriented systems management application that provides
monitoring and event management of resources, applications, and subsystems, that
is integrated with Tivoli Workload Scheduler.

Network managers can use Tivoli Workload Scheduler/NetView, a NetView

application, to monitor and diagnose Tivoli Workload Scheduler networks from a
NetView management node. It includes a set of submaps and symbols to view
Tivoli Workload Scheduler networks topographically, and determine the status of
job scheduling activity and critical Tivoli Workload Scheduler processes on each
workstation. Menu actions are provided to start and stop Tivoli Workload
Scheduler processing and to run conman on any workstation in the network.

Controlling with IBM Tivoli Monitoring

IBM Tivoli Monitoring is a product that applies pre-configured best practices to the
automated monitoring of essential system resources. It helps you to detect
bottlenecks and other potential problems and provides you with the means for
automatic recovery from critical situations. In this way it eliminates the need for
system administrators to manually scan through extensive performance data.

Tivoli Workload Scheduler integrates with IBM Tivoli Monitoring. A set of IBM
Tivoli Monitoring resource models, tailored to check the status of scheduling
resources, is included with Tivoli Workload Scheduler.

By adding this set of resource models to the IBM Tivoli Monitoring default
resource models set, you can add these resource models to monitoring profiles and
distribute them to the profile subscribers where the scheduling resources are.

Within the monitoring profile you can define the following items:
v Which resource models you want to distribute, and, for each resource model:
– When an alarm is triggered
– Which response severity is assigned to the triggered alarm
– Who is notified about the alarm and how
– If a program is run in response to a triggered alarm
– If events are to be sent to Tivoli Enterprise Console in response to triggered
alarms

54 IBM Tivoli Workload Automation: Overview

Tivoli Workload Scheduler

v Who are the subscribers of the monitoring profile distribution

v When the monitoring profile containing the resource model is active

In addition to these resource models a set of additional BAROC files is provided.

These BAROC profiles are used to customize the TEC Event Server to manage the
events triggered by the new set of resource models.

Reporting
As part of the pre-production and post-production processes, reports are generated
which show summary or detail information about the previous or next production
day. These reports can also be generated ad-hoc. The following reports are
available:
v Job details listing
v Prompt listing
v Calendar listing
v Parameter listing
v Resource listing
v Job History listing
v Job histogram
v Planned production schedule
v Planned production summary
v Planned production detail
v Actual production summary
v Actual production detail
v Cross reference report

In addition, during production, a standard list file (STDLIST) is created for each
job instance launched by Tivoli Workload Scheduler. Standard list files contain
header and trailer banners, echoed commands, and errors and warnings. These
files can be used to troubleshoot problems in job execution.

Auditing
An auditing option helps track changes to the database and the plan.

For the database, all user modifications, except for the delta of the modifications,
are logged. If an object is opened and saved, the action is logged even if no
modification is made.

For the plan, all user modifications to the plan are logged. Actions are logged
whether or not they are successful.

Audit files are logged to a flat text file on individual machines in the Tivoli
Workload Scheduler network. This minimizes the risk of audit failure due to
network issues and allows a straightforward approach to writing the log. The log
formats are basically the same for both the plan and the database. The logs consist
of a header portion which is the same for all records, an “action ID”, and a section
of data which varies according to the action type. All data is stored in clear text
and formatted to be readable and editable from a text editor such as vi or notepad.

Chapter 7. Tivoli Workload Scheduler 55

Tivoli Workload Scheduler

| Using event-driven workload automation

| Use this optional feature to set up and run rules that perform predefined actions in
| response to particular events occurring on your agents. Your organization can
| benefit from using this feature by adding on-demand workload automation to
| plan-based job scheduling, gaining savings in time and resources.

| Event-driven workload automation is based on the concept of event rule. In Tivoli

| Workload Scheduler an event rule is a scheduling object and is made up of events,
| event-correlating conditions, and actions. When you define an event rule, you
| specify one or more events, a correlation rule, and one or more actions that are
| triggered by those events. Moreover, you can specify validity dates, a daily time
| interval of activity, and a common time zone for all the time restrictions that are
| set.

| You can set up event rules to:

| v Trigger the execution of batch jobs and job streams based on the occurrence or
| combination of real time events
| v Reply to prompts
| v Notify users when anomalous conditions occur in the Tivoli Workload Scheduler
| scheduling environment or batch scheduling activity
| v Invoke an external product when a particular event condition occurs

| Tivoli Workload Scheduler includes a set of predefined event and action plug-ins,
| but also provides a software development kit with samples and templates for your
| application programmers to develop their own plug-ins.

Options and security

The Tivoli Workload Scheduler options files determine how Tivoli Workload
Scheduler runs on your system. Several performance, tuning, security, logging, and
other configuration options are available.

Setting the Tivoli Workload Scheduler options

You can set two types of properties to configure your Tivoli Workload Scheduler
runtime environment, properties that are set on the master domain manager and
affect processing on all workstations in the Tivoli Workload Scheduler network,
and properties that are set locally on a workstation and affect processing on that
workstation only. The former are managed using the Tivoli Workload Scheduler
command line program named optman, and the latter you define locally on the
workstation by customizing the configuration files useropts, localopts, and
jobmanrc.

Global options are used to:

v Define if the security files of all the workstations of the network can be created
and managed only from the master domain manager or if the root user or
administrator of each workstation can create and manage their own.
v Select whether to enable or disable database auditing.
v Control which objects in the plan the user is permitted to list when running a
query.
v Select whether to enable plan auditing.
v Select whether to enable strong encryption.
v Select whether to enable or disable the fault tolerant switch manager.

56 IBM Tivoli Workload Automation: Overview

Tivoli Workload Scheduler

v Select whether to enable or disable the time zone option.

v Enter the number of days for which you want to save job statistics.
v Set the minimum and maximum lengths of the preproduction plan in days.
v Determine if uncompleted job streams are carried forward from the old to the
new production control file.
v Define the start time of the Tivoli Workload Scheduler processing day.

Local options are used to:

v Specify the name of the local workstation
v Prevent the launching of jobs run by root in UNIX®
v Prevent unknown clients from connecting to the system
v Specify a number of performance options
v Specify a number of logging preferences
v Set SSL security options.

Setting security
Security is accomplished with the use of a security file that contains one or more
user definitions. Each user definition identifies a set of users, the objects they are
permitted to access, and the types of actions they can perform.

A template file is installed with the product. Edit the template to create the user
definitions and compile and install it with a utility program to create a new
operational security file. After it is installed, you make further modifications by
creating an editable copy with another utility.

Each workstation in a Tivoli Workload Scheduler network has its own security file.
An individual file can be maintained on each workstation, or a single security file
can be created on the master domain manager and copied to each domain
manager, fault-tolerant agent, and standard agent.

Secure authentication and encryption

Security is enhanced for connections between protected and non-protected domains
by applying the authentication and encryption mechanism based on the Secure
Sockets Layer (SSL) protocol. SSL uses digital certificates to authenticate the
identity of a workstation.

The Tivoli Workload Scheduler administrator must plan how authentication will be
used within the network:
v Use one certificate for the entire Tivoli Workload Scheduler network.
v Use a separate certificate for each domain.
v Use a separate certificate for each workstation.

SSL support is automatically installed with Tivoli Workload Scheduler.

Work across firewalls

For previous versions of Tivoli Workload Scheduler, running the commands to start
or stop a workstation or to get the standard list required opening a direct TCP/IP
connection between the originator and the destination nodes. In a firewall
environment, this forces users to break the firewall to open a direct communication
path between the master and each fault-tolerant agent in the network.

Chapter 7. Tivoli Workload Scheduler 57

Tivoli Workload Scheduler

Tivoli Workload Scheduler provides a configurable attribute, named behindfirewall,

in the workstation’s definition in the database. You can set this attribute to ON to
indicate that a firewall exists between that particular workstation and its domain
manager, and that the link between the domain manager and the workstation
(which can be another domain manager) is the only allowed link between the
domains.

Also, for all the workstations having this attribute set to ON, the commands to
start or stop the workstation or to get the standard list will be transmitted through
the domain hierarchy instead of opening a direct connection between the master
(or domain manager) and the workstation.

Centralized security mechanism

A new global option makes it possible to change the security model in the Tivoli
Workload Scheduler network. If you use this option, then the security files for the
fault-tolerant agents in the network can be created or modified only on the master
domain manager. The Tivoli Workload Scheduler administrator is responsible for
creating, updating, and distributing the security files for all the agents where user
access is required. Setting this global option triggers a security mechanism to
identify and trust the Tivoli Workload Scheduler network corresponding to that
master domain manager.

If you prefer the traditional security model, you can still use it by not activating
the global variable.

Using time zones

Tivoli Workload Scheduler supports different time zones. Enabling time zones
provides you with the ability to manage your workload across a multiple time
zone environment. Both the 3-character and the variable length notations are
supported with the current version of Tivoli Workload Scheduler. The variable
length notation format is area/city, for example Europe/Paris as equivalent to ECT
(European Central Time). The 3-character notation is supported for backward
compatibility with previous versions of the product.

Once configured, time zones can be specified for start and deadline times within
jobs and job streams.

Using extended agents

With IBM Tivoli Workload Scheduler for Applications, extended agents (XA) are
used to extend the job scheduling functions of Tivoli Workload Scheduler to other
systems and applications. An extended agent is defined as a workstation that has a
host and an access method.

The host is a Tivoli Workload Scheduler fault-tolerant agent (FTA) or standard

agent (SA).

The access method is a program that is run by the hosting workstation whenever
Tivoli Workload Scheduler, either through its command line or either graphical
interface, interacts with the external system. IBM Tivoli Workload Scheduler for
Applications includes the following access methods:
v Oracle e-Business Suite access method (MCMAGENT)
v PeopleSoft access method (psagent)
v R/3 access method (r3batch)

58 IBM Tivoli Workload Automation: Overview

Tivoli Workload Scheduler

v z/OS access method (mvsca7, mvsjes, and mvsopc)

To launch and monitor a job on an extended agent, the host runs the access
method, passing it job details as command line options. The access method
communicates with the external system to launch the job and returns the status of
the job.

An extended agent workstation is a logical entity related to an access method

hosted by the physical Tivoli Workload Scheduler workstation (a fault-tolerant
agent or standard agent). More than one extended agent workstation can be hosted
by the same Tivoli Workload Scheduler workstation and rely on the same access
method. The extended agent is defined in a standard Tivoli Workload Scheduler
workstation definition, which gives the extended agent a name and identifies the
access method.

Figure 5 shows how these elements fit together in the case of a typical extended
agent configuration.

Figure 5. How extended agents work

To launch a job in an external environment, Tivoli Workload Scheduler runs the

extended agent access method, providing it with the extended agent workstation
name and information about the job. The method looks at the corresponding file
named <WORKSTATIONNAME>_<methodname>.opts to determine which external
environment instance it will connect to. The access method can then launch jobs on
that instance and monitor them through completion writing job progress and status
information in the standard list file of the job.

Extended agents can be used to run jobs also in an end-to-environment, where

their scheduling and monitoring is performed from a Tivoli Workload Scheduler
for z/OS controller.

Chapter 7. Tivoli Workload Scheduler 59

60 IBM Tivoli Workload Automation: Overview
Chapter 8. Tivoli Workload Scheduler for z/OS
Tivoli Workload Scheduler for z/OS expands the scope for automating your data
processing (DP) operations. It plans and automatically schedules the production
workload. From a single point of control, it drives and controls the workload
processing at both local and remote sites. By using Tivoli Workload Scheduler for
z/OS to increase automation, you use your DP resources more efficiently, have
more control over your DP assets, and manage your production workload
processing better.

How your production workload is managed

How does Tivoli Workload Scheduler for z/OS give you all this? This section
describes functions that make your information systems (IS) operations run more
efficiently. But first, here is a brief introduction to the structure of the product and
some concepts.

Structure
Tivoli Workload Scheduler for z/OS consists of a base product, the agent and a
number of features. Every z/OS system in your complex requires the base product.
One z/OS system in your complex is designated the controlling system and runs
the engine feature. Only one engine feature is required, even when you want to
start standby engines on other z/OS systems in a sysplex.

Tivoli Workload Scheduler for z/OS with Tivoli Workload Scheduler addresses
your production workload in the distributed environment. You can schedule,
control, and monitor jobs in Tivoli Workload Scheduler from Tivoli Workload
Scheduler for z/OS. For example, in the current plan, you can specify jobs to run
on workstations in Tivoli Workload Scheduler.

The workload on other operating environments can also be controlled with the
open interfaces provided with Tivoli Workload Scheduler for z/OS. Sample
programs using TCP/IP or an NJE/RSCS (network job entry/remote spooling
communication subsystem) combination show you how you can control the
workload on environments that at present have no scheduling feature.

Additionally, national language features let you see the dialogs and messages, in
the language of your choice. These languages are currently available:
v English
v German
v Japanese
v Spanish

Panel and message text can also be modified to include enterprise-specific

instructions or help.

Concepts
In managing production workloads, Tivoli Workload Scheduler for z/OS builds on
several important concepts.

Plans. Tivoli Workload Scheduler for z/OS constructs operating plans based on
user-supplied descriptions of the DP operations department and its production

© Copyright IBM Corp. 1991, 2008 61

Tivoli Workload Scheduler for z/OS

workload. These plans provide the basis for your service level agreements and give
you a picture of the status of the production workload at any point in time. You
can simulate the effects of changes to your production workload, calendar, and
installation by generating trial plans.

Job streams. A job stream is a description of a unit of production work. It can

include the following:
v A list of the jobs (related tasks) associated with that unit of work, such as:
– Data entry
– Job preparation
– Job submission or started-task initiation
– Communication with the NetView program
– File transfer to other operating environments
– Printing of output
– Postprocessing activities, such as quality control or dispatch
– Other tasks related to the unit of work that you want to schedule, control,
and track
v A description of dependencies between jobs within a job stream and between
jobs in other job streams
v Information about resource requirements, such as exclusive use of a data set
v Special operator instructions that are associated with a job
v How and where each job should be processed
v Run policies for that unit of work; that is, when it should be scheduled or
alternatively the name of a group definition that records the run policy

Tivoli Workload Scheduler for z/OS schedules work based on the information you
provide in your job stream descriptions.

Workstations. When scheduling and processing work, Tivoli Workload Scheduler

for z/OS considers the processing requirements of each job. Some typical
processing considerations are:
v Which human or machine resources are required for processing the work, for
example, operators, processors, or printers?
v When are these resources available?
v How are these jobs to be tracked?
v Can this work be processed somewhere else if the resources become
unavailable?

Tivoli Workload Scheduler for z/OS supports a range of work process types, called
workstations, that map the processing requirements of any task in your production
workload. Each workstation supports one type of activity. This gives you the
flexibility to schedule, monitor, and control any type of DP activity, including the
following:
v Job setup, both manual and automatic
v Job submission
v Started-task actions
v Communication with the NetView program
v Print jobs
v Manual preprocessing or postprocessing activity

You can plan for maintenance windows in your hardware and software
environments. Tivoli Workload Scheduler for z/OS helps you perform a controlled
and incident-free shutdown of the environment, preventing last-minute

62 IBM Tivoli Workload Automation: Overview

Tivoli Workload Scheduler for z/OS

cancellation of active tasks. You can choose to reroute the workload automatically
during any outage, planned or unplanned.

Tivoli Workload Scheduler for z/OS tracks jobs as they are processed at
workstations and dynamically updates the plan with real-time information on the
status of jobs. You can view or modify this status information online using the
workstation ready lists in the dialog.

Dependencies. In general, every DP-related activity must occur in a specific order.

Activities performed out of order might create invalid output and possibly even
corrupt your corporate data. This might cause costly reruns, missed deadlines, and
unsatisfied customers.

You can define dependencies for jobs when a specific processing order is required.
When Tivoli Workload Scheduler for z/OS manages the dependent relationships
for you, the jobs are always started in the correct order every time they are
scheduled. A dependency is called internal when it is between two jobs in the same
job stream, and external when it is between two jobs in different job streams.

You can work with job dependencies graphically from the Tivoli Job Scheduling
Console.

Tivoli Workload Scheduler for z/OS lets you serialize work based on the status of
any DP resource. A typical example is a job that uses a data set as input, but must
not start until the data set is successfully created and loaded with valid data. You
can use resource serialization support to send availability information about a DP
resource to Tivoli Workload Scheduler for z/OS.

Special resources. Special resources are typically defined to represent physical or

logical objects used by jobs. A special resource can be used to serialize access to a
data set or to limit the number of file transfers on a particular network link. The
resource does not have to represent a physical object in your configuration,
although it often does.

Tivoli Workload Scheduler for z/OS keeps a record of the state of each resource
and its current allocation status. You can choose to hold resources if a job
allocating the resources ends abnormally. You can also use the Tivoli Workload
Scheduler for z/OS interface with the Resource Object Data Manager (RODM) to
schedule jobs according to real resource availability. You can subscribe to RODM
updates in both local and remote domains.

Tivoli Workload Scheduler for z/OS lets you subscribe to data set activity on z/OS
systems. The data set triggering function of Tivoli Workload Scheduler for z/OS
automatically updates special resource availability when a data set is closed. You
can use this notification to coordinate planned activities or to add unplanned work
to the schedule.

Calendars. Tivoli Workload Scheduler for z/OS uses information about when the
job departments work, so that job streams are not scheduled to run on days when
processing resources are not available (for example, Sundays and holidays). This
information is stored in a calendar. Tivoli Workload Scheduler for z/OS supports
multiple calendars for enterprises where different departments have different work
days and non-working days. Different groups within a business operate according
to different calendars.

Chapter 8. Tivoli Workload Scheduler for z/OS 63

Tivoli Workload Scheduler for z/OS

The multiple calendar function is critical if your enterprise has installations in

more than one geographical location (for example, with different local or national
holidays).

Business processing cycles. Tivoli Workload Scheduler for z/OS uses business
processing cycles, or periods, to calculate when your job streams run, for example,
weekly, or every 10th working day. Periods are based on the business cycles of
your customers. Tivoli Workload Scheduler for z/OS supports a range of periods
for processing the different job streams in your production workload.

When you define a job stream, you specify when it is planned to run, using a run
cycle, which can be:
v A rule with a format such as
ONLY the SECOND TUESDAY of every MONTH
EVERY FRIDAY in the user-defined period SEMESTER1

where the words in upper case are selected from lists of ordinal numbers, names
of days, and common calendar intervals or period names.
v A combination of period and offset. For example, an offset of 10 in a monthly
period specifies the 10th day of each month.

Using Plans in Tivoli Workload Scheduler for z/OS

Tivoli Workload Scheduler for z/OS plans your production workload schedule. It
produces both high-level and detailed plans. These plans both drive the production
workload and show you the status of the production workload on your system at
any specified time. You can produce trial plans to forecast future workloads.

Long-term planning
The long-term plan is a high-level schedule of your anticipated production
workload. It lists, by day, the instances of job streams to be run during the period
of the plan. Each instance of a job stream is called an occurrence. The long-term
plan shows when occurrences are to run, as well as the dependencies that exist
between the job streams. You can view these dependencies graphically on your
workstation as a network, to check that work has been defined correctly. The plan
can help you in forecasting and planning for heavy processing days. The
long-term-planning function can also produce histograms showing planned
resource use for individual workstations during the plan period.

You can use the long-term plan as the basis for documenting your service level
agreements. It lets you relate service level agreements directly to your production
workload schedules so that your customers can see when and how their work is to
be processed.

The long-term plan provides a window to the future. You can decide how far into
the future, from one day to four years. You can also produce long-term plan
simulation reports for any future date. Tivoli Workload Scheduler for z/OS can
automatically extend the long-term plan at regular intervals. You can print the
long-term plan as a report, or you can view, alter, and extend it online using the
dialogs.

Detailed planning
The current plan is the center of Tivoli Workload Scheduler for z/OS processing. It
drives the production workload automatically and provides a way to check its
status. The current plan is produced by the run of batch jobs that extract from the
long-term plan the occurrences that fall within the specified period of time from

64 IBM Tivoli Workload Automation: Overview

Tivoli Workload Scheduler for z/OS

the job details. The current plan selects a window from the long-term plan and
makes the jobs ready to be run. They are started depending on the decided
restrictions (for example, dependencies, resources availability, or time-dependent
jobs).

The current plan is a rolling plan that can cover several days. A common method
is to cover 1 to 2 days with regular extensions each shift. Production workload
processing activities are listed by minute.

You can either print the current plan as a report, or view, alter, and extend it
online, by using the dialogs.

Automatically controlling the production workload

Tivoli Workload Scheduler for z/OS automatically drives the production workload
by monitoring the flow of work and by directing the processing of jobs to follow
the business priorities established in the plan.

Through its interface to the NetView program or its management-by-exception

ISPF dialog, Tivoli Workload Scheduler for z/OS can alert the production control
specialist to problems in the production workload processing. Furthermore, the
NetView program can automatically trigger Tivoli Workload Scheduler for z/OS to
perform corrective actions in response to these problems.

Tivoli Workload Scheduler for z/OS automatically:

v Starts and stops started tasks
v Edits job statements: z/OS JCL or equivalent job statements for other operating
environments before submission
v Submits jobs in the specified sequence to the target operating environment every
time
v Tracks each scheduled job in the plan
v Determines the success or failure of the jobs
v Displays status information and instructions to guide workstation operators
v Provides automatic recovery of jobs when they end in error, regardless of the
operating environment
v Generates processing dates for your job stream run cycles using rules, such as:
– Every second Tuesday of the month
– Only the last Saturday in June, July, and August
– Every third workday in the user-defined PAYROLL period
v Starts jobs with regard to real resource availability
v Performs data set cleanup in error and rerun situations for the z/OS workload
v Tailors the JCL for step restarts of z/OS jobs and started tasks
v Dynamically schedules additional processing in response to unplannable
activities
v Provides automatic notification when an updated data set is closed; this can be
used to trigger subsequent processing
v Generates alerts when abnormal situations are detected in the workload

Tivoli Workload Scheduler for z/OS also provides manual control facilities, which
are described in “Manual control and intervention” on page 69.

Chapter 8. Tivoli Workload Scheduler for z/OS 65

Tivoli Workload Scheduler for z/OS

Automatic workload submission

Tivoli Workload Scheduler for z/OS automatically drives work through the system,
taking into account work that requires manual or program-recorded completion.
Program-recorded completion refers to situations where the status of a
scheduler-controlled job is set to “complete” by a user-written program. It also
promotes the optimum use of resources, improves system availability, and
automates complex and repetitive operator tasks. Tivoli Workload Scheduler for
z/OS automatically controls the submission of work according to:
v Dependencies between jobs
v Workload priorities
v Specified time for the submission of particular work
v Availability of resources

By saving a copy of the JCL for each separate run, or occurrence, of a particular job
in its plans, Tivoli Workload Scheduler for z/OS prevents the unintentional reuse
of temporary JCL changes, such as overrides.

Job tailoring. Tivoli Workload Scheduler for z/OS provides automatic job tailoring
functions to automatically edit jobs. This can reduce your dependency on
time-consuming and error-prone manual editing of jobs. Tivoli Workload Scheduler
for z/OS job tailoring provides:
v Automatic variable substitution
v Dynamic inclusion and exclusion of inline job statements
v Dynamic inclusion of job statements from other libraries or from an exit

For jobs submitted on a z/OS system, these job statements are z/OS JCL.
Scheduler JCL tailoring directives can be included in jobs that are submitted on
other operating systems, such as AIX®/6000.

Variables can be substituted in specific columns, and you can define verification
criteria to ensure that invalid strings are not substituted. Special directives
supporting a variety of date formats used by job stream programs let you
dynamically define the required format and change the multiple times for the same
job. You can define arithmetic expressions to calculate values such as the current
date plus four work days.

System Automation commands tailoring. Tivoli Workload Scheduler for z/OS

provides a function that edits system automation commands automatically. This
helps you to save time and reduce the possibility of editing errors. Tivoli Workload
Scheduler for z/OS command tailoring provides automatic variable substitution.

Automatic recovery and restart

Tivoli Workload Scheduler for z/OS provides automatic restart facilities for your
production work. You can specify the restart actions to take if work initiated by
Tivoli Workload Scheduler for z/OS ends in error (see Figure 6 on page 67.) You
can use these functions to predefine automatic error recovery and restart actions
for jobs and started tasks. The scheduler’s integration with the NetView program
allows it to automatically pass alerts to the NetView program in error situations.
Using the z/OS cross-system coupling facility (XCF) enables Tivoli Workload
Scheduler for z/OS to maintain production workload processing when system
failures occur.

Recovery of jobs and started tasks. Automatic recovery actions for failed jobs are
specified in user-defined control statements. Parameters in these statements
determine the recovery actions to be taken when a job or started task ends in error.

66 IBM Tivoli Workload Automation: Overview

Tivoli Workload Scheduler for z/OS

User Application
Restart
An Earlier
Job? Job 1

Automatic
Catalog
Cleanup? Recovery
Job?
Job 2
Restart
the Failing
Job? 2
The Scheduler Analyzes
the Error and Determines
the Restart Action
1 Job 3

Job 3 Analyze
Ends In
Error !

Continue? Do Nothing?

Figure 6. Automatic recovery and restart

Restart and cleanup. You can use restart and cleanup to catalog, uncatalog, or
delete data sets when a job ends in error, or when you need to rerun a job. Data
set cleanup handles JCL in the form of in-stream JCL, in-stream procedures, and
cataloged procedures on both local and remote systems. This function can be
initiated automatically by Tivoli Workload Scheduler for z/OS or manually by
using the panels. Tivoli Workload Scheduler for z/OS resets the catalog to the
status that it was before the job ran for both generation data set groups (GDGs)
and for DD allocated data sets contained in JCL. In addition, restart and cleanup
supports the use of Removable Media Manager in your environment.

Restart at both the step- and job-level is also provided in the Tivoli Workload
Scheduler for z/OS panels. It manages resolution of generation data group (GDG)
names, JCL containing nested INCLUDEs or PROC, and IF-THEN-ELSE
statements. Tivoli Workload Scheduler for z/OS also automatically identifies
problems that can prevent successful restart, providing a logic of the “best restart
step.”

You can browse the job log or request a step-level restart for any z/OS job or
started task even when there are no catalog modifications. The job-log browse
functions are also available for the workload on other operating platforms, which
is especially useful for those environments that do not support an SDSF-like
facility. If you use a SYSOUT archiver, for example RMDS, you can interface with
it from Tivoli Workload Scheduler for z/OS and so prevent duplication of job log
information.

These facilities are available to you without the need to make changes to your
current JCL.

Tivoli Workload Scheduler for z/OS gives you an enterprise-wide data set cleanup
capability on remote agent systems.

Chapter 8. Tivoli Workload Scheduler for z/OS 67

Tivoli Workload Scheduler for z/OS

Production workload restart. Tivoli Workload Scheduler for z/OS provides a

production workload restart, which can automatically maintain the processing of
your work if a system or connection fails. Scheduler-controlled production work
for the unsuccessful system is rerouted to another system. Because Tivoli Workload
Scheduler for z/OS can restart and manage the production workload, the integrity
of your processing schedule is maintained, and service continues for your
customers.

Tivoli Workload Scheduler for z/OS uses the VTAM® Model Application Program
Definition feature and the z/OS defined symbols to ease the configuration and job
in a sysplex environment, giving you a single system view of the sysplex.

Starting, stopping, and managing your engines and agents do not require you to
know on which sysplex z/OS image they are actually running on.

z/OS
Parallel Sysplex

Shared
DASD

XCF Controlled
Controlling Scheduler
Scheduler (Hot Standby)

F
XC

XC
F

Controlled
Scheduler

Figure 7. Production workload restart and hot standby

Hot standby. Tivoli Workload Scheduler for z/OS provides a single point of
control for your z/OS production workload. If this controlling system fails, Tivoli
Workload Scheduler for z/OS can automatically transfer the controlling functions
to a backup system within a Parallel Sysplex®, see Figure 7. Through XCF, Tivoli
Workload Scheduler for z/OS can automatically maintain production workload
processing during system or connection failures.

z/OS automatic restart manager support

All the scheduler components are enabled to be restarted by the Automatic Restart
Manager (ARM) of the z/OS operating system, in the case of program failure.

Workload Manager (WLM) support

With Workload Manager (WLM), you can make the best use of resources accessed
by your scheduled jobs. In addition, your jobs maintain the highest possible
throughput with WLM and Tivoli Workload Scheduler for z/OS. When used with
WLM, the scheduler can achieve the best possible system response times.

Automatic status checking

To track the work flow, Tivoli Workload Scheduler for z/OS interfaces directly
with the operating system, collecting and analyzing status information about the
production work that is currently active in the system. Tivoli Workload Scheduler
68 IBM Tivoli Workload Automation: Overview
Tivoli Workload Scheduler for z/OS

for z/OS can record status information from both local and remote processors.
When status information is reported from remote sites in different time zones,
Tivoli Workload Scheduler for z/OS makes allowances for the time differences.

Status reporting from heterogeneous environments

The processing on other operating environments can also be tracked by Tivoli
Workload Scheduler for z/OS. You can use supplied programs to communicate
with the engine from any environment that can establish communications with a
z/OS system.

Status reporting from user programs

You can pass status information about production workload processing to Tivoli
Workload Scheduler for z/OS from your own user programs through a standard
supplied routine.

Additional job-completion checking

If required, Tivoli Workload Scheduler for z/OS provides further status checking
by scanning SYSOUT and other print data sets from your processing when the
success or failure of the processing cannot be determined by completion codes. For
example, Tivoli Workload Scheduler for z/OS can check the text of system
messages or messages originating from your user programs. Using information
contained in job completion checker (JCC) tables, Tivoli Workload Scheduler for
z/OS determines what actions to take when it finds certain text strings. These
actions can include:
v Reporting errors
v Requeuing SYSOUT
v Writing incident records to an incident data set

Managing unplanned work

Tivoli Workload Scheduler for z/OS can be automatically triggered to update the
current plan with information about work that cannot be planned in advance. This
allows Tivoli Workload Scheduler for z/OS to control unexpected work. Because
Tivoli Workload Scheduler for z/OS checks the processing status of this work,
automatic recovery facilities are also available.

Interfacing with other programs

Tivoli Workload Scheduler for z/OS provides a program interface (PIF). Using this
interface, you can automate most actions that you can perform online through the
dialogs. This interface can be called from CLISTs, user programs, and using TSO
commands.

The application programming interface (API) lets your programs communicate

with Tivoli Workload Scheduler for z/OS from any compliant platform. You can
use Common Programming Interface for Communications (CPI-C), advanced
program-to-program communication (APPC), or your own logical unit (LU) 6.2
verbs to converse with Tivoli Workload Scheduler for z/OS through the API. You
can use this interface to query and update the current plan. The programs can be
running on any platform that is connected locally, or remotely through a network,
with the z/OS system where the engine runs.

Manual control and intervention

Tivoli Workload Scheduler for z/OS lets you check the status of work and
intervene manually when priorities change or when you want to run unplanned
work. You can query the status of the production workload and then modify the
schedule if needed.

Chapter 8. Tivoli Workload Scheduler for z/OS 69

Tivoli Workload Scheduler for z/OS

Status inquiries
With the ISPF dialogs or with the Job Scheduling Console, you can make queries
online and receive timely information on the status of the production workload.

Time information that is displayed by the dialogs is in the local time of the dialog
user. Using the dialogs, you can request detailed or summary information on
individual job streams, jobs, and workstations, as well as summary information
concerning workload production as a whole. You can also display dependencies
graphically as a network at both job stream and job level. Status inquiries:
v Provide you with overall status information that you can use when considering
a change in workstation capacity or when arranging an extra shift or overtime
work.
v Help you supervise the work flow through the installation; for example, by
displaying the status of work at each workstation.
v Help you decide whether intervention is required to speed up the processing of
specific job streams. You can find out which job streams are the most critical.
You can also check the status of any job stream, as well as the plans and actual
times for each job.
v Help you to check information before making modifications to the plan. For
example, you can check the status of a job stream and its dependencies before
deleting it or changing its input arrival time or deadline. See “Modifying the
current plan” for more information.
v Provide you with information on the status of processing at a particular
workstation. Perhaps work that should have arrived at the workstation has not
arrived. Status inquiries can help you locate the work and find out what has
happened to it.

Modifying the current plan

Tivoli Workload Scheduler for z/OS makes status updates to the plan
automatically, using its tracking functions. However, it lets you change the plan
manually to reflect unplanned changes to the workload or to the operations
environment, which often occur during a shift. For example, you might want to
change the priority of a job stream, add unplanned work, or reroute work from
one workstation to another. You might also want to correct operational errors
manually. Modifying the current plan might be the best way to handle these
situations.

You can modify the current plan online. For example, you can:
v Include unexpected jobs or last-minute changes to the plan. Tivoli Workload
Scheduler for z/OS then automatically creates the dependencies for this work.
v Manually modify the status of jobs.
v Delete occurrences of job streams.
v Graphically display job dependencies before you modify them.
v Modify the data in job streams, including the JCL.
v Respond to error situations by:
– Rerouting jobs
– Rerunning jobs or occurrences
– Completing jobs or occurrences
– Changing jobs or occurrences
v Change the status of workstations by:
– Rerouting work from one workstation to another
– Modifying workstation reporting attributes
– Updating the availability of resources

70 IBM Tivoli Workload Automation: Overview

Tivoli Workload Scheduler for z/OS

– Changing the way resources are handled

v Replan or extend the current plan

In addition to using the dialogs, you can modify the current plan from your own
job streams using the program interface or the application programming interface.
You can also trigger Tivoli Workload Scheduler for z/OS to dynamically modify
the plan using TSO commands or a batch program. This adds unexpected work
automatically to the plan.

Management of critical jobs

Tivoli Workload Scheduler for z/OS uses the capability of the Workload Manager
component of z/OS to ensure that critical jobs are completed on time. If a critical
job is late, Tivoli Workload Scheduler for z/OS favors it using the Workload
Manager interface.

Security
Today, DP operations increasingly require a high level of data security, particularly
as the scope of DP operations expands and more people within the enterprise
become involved. Tivoli Workload Scheduler for z/OS provides complete security
and data integrity within the range of its functions. It provides a shared central
service to different user departments even when the users are in different
companies and countries. Tivoli Workload Scheduler for z/OS provides a high
level of security to protect scheduler data and resources from unauthorized access.
With Tivoli Workload Scheduler for z/OS, you can easily organize, isolate, and
protect user data to safeguard the integrity of your end-user applications (see
Figure 8 on page 71). Tivoli Workload Scheduler for z/OS can plan and control the
work of many user groups, and maintain complete control of access to data and
services.

Audit
Trail
Scheduler
TSO User JCL

TSO User JCL

RACF

Scheduler Data
Finance Sales Manufact.

Figure 8. Security

Audit trail
With the audit trail, you can define how you want Tivoli Workload Scheduler for
z/OS to log accesses (both reads and updates) to scheduler resources. Because it
provides a history of changes to the databases, the audit trail can be extremely
useful for staff that work with debugging and problem determination.

Chapter 8. Tivoli Workload Scheduler for z/OS 71

Tivoli Workload Scheduler for z/OS

A sample program is provided for reading audit-trail records. The program reads
the logs for a period that you specify and produces a report detailing changes that
have been made to scheduler resources.

System authorization facility

Tivoli Workload Scheduler for z/OS uses the system authorization facility (SAF), a
function of z/OS, to pass authorization verification requests to your security
system, for example RACF. This means that you can protect your scheduler data
objects with any security system that uses the SAF interface.

Protection of data and resources: Each user request to access a function or to

access data is validated by SAF. This is some of the information that can be
protected:
v Calendars and periods
v Job stream names or job stream owner, by name
v Workstation, by name
v Job stream-specific data in the plan
v Operator instructions
v JCL
To support distributed, multi-user handling, Tivoli Workload Scheduler for z/OS
lets you control the level of security you want to implement, right down to the
level of individual records. You can define generic or specific RACF resource
names to extend the level of security checking.

If you have RACF Version 2 Release 1 installed, you can use the Tivoli Workload
Scheduler for z/OS reserved resource class to manage your Tivoli Workload
Scheduler for z/OS security environment. This means that you do not have to
define your own resource class by modifying RACF and restarting your system.

Data integrity during submission: Tivoli Workload Scheduler for z/OS can
ensure the correct security environment for each job it submits, regardless of
whether the job is run on a local or a remote system. Tivoli Workload Scheduler
for z/OS lets you create tailored security profiles for individual jobs or groups of
jobs.

Configurations of Tivoli Workload Scheduler for z/OS

Tivoli Workload Scheduler for z/OS supports many configuration options using a
variety of communication methods:
v The controlling system
v Controlled z/OS systems
v Remote panels and program interface applications
v Scheduling jobs that are in Tivoli Workload Scheduler

The controlling system

The controlling system requires both the agent and the engine. One controlling
system can manage the production workload across all your operating
environments.

The engine is the focal point of control and information. It contains the controlling
functions, the dialogs, and the scheduler’s own batch programs. Only one engine is
required to control the entire installation, including local and remote systems (see
Figure 9 on page 73).

72 IBM Tivoli Workload Automation: Overview

Tivoli Workload Scheduler for z/OS

Tivoli Dynamic Workload Console

or
Job Scheduling Console
Note: TDWC does not need Connector
to link to distributed engines

OS/390
Z/OS Tracker
Tracker
Hot Standby Controller
Distributed z/OS
WebSphere Connector Connector Sysplex
Application
Server OS/390
Z/OS Tracker
Tracker
Z/OSTracker
OS/390 Tracker Hot Standby Controller
Active Controller

Domain Managers

z/OS Agents
Distributed
Agents

Figure 9. Tivoli Workload Scheduler for z/OS configurations

Controlled z/OS systems

An agent is required for every controlled z/OS system in an configuration. This
includes, for example, local controlled systems within shared DASD or sysplex
configurations.

The agent runs as a z/OS subsystem and interfaces with the operating system
(through JES2 or JES3, and SMF), using the subsystem interface and the operating
system exits. The agent monitors and logs the status of work, and passes the status
information to the engine via shared DASD, XCF, or ACF/VTAM.

You can use z/OS and cross-system coupling facility (XCF) to connect your local
z/OS systems. Instead of being passed to the controlling system using shared
DASD, work status information is passed directly through XCF connections. XCF
lets you use all the production-workload-restart facilities and its hot standby
function. See “Automatic recovery and restart” on page 66.

Chapter 8. Tivoli Workload Scheduler for z/OS 73

Tivoli Workload Scheduler for z/OS

Remote systems
The agent on a remote z/OS system passes status information about the
production work in progress to the engine on the controlling system. All
communication between Tivoli Workload Scheduler for z/OS subsystems on the
controlling and remote systems is done through ACF/VTAM.

Tivoli Workload Scheduler for z/OS lets you link remote systems using
ACF/VTAM networks. Remote systems are frequently used locally “on premises”
to reduce the complexity of the data processing (DP) installation.

Remote panels and program interface applications

ISPF panels and program interface (PIF) applications can run in a different z/OS
system from the one where the engine is running. Dialogs and PIF applications
send requests to and receive data from a Tivoli Workload Scheduler for z/OS
server which is running on the same z/OS system where the target engine is
running, using advanced program-to-program communications (APPC). The server
communicates with the engine to perform the requested actions.

The server is a separate address space, started and stopped either automatically by
the engine or by the user through the z/OS start command. There can be more
than one server for an engine.

If the dialogs or the PIF applications run on the same z/OS system where the
target engine is running, the server might not be involved.

Scheduling jobs that are in Tivoli Workload Scheduler

Tivoli Workload Scheduler for z/OS also allows you to access job streams
(schedules in Tivoli Workload Scheduler) and add them to the current plan in
Tivoli Workload Scheduler for z/OS. In addition, you can build dependencies
among Tivoli Workload Scheduler for z/OS job streams and Tivoli Workload
Scheduler jobs. From Tivoli Workload Scheduler for z/OS, you can monitor and
control the distributed agent.

In the Tivoli Workload Scheduler for z/OS current plan, you can specify jobs to
run on workstations in Tivoli Workload Scheduler. Tivoli Workload Scheduler for
z/OS passes the job information to the Tivoli Workload Scheduler Symphony file,
which in turn passes the jobs in the current plan to Tivoli Workload Scheduler to
distribute and process. In turn, Tivoli Workload Scheduler reports the status of
running and completed jobs back to the current plan for monitoring in Tivoli
Workload Scheduler for z/OS.

74 IBM Tivoli Workload Automation: Overview

| Chapter 9. Tivoli Dynamic Workload Broker

| Tivoli Dynamic Workload Broker is an on-demand scheduling infrastructure that
| integrates with Tivoli Workload Scheduler and provides dynamic management of
| your environment. It improves workload coordination, job throughput, operations
| control, and helps to better align IT with business objectives to improve
| performance and reduce costs. It optimizes the use of the IT infrastructure by
| constantly analyzing your environment to maintain an up-to-date view of the
| resources available and matching them to the requirements defined for each job.

| Tivoli Dynamic Workload Broker implements a job scheduling and brokering

| infrastructure that provides the following major functions to help you dynamically
| manage your business:
| v Performs automatic discovery of computers available in the scheduling domain
| with their attributes.
| v Matches jobs to appropriate resources based on job requirements and resource
| attributes.
| v Manages job dispatching to target resources, both physical and virtual, that are
| capable of running the job.
| v Optimizes the use of IT resources.
| v Manages resource consumption of a job based on the quantities that it is
| planned to use while running.
| v Optionally allocates the required quantity exclusively to the job while it is
| running.
| v Releases the quantity as soon as the job terminates for use by other waiting jobs.
| v Uses the common agent services infrastructure to provide an agent that
| simplifies the administration and deployment of the scheduling components on
| the endpoint systems that are targets for the jobs.
| v Provides an easy-to-use Web-based user interface for managing the scheduling
| activities.
| v Integrates scheduling functions and services in the IBM Service Oriented
| Architecture (SOA) common programming model.
| v Integrates with a number of IBM Tivoli products to set up a dynamic and
| on-demand scheduling environment that dynamically balances and distributes
| application workloads to the best available resource. Tivoli Dynamic Workload
| Broker integrates seamlessly with the other Tivoli Workload Automation
| products to provide a scheduling solution that integrates business scheduling
| and dynamic on-demand scheduling.

| Tivoli Dynamic Workload Broker integrates with the common agent services
| infrastructure to retrieve information about the available workstations in the
| environment. The goal of common agent services is to reduce the cost of
| ownership by minimizing customer effort, by reducing the complexity of the
| deployment, and by using resources more efficiently. To accomplish this, the
| common agent services architecture provides a shared infrastructure for managing
| the computer systems in your environment. This infrastructure has the following
| parts:
| common agent
| Each managed system in your deployment runs the common agent

Tivoli Dynamic Workload Broker

| software, which provides a shared runtime for product agents and a single
| implementation of services used by multiple products.
| agent manager
| One server in your deployment runs the agent manager, which is a
| network service that provides authentication and authorization services
| and maintains a registry of configuration information about the managed
| systems in your environment.
| resource manager
| Each Tivoli management application that uses the common agent services
| architecture provides software called a resource manager, which uses the
| services of the agent manager to communicate securely with and to obtain
| information about the managed systems running the common agent
| software. The resource manager uses the services of the common agent to
| deploy and run its software on managed systems.

| The agent manager provides the Tivoli Dynamic Workload Broker server with a list
| of the common agents installed on the workstations in the environment. Based on
| this list, you decide on which workstations you want to install the Workload
| Agent. By installing the Workload Agent on a workstation, you add the
| workstation as a resource to the Tivoli Dynamic Workload Broker environment.
| The agent manager also enables secure connections via SSL between managed
| systems in your deployment by providing authentication and authorization
| services and issuing certificates.

| In your environment, you can manage resources as computers or logical resources.

| A computer is a workstation categorized on the basis of its hardware
| characteristics, such as computer systems, operating systems, file systems and
| network systems. All characteristics of a computer are retrieved by the hardware
| and software scan. A logical resource is a logical entity that can be used to
| represent applications, groups, licenses, servers and any feature that might be
| applied to a computer system or to other logical resources. You can define the
| characteristics of a logical resource to match your requirements.

| When the Workload Agent is installed, it communicates directly with the Tivoli
| Dynamic Workload Broker server. Together with the Agent, you also install the
| related features. A feature is a functional capability associated to the Workload
| Agent. The features are stored on the server and are available for installation and
| update on the target workstations in the environment using the Tivoli Dynamic
| Workload Console. By installing or removing features, you add or remove
| functional capabilities from the target workstation.

| Available resources are constantly monitored for up-to-date status with the
| Workload Agent. The information about resources in the IT environment is stored
| in the Resource Repository database.

| You can create and submit jobs in Tivoli Workload Scheduler, or you can create
| them in Tivoli Dynamic Workload Broker, using the Job Brokering Definition
| Console. The Job Brokering Definition Console provides an easy-to-use graphical
| interface for creating and editing jobs based on the Job Submission Description
| Language (JSDL) schema.

| When a job is submitted, Tivoli Dynamic Workload Broker checks the job
| requirements, the available resources and the related characteristics and submits
| the job to the resource that best meets the requirements.

76 IBM Tivoli Workload Automation: Overview

Tivoli Dynamic Workload Broker

| Tivoli Dynamic Workload Broker guarantees load balancing across resource pools
| over time. New resources just provisioned are automatically discovered and
| integrated in the scheduling environment so that jobs can run automatically on
| these resources.

| You can also establish an affinity relationship between two or more jobs when you
| want them to run on the same resource, for example when the second job must use
| the results generated by the previous job. If the resource is not available, the affine
| job is held until the resource is available again. You can define affinity between
| two or more jobs using the Web console or the command line interface.

Chapter 9. Tivoli Dynamic Workload Broker 77

78 IBM Tivoli Workload Automation: Overview
|

| Chapter 10. Tivoli Dynamic Workload Console

| The Tivoli Dynamic Workload Console is a Web-based user interface for:
| v Tivoli Workload Scheduler
| v Tivoli Workload Scheduler for z/OS
| v Tivoli Workload Scheduler for Applications
| v Tivoli Dynamic Workload Broker

| It is now the strategic user interface for the Tivoli Workload Automation suite of
| products and includes support for the latest functions and enhancements available
| with the scheduling engines. It is replacing the Job Scheduling Console whose
| functional contents are not being extended beyond those of version 8.4.

| The Tivoli Dynamic Workload Console is a light, powerful and user-friendly single
| point of operational control for the entire scheduling network. It allows for single
| sign-on and authentication to one or many schedulers, is highly scalable, and
| provides real-time monitoring, management and reporting of enterprise workloads.
| It also greatly simplifies report creation and customization.

| With Tivoli Dynamic Workload Console you can:

| v Manage your workload to design objects in the database, handle plans, submit
| jobs or job streams, and monitor objects in the plan.
| v Design and control the topology of your scheduling environment, that is
| workstations and domains.
| v Define and run reports to gather historical data or details about your plans. You
| can also generate and run customized SQL reports.

| You can access the Tivoli Dynamic Workload Console from any computer in your
| environment using a Web browser through both secure HTTPS or HTTP protocol.

| The first and main actions you perform when you connect to the Tivoli Dynamic
| Workload Console are:
| Creating a connection to a scheduling engine (Tivoli Workload Scheduler or
| Tivoli Workload Scheduler for z/OS)
| You type the details (such as IP address, user name, and password) to
| access a scheduling engine, and, optionally, a database to operate with
| objects defined in plans or stored in the database. You can also define new
| scheduling objects in the database.
| From the Tivoli Dynamic Workload Console you can access the current
| plan, a trial plan, a forecast plan, or an archived plan for the distributed
| environment or the current plan for the z/OS environment.
| You might want to access the database to perform actions against objects
| stored in it or generate reports showing historical or statistical data.
| In addition, working both on the database and on plans, you can create
| and run event rules to define and trigger actions that you want to run in
| response to events occurring on Tivoli Workload Scheduler nodes.
| Creating tasks to manage scheduling objects in the plan
| You specify some filtering criteria to query a list of scheduling objects
| whose attributes satisfy the criteria you specified. Starting from this list,
© Copyright IBM Corp. 1991, 2008 79
Tivoli Dynamic Workload Console

| you can navigate and modify the content of the plan, switching between
| objects, opening more lists and accessing other plans or other Tivoli
| Workload Scheduler or Tivoli Workload Scheduler for z/OS environments.

80 IBM Tivoli Workload Automation: Overview

Chapter 11. Tivoli Job Scheduling Console
This chapter describes the Tivoli Job Scheduling Console that is distributed as part
of the Tivoli Workload Automation portfolio.

Overview
The Tivoli Job Scheduling Console for the Tivoli Workload Automation portfolio is
an interactive interface for creating, modifying, and deleting objects in the product
database. It also helps you monitor and control objects scheduled in the current
plan.

The Job Scheduling Console helps you to work with Tivoli Workload Scheduler for
z/OS and with Tivoli Workload Scheduler. You can work with these products
simultaneously from the same graphical console.

To run the console, you only have to be able to log into a scheduling engine
through a connector. This means that you can manage plan and database objects
from any system, including a laptop, on which the Job Scheduling Console is
installed and from which you can reach via TCP/IP a server running the connector
for Tivoli Workload Scheduler or for Tivoli Workload Scheduler for z/OS.

Connectors manage the traffic between the Job Scheduling Console and the job
schedulers. Connectors are installed separately on a Tivoli management server and
on managed nodes that have access to the scheduler.

If you plan to use the Job Scheduling Console to schedule the workload with Tivoli
Workload Scheduler for z/OS, you need to install the Tivoli Workload Scheduler
for z/OS connector. If you plan to use the Job Scheduling Console to schedule the
workload with Tivoli Workload Scheduler, you need to install the Tivoli Workload
Scheduler connector.

The Job Scheduling Console provides two main functions:

Scheduling
Allows you to define and list job streams, jobs, and resource availability in
the scheduler database.
Monitoring and control
Allows you to monitor and control scheduled jobs and job streams in the
scheduler plan. In the Job Scheduling Console, a scheduled job stream is
called a job stream instance whereas a scheduled job is called a job
instance.

Extensions, built into the Job Scheduling Console, extend its base scheduling
functions to specific scheduling functions of Tivoli Workload Scheduler for z/OS
and of Tivoli Workload Scheduler.

For each of these functions, you can use a list creation mechanism to list database
or plan objects that you select according to filtering criteria. Filtering criteria
narrow a list down to selected objects that you want to work with. You can list
objects without using filtering criteria. In this case, the list displays all the existing
objects of a kind. You can use both pre-defined lists that are packaged with the Job
Scheduling Console and lists that you create.

Tivoli Job Scheduling Console

Tivoli Workload Scheduler for z/OS tasks

This section describes what Tivoli Workload Scheduler for z/OS tasks can be
accomplished with the Job Scheduling Console. The tasks are grouped according to
whether they are run typically by an administrator or by an operator.

Work begins by selecting a Tivoli Workload Scheduler for z/OS engine. A popup
window lists what actions are available for the engine. The same actions can be
done by clicking the corresponding icons at the top of the window. The icons
display contextually with the engine.

Scheduler tasks
From the Job Scheduling Console, you can define and manage the following
objects in the scheduler database:
v Job streams
v Jobs
v Workstations
v Resources

Working with job streams

Job streams are a collection of jobs, scheduling information, and the resources they
require to run. The jobs that comprise a job stream usually follow a sequence
where the execution of a job depends on the successful completion of another job.
Creating a job stream involves:
1. Defining job stream properties.
2. Creating jobs, which includes defining what resources each job requires to run
and the timing of its execution.
3. Defining the necessary dependencies, or sequencing, among the jobs of the job
stream and with jobs that belong to other job streams.
4. Defining one or more run cycles, or the days on which the job stream must run
and when it must start.

Modifying a job stream involves adding, deleting, or modifying any of the jobs
that comprise it, along with the dependencies and run cycles. You can also delete
an entire job stream.

Job stream definitions are stored in the job scheduler databases. To browse or
update job streams you have created, you must make and run a list of job streams
in the database.

Working with jobs

Jobs are the units of work in a job stream. You cannot create jobs outside of a job
stream. You must first create a job stream and define its properties before you can
start to create the jobs that comprise it. Creating a job involves:
1. Defining job properties.
2. Specifying when the job must run (time restrictions) within its job stream’s run
cycle.
3. Defining the properties of the task associated with the job, if applicable.
4. Specifying the resources that the job requires to run.

Jobs are stored in the job scheduler database as parts of job streams. To browse,
update, or delete a job definition, you must list the parent job stream in the
database.
82 IBM Tivoli Workload Automation: Overview
Tivoli Job Scheduling Console

Working with workstations

Workstations describe how jobs have to be run. A workstation is not necessarily
hardware. It is a stage in the processing that is controlled by the scheduler. To
schedule a job instance, a workstation must have been defined beforehand. Before
the scheduler can start a job instance, the workstation on which the job instance is
defined must be available. So, by controlling workstation availability, you control
the running of job instances that are defined on the workstation. Defining a
workstation involves:
1. Defining the workstation’s general properties.
2. Specifying open time intervals, periods during which the workstation‘s
resources and parallel servers are available to process work. Parallel servers
and resources are usually necessary to run work at the workstation.

Working with resources

Resources represent physical or logical devices that jobs use to run. Defining a
resource involves:
1. Defining the resource’s general properties.
2. Specifying availability intervals, periods during which the resource’s state and
quantity available for running jobs differ from the values specified as general
properties.

Resource definitions are stored in the job scheduler database. To browse, update, or
delete a resource definition, you must make and run a list of resources in the
database.

Operator tasks
From the Job Scheduling Console, you can monitor and control the following
objects in the current plan:
v Job stream instances
v Job instances
v Workstations
v Resources

To monitor and control these objects, you must first display them in a list in the
Job Scheduling Console.

Working with job stream instances

Job streams that are scheduled in the plan are job stream instances. You can
browse, modify, and delete job stream instances, provided you display them in a
job stream instance list. Modifying a job stream instance includes changing some of
its general properties and the start and deadline times.

You can also change the status of a job stream instance to Waiting or to Complete.

Working with job instances

Jobs belonging to a job stream that is scheduled in the plan are job instances. You
can browse, modify, and delete job instances after displaying them in a job instance
list. Modifying a job instance involves:
v Changing its state, resource dependencies, and time restrictions.
v Deleting predecessor and successor jobs in the job instance’s dependency chain.
v Mark job instances for monitoring with Tivoli Business Systems Manager.

In addition, you can:

Chapter 11. Tivoli Job Scheduling Console 83

Tivoli Job Scheduling Console

v Hold or release job instances.

v Remove or restore job instances in the current plan.
v Run a job instance immediately regardless of normal scheduling rules.
v Browse the job log.
v View and modify operator instructions.
v Tailor job statements.
v Restart a job instance and perform cleanup operations.

Working with workstations in the plan

A workstation instance is a workstation that is allocated to the plan. By using
filtered lists of workstations in the plan, you can:
v Monitor the status of a workstation in the plan and of the job instances
scheduled to run on it.
v Modify the settings and availability of the workstation.
v Change the status of a workstation.
v Reroute the job instances that are scheduled to run on a workstation.
v Display by status the job instances scheduled on a workstation and, eventually,
modify the job instances.

Working with resources in the plan

A resource instance is a resource that is allocated to the plan. The resource is
reserved for the duration of the plan for use by the jobs that depend on it. The
status and quantities of the resource are specified in the general properties and
availability intervals definitions in the database. You can:
v Modify a resource’s availability intervals and quantity after the resource has
been allocated to the plan.
v Use lists of resource instances to view and modify job instances associated with
the resources.
v Specify connected workstations.

Tivoli Workload Scheduler tasks

The Job Scheduling Console provides conman and composer functionality for Tivoli
Workload Scheduler engines. This section describes what Tivoli Workload
Scheduler tasks can be accomplished with the Job Scheduling Console. The tasks
are grouped according to whether they are run typically by an administrator or by
an operator.

Work begins by selecting a Tivoli Workload Scheduler engine. A popup window

lists what actions are available for the engine. The same actions can be done by
clicking the corresponding icons at the top of the window. The icons display
contextually with the engine.

Scheduler tasks
From the Job Scheduling Console, you can define and manage the following
objects in the scheduler database:
v Job streams
v Jobs
v Calendars
v Prompts
v Parameters

84 IBM Tivoli Workload Automation: Overview

Tivoli Job Scheduling Console

v Domains
v Workstations and workstation classes
v Resources
v Users

Working with job streams

You can use the Job Scheduling Console to work with job streams and job stream
templates. Job stream templates contain only scheduling information. When you
define a job stream as belonging to a template, you imply that it must share the
template calendar and run cycles. You can:
v Create, update, or delete job stream templates.
v Add or remove a job stream from a job stream template.
v List job stream templates in the scheduler database.
v Mark job streams for monitoring with Tivoli Business Systems Manager.

Working with jobs

When you create or modify a job, the Tivoli Workload Scheduler extension adds
the following features to a basic job definition:
v Assigning the necessary special (logical) and workstation resources for the
execution of the job.
v Defining the job’s automatic and feedback options.

Working with calendars

A calendar is a list of scheduling dates defined in the scheduler database.
Assigning a calendar run cycle to a job stream causes that job stream to be run on
the days specified in the calendar. Because a calendar is defined to the scheduler
database, it can be assigned to multiple job streams. You can create as many
calendars as required to meet your scheduling needs.

Working with prompts

Prompts can be used as dependencies for jobs and job streams. A prompt must be
answered affirmatively for the dependent job or job stream to launch. For example,
you can issue a prompt to make sure that a printer is online before a job that
prints a report runs.

There are two types of prompt:

Ad hoc prompt
Is defined within the properties of a job or a job stream and is unique to
that job or job stream.
Predefined prompt
Is defined in the Tivoli Workload Scheduler database and can be used by
any job or job stream.

You can create, modify, and delete prompts in the Tivoli Workload Scheduler
database.

Working with parameters

Parameters are useful to substitute values into your jobs and job streams. Because
parameters are stored in the Tivoli Workload Scheduler database, all jobs and job
streams that use the particular parameter are updated automatically when the
value changes. For scheduling, a parameter can be used as a substitute for all or
part of:
v File dependency path names

Chapter 11. Tivoli Job Scheduling Console 85

Tivoli Job Scheduling Console

v Text for prompts

v Logon, command, and script file names

You can create, modify, and delete parameters in the Tivoli Workload Scheduler
database.

Working with domains

A domain is a named group of Tivoli Workload Scheduler workstations, consisting
of one or more workstations and a domain manager acting as the management
hub. All domains have a parent domain, except for the master domain.

You can create, modify, and delete domain definitions in the Tivoli Workload
Scheduler database.

Working with workstations

You can create, update, and delete workstation definitions in the scheduler
database. You define the following workstation characteristics:
v General properties
v Availability status during specific periods of time
v Available quantities during specific periods of time

You can list workstations defined in the scheduler database, selected according to
filtering criteria, and browse or modify their properties. You can also delete
workstations from the database.

Working with workstation classes

A workstation class is a group of workstations. Any number of workstations can be
placed in a class. Job streams and jobs can be assigned to execute on a workstation
class, making replication across many workstations easy.

If a job stream is defined on a workstation class, each job added to the job stream
must be defined either on a single workstation or on the exact same workstation
class that the job stream was defined on.

You can create, modify, and delete workstation classes.

Working with resources

You can create, update, and delete resource definitions in the scheduler database.
You define the following resource characteristics:
v General properties
v Availability status on a given workstation during specific periods of time
v Available quantities on a given workstation during specific periods of time
v Workstations connected to the resource

You can list resources defined in the scheduler database, selected according to
filtering criteria, and browse or modify their properties. You can also delete
resources from the database.

Working with users

The users for whom Tivoli Workload Scheduler will launch jobs must be defined in
the database. This is required for Windows users only.

From the Job Scheduling Console you can:

v Create, modify, and delete user definitions in the database.

86 IBM Tivoli Workload Automation: Overview

Tivoli Job Scheduling Console

v Change user passwords.

Operator tasks
From the Job Scheduling Console you can monitor and control the following
objects in the daily plan:
v Job stream instances
v Job instances
v Workstations
v Domains
v File dependencies
v Prompt dependencies
v Resource dependencies

To monitor and control these objects, you must first display them in a list.

You can also select a different plan to use, other than the current plan.

Working with job stream instances

You can use the console to do the following on job stream instances:
v Modify the properties.
v Mark or unmark for monitoring with Tivoli Business Systems Manager.
v Display, add, and delete predecessors.
v Display successors.
v Hold or release.
v Cancel, or re-submit.
v Change the job limit or the priority.
v Release from dependencies.
v Submit additional job streams to the current plan.

Working with job instances

You can use the console to do the following on job instances:
v Modify the properties.
v Mark or unmark for monitoring with Tivoli Business Systems Manager.
v Display, add, and delete predecessors.
v Display successors.
v Hold or release.
v Cancel, kill, or rerun.
v Confirm as successful or abended.
v Release from dependencies.
v Submit additional jobs to the current plan.

In addition, you can browse job logs and get job outputs (STDLST).

Working with workstations

You can use the console to do the following on workstation instances:
v Display the properties and the status.
v Change the job limit or the job fence.
v Start or stop.

Chapter 11. Tivoli Job Scheduling Console 87

Tivoli Job Scheduling Console

v Link or unlink.

Working with domains

You can use the console to do the following on domains in the Tivoli Workload
Scheduler plan:
v List the domains.
v Start or stop the workstations in a domain.
v Link or unlink the workstations in a domain.
v Switch the domain manager in a domain.

Working with file dependencies

A file dependency is when a job or job stream needs to verify the existence of one
or more files before it can begin execution. You can display the status of file
dependencies.

Working with prompt dependencies

A prompt dependency is when a job or job stream needs to wait for an affirmative
response to a prompt before it can begin execution. From the Job Scheduling
Console you can:
v Display the status of prompt dependencies.
v Reply to a prompt dependency.

Working with resource dependencies

Resources represent any type of resources on your system such as tape drives,
communication lines, databases, or printers, that are needed to run a job. Resources
can be physical or logical. After defining a resource in the Tivoli Workload
Schedulerdatabase, it can be used as a dependency for jobs and job streams that
run on the workstation or workstation class for which the resource is defined.

Use the Job Scheduling Console to:

v Display the properties and the status of resource dependencies.
v Change the number of units of a resource dependency.

Common tasks
The Common view is an additional selection at the bottom of the tree view of the
scheduling engines. It provides the ability to list job and job stream instances in a
single view and regardless of the scheduling engine, thus furthering integration for
workload scheduling on the mainframe and the distributed platforms.

You can display common plan lists in the main Job Scheduling Console window.
With these you can run common lists of job and job stream instances from all the
engines displayed in the Job Scheduling tree.

You can list job or job stream instances from all the engines to which the Job
Scheduling Console is connected. As it is for individual engines, default lists are
provided, but you can also create and save filtered lists that respond to your
needs.

The Common view implementation considers only the common properties of job
and job stream instances. This means that you can filter your queries only on
common characteristics and the resulting lists will have only columns that display
the common attributes.

88 IBM Tivoli Workload Automation: Overview

Tivoli Job Scheduling Console

You can select the engines to query on. You can also modify the objects by
selecting the actions that are allowed by the specific scheduler engine

Chapter 11. Tivoli Job Scheduling Console 89

90 IBM Tivoli Workload Automation: Overview
Chapter 12. End-to-end scheduling
By using end-to-end scheduling, you can schedule and control jobs on mainframe,
Windows®, and UNIX environments, for truly distributed scheduling. In the
end-to-end configuration, Tivoli Workload Scheduler for z/OS is used as the
planner for the job scheduling environment. Tivoli Workload Scheduler domain
managers, standard, and fault-tolerant agents are used to schedule on the
distributed platforms. The agents replace the use of tracker agents.

How end-to-end scheduling works

End-to-end scheduling directly connects Tivoli Workload Scheduler standard
agents, fault-tolerant agents, and domain managers (with their underlying agents
and domains) to Tivoli Workload Scheduler for z/OS. Tivoli Workload Scheduler
for z/OS is seen by the distributed network as the master domain manager.

Tivoli Workload Scheduler for z/OS creates the production plan also for the
distributed network and sends it to the domain managers and to the
directly-connected agents. The domain managers send a copy of the plan to each of
their agents and subordinate domain managers for execution.

The Tivoli Workload Scheduler domain managers function as the broker systems
for the distributed network by resolving all dependencies for their subordinate
managers and agents. They send their updates (in the form of events) to Tivoli
Workload Scheduler for z/OS so that it can update the plan accordingly. Tivoli
Workload Scheduler for z/OS handles its own jobs and notifies the domain
managers of all the status changes of the Tivoli Workload Scheduler for z/OS jobs
that involve the Tivoli Workload Scheduler plan. In this configuration, the domain
managers and all the distributed agents recognize Tivoli Workload Scheduler for
z/OS as the master domain manager and notify it of all the changes occurring in
their own plans. At the same time, the agents are not permitted to interfere with
the Tivoli Workload Scheduler for z/OS jobs, because they are viewed as running
on the master that is the only node that is in charge of them.

In the Tivoli Workload Scheduler for z/OS current plan, you can specify jobs to
run on workstations in the Tivoli Workload Scheduler network. Tivoli Workload
Scheduler for z/OS passes the job information to the Symphony file in the Tivoli
Workload Scheduler for z/OS server, which in turn passes the Symphony file to
the Tivoli Workload Scheduler domain managers (DMZ) to distribute and process.
In turn, Tivoli Workload Scheduler reports the status of running and completed
jobs back to the current plan for monitoring in the Tivoli Workload Scheduler for
z/OS engine.

Figure 10 on page 92 shows a Tivoli Workload Scheduler network managed by a

Tivoli Workload Scheduler for z/OS and the flow of data.

End-to-end scheduling

MASTERDM
z/OS
Master The TWS plan is extracted
Domain from the TWS for z/OS plan
Manager

TWS for TWS plan

z/OS plan
TWS topology
SA1

Windows 2000
A light version of the TWS plan The TWS plan is distributed to
is distributed to the SAs the subordinate DMs and FTAs

FTA1
TWS plan
Windows 2000

FTA2 TWS plan

AIX

DomainZ
Domain AIX
Manager
DMZ
TWS plan

DomainA DomainB
AIX HPUX
Domain Domain
Manager Manager
DMA DMB

FTA3 FTA4 FTA5 FTA6

AIX OS/400 Windows 2000 Solaris

Figure 10. End-to-end configuration

92 IBM Tivoli Workload Automation: Overview

End-to-end scheduling

Distributed agents
A distributed agent is a computer running Tivoli Workload Scheduler on which
you can schedule jobs from Tivoli Workload Scheduler for z/OS. Examples of
distributed agents are the following: standard agents, extended agents,
fault-tolerant agents, and domain managers.

The following is a description of the types of distributed agents:

Domain Manager
The management hub in a domain. All communications to and from the
agents in a domain are routed through the domain manager.
Backup Domain Manager
A fault-tolerant agent or domain manager capable of assuming the
responsibilities of its domain manager for automatic workload recovery.
Fault-tolerant Agent (FTA)
A workstation capable of resolving local dependencies and launching its
jobs in the absence of a domain manager.
Standard Agent
A workstation that launches jobs only under the direction of its domain
manager.
Extended Agent
A logical workstation definition that helps you launch and control jobs on
other systems and applications, such as Peoplesoft, Oracle Applications,
SAP, and z/OS JES2 and JES3.

Distributed agents replace tracker agents in Tivoli Workload Scheduler for z/OS.
The distributed agents help you schedule on non-z/OS systems with a more
reliable, fault-tolerant and scalable agent.

In the Tivoli Workload Scheduler for z/OS plan, the logical representation of a
distributed agent is called a fault-tolerant workstation.

Benefits of end-to-end scheduling

The benefits that can be gained from using end-to-end scheduling are the
following:
v Connecting fault-tolerant agents Tivoli Workload Scheduler to Tivoli Workload
Scheduler for z/OS.
v Scheduling on additional operating systems.
v Synchronization of work in mainframe and distributed environments.
v The ability for Tivoli Workload Scheduler for z/OS to use multi-tier architecture
with domain managers.

Chapter 12. End-to-end scheduling 93

94 IBM Tivoli Workload Automation: Overview
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user’s responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not give you
any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing

IBM Corporation
North Castle Drive
Armonk, NY 10504-1785 U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:

IBM World Trade Asia Corporation

Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan

The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS

PUBLICATION ″AS IS″ WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.

Some states do not allow disclaimer of express or implied warranties in certain

transactions, therefore, this statement might not apply to you.

This information could include technical inaccuracies or typographical errors.

Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:

IBM Corporation
2Z4A/101
11400 Burnet Road
Austin, TX 78758 U.S.A.

Such information may be available, subject to appropriate terms and conditions,

including in some cases payment of a fee.

The licensed program described in this document and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement or any equivalent agreement
between us.

This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.

Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of
International Business Machines Corporation in the United States, other countries,
or both. If these and other IBM trademarked terms are marked on their first
occurrence in this information with a trademark symbol (® or ™), these symbols
indicate U.S. registered or common law trademarks owned by IBM at the time this
information was published. Such trademarks may also be registered or common
law trademarks in other countries. A current list of IBM trademarks is available on
the Web at ″Copyright and trademark information″ at http://www.ibm.com/legal/
copytrade.shtml.

Adobe, and all Adobe-based trademarks are either registered trademarks or

trademarks of Adobe Systems Incorporated in the United States, other countries, or
both.

Intel, and Itanium, are trademarks or registered trademarks of Intel Corporation or

its subsidiaries in the United States and other countries.

ITIL is a registered trademark, and a registered community trademark of the Office

of Government Commerce, and is registered in the U.S. Patent and Trademark
Office.

UNIX is a registered trademark of The Open Group in the United States and other
countries.

96 IBM Tivoli Workload Automation: Overview

Java and all Java-based trademarks and logos are trademarks or
registered trademarks of Sun Microsystems, Inc. in the United States,
other countries, or both.

Other company, product, and service names might be trademarks or service marks
of others.

Notices 97
98 IBM Tivoli Workload Automation: Overview
Index
A D L
accessibility ix Data Facility Hierarchical Storage local options 56
advanced program-to-program Manager (DFSHM) 17 long-term plan 64
communication (APPC) 69 Decision Support 17
alerts, passing to NetView 66 dependencies
API (application programming
interface) 69
defining 63
graphic display of 63
M
mailman 47
APPC (advanced program-to-program DFHSM (Data Facility Hierarchical
manual status control 71
communication) 69 Storage Manager) 17
master domain 44
application domain manager 45
master domain manager 45
definition of 62
monitoring the workload 18
application programmer 21
multi-tier architecture 93
application programming interface
(API) 69
E
education
audit-trail facility 71
authority checking 72
See Tivoli technical training
end users, queries from 22
N
automatic national language features 61
extended agent 45
job submission 66 netman 47
status checking 68 NetView
status reporting 69 alerts 66
automatic job and started-task F description of 16
recovery 66, 68 fault-tolerant agent 45 RODM 17
automation 18 file dependency 54 network Agent 45
availability 19

G O
B global options 56 occurrences 64
backup domain manager 45 glossary viii operation dependencies 63
backup master 45 graphic display of dependencies 63 operations manager 21
backup system 68 operator, workstation 21
batchman 47 Output Manager for z/OS 17
benefits 15, 22
business processing cycle 64
H
helpdesk 22
P
parameter 49
C I periods 64
calendar 49 PIF (program interface) 69
IMS 17
definition of 63 PIF applications
integration 16
CICS 17 applications 74
ISPF (Interactive System Productivity
Common Programming Interface for plan
Facility)
Communications (CPI-C) 69 current 64
dialog 65
Composer 47 definition of 64
configurations 72 detailed 64
Conman 48 long-term 64
connector 43 J modification of 70
for Tivoli Workload Scheduler 43 job completion checker (JCC) 69 trial 62
console operator 21 job dependencies types 61
controlled systems 73 See operation dependencies planning
controlling system job log 84 trial plans 62
description 72 job recovery production control file 44
recovery of 68 automatic 66 production period 50
conventions used in publications viii manual 70 production workload restart 66, 68
CPI-C (Common Programming Interface Job Scheduling Console program interface (PIF) 69
for Communications) 69 accessibility ix prompt 49, 85
cross-system coupling facility (XCF) 66, job streams 74 prompt dependency 54
68, 73 job submission publications viii
current plan 64 automatic 66
customers, queries from 22 manual 70
job tailoring 66
jobman 47

R Tivoli Workload Scheduler/NetView 54
tracker agents 91
RACF (Resource Access Control training
Facility) 17, 72 See also Tivoli technical training
recovery 66, 68 technical ix
recovery job 52 trial plans 62
recovery prompt 51 TWS connector 43
remote dialogs
dialogs 74
resource 49
Resource Access Control Facility U
(RACF) 17, 72 unplannable work 69
Resource Object Data Manager user 49
(RODM) 17 user authority checking 72
restart 66, 68
restart management 66, 68
RODM (Resource Object Data V
Manager) 17 variable 49
run cycle 49 variable table 49

S W
SA for z/OS Automation Feature 17 work submission, automatic 66
SAF (system authorization facility) 72 Workload Manager (WLM) 16, 68
schedule 64 workload monitoring 18
scheduling manager 20 workload restart 66, 68
security 72 workstation
shift supervisor 21 changing the status of 70
simulation with trial plans 62 definition of 62
special resources operator 21
definition of 63 workstation class 48
standard agent 45 writer 47
standard list file 55
status checking, automatic 68
status control
manual 69, 70 X
status inquiries 69 XCF (cross-system coupling facility) 66,
status reporting 68, 73
automatic 69
from heterogeneous environments 69
from user programs 69
step-level restart 67
symphony 44, 50
syntax diagrams, how to read ix
SYSOUT, checking of 69
system authorization facility (SAF) 72
system automation commands
tailoring 66
System Automation for z/OS 17
System Automation z/OS (SA/zOS) 17
system failures 66
Systems Application Architecture
Common Programming Interface for
Communications 69

T
technical training
See Tivoli technical training
time restrictions 83
Tivoli Business Systems Manager 54
Tivoli Dynamic Workload Console
accessibility ix
Tivoli Information Management for
z/OS 17
Tivoli technical training ix
Tivoli Workload Scheduler 61, 74

100 IBM Tivoli Workload Automation: Overview

Program Number: 5698-A17, 5698-WSH, 5698-WSE

Printed in USA

SC32-1256-07
Spine information:

IBM Tivoli Workload Automation Version 8.5 Overview

IBM Tivoli Workload Scheduler V8.5.1 (Revised May 2010) User's Guide and Reference
No ratings yet
IBM Tivoli Workload Scheduler V8.5.1 (Revised May 2010) User's Guide and Reference
587 pages
TWS 8.4 Reference Guide
No ratings yet
TWS 8.4 Reference Guide
627 pages
TWS8.5 Planning and Installation
No ratings yet
TWS8.5 Planning and Installation
361 pages
Developer's Guide: Driving Tivoli Workload Automation
No ratings yet
Developer's Guide: Driving Tivoli Workload Automation
88 pages
TWS
No ratings yet
TWS
384 pages
Scheduling Workload Dynamically: IBM Tivoli Workload Scheduler
No ratings yet
Scheduling Workload Dynamically: IBM Tivoli Workload Scheduler
78 pages
TWS8.5 Administration
No ratings yet
TWS8.5 Administration
269 pages
Tivoli Workload Schedulder
No ratings yet
Tivoli Workload Schedulder
640 pages
TWS8 5 1-Planningandinstallation
No ratings yet
TWS8 5 1-Planningandinstallation
367 pages
Tivoli: IBM Tivoli Workload Scheduler
No ratings yet
Tivoli: IBM Tivoli Workload Scheduler
194 pages
EQQI1 MST
No ratings yet
EQQI1 MST
256 pages
SG 246022
100% (1)
SG 246022
506 pages
Awsadmst
No ratings yet
Awsadmst
371 pages
Release Notes For Tivoli Workload Scheduler, Version 8.5
No ratings yet
Release Notes For Tivoli Workload Scheduler, Version 8.5
26 pages
SG 246648
No ratings yet
SG 246648
728 pages
Tivoli Workloud Scheduler Guide
No ratings yet
Tivoli Workloud Scheduler Guide
420 pages
Integrating IBM Tivoli Workload Scheduler With Tivoli Products Sg246648
0% (1)
Integrating IBM Tivoli Workload Scheduler With Tivoli Products Sg246648
728 pages
Getting Started With Tivoli Dynamic Workload Broker Version 1.1 Sg247442
No ratings yet
Getting Started With Tivoli Dynamic Workload Broker Version 1.1 Sg247442
706 pages
JSC 8.3 Users Guide
No ratings yet
JSC 8.3 Users Guide
499 pages
OPC Error Codes
No ratings yet
OPC Error Codes
496 pages
High Availability Scenarios With IBM Tivoli Workload Scheduler and IBM Tivoli Framework Sg246632
No ratings yet
High Availability Scenarios With IBM Tivoli Workload Scheduler and IBM Tivoli Framework Sg246632
646 pages
Dynamic Workload Console Installation Guide
100% (1)
Dynamic Workload Console Installation Guide
245 pages
Integrating IBM Tivoli Workload Scheduler and Content Manager OnDemand To Provide Centralized Job Log Processing Sg246629
No ratings yet
Integrating IBM Tivoli Workload Scheduler and Content Manager OnDemand To Provide Centralized Job Log Processing Sg246629
278 pages
Tivoli: Workload Scheduler
No ratings yet
Tivoli: Workload Scheduler
28 pages
Awsaumst
No ratings yet
Awsaumst
404 pages
IBM - Tivoli Workload Autom...
No ratings yet
IBM - Tivoli Workload Autom...
3 pages
Tivoli Workload SchedulerReference
No ratings yet
Tivoli Workload SchedulerReference
362 pages
Ibm Tivoli Workload Scheduler
No ratings yet
Ibm Tivoli Workload Scheduler
23 pages
IBM Tivoli Monitoring User's Guide
No ratings yet
IBM Tivoli Monitoring User's Guide
272 pages
SG 246013
No ratings yet
SG 246013
444 pages
OPC Scheduler
No ratings yet
OPC Scheduler
444 pages
TWS Basic Terms
No ratings yet
TWS Basic Terms
4 pages
TWS 9.4 Planning and Installation Awspimst
No ratings yet
TWS 9.4 Planning and Installation Awspimst
472 pages
8.4 Tws Small
No ratings yet
8.4 Tws Small
56 pages
TWS
No ratings yet
TWS
726 pages
Implementing IBM Tivoli Workload Scheduler V 8.2 Extended Agent For IBM Tivoli Storage Manager Sg246696
100% (1)
Implementing IBM Tivoli Workload Scheduler V 8.2 Extended Agent For IBM Tivoli Storage Manager Sg246696
124 pages
Operations Planning and Control: The State-of-the-Art Solution
No ratings yet
Operations Planning and Control: The State-of-the-Art Solution
6 pages
IBM Tivoli Monitoring Installation and Setup Guide
No ratings yet
IBM Tivoli Monitoring Installation and Setup Guide
278 pages
Tivoli Enterprise Console - Guia Do Usuário
No ratings yet
Tivoli Enterprise Console - Guia Do Usuário
132 pages
TPC 4.1 Usersguide v41
No ratings yet
TPC 4.1 Usersguide v41
880 pages
Tivoli Storage Productivity Center Users Guide PDF
No ratings yet
Tivoli Storage Productivity Center Users Guide PDF
880 pages
IBM Workload Scheduler Guide 10.2
No ratings yet
IBM Workload Scheduler Guide 10.2
1,078 pages
IBM Tivoli Business Service Manager V4.1 Redp4288
No ratings yet
IBM Tivoli Business Service Manager V4.1 Redp4288
96 pages
2012 IBM TWA - SAP Demo Introduction
No ratings yet
2012 IBM TWA - SAP Demo Introduction
9 pages
TSM 5.4 BA Client - Unix Linux
No ratings yet
TSM 5.4 BA Client - Unix Linux
591 pages
B SRV Install Guide Linux 718
No ratings yet
B SRV Install Guide Linux 718
198 pages
IBM Tivoli Storage Manager For UNIX and Linux Backup-Archive Client Installation and User's Guide Version 5.5 - Ans50000
No ratings yet
IBM Tivoli Storage Manager For UNIX and Linux Backup-Archive Client Installation and User's Guide Version 5.5 - Ans50000
627 pages
Itm Ux Agent
No ratings yet
Itm Ux Agent
270 pages
SRM Overview
No ratings yet
SRM Overview
37 pages
Conman
No ratings yet
Conman
52 pages
Composer Commands
No ratings yet
Composer Commands
1 page
TWS Documents
No ratings yet
TWS Documents
18 pages
AdigoDwaraka by CH SrinivasaRao
No ratings yet
AdigoDwaraka by CH SrinivasaRao
101 pages
User Guide: Smartkey Programmer
No ratings yet
User Guide: Smartkey Programmer
22 pages
IMAGEnet I-Base en New CI
No ratings yet
IMAGEnet I-Base en New CI
6 pages
Function Points Analysis Training Course: Instructor: David Longstreet 816.739.4058
No ratings yet
Function Points Analysis Training Course: Instructor: David Longstreet 816.739.4058
10 pages
Array: Passing Arrays As Function Arguments in C
No ratings yet
Array: Passing Arrays As Function Arguments in C
10 pages
Detecting and Preventing Attacks Using Network Intrusion Detection Systems
No ratings yet
Detecting and Preventing Attacks Using Network Intrusion Detection Systems
13 pages
Epson WF-C5810 - 5890 - 5390 - 5310 (New)
No ratings yet
Epson WF-C5810 - 5890 - 5390 - 5310 (New)
5 pages
Components of A Computer System
47% (15)
Components of A Computer System
12 pages
Electronics Engineer Hardware Development
No ratings yet
Electronics Engineer Hardware Development
2 pages
Acer Aspire 4332, 4732z Service Guide
No ratings yet
Acer Aspire 4332, 4732z Service Guide
104 pages
SQL Server Managed Support Services
No ratings yet
SQL Server Managed Support Services
5 pages
SP Initial Series
No ratings yet
SP Initial Series
25 pages
800XA 5.1 To 6.0 Manual
No ratings yet
800XA 5.1 To 6.0 Manual
318 pages
A High-Speed, Energy-Efficient Two-Cycle Multiply-Accumulate (MAC) Architecture and Its Application To A Double-Throughput MAC Unit
No ratings yet
A High-Speed, Energy-Efficient Two-Cycle Multiply-Accumulate (MAC) Architecture and Its Application To A Double-Throughput MAC Unit
9 pages
GTMedia V7S Firmware Updates
No ratings yet
GTMedia V7S Firmware Updates
6 pages
7641v3.0 (G52-76411X4) (760GM-P25 (FX) - 760GM-P23 (FX) - 760GM-P21 (FX) ) 100x150
No ratings yet
7641v3.0 (G52-76411X4) (760GM-P25 (FX) - 760GM-P23 (FX) - 760GM-P21 (FX) ) 100x150
169 pages
How To Analyse Nintendo Switch
100% (2)
How To Analyse Nintendo Switch
38 pages
DLD Lab Manual#3 Document
No ratings yet
DLD Lab Manual#3 Document
10 pages
ECA 2, Lab 11,12 (Terminal), Osama Sattar, FA19-BEE-172
No ratings yet
ECA 2, Lab 11,12 (Terminal), Osama Sattar, FA19-BEE-172
28 pages
Abdul Hadi Walizai - Scrum Master
No ratings yet
Abdul Hadi Walizai - Scrum Master
6 pages
Training Activity Matrix
No ratings yet
Training Activity Matrix
14 pages
University of Vaasa: Faculty of Technology Department of Computer Science
No ratings yet
University of Vaasa: Faculty of Technology Department of Computer Science
19 pages
Basic of Internet
No ratings yet
Basic of Internet
19 pages
Javascript Developer Syllabus
No ratings yet
Javascript Developer Syllabus
7 pages
Oled65B6P Webos Uhd Oled TV
No ratings yet
Oled65B6P Webos Uhd Oled TV
5 pages
Libelf by Example PDF
No ratings yet
Libelf by Example PDF
61 pages
PLC Basics and Applications Guide
100% (1)
PLC Basics and Applications Guide
39 pages
Sistem Otomatis Pengisian Teh Kemasan-1 (Hmi) Ok
No ratings yet
Sistem Otomatis Pengisian Teh Kemasan-1 (Hmi) Ok
23 pages
AI Application Engineer
No ratings yet
AI Application Engineer
2 pages
Reference 01 - Indicating System (ATA 31) - General PDF
No ratings yet
Reference 01 - Indicating System (ATA 31) - General PDF
132 pages
ThinkCentre M90t Gen 3 Spec
No ratings yet
ThinkCentre M90t Gen 3 Spec
10 pages