Scheduling End-to-end with z-centric Capabilities...dynamic workstations .....21 Creating broker...

Workload Scheduler for z/OSVersion 8.6

Scheduling End-to-end with z-centricCapabilities

SC27-2399-01

��

NoteBefore using this information and the product it supports, read the information in Notices.

This edition applies to version 8, release 6 of IBM Tivoli Workload Scheduler for z/OS (program number 5698-A17)and to all subsequent releases and modifications until otherwise indicated in new editions.

This edition replaces SC27-2399-00.

© Copyright IBM Corporation 1991, 2011.US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contractwith IBM Corp.

Contents

Figures . . . . . . . . . . . . . . . v

Tables . . . . . . . . . . . . . . . vii

About this publication . . . . . . . . ixWhat is new in this release . . . . . . . . . ixWhat is new in this publication . . . . . . . . ixWho should read this publication . . . . . . . ixPublications . . . . . . . . . . . . . . ixUsing LookAt to look up message explanations. . . xAccessibility . . . . . . . . . . . . . . xTivoli technical training. . . . . . . . . . . xSupport information . . . . . . . . . . . xiConventions used in this publication . . . . . . xiHow to read syntax diagrams . . . . . . . . xi

Chapter 1. Configuring . . . . . . . . 1Overview . . . . . . . . . . . . . . . 1

Advantages of job types with advanced options . 5Configuring the Tivoli Workload Scheduler for z/OSAgent settings . . . . . . . . . . . . . . 6

Configuring log and trace properties . . . . . 7Configuring common launchers properties . . . 7Configuring properties of the native job launcher 8Configuring properties of the Java job launcher. . 9

Defining destinations with the ROUTOPTS statement 9

Chapter 2. Customizing the HTTPconnection with the HTTPOPTSstatement . . . . . . . . . . . . . 13

Chapter 3. Defining user IDs andpasswords with the USRREC statement 15USRREC . . . . . . . . . . . . . . . 15

Chapter 4. Defining and managingTivoli Workload Scheduler for z/OSAgent workstations in the database . . 17Creating . . . . . . . . . . . . . . . 17Modifying . . . . . . . . . . . . . . . 18Browsing . . . . . . . . . . . . . . . 18Deleting . . . . . . . . . . . . . . . 19Listing . . . . . . . . . . . . . . . . 19

Chapter 5. Defining and managingdynamic workstations . . . . . . . . 21Creating broker workstations . . . . . . . . 22Defining a backup dynamic domain manager . . . 23Creating pools and dynamic pools. . . . . . . 24Submitting jobs to pools or dynamic pools . . . . 24Submitting jobs by reference. . . . . . . . . 24

Chapter 6. Setting the security features 27Setting SSL-secure connections for communication 27

Using security certificates. . . . . . . . . 27Encrypting the user password . . . . . . . . 28

Chapter 7. Using . . . . . . . . . . 29Starting and stopping HTTP subtasks. . . . . . 29Defining a job in the JOBLIB data set . . . . . . 30

JOBREC . . . . . . . . . . . . . . 30Syntax diagram for database job types . . . . 32

Syntax diagram for DB2 and Oracle databasejob types . . . . . . . . . . . . . 32Syntax diagram for MSSQL database job type 35

Syntax diagram for file transfer job types . . . 38Syntax diagram for file transfer job types . . 38

Syntax diagram for web service job types . . . 41Syntax diagram for web service job types . . 41

Syntax diagram for Java job type . . . . . . 43Syntax diagram for Java job type . . . . . 43

Syntax diagram for xajob type . . . . . . . 44Syntax diagram for xajob job type . . . . . 44

Syntax diagram for J2EE jms job type. . . . . 46Syntax diagram for J2EE jms job type. . . . 46

Syntax diagram for native job type . . . . . 48Syntax diagram for script and executable jobtype . . . . . . . . . . . . . . . 48

Scheduling on IBM i . . . . . . . . . . . 51Issuing List requests by using the PIF and the BCIT 51Using variable substitution . . . . . . . . . 52Defining file dependencies to check for file changes 52

Syntax . . . . . . . . . . . . . . . 53Arguments . . . . . . . . . . . . . 53Maintaining the filewatch log database . . . . 55

Syntax . . . . . . . . . . . . . . 55Arguments . . . . . . . . . . . . 55

Usage Notes . . . . . . . . . . . . . 56Managing the status of the Tivoli WorkloadScheduler for z/OS Agent workstation in the plan . 56

Automatic and manual changes to the status ofthe Tivoli Workload Scheduler for z/OS Agentworkstation . . . . . . . . . . . . . 57WSSTAT . . . . . . . . . . . . . . 57

Browsing system information of Tivoli WorkloadScheduler for z/OS Agent workstations . . . . . 60Killing Tivoli Workload Scheduler for z/OS Agentoperations . . . . . . . . . . . . . . . 60

ISPF . . . . . . . . . . . . . . . . 60PIF . . . . . . . . . . . . . . . . 61BCIT . . . . . . . . . . . . . . . 61OCL . . . . . . . . . . . . . . . . 61Dynamic Workload Console . . . . . . . . 61

Chapter 8. Job monitoring andrecovering . . . . . . . . . . . . . 63

© Copyright IBM Corp. 1991, 2011 iii

||||

||

||||

|||||||||||||

||

||

Tivoli Workload Scheduler for z/OS Agent jobstatus notifications . . . . . . . . . . . . 63Setting up and running automatic recovery forTivoli Workload Scheduler for z/OS Agent jobs . . 63

Automatic-recovery-control statement for TivoliWorkload Scheduler for z/OS Agent scripts . . 64

RECOVER statement syntax . . . . . . . 64Statement parameters . . . . . . . . . 65Selection parameters . . . . . . . . . 66Action parameters . . . . . . . . . . 67

Appendix A. Configuring to scheduleJ2EE jobs . . . . . . . . . . . . . 71Configuring the J2EE executor . . . . . . . . 71

J2EEJobExecutorConfig.properties file. . . . . 71Running {xor} encryption on your password 73

The soap.client.props file . . . . . . . . . 73Configuring the J2EE Job Executor Agent . . . . 74

Create a Service Integration Bus . . . . . . 74Configure the Default Messaging Service . . . 75Configure the Java security . . . . . . . . 76Create an XA DataSource . . . . . . . . . 76Create a WorkManager . . . . . . . . . 76

Create and configure a scheduler . . . . . . 76

Appendix B. Security order ofprecedence used for the execution ofJ2EE tasks . . . . . . . . . . . . . 77

Appendix C. Configuring to schedulejob types with advanced options . . . 79Logging information about job types with advancedoptions . . . . . . . . . . . . . . . . 79

Appendix D. Managing return codes . . 81

Appendix E. Modifying the workstationfrom fault-tolerant agent to TivoliWorkload Scheduler for z/OS Agent . . 83

Notices . . . . . . . . . . . . . . 85Trademarks . . . . . . . . . . . . . . 86

Index . . . . . . . . . . . . . . . 89

iv IBM Tivoli Workload Scheduler for z/OS: Scheduling End-to-end with z-centric Capabilities

||||||

Figures

1. Static end-to-end environment with Javaruntime installed in which you can run jobtypes with advanced options . . . . . . . 2

2. Dynamic end-to-end environment to run alsojob types with advanced options.. . . . . . 3

3. Process flow. . . . . . . . . . . . . 44. EQQWCGEP - Creating general information

about a Tivoli Workload Scheduler for z/OSAgent workstation . . . . . . . . . . 17

5. EQQWMGEP - Modifying a Tivoli WorkloadScheduler for z/OS Agent workstationdescription . . . . . . . . . . . . . 18

6. EQQWBGEP - Browsing a Tivoli WorkloadScheduler for z/OS Agent workstationdescription . . . . . . . . . . . . . 19

7. EQQWDGEP - Deleting a Tivoli WorkloadScheduler for z/OS Agent workstationdescription. . . . . . . . . . . . . 19

8. EQQWWSEP - Specifying list selection criteriafor Tivoli Workload Scheduler for z/OS Agentworkstations . . . . . . . . . . . . 20

9. EQQWCGEP - Creating general informationabout a broker workstation . . . . . . . 23

10. EQQWCEOD - Defining end-to-end options 2311. EQQSWIZC - Browsing a Tivoli Workload

Scheduler for z/OS Agent workstation systeminformation . . . . . . . . . . . . 60

© Copyright IBM Corp. 1991, 2011 v

|||||||||||||||||||||

|||||||||||||||||

vi IBM Tivoli Workload Scheduler for z/OS: Scheduling End-to-end with z-centric Capabilities

Tables

1. Installation and configuration steps for settingup an end-to-end with z-centric capabilitiesenvironment . . . . . . . . . . . . 4

2. Trace and log configurable properties of theTivoli Workload Scheduler for z/OS Agent . . 7

3. Common launchers configurable properties ofthe Tivoli Workload Scheduler for z/OS Agent . 8

4. Native job launcher configurable properties ofthe Tivoli Workload Scheduler for z/OS Agent . 8

5. Java job launcher configurable properties of theTivoli Workload Scheduler for z/OS Agent . . 9

6. Jobs and their keywords . . . . . . . . 317. Job status change notifications . . . . . . 638. J2EEJobExecutorConfig.properties file

keywords . . . . . . . . . . . . . 719. Configuration files for job types with advanced

options . . . . . . . . . . . . . . 79

© Copyright IBM Corp. 1991, 2011 vii

||||

||| |

||

viii IBM Tivoli Workload Scheduler for z/OS: Scheduling End-to-end with z-centric Capabilities

About this publication

IBM® Tivoli® Workload Scheduler for z/OS® Scheduling End-to-end with z-centricCapabilities describes how to set up IBM Tivoli Workload Scheduler for z/OS togenerate a lightweight end-to-end scheduling environment in which to scheduleand control workload from the mainframe to distributed systems. While itexhaustively describes the required installation and customization tasks, this firstedition provides only miscellaneous notes about the z-centric end-to-endscheduling solution. This publication is therefore to be used in conjunction withthe rest of the IBM Tivoli Workload Automation library. In particular, refer to thefollowing publications:v Tivoli Workload Scheduler for z/OS: Customization and Tuning, SC32-1265 for

information about customizing and tuning Tivoli Workload Scheduler for z/OS.v Tivoli Workload Scheduler for z/OS: Managing the Workload, SC32-1263 for details

about organizing your workload and information about managing the workloadwhen it becomes part of a plan and is run.

v Tivoli Workload Scheduler for z/OS: Messages and Codes, SC32-1267 for messageinformation.

v Tivoli Workload Scheduler for z/OS: Installation Guide, SC32-1264 for details abouthow to install the Tivoli Workload Scheduler for z/OS Agent.

v Tivoli Workload Automation: Overview, SC32-1256 for interoperability informationamong component versions.

What is new in this releaseFor information about the changes in this release, see IBM Tivoli WorkloadAutomation: Overview.

What is new in this publicationThis section describes what has changed in this publication since version 8.5.1, FixPack 1 GA. Except for editorial changes, changed or added text is marked in theleft margin with a vertical bar.

“Overview” on page 1Describes the new dynamic configuration.

Chapter 5, “Defining and managing dynamic workstations,” on page 21Describes how to create and manage dynamic workstations.

Who should read this publicationThis publication is intended for Tivoli Workload Scheduler for z/OS users who arealready familiar with Tivoli Workload Scheduler. A background knowledge ofTivoli Workload Scheduler for z/OS is required.

Publications

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

© Copyright IBM Corp. 1991, 2011 ix

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.

Using LookAt to look up message explanationsLookAt is an online facility that lets you look up explanations for most of the IBMmessages you encounter, as well as for some system abends (an abnormal end of atask) and codes. Using LookAt to find information is faster than a conventionalsearch because in most cases LookAt goes directly to the message explanation.

You can use LookAt from the following locations to find IBM messageexplanations for z/OS elements and features, z/VM®, VSE/ESA, and Clusters forAIX® and Linux:v The Internet. You can access IBM message explanations directly from the LookAt

website at http://www.ibm.com/eserver/zseries/zos/bkserv/lookat/.v Your z/OS TSO/E host system. You can install code on your z/OS system to

access IBM message explanations, using LookAt from a TSO/E command line(for example, TSO/E prompt, ISPF, or z/OS UNIX System Services runningOMVS).

v Your Microsoft Windows workstation. You can install code to access IBMmessage explanations on the IBM Online Library z/OS Software Products CollectionKit (SK3T-4270), using LookAt from a Microsoft Windows DOS command line.

v Your wireless handheld device. You can use the LookAt Mobile Edition with ahandheld device that has wireless access and an Internet browser (for example,Internet Explorer for Pocket PCs, Blazer, or Eudora for Palm OS, or Opera forLinux handheld devices). Link to the LookAt Mobile Edition from the LookAtwebsite.

You can obtain code to install LookAt on your host system or Microsoft Windowsworkstation from a disk on your IBM Online Library z/OS Software ProductsCollection Kit (SK3T-4270), or from the LookAt website (click Download, and selectthe platform, release, collection, and location that suit your needs). Moreinformation is available in the LOOKAT.ME files available during the downloadprocess.

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

For additional information, see the Accessibility Appendix in the Tivoli WorkloadScheduler for z/OS: Installation Guide.

Tivoli technical trainingFor Tivoli technical training information, refer to the following IBM TivoliEducation Web site:

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

x IBM Tivoli Workload Scheduler for z/OS: Scheduling End-to-end with z-centric Capabilities

http://www.ibm.com/eserver/zseries/zos/bkserv/lookat/

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

Support informationIf you have a problem with your IBM software, you want to resolve it quickly. IBMprovides the following ways for you to obtain the support you need:

OnlineGo to the IBM Software Support site at http://www.ibm.com/software/support/probsub.html and follow the instructions.

IBM Support AssistantThe IBM Support Assistant (ISA) is a free local software serviceabilityworkbench that helps you resolve questions and problems with IBMsoftware products. The ISA provides quick access to support-relatedinformation and serviceability tools for problem determination. To installthe ISA software, go to http://www.ibm.com/software/support/isa.

Troubleshooting GuideFor more information about resolving problems, see the problemdetermination information for this product.

For more information about these three ways of resolving problems, see theappendix on support information in Tivoli Workload Scheduler: Troubleshooting Guide,SC32-1275.

Conventions used in this publicationThe publication uses several typeface conventions for special terms and actions.Technical changes to the text are indicated by a vertical line to the left of thechange. These conventions have the following meanings:

Information type Style convention Example

Commands All capital letters CREATE

References in the text tofields on panels

All capital letters QUANTITY

File and directory names,input you should type inpanel fields

Monospace MYAPPLICATION

First time new termintroduced, publication titles

Italics Application

How to read syntax diagramsThroughout this publication, syntax is described in diagrams like the one shownhere, which describes the SRSTAT TSO command:

�� SRSTAT ' resource name 'OPCA

SUBSYS ( subsystem name )MSTR

�

About this publication xi

http://www.ibm.com/software/support/probsub.html

http://www.ibm.com/software/support/probsub.html

http://www.ibm.com/software/support/isa

�KEEP

AVAIL ( RESET )NOYES

KEEPDEVIATION ( amount )

RESET

�

�KEEP

QUANTITY ( amount )RESET

YESCREATE ( NO )

�

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

Read the syntax diagrams from left to right and from top to bottom, following thepath 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:

�� STATEMENToptional item

��

v An arrow returning to the left above the item indicates an item that you canrepeat. 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:

�� STATEMENT required choice 1required choice 2

��

xii IBM Tivoli Workload Scheduler for z/OS: Scheduling End-to-end with z-centric Capabilities

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

�� STATEMENToptional choice 1optional choice 2

��

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


,

optional choice 1optional choice 2optional choice 3

��


,

required choice 1required choice 2required choice 3

��

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

�� STATEMENTdefault

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 syntaxdiagram:

�� STATEMENT required choice 1option 1 option 2

required choice 2required choice 3

��

option 1

defaultoptional choice 1 ( alternative )

option 2

defaultoptional choice 2 ( alternative )

About this publication xiii

xiv IBM Tivoli Workload Scheduler for z/OS: Scheduling End-to-end with z-centric Capabilities

Chapter 1. Configuring

This chapter provides a general description of the end-to-end with z-centriccapabilities environment and describes the configuration steps required to make itwork.

It includes the following sections:v “Overview”v “Configuring the Tivoli Workload Scheduler for z/OS Agent settings” on page 6v “Defining destinations with the ROUTOPTS statement” on page 9v Chapter 2, “Customizing the HTTP connection with the HTTPOPTS statement,”

on page 13v Chapter 3, “Defining user IDs and passwords with the USRREC statement,” on

page 15v Appendix D, “Managing return codes,” on page 81v Chapter 4, “Defining and managing Tivoli Workload Scheduler for z/OS Agent

workstations in the database,” on page 17v Chapter 6, “Setting the security features,” on page 27v “Listing” on page 19

OverviewThis section describes the different types of workload scheduling you canimplement in your z-centric end-to-end environment:

Static schedulingThe Tivoli Workload Scheduler for z/OS Agents are installed on thedistributed systems and are connected to the z/OS system through theTivoli Workload Scheduler for z/OS controller.

Static scheduling including job types with advanced options

© Copyright IBM Corp. 1991, 2011 1

|

||

||||

||

The Tivoli Workload Scheduler for z/OS Agents are installed on thedistributed systems with the Java run time, and are connected to the z/OSsystem through the Tivoli Workload Scheduler for z/OS controller. Figure 1shows a static end-to-end environment in which Tivoli Workload Schedulerfor z/OS Agents:v Without the Java runtime installed, can run existing job typesv With the Java runtime installed, can run both existing jobs and job types

with advanced options

Dynamic schedulingThe Tivoli Workload Scheduler for z/OS Agents are installed on thedistributed systems with dynamic capabilities, and are connected to thedynamic domain manager. The dynamic domain manager is connected tothe z/OS system through the Tivoli Workload Scheduler for z/OScontroller.

Dynamic scheduling including job types with advanced options

TWS agentnetwork

DBserver

Serversystem

TDWCserver

Optional TWA instance

TWS for z/OS

z/OSConnector

TWS for z/OSserver

TWS for z/OScontroller

TWSfor Z/OS

Agent

TWSfor Z/OS

Agent

JavaRuntime

TWSfor Z/OS

Agent

Figure 1. Static end-to-end environment with Java runtime installed in which you can run jobtypes with advanced options

2 IBM Tivoli Workload Scheduler for z/OS: Scheduling End-to-end with z-centric Capabilities

|

||||

|||||

|

||

||||||

||

The Tivoli Workload Scheduler for z/OS Agents are installed on thedistributed systems with dynamic capabilities and the Java run time, andare connected to the dynamic domain manager. The dynamic domainmanager is connected to the z/OS system through the Tivoli WorkloadScheduler for z/OS controller. Figure 2 shows a dynamic end-to-endenvironment in which Tivoli Workload Scheduler for z/OS Agents:v Without the Java runtime installed, can run existing job typesv With the Java runtime installed, can run both existing jobs and job types

with advanced options

By using the z-centric end-to-end scheduling environment, you schedule andcontrol both static and dynamic workload from the mainframe to distributedsystems with a low cost of ownership. Tivoli Workload Scheduler for z/OS acts asa single point of control, providing you with all the mainframe capabilities tomanage distributed workload.

Tivoli Workload Scheduler for z/OS Agents can be installed on the UNIX IBM i, orWindows workstations where you run jobs scheduled from Tivoli WorkloadScheduler for z/OS. After installation, you associate each agent to a TivoliWorkload Scheduler for z/OS workstation definition, so that it can be used as atarget for Tivoli Workload Scheduler for z/OS jobs. The communication betweenthe Tivoli Workload Scheduler for z/OS Agent and Tivoli Workload Scheduler forz/OS controller is direct, through the HTTP or HTTPS protocol. If the connection isinterrupted, the HTTP client retries to establish it until it is successful.

TWS agentnetwork

DBserver

Serversystem

TDWCserver

Optional TWA instance

TWS for z/OS

z/OSConnector

TWS for z/OSserver

TWS for z/OScontroller

TWSDynamicDomainManager

TWSfor Z/OS

Agent

TWSfor Z/OS

Agent

TWSfor Z/OS

Agent

JavaRuntime

DBserver

dynamiccapabilities

Figure 2. Dynamic end-to-end environment to run also job types with advanced options.

Chapter 1. Configuring 3

|

||

||||||

|

||

|||||

||||||||

Figure 3 shows the process flow to submit and track jobs on Tivoli WorkloadScheduler for z/OS Agent workstations.

Table 1 shows the steps required to set up your end-to-end with z-centriccapabilities environment.

Table 1. Installation and configuration steps for setting up an end-to-end with z-centriccapabilities environment

To... Refer to...

Plan your end-to-end environmentwith z-centric capabilities andinstall the Tivoli WorkloadScheduler for z/OS Agent.

Tivoli Workload Scheduler for z/OS: Planning andInstallation

Install the dynamic domainmanager and dynamic agent.

Tivoli Workload Scheduler: Planning and InstallationGuide

Configure the Tivoli WorkloadScheduler for z/OS Agentproperties.

“Configuring the Tivoli Workload Scheduler forz/OS Agent settings” on page 6

Define the Tivoli WorkloadScheduler for z/OS Agent anddynamic domain managerdestinations.

“Defining destinations with the ROUTOPTSstatement” on page 9

Define the Tivoli WorkloadScheduler for z/OS Agentworkstations.

Chapter 4, “Defining and managing Tivoli WorkloadScheduler for z/OS Agent workstations in thedatabase,” on page 17

Define dynamic workstations. Chapter 5, “Defining and managing dynamicworkstations,” on page 21

TCP/IP

TCP/IP

TCP/IP

HTTP eventdata set

TWS z/OS Controller

HTTPclient

Datarouter

WorkstationAnalyzer

GeneralService

EventManager

HTTPserver

TWS forz/OS agent

TWS forz/OS agent

TWS forz/OS agent

Figure 3. Process flow


|

|||

|||

||

|||

||

||||

||

||||

|||

||

||||

||

|||

|||

|||

Table 1. Installation and configuration steps for setting up an end-to-end with z-centriccapabilities environment (continued)

To... Refer to...

Configure the SSL connectionprotocol, if you did not change thedefault configuration of the TivoliWorkload Scheduler for z/OSAgent.

Chapter 6, “Setting the security features,” on page 27

Customize the connectionparameters.

Chapter 2, “Customizing the HTTP connection withthe HTTPOPTS statement,” on page 13

Note: If you want to move from an end-to-end with fault tolerance capabilitiesenvironment to an end-to-end with z-centric one, refer to “Listing” on page 19.

Advantages of job types with advanced optionsThis section explains the advantages of job types with advanced options

While the existing Tivoli Workload Scheduler job is a generic script or command,you can define and schedule job types with advanced options to perform specifictasks, such as database, file transfer, Java, and web services operations. You caneasily define these job types without having specific skills on the applicationswhere the job runs.

The job types with advanced options include both those supplied with the productand the additional types implemented through the custom plug-ins.

The following job types with advanced options are available:

File transfer jobsTransfer files to and from a server reachable using FTP, SSH, or otherprotocols.

Web services jobsCall a web service.

Database jobsPerform queries, SQL statements, and jobs on a number of databases,including custom databases. You can also create and run stored procedureson DB2, Oracle, and MSSQL databases.

Executable jobsRun a script or command with advanced options, such as redirectingstandard input and standard output to a file.

Java jobsRun a Java class

MSSQL jobsRun a Microsoft SQL job.

XA jobsExtend job scheduling functions of Tivoli Workload Scheduler to othersystems and applications using access methods. The access methodscommunicate with the external system to launch the job and return thestatus of the job. The following access methods are available:v Oracle E-Business Suitev PeopleSoft


||

||

|||||

|

||||

|||

|

|

|||||

||

|

|||

||

||||

|||

||

||

|||||

|

|

v SAPv MVSv Custom methods

J2EE jobsAllow Java applications in the same network to send and receive messagesfrom and to a JMS destination.

IBM i jobsRun a command on IBM i systems.

You define job types with advanced options connecting to a z/OS engine with theDynamic Workload Console, with the exception of the IBM i job type which youcan create only with the JOBREC statement. From the Dynamic Workload Console,you open the Workload Designer and select the job type you want to create. Whenthe job definition is saved, it is stored in the JCL library and is available forscheduling from Tivoli Workload Scheduler for z/OS

The job types with advanced options run on Tivoli Workload Scheduler for z/OSAgents in both the static configuration (Tivoli Workload Scheduler for z/OS Agentconnected directly to the z/OS controller) and in the dynamic configuration (TivoliWorkload Scheduler for z/OS Agent connected to the dynamic domain manager).

In addition to configuring job types with advanced options using the DynamicWorkload Console, you can use the related configuration files. For moreinformation, see Appendix C, “Configuring to schedule job types with advancedoptions,” on page 79.

For more information about the procedure for defining job types with advancedoptions, see the section about creating job types with advanced options in TivoliDynamic Workload Console User's Guide. For more information about each job type,see the Dynamic Workload Console online help. For information about how tocreate jobs using the JOBREC statement, see “JOBREC” on page 30.

In addition, you can create custom plug-ins to implement your own job types withadvanced options for applications not supported by Tivoli Workload Scheduler. Formore information about how to create custom plug-ins, see Extending TivoliWorkload Automation, SC14-7623.

The agents with dynamic capabilities can run the jobs you created for the existingTivoli Workload Scheduler workstation types. To run these jobs on the dynamicagents, you only have to change the specification of the workstation where youwant the job to run. The major advantage is that you can use the workflows youpreviously created without additional effort.

Configuring the Tivoli Workload Scheduler for z/OS Agent settingsThe configuration settings of the Tivoli Workload Scheduler for z/OS Agent arecontained in the JobManager.ini file. The file is made up of many differentsections. Each section name is enclosed between square brackets and each sectionincludes a sequence of variable = value statements.

You can customize properties for the following:v Log and tracev Native job executorv Java job executor


|

|

|

|||

||

||||||

||||

||||

|||||

||||

|||||

Not all the properties in the JobManager.ini file can be customized. For a list ofthe configurable properties, see the tables in the following sections.

Configuring log and trace properties

In the JobManager.ini file, the section containing the log and trace properties isnamed:[JobManager.Logging]

You can change the configurable properties listed in Table 2.

Table 2. Trace and log configurable properties of the Tivoli Workload Scheduler for z/OSAgent

Property Value

Log messages JobManager.loggerhd.fileName The name of the filewhere messages are to belogged.

JobManager.loggerhd.maxFileBytes The maximum size thatthe log file can reach. Thedefault is 1024000 bytes.

JobManager.loggerhd.maxFiles The maximum number oflog files that can bestored. The default is 3.

JobManager.loggerfl.level The amount ofinformation to beprovided in the logs. Thevalue ranges from 4000to 7000. Smaller numberscorrespond to moredetailed logs. The defaultis 3000.

Traces

The output trace(JobManager_trace.log)is provided in XMLformat.

JobManager.trhd.fileName The name of the tracefile.

JobManager.trhd.maxFileBytes The maximum size thatthe trace file can reach.The default is 1024000bytes.

JobManager.trhd.maxFiles The maximum number oftrace files that can bestored. The default is 3.

JobManager.trfl.level The quantity ofinformation to beprovided in the traces.The value ranges from 0to 3000. Smaller numberscorrespond to moredetailed tracing. Thedefault is 3000.

Configuring common launchers properties

In the JobManager.ini file, the section containing the properties common to thedifferent launchers (or executors) is named:[Launchers]


You can change the configurable properties listed in Table 3:

Table 3. Common launchers configurable properties of the Tivoli Workload Scheduler forz/OS Agent

Property Value

BaseDir The installation path of the Tivoli WorkloadScheduler for z/OS Agent.

SpoolDir The path to the folder containing the jobstore andoutputs. The default is:

value of BaseDir/stdlidst/JM

MaxAge The number of days that job logs are kept (in pathTWA_home/TWS/stdlidst/JM) before being deleted.The default is 2. Possible values range from aminimum of 1 day.

CommandHandlerMinThreads The default is 20.

CommandHandlerMaxThreads The default is 100.

ExecutorsMinThreads The default is 38.

ExecutorsMaxThreads The default is 400.

NotifierMinThreads The default is 3.

NotifierMaxThreads The default is 5.

DirectoryPermissions The access rights assigned to the Tivoli WorkloadScheduler for z/OS Agents for creating directorieswhen running jobs. The default is 0755. Supportedvalues are UNIX-format entries in hexadecimalnotation.

FilePermissions The access rights assigned to the Tivoli WorkloadScheduler for z/OS Agents for creating files whenrunning jobs. The default is 0755. Supported valuesare UNIX-format entries in hexadecimal notation.

Configuring properties of the native job launcher

In the JobManager.ini file, the section containing the properties of the native joblauncher is named:[NativeJobLauncher]

You can change the configurable properties listed in Table 4.

Table 4. Native job launcher configurable properties of the Tivoli Workload Scheduler forz/OS Agent

Property Value

AllowRoot Applies to UNIX systems only. Specifies if the rootuser can run jobs on the agent. It can be true orfalse. The default is true.

CheckExec If true, before launching the job, the agent checksboth the availability and the execution rights of thebinary file. The default is true.

JobUnspecifiedInteractive Applies to Windows operating systems only. Specifiesif native jobs are to be launched in interactive mode.It can be true or false. The default is false.


|||

||

|||

|||

|

|||||

||

||

||

||

||

||

||||||

||||||

Table 4. Native job launcher configurable properties of the Tivoli Workload Scheduler forz/OS Agent (continued)

Property Value

LoadProfile Specifies if the user profile is to be loaded. It can betrue or false. The default is true.

PortMax The maximum range of the port numbers used by thetask launcher to communicate with the Job Manager.The default is 0, meaning that the operating systemassigns the port automatically.

PortMin The minimum range of the port numbers used by thetask launcher to communicate with the Job Manager.The default is 0, meaning that the operating systemassigns the port automatically.

RequireUserNameWhen true, requires that you add the user name inthe JSDL job definition.

When false, runs with the user name used by jobmanager, that is:

v TWS_user on UNIX and Linux systems

v The local system account on Windows systems

The default is false.

ScriptSuffix The suffix to be used when creating the script files. Itis:

.cmd For Windows

.sh For UNIX

VerboseTracing Enables verbose tracing. It is set to true by default.

Configuring properties of the Java job launcher

The properties of the Java job launcher are specified within the section named:[JavaJobLauncher]

Table 5 shows the properties you can modify.

Table 5. Java job launcher configurable properties of the Tivoli Workload Scheduler for z/OSAgent

Property Value

JVMDir The path to the virtual machine used to launchJava jobs. You can change the path to anothercompatible Java virtual machine.

Defining destinations with the ROUTOPTS statement

Tivoli Workload Scheduler for z/OS Agents and dynamic domain managers aredirectly connected to the controller. This means that you use the ROUTOPTSstatement to define the connection details of a Tivoli Workload Scheduler for z/OSAgent and dynamic domain manager to the controller or standby controller.


|

||||

Set the HTTP or HTTPS keyword to define all your Tivoli Workload Scheduler forz/OS Agent destinations. For Tivoli Workload Scheduler for z/OS Agents anddynamic domain managers, a destination is the combination of a name and thefully qualified host name, or IP address, and port number of the Tivoli WorkloadScheduler for z/OS Agent or dynamic domain manager.

HTTP and HTTPS have the same syntax. The difference is that HTTPS defines theconnection as SSL-secure. ROUTOPTS is defined in the member of the EQQPARMlibrary specified by the PARM parameter in the JCL EXEC statement of thecontroller.

The syntax for defining Tivoli Workload Scheduler for z/OS Agent and dynamicdomain managers destinations is the following:ROUTOPTS HTTP|HTTPS(destination,...,destination)

where destination is indicated as follows:

for Tivoli Workload Scheduler for z/OS Agentsdest name:’hostname or IP address of agent’/port num of agent

For more information, see Figure 1 on page 2.

for dynamic domain managershostname or IP address of DDM/port num of DDM/B

For more information, see Figure 2 on page 3.

for master domain managershostname or IP address of MDM/port num of MDM/B

The destination name is any alphanumeric sequence of up to 8 characters. You caninclude as many destinations as you want within the parentheses. They must beseparated by commas. Because you cannot specify more than 455 lines for eachROUTOPTS statement, you can add further destinations by specifying more thanone ROUTOPTS statement.

The following example specifies the destinations to two Tivoli Workload Schedulerfor z/OS Agents:ROUTOPTS HTTPS(ITAAC1:’192.27.144.12’/44112, ITAAC2:’192.14.55.231’/61424)

The following example specifies the destination to one dynamic domain manager:ROUTOPTS HTTPS(BRKS:’9.168.125.59’/8081/B)

For more information about the ROUTOPTS statement, see Customization andTuning.

You can modify, add, or delete a Tivoli Workload Scheduler for z/OS Agentdestination while Tivoli Workload Scheduler for z/OS is running. To make thechanges immediately effective, without stopping and restarting the controller, enterthe following MODIFY operator command:/F procname,RFRDEST

where procname is the Tivoli Workload Scheduler for z/OS JCL procedure name.For detailed information about the RFRDEST command, see Customization andTuning.


|||||

||||

||

|

|

||

|

||

|

||

|||||

||

|

|

|

||

||||

|

|||

To list the HTTP and HTTPS destinations that are currently used by the controller,enter the following MODIFY operator command (the list is stored in the MLOG):/F procname,DSPDEST

where procname is the Tivoli Workload Scheduler for z/OS JCL procedure name.For detailed information about the DSPDEST command, see Tivoli WorkloadScheduler for z/OS: Customization and Tuning.

You can add a maximum of 100 destinations, without having to restart thecontroller. The MODIFY command manages up to a total of 100 new destinations,regardless if you add them at once or at different times. After 100 destinationsadded, you must stop and restart the controller to have the MODIFY commandmanage other 100 new destinations.

Note: Deleting a destination does not increment the number of maximumadditions allowed.

You can modify or delete an unlimited number of destinations. However, if youmodify the destination name this operation is considered as adding a newdestination.


||

|

|||

|||||

||

|||

Chapter 2. Customizing the HTTP connection with theHTTPOPTS statement

You can optionally use the HTTPOPTS initialization statement to define a numberof parameters for Tivoli Workload Scheduler for z/OS Agents and dynamicdomain managers, for example:v Variable tables to be used when running job types with advanced optionsv Job log retrieval parameters

This statement is optional. You do not have to define the TCPIPJOBNAME and theHOSTNAME parameters if you already have a TCPOPTS initialization statementthat includes them. Define the job log retrieval parameters if you want to changethe defaults.

For a detailed description of the HTTPOPTS statement, see Customization andTuning.


|

|

|

|||

|

|

||||

||

Chapter 3. Defining user IDs and passwords with the USRRECstatement

Use the USRREC initialization statement to define the passwords for the users whoneed to schedule jobs to run on Windows workstations. Omit this statement, ifyour scheduling environment does not include these workstations.

If the statement is very long and needs to be split into two lines, use the comma (,)as a continuation character to continue the string to the next line.

USRREC is defined in the member of the EQQPARM library specified by theUSRMEM keyword in the HTTPOPTS statement.

You can make changes to the USRREC statement while Tivoli Workload Schedulerfor z/OS is running. To make them immediately effective, without stopping andrestarting the controller, enter the following MODIFY operator command:/F procname,RFRUSER

where procname is the Tivoli Workload Scheduler for z/OS JCL procedure name.For more information about the MODIFY command, see Managing the Workload.For more information about the USRREC statement, see “USRREC.”

USRRECPurpose

This statement defines the passwords for the users who need to schedule jobs torun on Windows workstations. Omit it if your scheduling environment does notinclude these workstations.

USRREC is defined in the member of the EQQPARM library as specified by theUSERMEM keyword in the TOPOLOGY statement.

Format

�� USRREC USRCPU ( cpu name ) USRNAM ( logon ID ) �

� USRPSW ( password ) ��

Parameters

USRCPU(cpu name)The Tivoli Workload Scheduler workstation on which the user can launchjobs. It consists of four alphanumeric characters, starting with a letter. It isvalid only on Windows workstations.

USRNAM(logon ID)The user name of a Windows workstation. It can include a domain nameand can consist of up to 47 characters. Windows user names might becase-sensitive, depending on the Windows version. The user must be ableto log on to the computer on which Tivoli Workload Scheduler haslaunched jobs, and must also be authorized to Log on as batch.


||

If the user name is not unique in Windows, it is considered to be either alocal user, a domain user, or a trusted domain user, in that order.

If you are defining a Windows domain user and the value contains abackslash (\), then the entire character string must be enclosed by singlequotes, for example:USRNAM(’XXXXX\user1’)

USRPSW(password)The user password for the user of a Windows workstation. It can consist ofup to 31 characters and must be enclosed in single quotation marks. Thepassword might be case-sensitive, depending on the Windows version. Donot specify this keyword if the user does not need a password. You canchange the password every time you create a Symphony™ file (that is,when creating a CP extension).

If you are defining a Windows domain user and the value contains abackslash (\), then the entire character string must be enclosed by singlequotes, for example:USRPSW(’XXXXX\password1’)

The password is stored in the USRINFO member in plaintext, meaning thatis not encrypted. To encrypt it, run the sample EQQE2EPW JCL provided inthe EQQBENCR member of the EQQSAMP library. For details about thissample JCL, see Tivoli Workload Scheduler for z/OS: Planning and Installation.

Alternatively, if you do not want to set some or all the user IDs andpasswords in the USRREC statement, define them in a local file on theWindows workstation, by using the user utility, and set LOCALPSW(YES)in the TOPOLOGY statement.


|||

|

Chapter 4. Defining and managing Tivoli Workload Schedulerfor z/OS Agent workstations in the database

After defining the destinations of your Tivoli Workload Scheduler for z/OS Agents,you need to define the Tivoli Workload Scheduler for z/OS Agents as TivoliWorkload Scheduler for z/OS computer automatic workstations. You can do thisby using either of the following:

ISPF The workstation definition and management panels in ISPF include theZ-CENTRIC AGENT field. You can take the following actions on TivoliWorkload Scheduler for z/OS Agent workstation definitions:v “Creating”v “Modifying” on page 18v “Browsing” on page 18v “Deleting” on page 19v “Listing” on page 19

Dynamic Workload ConsoleFor details, refer to the Dynamic Workload Console online help.

Creating

Figure 4 shows the CREATING GENERAL INFORMATION ABOUT A WORKSTATION panel, used to create general information about a Tivoli WorkloadScheduler for z/OS Agent workstation named ZCEN.

Define a Tivoli Workload Scheduler for z/OS Agent as a computer automaticworkstation and enter the destination name previously defined in the ROUTOPTSstatement. The Z-CENTRIC AGENT option excludes all other options.

EQQWCGEP ----- CREATING GENERAL INFORMATION ABOUT A WORK STATION --------Command ===>

Enter the command R for resources or A for availability or O for end-to-endoptions, or enter/change data below:

WORK STATION NAME ===> ZCENDESCRIPTION ===> z-centric workstation_____WORK STATION TYPE ===> C G General, C Computer, P Printer

R Remote EngineREPORTING ATTR ===> A A Automatic, S Manual start and completion

C Completion only, N Non reportingPRINTOUT ROUTING ===> SYSPRINT The ddname of daily plan printout data setSERVER USAGE ===> B Parallel server usage, B, N, P, or CDESTINATION ===> ITAAC1 Name of destinationOptions: allowed Y or NSPLITTABLE ===> N JOB SETUP ===> NSTARTED TASK, STC ===> N WTO ===> NAUTOMATION ===> N FAULT-TOLERANT AGENT ===> NWAIT ===> N Z-CENTRIC AGENT ===> YVIRTUAL ===> N DYNAMIC ===> N

REMOTE ENGINE TYPE ===> Z z/OS or D DistributedDefaults:TRANSPORT TIME ===> 00.00 Time from previous work station HH.MMDURATION ===> 00.05.00 Duration for a normal operation HH.MM.SS

Figure 4. EQQWCGEP - Creating general information about a Tivoli Workload Scheduler for z/OS Agent workstation


|||||||||||||||||||||||||||||

Modifying

Figure 5 shows the MODIFYING GENERAL INFORMATION ABOUT A WORKSTATION panel, used to modify the database definition of a Tivoli WorkloadScheduler for z/OS Agent workstation named ZCEN.

You can, at any time, modify a computer automatic workstation as follows:v From z-centric to fault-tolerant, and vice versav From z-centric to computer automatic, and vice versa

For detailed information about how to modify a fault-tolerant agent workstation toa z-centric one, refer to “Listing” on page 19.

Browsing

Figure 6 on page 19 shows the BROWSING A WORK STATION DESCRIPTIONpanel, used to browse the database description of a Tivoli Workload Scheduler forz/OS Agent workstation named ZCEN.

EQQWMGEP ---- MODIFYING GENERAL INFORMATION ABOUT A WORK STATION --------------Command ===>Enter the command R for resources A for availability O for end-to-end optionsor D for Destinations above, or enter data below:

Work station name : ZCENDESCRIPTION ===> z-centric workstation_____WORK STATION TYPE ===> C G General, C Computer, P PrinterREPORTING ATTR ===> A A Automatic, S Manual start and completion

C Completion only, N Non reportingPRINTOUT ROUTING ===> SYSPRINT The ddname of daily plan printout data setSERVER USAGE ===> N Parallel server usage C , P , B or NDESTINATION ===> ITAAC1__ Name of destinationOptions: allowed Y or NSPLITTABLE ===> N JOB SETUP ===> NSTARTED TASK, STC ===> N WTO ===> NAUTOMATION ===> N FAULT-TOLERANT AGENT ===> NWAIT ===> N Z-CENTRIC AGENT ===> YVIRTUAL ===> N DYNAMIC ===> N

Defaults:TRANSPORT TIME ===> 00.00 Time from previous work station HH.MMDURATION ===> ________ Duration for a normal operation HH.MM.SS

Figure 5. EQQWMGEP - Modifying a Tivoli Workload Scheduler for z/OS Agent workstation description


|||||||||||||||||||||||||

Deleting

Figure 7 shows the CONFIRMING DELETION OF A WORK STATIONDESCRIPTION panel, used to delete the database description of a Tivoli WorkloadScheduler for z/OS Agent workstation named ZCEN.

Listing

Figure 8 on page 20 shows the SPECIFYING WORK STATION LIST CRITERIApanel, used for specifying selection criteria to list Tivoli Workload Scheduler forz/OS Agent workstation definitions.

EQQWBGEP ------------ BROWSING A WORK STATION DESCRIPTION ---------------------Command ===>

Enter the command R for resources, A for availability, O for end-to-end optionsor D for Destinations above

Work station : ZCENDescription : z-centric workstation

Work station type : ComputerReporting attribute : AutomaticFT Work station : NoPrintout routing : SYSPRINTServer usage : NeitherDestination : ITAAC1

Splittable : No Job setup : NoStarted task STC : No WTO : NoAUTOMATION : No Fault-tolerant agent : NoWAIT : No z-centric agent : YesVIRTUAL : No Dynamic : NoTransport time : 00.00Duration :

Figure 6. EQQWBGEP - Browsing a Tivoli Workload Scheduler for z/OS Agent workstation description

EQQWDGEP ----- CONFIRMING DELETION OF A WORK STATION DESCRIPTION --------------Command ===>

Enter Y in the command field to confirm deletion orenter N to reject deletion.

Work station : ZCENDescription : Accts Receivable

Work station type : ComputerReporting attribute : Automatic

Printout routing : SYSPRINTServer usage : NeitherDestination : ITAAC1Splittable : No Job setup : NoStarted task STC : No WTO : NoAUTOMATION : No Fault-tolerant agent : NoWAIT : No z-centric agent : YesVIRTUAL : No Dynamic : NoTransport time : 00.00Duration :

Figure 7. EQQWDGEP - Deleting a Tivoli Workload Scheduler for z/OS Agent workstation description.

Chapter 4. Defining and managing Tivoli Workload Scheduler for z/OS Agent workstations in the database 19

||||||||||||||||||||||||||

|||||||||||||||||||||||||

EQQWWSEP ----------- SPECIFYING WORK STATION LIST CRITERIA --------------------Command ===>

Specify selection criteria below and press ENTER to create a list.

WORK STATION NAME ===> ____DESTINATION ===> ________TYPE ===> ___ G, C, P in any combination, or blankREPORTING ATTRIBUTE ===> ____ A, S, C, N in any combination or blankFT Work station ===> _ Y, N or blankAUTOMATION ===> _ Y, N or blankWAIT Work station ===> _ Y, N or blankVIRT Work station ===> _ Y, N or blankz-Centric Agent ===> Y Y, N or blankDynamic ===> _ Y, N or blank

Figure 8. EQQWWSEP - Specifying list selection criteria for Tivoli Workload Scheduler for z/OS Agent workstations


||||||||||||||||||

|

Chapter 5. Defining and managing dynamic workstations

When you add dynamic capabilities to your environment, you can schedule yourworkload dynamically. This section explains how you can add dynamic schedulingcapabilities to your environment.

You can add dynamic capabilities to your environment by connecting the z/OScontroller to a dynamic domain manager. The dynamic domain manager isinstalled in the distributed environment and manages Tivoli Workload Schedulerfor z/OS Agents with dynamic capabilities, also installed in the distributedenvironment.

The type of dynamic capabilities you add to your Tivoli Workload Scheduleragents depends on the type of workload you plan to run:v If you plan to run existing Tivoli Workload Scheduler jobs dynamically, install

the Tivoli Workload Scheduler for z/OS Agents with dynamic capabilities andconnect the agents to a dynamic domain manager connected to a TivoliWorkload Scheduler for z/OS controller.

v If you plan to run both existing Tivoli Workload Scheduler jobs and job typeswith advanced options dynamically, install the Tivoli Workload Scheduler forz/OS Agents with dynamic capabilities and Java runtime and connect the agentsto a dynamic domain manager connected to a Tivoli Workload Scheduler forz/OS controller.

In the z/OS environment, you can have the following dynamic workstations:

BrokerAlso known as dynamic domain manager in the distributed environment.An installed component in a Tivoli Workload Scheduler distributed orz/OS network that is the management hub in a domain where you runboth static and dynamic workload. All communications to and from thedynamic agents in the domain are routed through the dynamic domainmanager. You can use this workstation to submit jobs by reference. You candefine the broker workstation either from ISPF panels or from the DynamicWorkload Console. For more information, see Tivoli Workload Scheduler:Planning and Installation Guide.

Pool A workstation that groups a set of Tivoli Workload Scheduler for z/OSAgents with dynamic capabilities that have similar hardware or softwarecharacteristics to submit jobs to. Tivoli Workload Scheduler balances thejobs among the Tivoli Workload Scheduler for z/OS Agents with dynamiccapabilities within the pool and automatically reassigns jobs to availableagents if an agent is no longer available. To create a pool of TivoliWorkload Scheduler for z/OS Agents with dynamic capabilities, define aworkstation of type pool hosted by the workload broker workstation, thenselect the Tivoli Workload Scheduler for z/OS Agents with dynamiccapabilities you want to add to the pool. You can define the pool onlyusing the Dynamic Workload Console.

Dynamic poolA workstation that groups a set of Tivoli Workload Scheduler for z/OSAgents with dynamic capabilities, which is dynamically defined based onthe resource requirements you specify. For example, if you require aworkstation with low CPU usage and Windows installed to run your job,


|

|

|||

|||||

||

||||

|||||

|

||||||||||

||||||||||||

|||||

you specify these requirements using the Dynamic Workload Console. Thisworkstation maps all the Tivoli Workload Scheduler for z/OS Agents withdynamic capabilities in your environment that meet the requirements youspecified. The resulting pool is dynamically updated whenever a newsuitable Tivoli Workload Scheduler for z/OS Agent with dynamiccapabilities becomes available. You can define the dynamic pool only usingthe Dynamic Workload Console.

To enable dynamic end-to-end communication, perform the following steps:1. Install the dynamic domain manager in the distributed environment. For more

information, see Tivoli Workload Scheduler: Planning and Installation Guide.2. Establish a connection between the z/OS controller and the dynamic domain

manager: in the ROUTOPTS statement, set the DESTINATION keyword to thehost name of the dynamic domain manager previously installed, in thefollowing format:DESTINATION NAME=DDM_hostname/DDM:port_number/B

3. Define the dynamic domain manager workstation. Depending on how you planto use the dynamic domain manager, the procedure varies:

Submission of jobs by referenceDefine the dynamic domain manager using the following ISPF panels:a. CREATING GENERAL INFORMATION ABOUT A WORKSTATIONb. WORKSTATION END-TO-END OPTIONS

For more information, see “Creating broker workstations.”

Dynamic submission of jobs to pools and dynamic poolsDefine the dynamic domain manager in the Dynamic WorkloadConsole using the Create Workstations panel. For more information,see “Creating pools and dynamic pools” on page 24.

4. Install the Tivoli Workload Scheduler for z/OS Agents with dynamiccapabilities.

5. Optionally, define the pools and dynamic pools in the distributed environmentusing the Dynamic Workload Console.

To schedule jobs from Tivoli Workload Scheduler for z/OS to a distributedenvironment, you have the following options:v Submission to pools and dynamic pools. For more information, see “Submitting

jobs to pools or dynamic pools” on page 24.v Submission of jobs defined on the dynamic domain manager . For more

information, see “Submitting jobs by reference” on page 24.

Creating broker workstations

You can create broker workstations using the ISPF panels and the DynamicWorkload Console. You can use broker workstations to submit jobs by reference, asexplained in “Submitting jobs by reference” on page 24. To define a brokerworkstation, perform the following steps:1. Define a broker workstation as a computer automatic workstation, as described

in Figure 9 on page 23 and enter the destination name previously defined in theROUTOPTS statement. The DYNAMIC option excludes all other options.


|||||||

|

||

||||

|

||

||

|

|

|

||||

||

||

||

||

||

||

||||

||||

2. Select O to open the WORK STATION END-TO-END OPTIONS panel.3. Select BROKER=Y.

For more information, see the section about creating workstations in TivoliWorkload Scheduler for z/OS: Managing the Workload.

Defining a backup dynamic domain managerThis section explains how you can define a backup dynamic domain manager.

To define a backup dynamic domain manager, perform the following steps:1. Install the backup dynamic domain manager in the distributed environment.

For more information, see Tivoli Workload Scheduler: Planning and InstallationGuide.

2. Establish a connection between the z/OS controller and the backup dynamicdomain manager: in the ROUTOPTS statement, set the DESTINATIONkeyword to the host name of the backup dynamic domain manager previouslyinstalled, in the following format:

EQQWCGEP ----- CREATING GENERAL INFORMATION ABOUT A WORK STATION --------Command ===>

Enter the command R for resources or A for availability or O for end-to-endoptions, or enter/change data below:

WORK STATION NAME ===> DYNWDESCRIPTION ===> dynamic workstation_____WORK STATION TYPE ===> C G General, C Computer, P Printer

R Remote EngineREPORTING ATTR ===> A A Automatic, S Manual start and completion

C Completion only, N Non reportingPRINTOUT ROUTING ===> SYSPRINT The ddname of daily plan printout data setSERVER USAGE ===> B Parallel server usage, B, N, P, or CDESTINATION ===> ITAAC1 Name of destinationOptions: allowed Y or NSPLITTABLE ===> N JOB SETUP ===> NSTARTED TASK, STC ===> N WTO ===> NAUTOMATION ===> N FAULT-TOLERANT AGENT ===> NWAIT ===> N Z-CENTRIC AGENT ===> NVIRTUAL ===> N DYNAMIC ===> Y

REMOTE ENGINE TYPE ===> Z z/OS or D Distributed

Defaults:TRANSPORT TIME ===> 00.00 Time from previous work station HH.MMDURATION ===> 00.05.00 Duration for a normal operation HH.MM.SS

Figure 9. EQQWCGEP - Creating general information about a broker workstation

EQQWCEOD ----- WORK STATION END-TO-END OPTIONS--------Command ===>

Enter/change data below:

WORK STATION NAME ===> BRK

Default JOBREC values on this workstation:JOBUSER ===> User nameJOBPWD ===> PasswordJOBTYPE ===> Access method

Dynamic options:BROKER ===> Y

Figure 10. EQQWCEOD - Defining end-to-end options

Chapter 5. Defining and managing dynamic workstations 23

|||||||||||||||||||||||||||||

|||||||||||||||||

|

||

||

||

|

|

|||

||||

DESTINATION NAME=backup_DDM_hostname/backup_DDM:port_number/B

3. Define a dynamic workstation with type broker.4. Define the dynamic workstation as alternate workstation of the workstation

corresponding to the dynamic domain manager.You do not need to define pools and dynamic pools associated to the backupdynamic domain manager. When the dynamic domain manager fails and thebackup dynamic domain manager takes over, the backup dynamic domainmanager automatically inherits the dynamic agents, pools, and dynamic poolsdefined on the dynamic domain manager.

Creating pools and dynamic pools

You can create pools and dynamic pools using the Dynamic Workload Console.

To create pools and dynamic pools using theDynamic Workload Console , performthe following steps:1. Log in to the Dynamic Workload Console.2. Click Scheduling Environment > Design > Create Workstations.3. Select a z/OS engine from the list and click Create Workstation.4. Specify the workstation attributes using the General, Resources, and Open

Time Intervals tabs as appropriate. Depending on the type of workstation youselect, some attributes are mandatory.

5. Click Save.6. Create the number and type of workstations you require.7. Define the new workstations in the z/OS environment as dynamic

workstations.8. In the ROUTOPTS statement, set the DESTINATION keyword to the hostname

of the dynamic domain manager.

For more information about workstation characteristics and attributes, see theDynamic Workload Console online help.

Submitting jobs to pools or dynamic poolsAbout this task

To submit jobs to a pool or dynamic pool, perform the following steps:1. Define a JOBREC statement using the appropriate syntax, as explained in

“Defining a job in the JOBLIB data set” on page 30. Alternatively, you cancreate the job from the Dynamic Workload Console.

2. Submit the JOBREC statement to the workstation defined in “Creating poolsand dynamic pools.” The job is submitted to the workstation you specified.Tivoli Workload Scheduler dynamically assigns the job to the best availableresource.

Submitting jobs by referenceAbout this task

When you submit a job by reference, you create a job definition in the distributedenvironment and submit it from Tivoli Workload Scheduler for z/OS to thedistributed environment. In the distributed environment, the job is dynamically


|

|

||

|||||

||

|

||

|

|

|

|||

|

|

||

||

||

||

|

|

|||

||||

||

|

|||

assigned to the best available resource. You write in the Tivoli Workload Schedulerfor z/OS JCL only the job name of the job, without having to write or import thewhole job into the JCL. You can submit jobs by reference only on brokerworkstations.

To submit jobs by reference from Tivoli Workload Scheduler for z/OS, perform thefollowing steps:1. Define a job with name broker_test using the Tivoli Dynamic Workload Broker

web console. This job contains the operations to be performed:2. Create a JCL, using the ISPF panels or the Dynamic Workload Console,

specifying the name of the job you created in step 1. This references the job inthe distributed environment.

3. Submit the JCL. As a result, the broker_test job is submitted in the distributedenvironment.

Chapter 5. Defining and managing dynamic workstations 25

||||

||

||

|||

||

|

Chapter 6. Setting the security features

Tivoli Workload Scheduler for z/OS provides a secure, authenticated, andencrypted connection mechanism for communication across the network. Thismechanism is based on the Secure Sockets Layer (SSL) protocol.

By default, the Tivoli Workload Scheduler for z/OS Agent is installed with the SSLprotocol enabled. According to this default, in the HTTPOPTS statement you mustset the connection security for end-to-end communication to enable SSL.

The security features of Tivoli Workload Scheduler on distributed networksinclude:v “Creating” on page 17v “Browsing” on page 18

Setting SSL-secure connections for communicationTo provide SSL security for an HTTP connection between the z/OS controller andTivoli Workload Scheduler for z/OS Agent, set the HTTPS keyword in theROUTOPTS statement (for details about ROUTOPTS, refer to Tivoli WorkloadScheduler for z/OS: Customization and Tuning).

Using security certificatesAt installation time, the default security certificates are automatically stored intothe SEQQDATA library:

EQQCERCLThe security certificate for the client.

EQQCERSRThe security certificate for the sever.

You can decide to use these default certificates or create your own. In both cases,you need to import them into your security system. If you are using RACF®, youare provided with the sample job EQQRCERT to import the certificates. To run thisjob, ensure that you use the same user ID that RACF associates with the controllerstarted task.

The EQQRCERT job:v Copies the EQQCERCL certificate to a temporary sequential data setv Copies the EQQCERSR certificate to a temporary sequential data setv Imports EQQCERCL to RACFv Imports EQQCERSR to RACFv Deletes the temporary sequential data setsv Creates the SAF key ring that is used to connect the imported certificatesv Updates the RACF database with the new certificates and key ring


Encrypting the user passwordYou define Windows user IDs and passwords for Windows users by using theUSRREC statement in a PARMLIB member (the default member name is USRINFO).For details, see Customization and Tuning. To encrypt it, run the sample EQQE2EPWJCL provided in the EQQBENCR member of the EQQSAMP library. For detailsabout this sample JCL, see Tivoli Workload Scheduler for z/OS: Planning andInstallation.


Chapter 7. Using

This chapter describes how to use the z-centric end-to-end scheduling solution. Itcontains the following sections:v “Starting and stopping HTTP subtasks”v “Defining a job in the JOBLIB data set” on page 30v “Issuing List requests by using the PIF and the BCIT” on page 51v “Using variable substitution” on page 52v “Defining file dependencies to check for file changes” on page 52v “Managing the status of the Tivoli Workload Scheduler for z/OS Agent

workstation in the plan” on page 56v “Browsing system information of Tivoli Workload Scheduler for z/OS Agent

workstations” on page 60v “Killing Tivoli Workload Scheduler for z/OS Agent operations” on page 60

Starting and stopping HTTP subtasksAn HTTP Server subtask and an HTTP Client subtask run the transmission of databetween the scheduler and the Tivoli Workload Scheduler for z/OS Agents on thedistributed side. These subtasks automatically start at controller startup. You can atanytime start or stop them while Tivoli Workload Scheduler for z/OS is runningby using the MODIFY command. You can enter this command from a multipleconsole support (MCS) console or from a program such as the spool display andsearch facility (SDSF). In both cases, the terminal or console operator must havethe required authority to enter operator commands.

Enter the MODIFY command as follows:/F procname,modifyoption

where:

procnameIs the Tivoli Workload Scheduler for z/OS controller JCL procedure name.

modifyoptionCan be one of the following:

S=tasknameStart the specified subtask.

P=tasknameStop the specified subtask.

where taskname is either of the following:

HTC The HTTP Client subtask

HTS The HTTP Server subtask


Defining a job in the JOBLIB data setYou define the jobs to be run on Tivoli Workload Scheduler for z/OS Agentworkstations in a job definition member of the JOBLIB data set. In the JOBLIBmember, you can either define the job contents or invoke a script or an executablethat is stored locally on the Tivoli Workload Scheduler for z/OS Agentworkstation. If you do not specify any content in the job definition member, theerror code JCLI is issued.

To define the job contents, the following syntax rules apply:v The lines that start with //* OPC, //*%OPC, or //*>OPC are used for variable

substitution and automatic recovery. They are removed before the script isdownloaded onto the Tivoli Workload Scheduler for z/OS Agent.

v Each line starts between column 1 and column 80.v The final backslash (\) in a line is considered the character of continuation.v Blanks at the end of the line are automatically removed.

To define the job properties, use the “JOBREC” statement.

JOBREC

To define the properties of a job to be run on Tivoli Workload Scheduler for z/OSAgent workstations, use the following format://JOBRECkeyword(value)keyword(value)//END JOBREC

The following syntax rules apply:v The value of each keyword can continue over one or more lines.v Each statement must be on a separate line.v The value of each keyword must be enclosed within parentheses. This means

that every character enclosed within the parentheses is considered to be part ofthe keyword value, including blanks and single quotes.

v The script or executable must follow the //END JOBREC line.v If you specify the same keyword more than once, only the last keyword

specified is considered valid.v You can insert any comment text by using //* as the starting characters.v Unsupported keywords inserted in the statement are ignored without warning.v Keywords are optional, unless otherwise indicated.v Keywords and values are case-sensitive.

In the JOBREC statement, you can define different job types.

Supported job types and their related keywords are listed in Table 6 on page 31.


Table 6. Jobs and their keywords

Job to be run Keywords Section

databaseSTATEMENT(id) (required)CMDTYPE(id) (optional)DBNAME (required)DBTYPE (required)JOBPWD (optional)JOBTYPE (required)JOBUSR (optional)POLLINGIVL(id) (optional, appliesonly to the MSSQL database type)PORT (required)SERVER (required)SYNCTYPE(id) (optional, appliesonly to the MSSQL database type)WSNAME (optional)

“Syntax diagram for database jobtypes” on page 32

file transferJOBPWD (required)JOBTYPE (required)JOBUSR (required)LOCALFILE (required)PROTOCOL (optional)REMOTEFILE (required)SERVER (required)TRANSFERTYPE (required)WSNAME (optional)

“Syntax diagram for file transferjob types” on page 38

web serviceJOBPWD (optional)JOBTYPE (required)JOBUSR (optional)OPNAME (required)PARM(id) (optional)URL (required)WSNAME (optional)

“Syntax diagram for web servicejob types” on page 41

javaCLASSNAME (required)JARPATH (optional)JAVAPARM(id) (optional)JOBTYPE (required)

“Syntax diagram for Java job type”on page 43

xajobENVVAR(id) (optional)JOBPWD (optional)JOBTYPE (required)JOBUSR (optional)WSNAME (optional)

“Syntax diagram for xajob type” onpage 44

j2ee jmsAUTHALIAS (optional)CONNFACTORY (required)DESTINATION (required)INVOKEYTYPE (optional)JOBPWD (optional)JOBTYPE (required)JOBUSR (optional)MESSAGE (optional)WSNAME (optional)

“Syntax diagram for J2EE jms jobtype” on page 46

Chapter 7. Using 31

Table 6. Jobs and their keywords (continued)

Job to be run Keywords Section

native(executable orscript)

ENVVAR(id) (optional)INTRACTV (optional)JOBCMD (required for executable,optional for script)JOBPWD (optional)JOBUSR (optional)PARM(id) (optional)STDERROR (optional)STDINPUT (optional)STDOUTPUT (optional)WRKDIR (optional)WSNAME (optional)

“Syntax diagram for native jobtype” on page 48

Syntax diagram for database job typesThis section describes the database job type.

If you set JOBTYPE to (/database), you can choose among the following databasetypes:v DB2®

v Oraclev MSSQL

The syntax for DB2 and Oracle is identical, but the syntax for MSSQL supportsMSSQL-specific operations. For details, see “Syntax diagram for DB2 and Oracledatabase job types” and “Syntax diagram for MSSQL database job type” on page35.

Syntax diagram for DB2 and Oracle database job typesPurpose

This section provides detailed information about the syntax diagram for the DB2and Oracle database job types. The following syntax rules apply:v You can define multiple statements in the same job by specifying a series of

STATEMENTid keywords, where id is a unique numeric value, including nulland zero. For example, you can define STATEMENT, STATEMENT0,STATEMENT1, STATEMENT2, and so on.

v If you set DBTYPE to DB2 or Oracle, you can set CMDTYPE to SQL.v You can specify any number of CMDTYPE keywords, according to the

corresponding STATEMENT keyword. The STATEMENT keyword must bespecified before the corresponding CMDTYPE keyword. For example, you canspecify CMDTYPE3 only if you have previously specified STATEMENT3.

Format

�� JOBREC � STATEMENTid ( string )... CMDTYPEid ( SQL )

...

�


� DBNAME ( database name )DB2

DBTYPE ( ORACLE ) �

�NO

JOBPWD ( YES )

JOBTYPE ( /database ) �

�JOBUSR ( user name )

PORT ( port number ) �

� SERVER ( host name )WSNAME ( workstation name )

��

Parameters

STATEMENTid(string)The string defining the SQL query or job. This keyword is required. You candefine multiple statements in the same job by specifying a series ofSTATEMENTid keywords, where id is a unique numeric value, including nulland zero. For example, you can define STATEMENT, STATEMENT0,STATEMENT1, STATEMENT2, and so on.

When running stored procedures, ensure that the returned result is in tabularformat. Results in any other format are not supported.

CMDTYPEid(SQL)The type of command to be run. You can specify a series of CMDTYPEidkeywords, where id is a unique numeric value, including null and zero. The idof the CMDTYPE keyword must match the id of the related STATEMENTkeyword. For example, you can specify CMDTYPE3 only if you specifySTATEMENT3.

If you set DBTYPE to (/DB2) or to (/ORACLE), you can set CMDTYPE to SQL.

DBNAME(database name)The name of the database. This keyword is required.

DBTYPE(DB2|ORACLE)The database type. This keyword is required.

JOBPWD(YES|NO)Specifies that the user name set in JOBUSR or by using the job-submit exitEQQUX001 is associated with a password. If you set JOBPWD to YES, TivoliWorkload Scheduler for z/OS searches for the user password in the USRPSWkeyword of the USRREC statement (for details, see Tivoli Workload Scheduler forz/OS: Customization and Tuning).

Typically, the password is required for users who schedule jobs to run onWindows workstations. Set JOBPWD to NO if the user works with UNIXworkstations.

Chapter 7. Using 33

||||

JOBTYPE(/xajob/access method name|/j2ee/jms|/web service|/filetransfer|/database|/java)

To run a database job, specify /database. For information about the other typesof job, see the specific section for each job type. This keyword is required.

/databaseSet this value to submit a database job. Before you can run a query ona database, download the JDBC drivers for your database client to eachTivoli Workload Scheduler for z/OS Agent on which you want tosubmit database jobs. Specify the path to the database client jar files inthe DatabaseJobExecutor.properties file, located in the JavaExt\cfgdirectory in your Tivoli Workload Scheduler installation directory.Define the jdbcDriversPath property to point to the JDBC jar filesdirectory, for example, jdbcDriversPath=c:\\mydir\\jars\\jdbc. TheJDBC jar files must be located in the specified directory or itssubdirectories. Ensure that you have list permissions for the directoryand its subdirectories.

JOBUSR(user name)The user name for accessing the database.

If the user schedules jobs to run on Windows workstations, ensure that a userpassword is also defined (see the JOBPWD keyword). If you are defining aWindows domain user, use the following format:JOBUSR(domainName\user1)

To specify the user name, you can also use the job-submit exit EQQUX001.This user name overrides the value specified for JOBUSR. In turn, the valuespecified for JOBUSR overrides the value specified for USRNAM in theUSRREC statement.

PORT(port number)The port number for the database job. This keyword is required.

SERVER(host name)The host name of the server where the file transfer is to be performed or wherethe database is located. This keyword is required if you set JOBTYPE to (/filetransfer) or to (/database).

WSNAME(workstation_name)The name of the workstation from which user name and password must beretrieved. User name and password can be specified in the statement, using theJOBUSR and JOBPWD keywords, or can be associated to a workstation withthe USRREC statement. With the WSNAME keyword, you can specify aworkstation where the user name and password are stored, which is differentfrom the workstation where the job runs.

Examples

The following is an example of a JOBREC statement to select all records from tableSYSTOOLS.POLICY://JOBRECJOBTYPE(/database)STATEMENT20(SELECT * FROM SYSTOOLS.POLICY)DBNAME(DBWEB)DBTYPE(DB2)SERVER(9.168.99.87)PORT(50000)


|||||||

JOBUSR(Administrator)JOBPWD(YES)CMDTYPE20(SQL)//END JOBREC

The following is an example of a JOBREC statement to select columns country_idand country_name FROM table countries://JOBRECJOBTYPE(/database)STATEMENT1(SELECT country_id, country_name FROM countries)DBNAME(SAMPLE)DBTYPE(ORACLE)SERVER(9.168.115.37)PORT(70000)CMDTYPE1(SQL)JOBUSR(ZCENTUMB)JOBPWD(YES)//END JOBREC

Syntax diagram for MSSQL database job typePurpose

This section provides detailed information about the syntax diagram for theMSSQL database job type. The following syntax rules apply:v You can define multiple statements in the same job by specifying a series of

STATEMENTid keywords, where id is a unique numeric value, including nulland zero. For example, you can define STATEMENT, STATEMENT0,STATEMENT1, STATEMENT2, and so on.

v If you set DBTYPE to (/MSSQL), you can set CMDTYPE to either JOB or SQL andspecify the related job or SQL query in the STATEMENT keyword. If you setCMDTYPE to JOB, you can specify a job saved on the server; if you setCMDTYPE to SQL, you can specify a statement in the native language of thedatabase that you selected.

v If you set CMDTYPE to JOB, you can optionally define the SYNCTYPE andPOLLINGIVL keywords. This information is not visible in the syntax diagram.

v If you set CMDTYPE to SQL, you cannot define the SYNCTYPE andPOLLINGIVL keywords. This information is not visible in the syntax diagram.

v You can specify any number of CMDTYPE, SYNCTYPE, and POLLINGIVLkeywords, according to the corresponding STATEMENT keyword. TheSTATEMENT keyword must be specified before the corresponding CMDTYPE,SYNCTYPE, and POLLINGIVL keywords. For example, you can specifyCMDTYPE3, SYNCTYPE3, and POLLINGIVL3 only if you have previously specifiedSTATEMENT3.

Format

�� JOBREC �

SQLCMDTYPEid JOB...

DBNAME ( database name ) �

Chapter 7. Using 35

� DBTYPE ( MSSQL )NO

JOBPWD ( YES )

�

� JOBTYPE ( /database )JOBUSR ( user name )

�

� �

10000POLLINGIVLid ( polling int )...

PORT ( port number ) �

� SERVER ( host name ) � STATEMENTid ( string )...

�

� �

YESSYNCTYPEid NO...

WSNAME ( workstation name )��

Parameters

CMDTYPEid(SQL|JOB)The type of command to be run. You can specify a series of CMDTYPEidkeywords, where id is a unique numeric value, including null and zero. The idof the CMDTYPE keyword must match the id of the related STATEMENTkeyword. For example, you can specify CMDTYPE3 only if you specifySTATEMENT3.

If you set DBTYPE to (/MSSQL), you can set CMDTYPE to either JOB or SQLand specify the related job or SQL query in the STATEMENT keyword. If youset CMDTYPE to JOB, you can specify a job saved on the server; if you setCMDTYPE to SQL, you can specify a statement in the native language of thedatabase that you selected.

DBNAME(database name)The name of the database. This keyword is required.

DBTYPE(MSSQL)The database type. This keyword is required.



||||



To run a database job, specify /database. For information about the other typesof job, see the specific section for each job type. This keyword is required.

/databaseSet this value to submit a database job. Before you can run a query ona database, download the JDBC drivers for your database client to eachTivoli Workload Scheduler for z/OS Agent on which you want tosubmit database jobs. Specify the path to the database client jar files inthe DatabaseJobExecutor.properties file, located in the JavaExt\cfgdirectory in your Tivoli Workload Scheduler installation directory.Define the jdbcDriversPath property to point to the JDBC jar filesdirectory, for example, jdbcDriversPath=c:\\mydir\\jars\\jdbc. TheJDBC jar files must be located in the specified directory or itssubdirectories. Ensure that you have list permissions for the directoryand its subdirectories.

JOBUSR(user name)The user name for accessing the database.



POLLINGIVLid(polling int|10000)The polling interval in milliseconds. This keyword is valid only if you setCMDTYPE to (/JOB). You can specify a series of POLLINGIVLid keywords,where id is a unique numeric value, including null and zero. The id of thePOLLINGIVL keyword must match the id of the related STATEMENTkeyword. For example, you can specify POLLINGIVL3 only if you specifySTATEMENT3.

PORT(port number)The port number for the database job. This keyword is required.

SERVER(host name)The host name of the server where the file transfer is to be performed or wherethe database is located. This keyword is required if you set JOBTYPE to (/filetransfer) or to (/database).

STATEMENTid(string)The string defining the SQL query or job. This keyword is required. You candefine multiple statements in the same job by specifying a series ofSTATEMENTid keywords, where id is a unique numeric value, including nulland zero. For example, you can define STATEMENT, STATEMENT0,STATEMENT1, STATEMENT2, and so on.

When running stored procedures, ensure that the returned result is in tabularformat. Results in any other format are not supported.

Chapter 7. Using 37

SYNCTYPEid(YES|NO)Specifies if synchronization is required. This keyword is valid only if you setCMDTYPE to (/JOB). You can specify a series of SYNCTYPEid keywords,where id is a unique numeric value, including null and zero. The id of theSYNCTYPE keyword must match the id of the related STATEMENT keyword.For example, you can specify SYNCTYPE3 only if you specify STATEMENT3.


Examples

The following is an example of a JOBREC statement to run jobSPMTEST_BACKUP without synchronization and with a polling interval of 100milliseconds, and to select all records from the DBO.TWSRECORDS table://JOBRECJOBTYPE(/database)DBNAME(SCVTEST)DBTYPE(MSSQL)SERVER(SQLCON008)PORT(1278)STATEMENT1(SPMTEST_BACKUP)CMDTYPE1(JOB)SYNCTYPE1(NO)POLLINGIVL1(100)STATEMENT2(SELECT * FROM DBO.TWSRECORDS)CMDTYPE2(SQL)JOBUSR(PWR_USER)JOBPWD(YES)//END JOBREC

Syntax diagram for file transfer job types

This section describes the file transfer job type.

Syntax diagram for file transfer job typesPurpose

If you set JOBTYPE to (/file transfer), you can choose between the followingtransfer types for transferring binary files:v Uploadv Download

This section provides detailed information about the syntax diagram for both theupload and download job types. The following syntax rules apply:v The syntax of the selected protocol applies.

Format

�� JOBRECNO

JOBPWD ( YES ) JOBTYPE ( /file transfer ) �


|||||||

� JOBUSR ( user name ) LOCALFILE ( file name ) �

�PROTOCOL ( FTP )

WINDOWSSSH

REMOTEFILE ( file name ) �

� SERVER ( host name ) TRANSFERTYPE ( UPLOAD )DOWNLOAD

�

�WSNAME ( workstation name )

��

Parameters




To run a file transfer job, specify /file transfer. For information about the othertypes of job, see the specific section for each job type. This keyword isrequired.

/file transferSet this value to submit a file transfer job.

JOBUSR(user name)The user name for accessing the FTP, SSH, or Windows server.



LOCALFILE(file name)The name of the local file that you want to transfer. When uploading, this isthe source file, when downloading, this is the target file. This keyword isrequired.

PROTOCOL(FTP|WINDOWS|SSH)The protocol to be used for the file transfer. Allowed values are:

Chapter 7. Using 39

||||

FTP A standard network protocol used to exchange files over aTCP/IP-based network, such as the Internet.

WINDOWSThe Microsoft file sharing protocol. Specify the root shared directory inthe REMOTEFILE keyword. Specify the address of the workstationhosting the shared directory in the SERVER keyword.

SSH A network protocol that provides file access, file transfer, and filemanagement functions over any data stream.

REMOTEFILE(file name)The name of the remote file that you want to transfer. When uploading, this isthe target file, when downloading, this is the source file. This keyword isrequired.

SERVER(host name)The host name of the server where the file transfer is to be performed or wherethe database is located. This keyword is required if you set JOBTYPE to (/filetransfer) or (/database).

TRANSFERTYPE(UPLOAD|DOWNLOAD)The type of file transfer that you want to perform; either upload or download.This keyword is required.


Examples

The following is an example of a JOBREC statement to transfer a file using the FTPprotocol://JOBRECJOBTYPE(/file transfer)TRANSFERTYPE(DOWNLOAD)SERVER(server address)LOCALFILE(C:\file1.txt)REMOTEFILE(/file1.txt)PROTOCOL(FTP)JOBUSR(username)JOBPWD(YES)//END JOBREC

The following is an example of a JOBREC statement to transfer a file using theSSH protocol://JOBRECJOBTYPE(/file transfer)TRANSFERTYPE(DOWNLOAD)SERVER(server address)LOCALFILE(C:\file1.txt)REMOTEFILE(/home/provaftp/file1.txt)PROTOCOL(SSH)JOBUSR(username)JOBPWD(YES)//END JOBREC


|||||||

The following is an example of a JOBREC statement to transfer a file using theWINDOWS protocol://JOBRECJOBTYPE(/file transfer)TRANSFERTYPE(UPLOAD)SERVER(server address)LOCALFILE(C:\file3.txt)REMOTEFILE(shared directory\file88.txt)PROTOCOL(WINDOWS)JOBUSR(username)JOBPWD(YES)//END JOBREC

Syntax diagram for web service job types

This section describes the web service job type.

Syntax diagram for web service job typesPurpose

If you set JOBTYPE to (/web service), you can run an existing web service:

This section provides detailed information about the syntax diagram for the webservice job type.

Format

�� JOBRECNO

JOBPWD ( YES )

JOBTYPE ( /web service ) �

�JOBUSR ( user name )

OPNAME ( operation name ) �

� �

PARMid ( parameter )...

URL ( web service URL ) �


��

Parameters


Chapter 7. Using 41

||||



To run a web service job, specify /web service. For information about the othertypes of job, see the specific section for each job type. This keyword isrequired.

/web serviceSet this value to submit a web service job.

JOBUSR(user name)The user name for accessing the web service, if required.



OPNAME(operation name)The name of the operation to run. This keyword is required.

PARMid(parameter)The parameter to be used when running the script or command. You canspecify a series of PARMid keywords, where id is a unique numeric value,including null and zero.

URL(web service URL)The URL of the web service to be called. This keyword is required.


Examples

The following is an example of a JOBREC statement to call a web service thatcalculates the sum of the specified parameters://JOBRECJOBTYPE(/web service)PARM1(10)PARM2(20)JOBUSR(administrator)JOBPWD(YES)OPNAME(getSum)URL(http://manchester.testlab.uk.service.com:9467/Sum/services/Sum/wsdl/Sum.wsdl)//END JOBREC


|||||||

Syntax diagram for Java job type

This section describes the Java job type.

Syntax diagram for Java job typePurpose

If you set JOBTYPE to (/java), you can run an existing Java class:

This section provides detailed information about the syntax diagram for the Javajob type. The following syntax rules apply:v Use the UNIX format for the value of the JARPATH keyword.

Format

�� JOBREC CLASSNAME ( java class name )JARPATH ( path name )

�

� �

JAVAPARMid ( Java parameter name=value )...

�

� JOBTYPE ( /java ) ��

Parameters

CLASSNAME(java class name)The name of the Java class to run. This keyword is required.

JARPATH(path name)The path to the jar file.

JAVAPARMid(Java parameter name=value)The Java parameter used by the Java class. You can define multiple parametersin the same job by specifying a series of JAVAPARMid keywords, where id is aunique numeric value, including null and zero. For example, you can defineJAVAPARM1, JAVAPARM2, and so on.

Use the following format, which is case sensitive:JAVAPARMid(Java parameter name=value)

Where:

Java parameter nameThe name of the Java parameter.

value The value associated with the Java parameter.


To run a Java job, specify /java. For information about the other types of job,see the specific section for each job type.

Chapter 7. Using 43

/java Set this value to submit a Java job. Ensure that you have listpermissions for the folder specified in the jarPath property.

Examples

The following is an example of a JOBREC statement to run a class with namemypackage.base://JOBRECJOBTYPE(/java)CLASSNAME(mypackage.base)JAVAPARM1(name=backup)JARPATH(c:/jarPath2)//END JOBREC

Syntax diagram for xajob type

This section describes the xajob transfer job type.

Syntax diagram for xajob job typePurpose

If you set JOBTYPE to /xajob/access method name, you can run a job on anextended agent:

This section provides detailed information about the syntax diagram for the xajobjob type.

Format

�� JOBREC �

ENVVARid ( environment variable name=value )...

�

�NO

JOBPWD ( YES )

JOBTYPE ( /xajob/access method name ) �

�JOBUSR ( user name ) WSNAME ( workstation name )

��

Parameters

ENVVARid(environment variable name=value)The environment variable that the task launcher must set before submitting thejob. You can specify a series of ENVVARid keywords, where id is a uniquenumeric value, including null and zero.

Use the following format, which is case sensitive:ENVVARid(environment variable name=value)

Where:


||||

environment variable nameThe name of the environment variable.

value The value associated with the environment variable.


Typically, the password is required for users who schedule jobs to run onWindows workstations. Set JOBPWD to NO for the users working on UNIXworkstations.


To run an xajob, specify /xajob/access method name. For information about theother types of job, see the specific section for each job type. This keyword isrequired.

/xajob/access method nameThe name of the access method hosted by the extended agent on whichyou want to submit the job. For example, for a job to be submitted ona SAP extended agent, this value might be /xajob/r3batch. If you setthis keyword, the JOBCMD keyword value is ignored.

JOBUSR(user name)The name of the user submitting the job.




Examples

The following is an example of a JOBREC statement to un a job using the r3batchaccess method. The content of the JOBTYPE keyword is case sensitive://JOBRECJOBTYPE(/xajob/r3batch)ENVVAR10(VAL=10)//END JOBREC-JOB SAPJOB -USER SAPUSER

Chapter 7. Using 45

|||||||

|

||

|||||

Syntax diagram for J2EE jms job type

This section describes the J2EE jms job type.

Syntax diagram for J2EE jms job typePurpose

If you set JOBTYPE to (/j2ee/jms), you can run an existing j2ee jms class:

This section provides detailed information about the syntax diagram for the j2eejms job type.

Format

�� JOBRECAUTHALIAS ( authentication alias )

�

� CONNFACTORY ( connection factory ) �

� DESTINATION ( message destination )DIRECT

INVOKEYTYPE ( INDIRECT )

�

�NO

JOBPWD ( YES )

JOBTYPE ( /j2ee/jms ) �

�JOBUSR ( user name ) MESSAGE ( message )

�


��

Parameters

AUTHALIAS(authentication alias)The Java Authentication and Authorization Service (JAAS) authentication alias.This keyword is valid only if you set INVOKEYTYPE to (DIRECT).

CONNFACTORY(connection factory)The administered object that a client uses to create a connection to the JavaMessaging Service (JMS) provider. This keyword is required.

DESTINATION(message destination)The administered object that encapsulates the identity of a messagedestination, which is where messages are delivered and consumed. Thiskeyword is required.

INVOKEYTYPE(INDIRECT|DIRECT)The type of scheduling. This keyword is valid only if you set JOBTYPE to(/j2ee/jms). Allowed values are:

INDIRECTTivoli Workload Scheduler for z/OS uses an existing WebSphere®

Application Server scheduling infrastructure already configured on anexternal WebSphere Application Server.


|

||||

DIRECTTivoli Workload Scheduler for z/OS immediately forwards the job tothe components of the external WebSphere Application Server instance.




To run a j2ee jms job, specify /j2ee/jms. For information about the other typesof job, see the specific section for each job type. This keyword is required.

/j2ee/jmsSet this value to submit a Java Messaging Service (JMS) job.

JOBUSR(user name)The user name for accessing WebSphere Application Server, if required.



MESSAGE(message)The object that is sent from one application to another.


Examples

The following is an example of a JOBREC statement to submit a JMS job://JOBRECJOBTYPE(/j2ee/jms)INVOKEYTYPE(DIRECT)CONNFACTORY(jms/MyCF)DESTINATION(jms/MyQueue)MESSAGE(This is my message)JOBUSR(administrator)JOBPWD(YES)//END JOBREC

Chapter 7. Using 47

|||||||

Syntax diagram for native job type

This section describes the native job type.

Syntax diagram for script and executable job typePurpose

If you set JOBCMD to (script) or (executable), you can choose between thefollowing native job types:v Scriptv Executable

This section provides detailed information about the syntax diagram for the scriptand executable job types. The following syntax rules apply:v The JOBCMD keyword is required for executable and optional for script job

types.

Format

�� JOBREC �

ENVVARid ( environment variable name=value )...

�

�NO

INTRACTV ( YES )SCRIPT

JOBCMD ( EXECUTABLE )

�

�NO

JOBPWD ( YES )JOBUSR ( user name )

�

� �

PARMid ( parameter )...

�

�STDERROR ( standard error file path )

�

�STDINPUT ( standard input file path )

�


�STDOUTPUT ( standard output file path )

�

�WRKDIR ( working dir path ) WSNAME ( workstation name )

��

Parameters

ENVVARid(environment variable name=value)The environment variable that the task launcher must set before submitting thejob. You can specify a series of ENVVARid keywords, where id is a uniquenumeric value, including null and zero.

Use the following format, which is case sensitive:ENVVARid(environment variable name=value)

Where:

environment variable nameThe name of the environment variable.

value The value associated with the environment variable.

INTRACTV(YES|NO)Specifies if a Windows job runs interactively on the Windows desktop. Thiskeyword is valid only for jobs running on Windows Tivoli Workload Schedulerfor z/OS Agent workstations.

JOBCMD(EXECUTABLE|SCRIPT)The content of the job definition member. Valid values are:

SCRIPTThe job definition member contains the command or script to be run.

EXECUTABLEThe job definition member invokes the job that is to be run, which isstored locally on the Tivoli Workload Scheduler for z/OS Agentworkstation. If you did not set any value for the WRKDIR keyword,you must specify the fully qualified path to the job.



JOBUSR(user name)The user name for running the script or executable, if required.

If the user schedules jobs to run on Windows workstations, ensure that a userpassword is also defined (see the JOBPWD keyword). If you are defining aWindows domain user, use the following format:

Chapter 7. Using 49

||||

JOBUSR(domainName\user1)


PARMid(parameter)The parameter to be used when running the script or command. You canspecify a series of PARMid keywords, where id is a unique numeric value,including null and zero.

STDERROR(standard error file path)The fully qualified name of the file where the standard error must beredirected.

STDINPUT(standard input file path)The fully qualified name of the file to be used as standard input.

STDOUTPUT(standard output file path)The fully qualified name of the file to be used as standard output.

WRKDIR(working dir path)The fully qualified path to the directory where the script or command is to berun.


Examples

The following is an example of a JOBREC statement to invoke the scriptALLOCATE.BAT stored locally on the Tivoli Workload Scheduler for z/OS Agentworkstation://JOBRECWRKDIR(C:\)STDERROR(D:\MYDIR\ERROR.TXT)STDINPUT(D:\MYDIR\INPUT.TXT)STDOUTPUT(D:\MYDIR\OUTPUT.TXT)STDOUTPUT(D:\MYDIR\NEWT.TXT)JOBCMD(EXECUTABLE)PARM(300)PARM2(ELEMENT)//END JOBRECD:\MYDIR\ALLOCATE.BAT

The following is an example of a JOBREC statement to run the command DIR onthe directory C:\PROGRAM on the Tivoli Workload Scheduler for z/OS Agentworkstation://JOBRECWRKDIR(C:\PROGRAM)JOBCMD(SCRIPT)//END JOBRECDIR


|||||||

Scheduling on IBM iAbout this task

Using the IBM i job available in the Dynamic Workload Console, you can schedulejobs on IBM i. When scheduling on IBM i, consider the following points:v The native command can be either a system or a user command.v The native command can consists in a SBMJOB system command, that starts a

batch job.v The native command can start one or more batch jobs. The maximum number of

jobs that the IBM i agent can monitor is 130.

The batch jobs can be monitored only if they are started by the native command.

By default, all information about the running of the jobs is stored in the agentjoblog. To select the spool file types that you want include in the agent joblog, youcan use an option that works at IBM i agent level for any job to be submitted.

This option is based on the use of the IBM i system variable TWSASPOOLS. Itforces the IBM i agent to ignore any spool file or, at least, include one or more ofthem. On the IBM i agent, you must create a new system level environmentvariable named TWSASPOOLS and set it to the value NONE to ignore any spoolfile. Or, you can set it to a list of the spool file types that are to be included. Thelist must begin with the “SPOOLS:” token as described below.

To force the IBM i agent to ignore any spool file, you must create theTWSASPOOLS variable as follows.ADDENVVAR ENVVAR(TWSASPOOLS) VALUE(NONE) LEVEL(*SYS)

In this case, any agent joblog report for the IBM i agent is reduced to the activityreport that the Agent Monitor produces to trace its submitting and monitoringaction, and to the IBM i joblog of the Agent Monitor, that is always added at theend of the agent joblog.

To allow the IBM i agent to include only the QPRINT and the QPJOBLOG spoolfile types, that is, any spool files produced by “printf” instructions inside anyILE-C program and any produced joblog, you must create the TWSASPOOLS asfollows.ADDENVVAR ENVVAR(TWSASPOOLS) VALUE(’SPOOLS: QPRINT QPJOBLOG’) LEVEL(*SYS)

If the TWSASPOOLS variable already exists, change it as follows:CHGENVVAR ENVVAR(TWSASPOOLS) VALUE(’SPOOLS: QPRINT QPJOBLOG’) LEVEL(*SYS)

For any VALUE parameter set to an incorrect string, the IBM i agent will ignorethe TWSASPOOLS environment variable option. Both creation and change of theTWSASPOOLS environment variable can be done with the IBM i agent active, butwith no workload activity.

Issuing List requests by using the PIF and the BCITYou can use the Program Interface and the Batch Command Interface Tool to issuein user-written programs the following requests to Tivoli Workload Scheduler forz/OS:v With the PIF:

– List wscom

Chapter 7. Using 51

|

|

||

|

||

||

|

|||

||||||

||

|

||||

||||

|

|

|

||||

– Select wscomv With the BCIT:

– List cpwscom– List wscom– Select cpws– Select ws

For all these requests, use the argument WSZCENTR to filter for workstations of typez-centric: the value can be Y or N.

For more detailed information, refer to Tivoli Workload Scheduler for z/OS:Programming Interfaces.

Using variable substitutionThe variable substitution mechanism that is used in Tivoli Workload Scheduler forz/OS native job types works the same way when scheduling jobs on TivoliWorkload Scheduler for z/OS Agents.

The variable substitution mechanism changes when you define job types withadvanced options, such as Java jobs that run a Java class, or file transfer jobs thattransfer files to and from a server, to name a few. These types of jobs are createdand edited using the Dynamic Workload Console. When you define a variable forjob types with advanced options, the variable must be preceded by the $ (dollar)sign and enclosed in {} (curly brackets), as follows:${variable_name}

If you want to nest variables, use the following syntax:${variable_1_name ${variable_2_name}}

In this case, variable_2 is resolved first and provides the value for variable_1.

Dependent variables and promptable variables are not supported in job types withadvanced options.

For more information about variable substitution, see Tivoli Workload Scheduler forz/OS: Managing the Workload.

Defining file dependencies to check for file changesStarting from Tivoli Workload Scheduler version 8.5.1 Fix Pack 1, you can use thefilewatch utility to check for file system changes on files and directories, forexample, when you want to make sure that a file exists before running a job thatprocesses that file. By defining a job that runs the filewatch utility, you canimplement file dependency, that is, a relationship between a file and an operationin which specific activity on the file determines the starting of the operation.

The filewatch utility is automatically available for Version 8.6 Tivoli WorkloadScheduler for z/OS Agents and there is no need to install the utility.

For Version 8.5.1, Fix Pack 1Tivoli Workload Scheduler for z/OS Agents, install theutility as outlined in the following procedure.


|

|||

||||||

|

|

|

|

||

||

||

||

To install the filewatch utility, go to the TWS/op_sys/filewatch directory and enterthe following command (ensure you are connected as TWSuser):unzip -d dest_path filewatch.zip

where dest_path is the complete path where you installed the Tivoli WorkloadScheduler for z/OS Agent (by default, on UNIX is /opt/IBM/TWA/TWS, on Windowsis c:\Program Files\IBM\TWA\TWS).

Syntax

filewatch -v | -u | -?

filewatch -c[ondition] condval -f[ilename] file_path -dea[dline] deadline[-i[nterval] interval][-dat[abase] log_extension][-r[eturncode] rc][-t[race] trace level]

The arguments are not positional. You can use an abbreviated format for all thearguments. Generally you can truncate the arguments to any position following thefirst character, except for deadline and database that require at least threecharacters.

Arguments-v Returns the command version and exits.

-u Returns command usage information and exits.

-? Same as -u

-conditionThe condition to be checked. Valid values are:

wcr | waitCreatedWaits until the file exists. If the file already exists, filewatch exitsimmediately. If -filename argument specifies a directory, theprocess waits until the directory exists and contains a new file.

wmr | waitModificationRunningWaits until the file size or modification time changes. If -filenameargument specifies a directory, the process waits until the size orearlier file modification time changes, when a file is created,modified, or deleted.

wmc | waitModificationCompletedChecks that the file size or modification time stopped changing,meaning that filewatch waits for three search intervals without anychange. If -filename argument specifies a directory, the processchecks the size or the earlier file modification time change, forexample if the number of directory files and the earlier filemodification time does not change within three search intervals.

wmrc | waitModificationRunningCompletedWaits until the file size or modification time changes and stopschanging, meaning that, after the first change, filewatch waits forthree search intervals without any further change. If -filenameargument specifies a directory, the process checks the size or theearlier file modification time change, for example if the number of

Chapter 7. Using 53

directory files and the earlier file modification time does notchange within three search intervals.

wdl | waitDeleteStops running when the file is deleted. If -filename argumentspecifies a directory, the process waits until a file is deleted fromthe directory.

-filenameThe file path to be processed. You can embed blank or special characters,by using double quotes. Wildcard characters are not supported. To includemore files in the monitoring process, you can store those files in a specificdirectory and use a file path specifying that directory. When filewatch isused on a Windows server, and the file path specifies a directory, the pathname must not include a trailing forward slash "/" character.

-deadlineThe deadline period, expressed in seconds. The allowed formats are:v An integer in the range 0 to 31536000 (the upper value corresponds to

one year). To have filewatch performing an indefinite loop, specify 0.v hh:mm:ss, in the range 00:00:01 to 24:00:00, to select a time within the

same day when filewatch started.

-intervalThe file search interval, expressed in seconds. Specify an integer in therange:v 5–3600 when specifying wcr or wdl as condition value.v 30–3600 otherwise.

The default is 60.

-databaseOptional extension of the log database, that is the database wherefilewatch stores the file status. If you specify this value, filewatch updatesthe TWA_home/TWS/mozart/filewatchdb.log_extension database, otherwiseTWA_home/TWS/mozart/filewatchdb is updated.

For details about the log database, see “Maintaining the filewatch logdatabase” on page 55.

-returncodeThe exit return code, if the file is not found by the deadline. Specify aninteger in the range 0 to 256. The returncode value is ignored if youspecify 0 as deadline value. The default is 4.

-trace Trace level for internal logging and traces. Possible values are:

0 To receive error messages only.

1 Indicates the fine level, to receive the most important messageswith the lowest volume.

2 Indicates the finer level, to activate entry and exit traces.

3 Indicates the finest level, to receive the most detailed tracingoutput.

The default value is 0.

You find the trace output in the log of the job that run filewatch.


Maintaining the filewatch log databaseThe log database is used to store filewatch activity data. This log is located in theTWA_home/TWS directory. The default name is filewatchdb. When processing a file,filewatch uses it to store records with information about:v File name.v File status. The allowed values are Exist, Created, Running, Completed,

RunningCompleted, or Deleted.v Date and time of file creation at the entry update time.v Date and time of the last file modification at the entry update time.v Date and time of the last entry update.

Note: The log contains only one entry for each file.

To maintain the log database, use the filewatchdb utility.

Syntax

filewatchdb -v | -u | -?

filewatchdb -c[ondition] condval[-f[ilename] file_path[-d[atabase] log_extension][-r[eturncode] rc]

The arguments are not positional. A detailed description follows.

Arguments-v Returns the command version and exits.

-u Returns command usage information and exits.

-? Same as -u

-conditionThe condition to be checked. Valid values are:

bld| buildRebuild the log database.

dlt | deleteDelete the log database record corresponding to the filenameargument value.

gls | getLastStatusChange

Gets and returns the log database record corresponding to thefilename argument value.

-filenameUse this argument to delete the entry corresponding to the specified value.You can embed blank or special characters, by using double quotes. Use *as wildcard character. This argument is required if you specify dlt (delete)or gls (getLastStatusChange) as condition value.

-databaseOptional extension of the log database to be accessed. If you specify thisvalue, filewatchdb accesses the TWA_home/TWS/filewatchdb.log_extensiondatabase, otherwise TWA_home/TWS/filewatchdb is accessed.

Chapter 7. Using 55

Usage Notes®

To run the filewatch utility you can use variable substitution, which occurs when:v The controller submits the job associated to a JOBLIB member. For details about

the scheduler job tailoring, see Tivoli Workload Scheduler for z/OS: Managing theWorkload.

v The Tivoli Workload Scheduler for z/OS Agent submits the job. For detailsabout submitting a job, see “Defining a job in the JOBLIB data set” on page 30.

Managing the status of the Tivoli Workload Scheduler for z/OS Agentworkstation in the plan

Use the WSSTAT command when you want to:v Change the status of a Tivoli Workload Scheduler for z/OS Agent workstation in

the current plan.v Verify if the communication between the Tivoli Workload Scheduler for z/OS

Agent workstation and the controller is active.

You use WSSTAT on Tivoli Workload Scheduler for z/OS Agents in the same wayas you do with any other computer automatic workstation.

The status information is communicated to the controller to indicate that aworkstation is in one of the following states:

ACTIVEThe workstation is running and scheduling its own plan.

OFFLINECommunication is lost between the controller and the Tivoli WorkloadScheduler for z/OS Agent workstation on the system that the workstationrepresents. The HTTP client retries to establish the connection until it issuccessful.

FAILEDYou manually set the workstation status to FAILED.

When you run the WSSTAT command, you can optionally define restart androuting options for the workload defined on the workstation when you arereporting a status of OFFLINE or FAILED.

You can invoke WSSTAT as a TSO command or by using a batch job which runsprogram EQQEVPGM. If you invoke WSSTAT as a TSO command, you mustallocate the EQQMLIB data set to the address space of the TSO user, either byadding DD statements to the logon procedure, or by using the ALLOC commandafter TSO logon. In the TSO environment, error messages and trace records aresent directly to the terminal user. Messages are not delivered to indicate successfulcommand execution.

Use of the WSSTAT command can be restricted with fixed resource code RL andsubresource RL.WSSTAT. The authority of the requestor is verified by thesubsystem name identified in the command if an AUTHDEF statement is definedfor that subsystem. When SUBSYS(MSTR) is specified, all tracker subsystemsdefined on the z/OS system where the WSSTAT command is issued attempt toverify the authority of the requestor before an event is generated. A requestormight be rejected by one subsystem and accepted by another.


The subsystem to which you direct the command need not be active when thecommand is issued. An event is generated and queued in CSA together with otherjob-tracking events. If the subsystem is not active when the command is issued, theauthority of the requestor is verified using the class name specified in theAUTHDEF statement when the subsystem was last started. If the subsystem hasnot been started since a z/OS IPL, no authority verification can be performed.

Note: If you used the panels to set the status of a workstation to OFFLINE, youcannot reset it to ACTIVE with WSSTAT.

Automatic and manual changes to the status of the TivoliWorkload Scheduler for z/OS Agent workstation

At startup, the controller does not establish a connection with a Tivoli WorkloadScheduler for z/OS Agent workstation until the first job is submitted on that TivoliWorkload Scheduler for z/OS Agent. The workstation status is automatically set toACTIVE with extended status Waiting for first submission. When the first job issubmitted, the communication between the controller and agent is opened and theworkstation is set to ACTIVE.

You can manually change the Tivoli Workload Scheduler for z/OS Agentworkstation status in the following ways:v From ACTIVE to OFFLINE.v From ACTIVE, Waiting for first submission to ACTIVE. This operation is also

useful to check if the communication between the controller and the agent isestablished.

v From OFFLINE to ACTIVE.

You cannot set the agent workstation to ACTIVE, if it was set to OFFLINEautomatically. In this case, message EQQWL17W is issued:WORK STATION WSNAME CANNOT BE VARIED TO ACTIVE STATUS.A QUERY AGENT INFO REQUEST HAS BEEN SENT TO THE AGENT AT DESTINATION DEST.

and the controller tries to establish a connection with the Tivoli WorkloadScheduler for z/OS Agent. If the attempt is successful, the workstation status is setto ACTIVE by the controller.

WSSTATFormat

�� WSSTATALTWS ( alternate workstation name )

�

�REROUTE ( R )

LSTARTOPR ( R )

LE

STATUS ( A )OF

�

�OPCA

SUBSYS ( subsystem name )MSTR

0TRACE ( trace level )

�

� WSNAME ( workstation name ) ��

Chapter 7. Using 57

|

Note: These are the only WSSTAT parameters that apply to the Tivoli WorkloadScheduler for z/OS Agent workstation. For a complete list of the WSSTATparameters, see Tivoli Workload Scheduler for z/OS: Managing the Workload.

Parameters

ALTWS (alternate workstation name)When the workstation status is set to OFFLINE or FAILED, you can specifythe alternate workstation on which to start reroutable operations.

If you omit this parameter, the value defined for the current workstationopen interval is used. If the REROUTE parameter specifies L, or if thedefault specifies no rerouting, the value of ALTWS is ignored.

The parameter is optional.

REROUTE (R | L)When the workstation status is set to OFFLINE or FAILED, you can specifyR for operations to be rerouted to the alternate workstation, or L for norerouting (to leave the operations on the inactive workstation).

If you omit this parameter, the value defined in either the WSOFFLINE orthe WSFAILURE keyword on the JTOPTS initialization statement is used asthe default.


STARTOPR (R | E | L)When the workstation status is set to OFFLINE or FAILED, you can specifywhat the scheduler must do with operations that are currently in startedstatus at the workstation, where:R Restart operations automatically on the alternate workstation.E Set all started operations to ended-in-error.L Leave the operations in started status.

If you omit this parameter, the value defined in either the WSOFFLINE orthe WSFAILURE keyword on the JTOPTS initialization statement is used asthe default.


Note: If you select STARTOPR(E), a started job continues to run, becauseTivoli Workload Scheduler for z/OS never cancels jobs that havestarted.

STATUS (A | O | F)The status you want to report for the workstation:A ActiveO OfflineF Failed

You must specify either STATUS or one of the alternative parameters.

SUBSYS (subsystem name | MSTR | OPCA)The name of the tracker subsystem that WSSTAT is directed to. Thisparameter can be up to 4 characters long. The first character must bealphabetic while the remaining characters must be alphanumeric. Alllowercase characters are converted to uppercase.

If you specify MSTR, the command is directed to all tracker subsystems onthe z/OS system on which the command is issued.


Note: If the tracker and controller in your configuration run on differentsubsystems, specify the name of the tracker subsystem in thisparameter.

TRACE (level | 0)The event tracing indicator. When any nonzero positive number isspecified, a trace entry is created for each event generated by WSSTAT. Thetrace record is written to the message log file identified by ddnameEQQMLOG. The record identifies the name of each receiving subsystem.The default value 0 does not generate trace records.

WSNAME (workstation name)The name of the workstation to be updated. You must specify thisparameter.

The WSSTAT parameters are checked for validity and consistency. The validitychecks are performed on the tracker where the command is run. The validity checkprocesses parameter names, and length and type of parameter values.

If the input is valid, a workstation status event is generated and communicated tothe controller. Processing of the event includes a consistency check of the valuesspecified in the parameters. The following consistency checks are made:v The workstation name exists.v The alternate workstation exists.v If the value given in the STATUS parameter is the same as the current status of

the workstation, the command is ignored.

Examples

The following two examples show how you can use WSSTAT in TSO, or in a batchjob (using the batch program EQQEVPGM).

Example 1 - TSO commandALLOC F(EQQMLIB) DA(’OPC.MESSAGE.LIBRARY’) SHR REUSE

WSSTAT SUBSYS(OPCB) WSNAME(AS4H) STATUS(O) START(R)

In this example, the status of workstation AS4H is set to OFFLINE. Startedoperations are restarted on the alternate workstation.

Example 2 - Batch job//CHSTATUS JOB (ACCOUNT),’Change WS status’,CLASS=A//STEP1 EXEC PGM=EQQEVPGM//STEPLIB DD DSN=OPC.LOAD.MODULE.LIBRARY,DISP=SHR//EQQMLIB DD DSN=OPC.MESSAGE.LIBRARY,DISP=SHR//EQQMLOG DD SYSOUT=A//SYSIN DD *WSSTAT SUBSYS(OPCB) WSNAME(AS4H) STATUS(A)/*

In this example, the status of workstation AS4H is set to ACTIVE.

Chapter 7. Using 59

Browsing system information of Tivoli Workload Scheduler for z/OSAgent workstations

You can view the system information of a Tivoli Workload Scheduler for z/OSAgent workstation by entering the I row command in the following panels:v Modifying Workstations in the Current® Plan (EQQMWSLL)v Browsing Summary of Activities at a Workstation (EQQSWSSP)

Figure 11 shows what type of information is provided in the panel.

Killing Tivoli Workload Scheduler for z/OS Agent operationsThe kill action ends an operation in the current plan that has already started. Youcan kill a running Tivoli Workload Scheduler for z/OS Agent operation from anyof the following interfaces:v “ISPF”v “PIF” on page 61v “BCIT” on page 61v “OCL” on page 61v “Dynamic Workload Console” on page 61

This action can be taken only on STARTED operations that are in the EXECUTINGstatus, so that their job ID is known.

The operation number (except for the OCL instructions where the applicationnumber is the required parameter) is required to identify the operation that is to bekilled.

ISPFAbout this task

To kill a Tivoli Workload Scheduler for z/OS Agent operation, perform thefollowing steps:

EQQSWIZC -------- BROWSING TWSZ Z-CENTRIC SYSTEM INFORMATION -------Command ===>

Work station : LWE1 Accts ReceivableDestination : ITAAC1 HTTPCode page : IBM-037Hostname : AR11.ZAPHOD.COMPort number : 44112

System Information:Operating system name : WINDOWSOperating system level:Agent version : 8.6Agent fixpack level : 0

Default JOBREC valuesJOBUSR : user01 User nameJOBPWD : Y Password (Y/N)JOBTYPE : accessmeth1 Access Method

Figure 11. EQQSWIZC - Browsing a Tivoli Workload Scheduler for z/OS Agent workstation system information


||||||||||||||||||||||

1. Select option 3 (OPERATIONS) from the Modifying the Current Plan panel (fastpath 5.3).

2. Specify the list criteria for the operation you want to kill.You see the Modifying Operations in the Current Plan panel (EQQMOPRL).This panel lists the operations in the current plan that fulfill the list criteria youspecified.

3. Enter the K (Kill) row command next to the row that lists the operation.

The Tivoli Workload Scheduler for z/OS Agent notifies the controller when theoperation is killed.

PIFTo kill a Tivoli Workload Scheduler for z/OS Agent operation, use the followingrequest:MODIFY CPOP OPNO=operation_number OPCMD=KJ


BCITTo kill a Tivoli Workload Scheduler for z/OS Agent operation, use the followinginstruction:ACTION=MODIFY,RESOURCE=CPOP,OPNO=operation_number,OPCMD=KJ


OCLTo kill a Tivoli Workload Scheduler for z/OS Agent operation, use the followinginstruction:KILLJOB APPL(application_number) OPNO(operation_number)

For more detailed information, refer to Tivoli Workload Scheduler for z/OS:Programming Interfaces .

Dynamic Workload ConsoleAbout this task

To kill a Tivoli Workload Scheduler for z/OS Agent operation, perform thefollowing steps:1. Click Tivoli Workload Scheduler for z/OS→Workload→Monitor→Monitor Jobs.2. Select All Jobs in plan or another predefined task name.3. Choose an engine name, or specify connection properties, and click OK.4. Select a job and click More Actions→Kill.

Chapter 7. Using 61

Chapter 8. Job monitoring and recovering

This chapter contains the following sections:v “Tivoli Workload Scheduler for z/OS Agent job status notifications”v “Setting up and running automatic recovery for Tivoli Workload Scheduler for

z/OS Agent jobs”

Tivoli Workload Scheduler for z/OS Agent job status notifications

Notifications about the change of status of running jobs are returned to the HTTPserver subtask by the Tivoli agent. Table 7 shows the possible status changes forjobs running on Tivoli Workload Scheduler for z/OS Agents.

Table 7. Job status change notifications

Notification New operation status Explanation

Submitted (POST executed) S Post executed (from localHTTP client)

Submitted S Agent launched the job

Canceled E (+ CAN) Job canceled by command

Executing S Job started execution

Failed_Execution E (+ error code) Job ended in error

Succeeded_Execution C Job completed successfully

Failed_Submission E (+ OSUB) Job submission failed

Unknown_Execution E (+ CCUN) Agent lost track of the job

Setting up and running automatic recovery for Tivoli WorkloadScheduler for z/OS Agent jobs

Tivoli Workload Scheduler for z/OS supports the use of automatic recoverystatements in Tivoli Workload Scheduler for z/OS Agent scripts.

When you create or edit a Tivoli Workload Scheduler for z/OS Agent script, startthe lines where you specify the automatic recovery statements with //* OPC,//*%OPC, or //*>OPC. These lines are removed before the script is downloaded ontothe Tivoli Workload Scheduler for z/OS Agents.

You can run the following recovery actions on Tivoli Workload Scheduler for z/OSAgent jobs:v Restart the current occurrence at the failed operation, with or without JCL

changes.v Restart the current occurrence at another operation.v Add occurrences of special recovery applications. Make the restart of the failed

occurrence dependent on the completion of the recovery occurrences.v Release a dependent occurrence.

Data set cleanup is not available.


Automatic-recovery-control statement for Tivoli WorkloadScheduler for z/OS Agent scripts

Each automatic-recovery-control statement describes an error situation and therecovery actions for it.

Use these rules to code RECOVER statements:v Each statement must begin in a new 80-byte logical record.

The symbols //*%OPC must appear in bytes 1 to 7 and be followed by at leastone blank.//*%OPC RECOVER

Identifies a RECOVER statement//*%OPC

Identifies a RECOVER continuation statementThe automatic recovery function also inserts informational statements in the JCL://* OPC

Identifies a message statement//*>OPC

Identifies a comment statementv You cannot use variables anywhere in the RECOVER statement.v The parameters are optional; you can code them in any sequence.v Each parameter consists of a keyword followed by an equals sign and variable

information.v Parameters are separated by commas.v You cannot code the same keyword more than once on the same statement.v If you code only one parameter value, you do not need to enclose it in

parentheses; for example, JOBCODE=PCHK.v Bytes 72 to 80 are ignored by the automatic recovery function.v When the total length of fields on a control statement exceeds 71 bytes, continue

the statement using the following continuation conventions:– Interrupt the field after a complete or partial parameter, including the comma

that follows it, before byte 72.– Code the identifying continuation characters //*%OPC followed by at least one

blank in bytes 1 to 7 of the statement that follows.– Continue the interrupted operand in any position from bytes 9 to 16.

v Limit the RECOVER statement to one card (avoid continuation).

RECOVER statement syntax

The syntax of the RECOVER statement follows. These are the only RECOVERparameters that apply to the Tivoli Workload Scheduler for z/OS Agentworkstation. For a complete list of the RECOVER parameters, see Tivoli WorkloadScheduler for z/OS: Managing the Workload.


�� //*%OPC RECOVER �

�

�

�

.,

,

JOBCODE =( abendcode )casecodereturncodereturncode1–returncode2

TIME =( hhmm-hhmm )CALLEXIT =( program name )

YRESTART =( YES )

NNO

RESJOB =( job name ),

ADDAPPL =( application name ),

RELSUCC =( application name )ALTWS =( workstation name )

��

Statement parameters

All the parameters for the RECOVER statement are optional. For Tivoli WorkloadScheduler for z/OS Agent jobs, the following are the available RECOVERstatement categories: selection and recovery action.

Selection parameters:

These selection parameters specify the error situations that the RECOVERstatement manages:

JOBCODERestricts the RECOVER statement to be valid only for those job completioncodes and return codes specified.

TIME Restricts the RECOVER statement to be valid only in the time rangespecified.

Note: Review the EXCLUDECC and EXCLUDERC keywords of theAROPTS statement, which specify codes for which no automaticrecovery is done. For information about the AROPTS statement, seeTivoli Workload Scheduler for z/OS: Customization and Tuning.

Recovery action parameters:

The following recovery action parameters specify the actions to take for recovery:

RESTARTSpecifies if the occurrence is to be restarted.

RESJOBSpecifies the name of the job from which the occurrence must be rerun.

ADDAPPLSpecifies an application or a list of applications to be added as occurrencesin the current plan.

Chapter 8. Job monitoring and recovering 65

RELSUCCSpecifies the application ID of a successor occurrence, or a list of IDs.

ALTWSSpecifies the name of an alternate workstation on which to run theoperation.

Selection parameters

When a job ends in error, this information is available:v Job namev Abend code, if job abendedv Return code, if job did not abend

The selection parameters use this information:

JOBCODEThe code can be an abend code, an error code set by Tivoli WorkloadScheduler for z/OS or JCC, a case code, a return code, or a return coderange. The values are those given as the error code on the HandlingOperations Ended in Error panel in the Modify Current Plan panel.

The JOBCODE keyword values are:

Sxxx Specifies a system abend code.

Uxxx Specifies a user abend code.

xxxx Specifies a case code or an error code set by Tivoli WorkloadScheduler for z/OS, either directly or by using the job completionchecker.

n Specifies a return code.

x-y Specifies a return code range, where x and y represent positivedecimal values.

The codes specified in the JOBCODE parameter are tested against the jobcode as set by Tivoli Workload Scheduler for z/OS when the job ends.

You can also specify abend codes in generic form. Therefore, an asterisk (*)can represent any character, or any group of characters, in those positionswhere it is placed. A code can contain more than one asterisk only if eachasterisk is separated from the next by another character.

Note: The JOBCODE=* notation covers all possible user and system abendcodes; it does not cover return codes. To cover all possible returncodes, specify a return code range in the form:JOBCODE=x-y

where x and y represent positive decimal values.

A return code cannot be greater than 4095. To specify a range of values, setx to the lower value and y to the higher value. To specify all return codesgreater than or equal to a certain value, set x to that value and y to 4095.

TIME The time is specified in the form hhmm, where hh is the hour from 00 to 24,and mm is the minute from 00 to 60. This is the time when the recovery isautomatic.

For example:


TIME=0700-1600No recovery actions occur between 4 p.m. and 7 a.m.

TIME=2200-0800Tivoli Workload Scheduler for z/OS does automatic recovery onlybetween 22.00 and 8.00.

TIME=0000-2400Recovery can be automatic at any time.

TIME=0000-0000Recovery is not started unless there is manual intervention.

The recovery actions for a job that remains in the ended-in-error list can bemanually started up later. Such requests override any TIME valuespecified.

Default: The recovery specification is for the time range specified by theSTARTIME and ENDTIME keywords of the AROPTS automatic recoveryoptions statement. Refer to Tivoli Workload Scheduler for z/OS: Customizationand Tuning for more details.

Action parameters

The following parameters specify the action that Tivoli Workload Scheduler forz/OS must take when the recovery statement is invoked.

RESTARTRESTART=Y causes the job to be rerun, either from the failing operation or,if you specified RESJOB, from an earlier operation within the occurrence.

RESTART=N prevents the restart. It can be used with ADDAPPL when therecovery actions are to be done by a separate application. It can also beused to select cases for which no recovery should be performed or whentesting the recovery procedure. The operation remains in ended-in-errorstatus.

Default: RESTART=Y.

RESJOBThe RESJOB parameter handles failures at an occurrence level, not withinthe failing job itself.

The occurrence of the application is rerun from the first precedingcomputer workstation operation, whose name matches the job namespecified in the RESJOB parameter. If the job name specified cannot befound in a computer operation preceding the failed operation in the sameoccurrence, no automatic recovery occurs and the job remains in the errorhandling list with an extended status code indicating an automaticrecovery error.

The indicated operation must be a predecessor to the failed operation or bethe failed operation itself.

Note: External successors cannot be handled automatically. Therefore theset of operations selected for rerun that can be completed at failuretime must not have any external successors.

The rerun operation must be defined on an automatically reportingcomputer workstation.

The parameter is ignored if RESTART=N is specified.


Default: Rerun from the failed operation.

ADDAPPLHere you specify a list of applications. Occurrences of these applicationsare added to the current plan if this RECOVER statement is invoked.v If RESTART=N is specified, the applications are independent of the

failed occurrence.v If RESTART=Y is specified, the recovery applications are added to the

current plan as predecessors to the failing operation or, if RESJOB isspecified, to the operation where restart is being attempted.

Added applications are independent of each other. A maximum of 40application occurrences can be added.

For example, suppose a database update fails. A rerun of the failed job isnecessary but must be postponed to a later time. However, a databaserestore job must be run to repair the database before the online usersrequire the database. This recovery situation can be specified as://*%OPC RECOVER JOBCODE=SCHK,RESTART=N,ADDAPPL=A301RORG

This means that, on case code SCHK, do not rerun the failing operation.However, add an occurrence of the application A301RORG to the currentplan, without a dependency to the failing operation and leave the failingoperation in ended-in-error status.

Default: No application occurrences are added.

Note:

1. When automatic recovery adds an occurrence to the current plan,input arrival and deadline times are not taken from theapplication description. Instead the occurrence is given an inputarrival of the time the add is run, according to the time on thez/OS system where the controller is started and the deadline isset for 8 hours after input arrival. If an occurrence of thatapplication already exists with this input arrival time, then oneminute is added to the time until a time is reached when theoccurrence can be included. If the added occurrence includestime-dependent operations with specific input arrival times, thenthe operations are started at the specified time.

2. An occurrence that has been added to the current plan byautomatic job recovery does not become the predecessor to anoccurrence that is added later by daily planning, even if normaldependency criteria are met.

RELSUCCThis parameter specifies which external successors to the failing operationare allowed to run even if their predecessor operation has ended in error.

The external successors to the failing operation are checked, and thedependencies between the failed operation and the specified successors aredeleted at recovery time.

The effect is that this predecessor (the failed operation) is reported ascomplete to the external successor, and the successor-predecessor chainingis removed. The external successor becomes ready if its other predecessorsare completed. The dependency does not exist when the failed occurrenceis rerun.


Even if one successor is released, other successors might be waiting for thefailed occurrence to complete. These might be successors not yet in thecurrent plan. Assume that W is a weekly application and D is a dailyapplication that is dependent on W. If W fails and there is a RECOVERstatement causing the release of that day's D, the occurrence of D the nextday also waits for W to complete, but without any automatic release.

You can specify a maximum of 40 application IDs.

Default: None.

ALTWSSpecifies the name of an alternate workstation on which to run theoperation. The ALTWS parameter overrides the alternate workstationdefined in the workstation description. You can use this parameter, forexample, with the TIME parameter to specify alternate workstations for anoperation, depending on the time of day.

Default: None.


Appendix A. Configuring to schedule J2EE jobs

To schedule J2EE jobs, complete the following configuration tasks:v Configure the J2EE executor on every Tivoli Workload Scheduler for z/OS Agent

where you want to submit J2EE jobs.v Configure the J2EE Job Executor Agent on an external WebSphere Application

Server

Configuring the J2EE executorTo be able to dynamically schedule J2EE jobs, you must configure the followingproperty files on every Tivoli Workload Scheduler for z/OS Agent where you wantto submit J2EE jobs:v J2EEJobExecutorConfig.properties

v soap.client.props

These files are configured with default values at installation time. The followingsections describe the values you can customize.

J2EEJobExecutorConfig.properties file

The J2EEJobExecutorConfig.properties file is located on the Tivoli WorkloadScheduler for z/OS Agent, under TWA_home/TWS/JavaExt/cfg.

Table 8 shows a description of the file keywords.

Table 8. J2EEJobExecutorConfig.properties file keywords

Keyword Specifies... Default value Must be customized

wasjaas.default The path to the IBMWebSphere configuration file(wsjaas_client.conf) usedto authenticate on theexternal WebSphereApplication Server usingJAAS security.

TWA_home/TWS/JavaExt/cfg/wsjaas_client.conf orTWA_home\TWS\JavaExt\cfg\wsjaas_client.conf

Optionally yes, if youmove the file to the pathyou specify.

credentials.mycred The credentials (ID andpassword) used to establishthe SOAP connection to theexternal WebSphereApplication Server whenusing indirect scheduling(the password must be {xor}encrypted)

wasadmin,{xor}KD4sPjsyNjE\=

(ID=wasadmin andpassword=wasadmin in {xor}encrypted format)

Yes, see “Running {xor}encryption on yourpassword” on page 73 tolearn how to encrypt yourpassword.


Table 8. J2EEJobExecutorConfig.properties file keywords (continued)


connector.indirect The name of thecommunication channel withWebSphere ApplicationServer. Selecting an indirectinvoker means that dynamicworkload broker leveragesan existing WebSphereApplication Serverscheduling infrastructurealready configured on atarget external WebSphereApplication Server. Whencreating the job definition,you can specify whether youwant to use a direct orindirect connector in theJ2EE Application pane inthe Application page in theJob Brokering DefinitionConsole, or in the invokerelement in the JSDL file. Formore information about theJob Brokering DefinitionConsole, see the online help.

A single line with the followingvalues separated by commas:

v indirect keyword

v Name of the scheduler:

sch/MyScheduler

v soap keyword

v Host name of the externalWebSphere Application Serverinstance:

washost.mydomain.com

v SOAP port of the WebSphereApplication Server instance:

8880

v Path to the soap.client.propsfile:

TWA_home/TWS/JavaExt/cfg/soap.client.props

v Credentials keyword:

mycred

You must customize thefollowing:

v The scheduler name.Replace thesch/MyScheduler stringwith the JNDI name ofthe IBM WebSpherescheduler you plan touse.

v The host name of theexternal WebSphereApplication Serverinstance.

v The SOAP port of theexternal WebSphereApplication Serverinstance.

connector.direct The name of the directcommunication channelwithout using theWebSphere ApplicationServer scheduler. Selecting adirect invoker means thatdynamic workload brokerimmediately forwards thejob to the externalWebSphere ApplicationServer instance component(JMS). When creating the jobdefinition, you can specifywhether you want to use adirect or indirect connectorin the J2EE Applicationpane in the Applicationpage in the Job BrokeringDefinition Console, or in theinvoker element in the JSDLfile. For more informationabout the Job BrokeringDefinition Console, see theonline help.

A single line with the followingvalues separated by commas:

v direct keyword

v The following string:

com.ibm.websphere.naming.WsnInitialContextFactory

v The following string:

corbaloc:iiop:washost.mydomain.com:2809

You must customize thefollowing:

v The host name of theexternal WebSphereApplication Serverinstance:washost.mydomain.com

v The RMI port of theexternal WebSphereApplication Serverinstance: 2809

trustStore.path The path to the WebSphereApplication Server trustorefile (this file must be copiedto this local path from theWebSphere ApplicationServer instance).

TWA_home/TWS/JavaExt/cfg/DummyClientTrustFile.jks

You can change the path(TWA_home/TWS/JavaExt/cfg), provided youcopy the trustore pathfrom the externalWebSphere ApplicationServer to this path.


Table 8. J2EEJobExecutorConfig.properties file keywords (continued)


trustStore.password The password for theWebSphere ApplicationServer trustore file.

WebAs Yes

Running {xor} encryption on your passwordAbout this task

To {xor} encrypt your password, use the PropFilePasswordEncoder commandlocated in the WAS_home/bin directory of the external WebSphere ApplicationServer.

Follow these steps:1. Open a new text file and write the following line:

string=your_password_in_plain_text

2. Save the file with a file_name of your choice.3. Run PropFilePasswordEncoder as follows:

PropFilePasswordEncoder file_name string

where:

file_nameIs the name of the file with your password.

string Is the string you used in the text file. This can be any word you choose;for example, password, mypwd, joe, and so on.

4. When the command completes, open the text file again. The content haschanged to:string={xor}your_encrypted_password

5. Copy your encrypted password, inclusive of the {xor} characters, and paste itwhere required onto your property files.

For example, you want to encrypt your password catamaran. Proceed as follows:1. Open a text file and write the following:

mypasswd=catamaran

2. Save the file with name encrfile.txt.3. Run:

PropFilePasswordEncoder encrfile.txt mypasswd

4. Open encrfile.txt. You find:mypasswd={xor}PD4rPjI+LT4x

5. Copy {xor}PD4rPjI+LT4x and paste it where you need to.

The soap.client.props file

The soap.client.props file is located on the Tivoli Workload Scheduler for z/OSAgent, under TWA_home/TWS/JavaExt/cfg/soap.client.props.

Following installation, this file is as follows:#------------------------------------------------------------------------------# SOAP Client Security Enablement#

Appendix A. Configuring to schedule J2EE jobs 73

# - security enabled status ( false[default], true )#------------------------------------------------------------------------------com.ibm.SOAP.securityEnabled=false

com.ibm.SOAP.loginUserid=wasadmincom.ibm.SOAP.loginPassword={xor}KD4sPjsyNjE\=

#------------------------------------------------------------------------------# SOAP Login Prompt## The auto prompting will happen only if all of the following are met:## - Running from a SOAP client# - Server is reachable and server security is enabled# - Username and password are not provided either on command line or in this# file# - com.ibm.SOAP.loginSource below is set to either "stdin" or "prompt"## stdin: prompt in command window# prompt: GUI dialog box; falls back to stdin if GUI not allowed## (So to disable auto prompting, set loginSource to nothing)#------------------------------------------------------------------------------com.ibm.SOAP.loginSource=prompt

#------------------------------------------------------------------------------# SOAP Request Timeout## - timeout (specified in seconds [default 180], 0 implies no timeout)##------------------------------------------------------------------------------com.ibm.SOAP.requestTimeout=180

#------------------------------------------------------------------------------# SSL configuration alias referenced in ssl.client.props#------------------------------------------------------------------------------com.ibm.ssl.alias=DefaultSSLSettings

To enable SOAP client security, follow these steps:1. Change com.ibm.SOAP.securityEnabled to true.2. Customize:

v com.ibm.SOAP.loginUserid with the true WebSphere Application Serveradministrator userid.

v com.ibm.SOAP.loginPassword with the true WebSphere Application Serveradministrator password in {xor} encrypted format. See “Running {xor}encryption on your password” on page 73.

Configuring the J2EE Job Executor AgentTo set up the environment on the external WebSphere Application Server, Version7.0, for the J2EE Job Executor Agent, perform the tasks in this section.

Create a Service Integration BusAbout this task1. Open the WebSphere Administrative Console (for example,

http://localhost:9060/admin, depending on the admin port you configured).2. Expand Service Integration and select Buses. The Buses panel is displayed.3. Click New to display the Buses configuration window.


4. Type a name for the new bus, for example MyBus, click Next, then Finish toconfirm. Now click on the MyBus name to display the MyBus properties.Under Topology, click Bus Members. The Buses>MyBus>Bus members panel isdisplayed.

5. Click Add, select the Server radio button, chooseyour_application_server_name, click Next, then click Finish.

6. When the Confirm the addition of a new bus member panel is displayed, clickFinish.

7. Select Service Integration → Buses → MyBus → Destinations → New.8. Select Queue as the type, and click Next

9. Type BusQueue as the identifier and assign the queue to a bus member. Thenclick Next. In the confirmation panel, click Finish.

Configure the Default Messaging ServiceAbout this task1. From the left panel of the WebSphere Administrative Console, expand

Resources→ JMS→ JMS Providers, then click Default messaging at the serverlevel as scope.

2. In the Connection Factories section, click New.3. On the New JMS connection factory panel, fill in the following fields:

Name MyCF

JNDI namejms/MyCF

Bus nameMyBus

Provider endpointshostname:Basic_SIB_port_number:BootstrapBasicMessaging;hostname:Secure_SIB_ port_ number:BootstrapSecureMessaging

where the Basic_SIB_port_number and Secure_SIB_port_number can befound by expanding Servers, then selectingyour_application_server_name, then selecting Messaging engineinbound transports under the Server Messaging heading.

4. Select again Resources → JMS → JMS Providers → Default Messaging at theserver level as scope, locate the section Destinations and click on Queues.Click New and fill in the fields as follows:Name=MyQueueJNDI name=jms/MyQueueBus name=MyBusQueue name=BusQueue

Click OK.5. Select again Resources → JMS → JMS Providers → Default Messaging at the

server level as scope, and locate the section Activation Specifications.6. Click JMS activation specification. Click New and fill the fields as follows:

Name=MyActSpecJNDI name=eis/MyActSpecBus name=MyBusDestination type=QueueDestination JNDI name=jms/MyQueue

Click OK.

Appendix A. Configuring to schedule J2EE jobs 75

Configure the Java securityAbout this task1. Select Security → Secure Administration, applications and infrastructure.2. Locate the Authentication section, expand the Java Authentication and

Authorization Service, and click J2C authentication data.3. Click New and fill the following fields as follows:

Alias=usrUser ID=usrPassword=pwd

where usr is the user ID authenticated when using connector security and pwdis the related password.

4. Click OK.

Create an XA DataSourceAbout this task1. In the left panel, go to Resources → JDBC..→ JDBCProviders. In the resulting

right panel, check that the scope is pointing to your_application_server_name.2. Locate the DERBY JDBC Provider (XA) entry and click it.3. Locate the Additional Properties section and click Data Sources.4. Click on New and fill in the fields as follows:

Name=MyScheduler XA DataSourceJNDI name=jdbc/SchedulerXADSDatabase name=${USER_INSTALL_ROOT}/databases/Schedulers/${SERVER}/SchedulerDB;

create=true

5. On top of the page, click the Test connection button.6. Even if you get a negative result, modify the Database name field, deleting the

part ;create=true. Click OK.

Create a WorkManagerAbout this task1. In the left panel, go to Resources → Asynchronous beans → Work managers and

click New.2. Fill in the fields as follows:

Name=SchedulerWMJNDI name=wm/SchedulerWM

3. Click OK.

Create and configure a schedulerAbout this task1. In the left panel, go to Resources → Schedulers and click New.2. Fill in the fields as follows:

Name=MySchedulerJNDI name=sch/MySchedulerData source JNDI name=jdbc/SchedulerXADSTable prefix=MYSCHEDWork managers JNDI name=wm/SchedulerWM

3. Click OK.4. Select MyScheduler and click Create tables.5. Deploy the test application.


Appendix B. Security order of precedence used for theexecution of J2EE tasks

There are three ways of verifying that a task will run with the correct usercredentials. Tasks run with specified security credentials using the followingmethods:1. Using the Java Authentication and Authorization Service (JAAS) security

context on the thread at the time the task was created.2. Using the setAuthenticationAlias method on the TaskInfo object.3. Using a specified security identity on a BeanTaskInfo task TaskHandler method.

The authentication methods are sorted in the order listed above, so that if anauthentication method succeeds, the following checks are ignored. This means thatthe usr and pwd credentials defined in Configure the Java security win over anycredentials specified in the tasks themselves.


Appendix C. Configuring to schedule job types with advancedoptions

About this task

In addition to defining job types with advanced options using the DynamicWorkload Console or the JOBREC statement, you can use the related configurationfiles. The options you define in the configuration files apply to all job types withadvanced options of the same type. You can override these options when definingthe job using the Dynamic Workload Console or the JOBREC statement.

Configuration files are available on each dynamic agent in TWA_home/TWS/JavaExt/cfg for the following job types with advanced options:

Table 9. Configuration files for job types with advanced options

Job type File name Keyword

v Databasejob type

v MSSQLJob

DatabaseJobExecutor.properties Use the jdbcDriversPath keyword to specify the pathto the JDBC drivers. Define the keyword so that itpoints to the JDBC jar files directory, for example:

jdbcDriversPath=c:\\mydir\\jars\\jdbc

The JDBC jar files must be located in the specifieddirectory or its subdirectories. Ensure you have listpermission for the directory and its sub subdirectories.Note: The MSSQL database requires version 4 of theJDBC drivers for both Database and MSSQL Job jobtypes.

Java JavaJobExecutor.properties Use the jarPath keyword to specify the path to thedirectory where the jar files are stored. This includes alljar files stored in the specified directory and all subdirectories.

J2EE J2EEJobExecutorConfig.properties For more information about the J2EE job type, seeAppendix A, “Configuring to schedule J2EE jobs,” onpage 71.

Logging information about job types with advanced options

You can use the logging.properties file to configure the logging process for jobtypes with advanced options, with the exception of the Executable and XA jobtypes.

The logging.properties file is located on the Tivoli Workload Scheduler for z/OSAgent, under TWA_home/TWS/JavaExt/cfg/logging.properties.

Following installation, this file is as follows:# Specify the handlers to create in the root logger# (all loggers are children of the root logger)# The following creates two handlershandlers = java.util.logging.ConsoleHandler, java.util.logging.FileHandler

# Set the default logging level for the root logger.level = INFO


|

|

|

|

|||||

||

||

|||

||

||

||||

|

||||||

||||||

||||||

||

|||

||

|

|||||||

# Set the default logging level for new ConsoleHandler instancesjava.util.logging.ConsoleHandler.level = INFO

# Set the default logging level for new FileHandler instancesjava.util.logging.FileHandler.level

= ALLjava.util.logging.FileHandler.pattern

= C:\TWA_home\TWS\JavaExt\logs\javaExecutor%g.logjava.util.logging.FileHandler.limit

= 1000000java.util.logging.FileHandler.count

= 10

# Set the default formatter for new ConsoleHandler instancesjava.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatterjava.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter

# Set the default logging level for the logger named com.mycompanycom.ibm.scheduling = INFO

You can customize:v The logging level (from INFO to WARNING, ERROR, or ALL) in the following

keywords:

.level Defines the logging level for the internal logger.

com.ibm.schedulingDefines the logging level for the job types with advanced options. To loginformation about job types with advanced options, set this keyword toALL.

v The path where the logs are written, specified by the following keyword:java.util.logging.FileHandler.pattern


||||||||||||||||||||

|

||

||

||||

|

|

Appendix D. Managing return codes

By default, all nonzero error codes are considered as an error. Optionally, you candefine the error codes that, for job-tracking purposes, are not considered as errors.To do this, set the following parameters:

NOERRORDefines a list of error codes that, for job-tracking purposes, are treated asnormal completion codes. When setting this value on a Tivoli WorkloadScheduler for z/OS Agent, beware that the maximum length allowed for areturn code is 4 digits. If the Tivoli Workload Scheduler for z/OS Agentreturns an error code higher than 9999, it is truncated at the fourthrightmost digit. For example, 12345 is considered as 2345.

For negative error codes, specify a five-character sequence starting with theminus (-) symbol, for example -0008.

ERRRESDefines a list of error codes that, for job-tracking purposes, result in anautomatic reset of an operation. The operation is reset to status A (arriving)and contains the message Error, automatically reset in its operation detailspanel. An error code can be:v A 4-digit job or started-task return code (nnnn)v A system abend code (Sxxx)v A user abend code (Uxxx)v A Tivoli Workload Scheduler for z/OS-defined code

The HIGHRC parameter is not supported onTivoli Workload Scheduler for z/OSAgents and dynamic agents. For a detailed description of NOERROR and ERRRES,see Tivoli Workload Scheduler for z/OS: Customization and Tuning.

The following is a list of the return codes for each job type with advanced options:Database Jobs:RC = 0 -> Job completed successfullyRC = -1 -> SQL statement was run with an exit code different from 1RC = -2 -> MSSQL Job errorRC = -3 -> SQL statement did not run because of an error in the statement

Web services Jobs:RC = 0 -> Job completed successfullyRC = -1 -> The server hostname contained in the Web Service URL is unknownRC = -2 -> Web Service invocation error

Web services Jobs:RC = 0 -> Job completed successfullyRC = -1 -> The server hostname contained in the Web Service URL is unknownRC = -2 -> Web Service invocation error

IBM i Jobs:Return code = user return code when retrievedReturn code = 0 -> job completed successfullyReturn code > 0 -> job completed unsuccessfully


|

||

|||

Appendix E. Modifying the workstation from fault-tolerantagent to Tivoli Workload Scheduler for z/OS Agent

About this task

To modify a fault-tolerant agent workstation that uses centralized job scripts to aTivoli Workload Scheduler for z/OS Agent workstation, perform the followingsteps.

Note:

v For jobs whose JOBREC includes an RCCONDSUC keyword, seeAppendix D, “Managing return codes,” on page 81 for information abouthow to perform return code management for jobs scheduled on a TivoliWorkload Scheduler for z/OS Agent.

v To modify a fault-tolerant agent workstation that uses non-centralized jobscripts to a Tivoli Workload Scheduler for z/OS Agent workstation, youcan follow the same procedure. Additionally, you must convert theinformation contained in the EQQSCLIB data set into information for theJOBLIB data set, by using the appropriate “JOBREC” on page 30statement keywords.

Procedure1. Define the Tivoli Workload Scheduler for z/OS Agent destination by setting the

ROUTOPTS statement. For details, refer to “Defining destinations with theROUTOPTS statement” on page 9.

2. Optionally, customize the HTTP connection with the HTTPOPTS statement. Fordetails, refer to Chapter 2, “Customizing the HTTP connection with theHTTPOPTS statement,” on page 13.

3. From the MODIFYING GENERAL INFORMATION ABOUT A WORKSTATION panel, modify the workstation database definition by settingZ-CENTRIC AGENT to Y. For details, refer to “Modifying” on page 18.

4. To prevent that message EQQ3036W is issued in the MLOG, comment out theCPUREC statement related to the fault-tolerant workstation you are modifying.

Results

At the next daily planning run, the changes take effect and message EQQ0371I isissued in EQQMLOG:FTA OR Z-CENTRIC AGENT INFO HAS BEEN CHANGED FOR WORKSTATION WSNAME

If on the workstation modified there were operations with status S (started), thestatus is changed to I (interrupted) and message EQQ0372W is issued inEQQMLOG:STATUS OF OPERATION ADID IA OPNO HAS BEEN CHANGED FROM STARTED TO INTERRUPTEDAS A CONSEQUENCE OF WORKSTATION WSNAME CHANGE

The DP batch job ends with RC=4.


||||

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 publicationin other countries. Consult your local IBM representative for information on theproducts and services currently available in your area. Any reference to an IBMproduct, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product,program, or service that does not infringe any IBM intellectual property right maybe used instead. However, it is the user's responsibility to evaluate and verify theoperation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matterdescribed in this publication. The furnishing of this publication does not give youany license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785 U.S.A.

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

Intellectual Property LicensingLegal and Intellectual Property LawIBM Japan, Ltd.1623-14, Shimotsuruma, Yamato-shiKanagawa 242-8502 Japan

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

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THISPUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHEREXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESSFOR A PARTICULAR PURPOSE.

Some states do not allow disclaimer of express or implied warranties in certaintransactions, 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 beincorporated in new editions of the publication. IBM may make improvementsand/or changes in the product(s) and/or the program(s) described in thispublication at any time without notice.

Any references in this information to non-IBM Web sites are provided forconvenience only and do not in any manner serve as an endorsement of those Websites. The materials at those Web sites are not part of the materials for this IBMproduct 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 itbelieves appropriate without incurring any obligation to you.

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

IBM Corporation2Z4A/10111400 Burnet RoadAustin, 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 publication and all licensed materialavailable for it are provided by IBM under terms of the IBM Customer Agreement,IBM International Program License Agreement or any equivalent agreementbetween us.

Information concerning non-IBM products was obtained from the suppliers ofthose products, their published announcements or other publicly available sources.IBM has not tested those products and cannot confirm the accuracy ofperformance, compatibility or any other claims related to non-IBM products.Questions on the capabilities of non-IBM products should be addressed to thesuppliers of those products.

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

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

Intel is a trademark of Intel Corporation in the United States, other countries, orboth.

Java and all Java-based trademarks and logos are trademarks or registeredtrademarks of Oracle and/or its affiliates.


http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/legal/copytrade.shtml

Linux is a trademark of Linus Torvalds in the United States, other countries, orboth.

Microsoft and Windows are registered trademarks of Microsoft Corporation in theUnited States, other countries, or both.

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

Other company, product, and service names may be trademarks or service marksof others.

Notices 87

Index

Aaccessibility xadvanced job types 21, 23APARs

PK00789 16PK40356 16

AROPTS initialization statementENDTIME keyword 67STARTTIME keyword 67

AUTHALIAS, keyword of JOBREC 46

Bbroker workstation

defining 22broker workstations

creating 24defining 24jobs by reference 24options 24

Ccall to a web service

sample JSDL files 5CLASSNAME, keyword of JOBREC 43CMDTYPE statements

JOBRECCMDTYPE keyword 33, 36

CMDTYPE, keyword of JOBREC 33, 36code page

view 60configuring

J2EE communication channel 71J2EE jobs 71WebSphere Application ServerWebSphere Application

Server 71CONNFACTORY, keyword of JOBREC 46conventions used in publications ix

Ddatabase data extract 5database data validation 5database executor 30database job 30

configuring 79database operations

sample JSDL files 5database stored procedure

database jobssample JSDL files 5

sample JSDL files 5DB2 database job type

detailed syntax diagram 32DBNAME, keyword of JOBREC 33, 36DBTYPE, keyword of JOBREC 33, 36defining

broker workstation 22

defining (continued)destinations 9dynamic pools 24file dependencies 52pools 24z-centric workstation 17

destinationsdefining 9displaying in MLOG 9listing in MLOG 9modifying 9refreshing 9view 60

detailed syntax diagramDB2 database job type 32download job type 38executable job type 48file transfer job type 38J2EE jms job type 46Java job type 43MSSQL database job type 35native job type 48Oracle database job type 32script job type 48upload job type 38web service job type 41xajob job type 44

direct schedulingJ2EE jobs 71

download job typedetailed syntax diagram 38

dynamic domain managerdestinations 9modifying destinations 9

dynamic domain managersdefining destinations 9

dynamic poolsdefining 24

dynamic schedulingjob types with advanced options 5

Eeducation xend-to-end with fault tolerance capabilities

changing to end-to-end with z-centric capabilities 18end-to-end with z-centric capabilities

changing to end-to-end with fault tolerance capabilities 18overview 1steps to set up environment 1

ENDTIME keyword of AROPTS 67ENVVAR, keyword of JOBREC 44, 49EQQMOPRL panel 60EQQWBGEP panel 18EQQWCEOD panel 23EQQWCGEP panel 17, 22EQQWDGEP panel 19EQQWMGEP panel 18EQQWWSEP panel 19executable job type

detailed syntax diagram 48


executable jobs 5executable or script executor 30executors 30

Ffile changes, checking 52file dependencies, defining 52file transfer executor 30file transfer job 30file transfer job type

detailed syntax diagram 38file transfer jobs

sample JSDL files 5file transfer operations

sample JSDL files 5filewatch

filewatchdb utility 55installing 52maintaining log database 55syntax 53variable substitution 56

filewatchdb, syntax 55

Ggeneric Java job

template 5generic web service call

template 5glossary ix

HHTTP subtasks

start, stop 29

Iindirect scheduling

J2EE jobs 71initialization statements

USRRECdefinition 15USRCPU keyword 15USRNAM keyword 15USRPSW keyword 16

INTRACTV, keyword of JOBREC 49INVOKEYTYPE, keyword of JOBREC 46

JJ2EE communication channel

configuring 71j2ee jms executor 30j2ee jms job 30J2EE jms job type

detailed syntax diagram 46J2EE job

configuring 79J2EE jobs 5

configuring 71configuring for 71direct scheduling 71enabling 71

J2EE jobs (continued)indirect scheduling 71JMS 71security settings 71supported operations 71WebSphere Application Server settings 71

J2EE jobs on agentconfiguration 71, 73

J2EEJobExecutorConfig.propertiesconfiguring 71

JARPATH, keyword of JOBREC 43java executor 30java job 30Java job

configuring 79Java job type

detailed syntax diagram 43Java jobs

sample JSDL files 5Java operations

sample JSDL files 5JAVAPARM, keyword of JOBREC 43JCL

RECOVER statement 64JMS

J2EE jobs 71job executors 21, 23

configuring 79job plug-ins 21, 23

configuring 79job types

template 5job types with advanced options

configuration files 79configuring 79customizing 79log configuration 79sample JSDL files 5template 5

job types with advanced options configuration fileslocation 79

JOBCMD, keyword of JOBREC 49JOBLIB statements

JOBRECAUTHALIAS keyword 46CLASSNAME keyword 43CONNFACTORY keyword 46DBNAME keyword 33, 36DBTYPE keyword 33, 36definition 30ENVVAR keyword 44, 49INTRACTV keyword 49INVOKEYTYPE keyword 46JARPATH keyword 43JAVAPARM keyword 43JOBCMD keyword 49JOBPWD keyword 33JOBPWD keyword for file transfer job types 39JOBPWD keyword for J2EE jms job type 47JOBPWD keyword for MSSQL database job type 36JOBPWD keyword for script and executable job

type 49JOBPWD keyword for web service job types 41JOBPWD keyword for xajob job type 45JOBTYPE keyword 34JOBTYPE keyword for file transfer job types 39JOBTYPE keyword for J2EE jms job type 47


JOBLIB statements (continued)JOBREC (continued)

JOBTYPE keyword for Java job type 43JOBTYPE keyword for MSSQL database job type 37JOBTYPE keyword for web service job types 42JOBTYPE keyword for xajob job type 45JOBUSR keyword 34JOBUSR keyword for file transfer job types 39JOBUSR keyword for J2EE jms job type 47JOBUSR keyword for MSSQL database job type 37JOBUSR keyword for script and executable job type 49JOBUSR keyword for web service job types 42JOBUSR keyword for xajob job type 45LOCALFILE keyword 39MESSAGE keyword 47OPNAME keyword 42PARM keyword 42, 50PORT keyword 34, 37PROTOCOL keyword 39REMOTEFILE keyword 40SERVER keyword 34, 37, 40STATEMENT keyword 33, 37STDERROR keyword 50STDINPUT keyword 50STDOUTPUT keyword 50TRANSFERTYPE keyword 40URL keyword 42WRKDIR keyword 50

JOBPWD, keyword of JOBREC 33JOBPWD, keyword of JOBREC for file transfer job types 39JOBPWD, keyword of JOBREC for J2EE jms job type 47JOBPWD, keyword of JOBREC for MSSQL database job

type 36JOBPWD, keyword of JOBREC for script and executable job

type 49JOBPWD, keyword of JOBREC for web service job types 41JOBPWD, keyword of JOBREC for xajob job type 45JOBREC statement of JOBLIB

AUTHALIAS keyword 46CLASSNAME keyword 43CMDTYPE keyword 33, 36CONNFACTORY keyword 46DBNAME keyword 33, 36DBTYPE keyword 33, 36definition 30ENVVAR keyword 44, 49INTRACTV keyword 49INVOKEYTYPE keyword 46JARPATH keyword 43JAVAPARM keyword 43JOBCMD keyword 49JOBPWD keyword 33JOBPWD keyword for file transfer job types 39JOBPWD keyword for J2EE jms job type 47JOBPWD keyword for MSSQL database job type 36JOBPWD keyword for script and executable job type 49JOBPWD keyword for web service job types 41JOBPWD keyword for xajob job type 45JOBTYPE keyword 34JOBTYPE keyword for file transfer job types 39JOBTYPE keyword for J2EE jms job type 47JOBTYPE keyword for Java job type 43JOBTYPE keyword for MSSQL database job type 37JOBTYPE keyword for web service job types 42JOBTYPE keyword for xajob job type 45JOBUSR keyword 34JOBUSR keyword for file transfer job types 39

JOBREC statement of JOBLIB (continued)JOBUSR keyword for J2EE jms job type 47JOBUSR keyword for MSSQL database job type 37JOBUSR keyword for script and executable job type 49JOBUSR keyword for web service job types 42JOBUSR keyword for xajob job type 45LOCALFILE keyword 39MESSAGE keyword 42, 47PARM keyword 42, 50PORT keyword 34, 37PROTOCOL keyword 39REMOTEFILE keyword 40SERVER keyword 34, 37, 40STATEMENT keyword 33, 37STDERROR keyword 50STDINPUT keyword 50STDOUTPUT keyword 50TRANSFERTYPE keyword 40URL keyword 42WRKDIR keyword 50

jobs by referencesubmitting 24

JOBTYPE, keyword of JOBREC 34JOBTYPE, keyword of JOBREC for file transfer job types 39JOBTYPE, keyword of JOBREC for J2EE jms job type 47JOBTYPE, keyword of JOBREC for Java job type 43JOBTYPE, keyword of JOBREC for MSSQL database job

type 37JOBTYPE, keyword of JOBREC for web service job types 42JOBTYPE, keyword of JOBREC for xajob job type 45JOBUSR, keyword of JOBREC 34JOBUSR, keyword of JOBREC for file transfer job types 39JOBUSR, keyword of JOBREC for J2EE jms job type 47JOBUSR, keyword of JOBREC for MSSQL database job

type 37JOBUSR, keyword of JOBREC for script and executable job

type 49JOBUSR, keyword of JOBREC for web service job types 42JOBUSR, keyword of JOBREC for xajob job type 45

Llist cpwscom 51list wscom 51listing destinations 9LOCALFILE, keyword of JOBREC 39log database, filewatch 55log level on AS/400 51log level on i5/OS 51log level on IBM i 51log settings on AS/400 51log settings on i5/OS 51log settings on IBM i 51logging

job types with advanced options 79LookAt message retrieval tool x

Mmessage retrieval tool, LookAt xMESSAGE, keyword of JOBREC 47MODIFY command

dspdest 9rfrdest 9rfruser 15

modifying operations in the current plan panel 60

Index 91

MSSQL database job typedetailed syntax diagram 35

MSSQL jobs 5

Nnative job type

detailed syntax diagram 48new executors 30

template 5new plug-ins 5

template 5

Ooperating system

view 60OPNAME, keyword of JOBREC 42Oracle database job type


Ppanels

EQQWBGEP 18EQQWCGEP 17, 22, 23EQQWDGEP 19EQQWMGEP 18EQQWWSEP 19

PARM, keyword of JOBREC 42, 50password

encrypting 28EQQE2EPW JCL 28

poolsdefining 24

port numberview 60

PORT, keyword of JOBREC 34, 37PROTOCOL, keyword of JOBREC 39publications ix

RRECOVER statement 64refreshing destinations 9REMOTEFILE, keyword of JOBREC 40return codes

NOERROR parameter 81ROUTOPTS 9ROUTOPTS initialization statement

making changes immediately effective 9

Sscript job type

detailed syntax diagram 48security

WSSTAT command 56select cpws 51select ws 51select wscom 51SERVER, keyword of JOBREC 34, 37, 40soap.client.props

configuring 73

specific job typessample JSDL files 5

STARTTIME keyword of AROPTS 67STATEMENT, keyword of JOBREC 33, 37STDERROR, keyword of JOBREC 50STDINPUT, keyword of JOBREC 50STDOUTPUT, keyword of JOBREC 50syntax diagrams, how to read xi

Ttask executors

configuring 79technical training xTivoli technical training xTivoli Workload Scheduler for z/OS Agent

browsing 18Tivoli Workload Scheduler for z/OS Agents

defining destinations 9training

technical xTRANSFERTYPE, keyword of JOBREC 40

Uupload job type

detailed syntax diagram 38URL, keyword of JOBREC 42USRCPU, keyword of USRREC 15USRNAM, keyword of USRREC 15USRPSW, keyword of USRREC 16USRREC initialization statement

definition 15making changes immediately effective 15USRCPU keyword 15USRNAM keyword 15USRPSW keyword 16

Vvariable substitution 52

filewatch 56jobs 52

Wweb service executor 30web service job 30web service job type

detailed syntax diagram 41web service jobs

sample JSDL files 5WebSphere Application Server

configuring 71workstation status 56WRKDIR, keyword of JOBREC 50WSSTAT command 56

XXA jobs 5xajob executor 30xajob job 30xajob job type



Zz-centric workstation

browsing 18defining 17deleting 19modifying definition 18specifying list selection criteria 19

Index 93

��

Product Number: 5698-A17

Printed in USA

SC27-2399-01

Spineinformation:

Wor

kloa

dSc

hedu

lerf

orz/

OSVe

rsio

n8.

6IB

MTi

voli

Wor

kloa

dSc

hedu

lerf

orz/

OS:S

ched

ulin

gEn

d-to

-end

with

z-ce

ntric

Capa

bilit

ies

��

�

Scheduling End-to-end with z-centric Capabilities...dynamic workstations .....21 Creating broker...

Documents

Transcript of Scheduling End-to-end with z-centric Capabilities...dynamic workstations .....21 Creating broker...