I B M W o r kl o a d S c h e d ul e r IBM...Befor e using this information and the pr oduct it...

IBM Workload Scheduler

Planning and InstallationVersion 9 Release 5

IBM

NoteBefore using this information and the product it supports, read the information in “Notices” on page 337.

This edition applies to version 9, release 5, modification level 0 of IBM Workload Scheduler (program number5698-WSH) and to all subsequent releases and modifications until otherwise indicated in new editions.

© Copyright IBM Corporation 1999, 2016. © Copyright HCL Technologies Limited 2016, 2019

Contents

Figures . . . . . . . . . . . . . . vii

Tables . . . . . . . . . . . . . . . ix

About this publication . . . . . . . . xiWhat is new in this release . . . . . . . . . xiAccessibility . . . . . . . . . . . . . . xiTechnical training . . . . . . . . . . . . xiSupport information . . . . . . . . . . . xi

Part 1. Planning . . . . . . . . . . 1

Chapter 1. Network planning . . . . . . 3IBM Workload Scheduler environment. . . . . . 3

IBM Workload Scheduler interfaces . . . . . . 8Planning the environment . . . . . . . . . . 9

Distributed workload environment with staticscheduling capabilities . . . . . . . . . . 9Distributed workload environment with dynamicscheduling capabilities. . . . . . . . . . 10Distributed workload environment with staticand dynamic scheduling capabilities . . . . . 13End-to-end workload environment . . . . . 14Workload environment integrated with externalsystems. . . . . . . . . . . . . . . 15Distributed-driven workload environment forz/OS . . . . . . . . . . . . . . . 16Dockerized environment . . . . . . . . . 17

Planning domains . . . . . . . . . . . . 18Localized processing in your domain . . . . . 19Considerations in planning domains . . . . . 19Single domain network . . . . . . . . . 20Multiple domain network . . . . . . . . 22

Workstation classes . . . . . . . . . . . . 24Time zone considerations . . . . . . . . . . 24

Chapter 2. Installation considerations 25Installation paths . . . . . . . . . . . . 26Finding out what has been installed in which IBMWorkload Automation instances . . . . . . . 29Directories created outside of TWA_home atinstallation time . . . . . . . . . . . . . 31Windows services . . . . . . . . . . . . 31

Part 2. Installing IBM WorkloadScheduler . . . . . . . . . . . . . 33

Chapter 3. Installing from the CLI . . . 35Downloading installation images . . . . . . . 35Prerequisites . . . . . . . . . . . . . . 35

IBM Workload Scheduler user management . . 37Scanning system prerequisites for IBM WorkloadScheduler . . . . . . . . . . . . . . 40

Typical installation scenario . . . . . . . . . 41Creating and populating the database . . . . 42Creating the IBM Workload Scheduleradministrative user . . . . . . . . . . . 62Installing WebSphere Application Server LibertyBase . . . . . . . . . . . . . . . . 63Installing the master domain manager andbackup master domain manager . . . . . . 65Installing the Dynamic Workload Console servers 71Installing agents . . . . . . . . . . . . 73Post-installation configuration . . . . . . . 91

Installing additional IBM Workload Schedulercomponents . . . . . . . . . . . . . . 103

Installing an additional backup domainmanager . . . . . . . . . . . . . . 103Installing dynamic domain components . . . 105Installing agents on IBM i systems . . . . . 112

Chapter 4. Deploying with containers 123Considerations about deploying with containers 123Deploying with Docker compose . . . . . . . 124

Prerequisites. . . . . . . . . . . . . 126Deploying IBM Workload Automation in IBMCloud Private . . . . . . . . . . . . . 127

Prerequisites. . . . . . . . . . . . . 127Adding an IBM Workload Automation containerinto IBM Cloud Private . . . . . . . . . 129Deploying an IBM Workload Automation imageinto IBM Cloud Private . . . . . . . . . 130

Deploying IBM Workload Automation Agent onRed Hat OpenShift . . . . . . . . . . . 131

Prerequisites. . . . . . . . . . . . . 132Customizing DB parameters . . . . . . . . 132Creating a Docker image to run dynamic agents 132Troubleshooting . . . . . . . . . . . . 132

Container maintenance procedure . . . . . 133Container deployment issues . . . . . . . 133"CURL error 35" error . . . . . . . . . 134

Part 3. Configuring . . . . . . . . 137

iii

\\

\\

\

\\

\\\\\\\\\\\

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Chapter 5. Setting the environmentvariables . . . . . . . . . . . . . 139

Chapter 6. Configuring a masterdomain manager . . . . . . . . . . 141

Chapter 7. Configuration steps for amaster domain manager configuredas backup . . . . . . . . . . . . . 143

Chapter 8. Configuring a domainmanager . . . . . . . . . . . . . 145

Chapter 9. Configuring a backupdomain manager . . . . . . . . . . 147

Chapter 10. Configuring a dynamicdomain manager . . . . . . . . . . 149

Chapter 11. Configuration steps for adynamic domain manager configuredas backup . . . . . . . . . . . . . 151

Chapter 12. Configuring afault-tolerant agent . . . . . . . . . 153

Chapter 13. Configuring a dynamicagent . . . . . . . . . . . . . . . 155Automatically register agents to pools . . . . . 156

Chapter 14. Configuring a remotecommand-line client . . . . . . . . 159Configuring SSL connection between remotecommand-line client and master domain manager . 160

Chapter 15. Configuring a z-centricagent on Windows operating systems. 163

Chapter 16. Adding a feature . . . . . 165Procedure . . . . . . . . . . . . . . 165

Chapter 17. Enabling dynamicscheduling after installation . . . . . 169

Part 4. Upgrading. . . . . . . . . 173

Chapter 18. Downloading installationimages on your workstation . . . . . 175

Chapter 19. Upgrading from the CLI 177Before upgrading . . . . . . . . . . . . 177

Scanning system prerequisites for IBMWorkload Scheduler . . . . . . . . . . 178

Upgrading the Dynamic Workload Console . . . 179

Creating and populating the Dynamic WorkloadConsole database . . . . . . . . . . . 180Installing the Dynamic Workload Console . . . 180Exporting the Dynamic Workload Consolesettings . . . . . . . . . . . . . . 183

Installing a new master domain managerconfigured as a backup . . . . . . . . . . 183

Upgrading the database schema . . . . . . 184Creating the IBM Workload Scheduleradministrative user . . . . . . . . . . 189Installing WebSphere Application Server LibertyBase . . . . . . . . . . . . . . . 189Installing the master domain manager as abackup master domain manager . . . . . . 191Configuring security . . . . . . . . . . 194Switching the master domain manager to thenew backup master . . . . . . . . . . 197Making the switch manager permanent . . . 199Customizing and submitting the optional finaljob stream . . . . . . . . . . . . . 200

Installing a new backup master domain manager 201Creating the IBM Workload Scheduleradministrative user . . . . . . . . . . 202Installing WebSphere Application Server LibertyBase . . . . . . . . . . . . . . . 203Installing the new backup master domainmanager . . . . . . . . . . . . . . 204Completing the security configuration for thenew environment . . . . . . . . . . . 207Uninstalling the old backup master domainmanager . . . . . . . . . . . . . . 209

Upgrading a dynamic domain manager instance orits backup . . . . . . . . . . . . . . 210

Upgrading the database schema for the dynamicdomain manager . . . . . . . . . . . 210Creating the IBM Workload Scheduleradministrative user . . . . . . . . . . 213Installing WebSphere Application Server LibertyBase . . . . . . . . . . . . . . . 214Installing a new backup dynamic domainmanager . . . . . . . . . . . . . . 215Switching the dynamic domain manager to thenew or upgraded dynamic domain managerconfigured as backup. . . . . . . . . . 217Installing a new backup dynamic domainmanager . . . . . . . . . . . . . . 218Switching back to the old dynamic domainmanager (optional) . . . . . . . . . . 220

Upgrading agents . . . . . . . . . . . . 220Upgrading agents and domain managers withtwsinst . . . . . . . . . . . . . . 222Centralized agent update . . . . . . . . 234Upgrading agents using IBM Endpoint Manager 243

Upgrading when there are corrupt registry files 258Re-creating registry files using twsinst . . . . 258

Chapter 20. Updating containers . . . 261

Part 5. Applying a fix pack . . . . 263

iv IBM Workload Scheduler: Planning and Installation

\\

\\\

\\\\\\\\\

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

\\

\\

Chapter 21. Downloading installationimages . . . . . . . . . . . . . . 265

Chapter 22. Installing the fix pack . . 267Updating the master domain manager and itsbackup . . . . . . . . . . . . . . . 267Updating the dynamic domain manager . . . . 269Updating the Dynamic Workload Console . . . . 270Updating agents . . . . . . . . . . . . 272

Chapter 23. Repairing an updatedversion . . . . . . . . . . . . . . 273Repairing the master domain manager and itsbackup . . . . . . . . . . . . . . . 273Repairing the dynamic domain manager . . . . 274Repairing the Dynamic Workload Console. . . . 274

Chapter 24. Returning to a previousproduct version level . . . . . . . . 277Returning the master domain manager and itsbackup to a previous product version level . . . 277Returning the dynamic domain manager to aprevious product version level . . . . . . . 278Returning the Dynamic Workload Console to aprevious product version level . . . . . . . 279

Part 6. Troubleshootinginstallation, migration, anduninstallation . . . . . . . . . . 281

Chapter 25. Installation log files . . . 283DB2 installation log files. . . . . . . . . . 284The twsinst log files . . . . . . . . . . . 284

Chapter 26. Updating issues on AIXplatform. . . . . . . . . . . . . . 285

Chapter 27. Packaging log files forsupport . . . . . . . . . . . . . . 287

Chapter 28. Analyzing return codesfor agent installation, upgrade,restore, and uninstallation . . . . . . 289

Chapter 29. Problem scenarios:install, reinstall, upgrade, migrate, anduninstall . . . . . . . . . . . . . 293Default and customized dashboard listing objectsreleased with a fix pack stop working afterreturning the Dynamic Workload Console to 9.5GA version . . . . . . . . . . . . . . 293

Error in testing a connection or running reports onan engine returned from Fix Pack 1 to GA levelwhen using an MSSQL or Informix database . . . 293

Chapter 30. Uninstalling IBMWorkload Scheduler manually . . . . 295Uninstalling manually on Windows operatingsystems . . . . . . . . . . . . . . . 295Uninstalling manually on UNIX operating systems 296Problems during manual uninstall . . . . . . 297

File deletion on Windows too slow . . . . . 298

Part 7. Uninstalling . . . . . . . . 299

Chapter 31. Uninstalling the maincomponents . . . . . . . . . . . . 301Uninstalling a backup master domain manager . . 301Uninstalling a master domain manager . . . . . 302Uninstalling the Dynamic Workload Console . . . 304Uninstalling a dynamic domain manager or itsbackup . . . . . . . . . . . . . . . 305

Uninstalling a dynamic domain managermaintaining a correct hierarchy in the network . 306

Uninstalling agents using the twsinst script . . . 307Uninstalling agents on IBM i systems . . . . . 309

The twsinst script log files on IBM i systems 310

Part 8. Appendixes . . . . . . . . 311

Appendix. Reference . . . . . . . . 313Master components installation - serverinst script 313Database configuration - configureDB script . . . 321Dynamic Workload Console installation - dwcinstscript . . . . . . . . . . . . . . . . 328Docker sample files . . . . . . . . . . . 334

Notices . . . . . . . . . . . . . . 337Trademarks . . . . . . . . . . . . . . 339Terms and conditions for product documentation 339

Index . . . . . . . . . . . . . . . 341

Contents v

\\\

\\\\\\\\\\\

\\\\\\\\\\

\\\\\\\\\\\\

\\\\\\\

vi IBM Workload Scheduler: Planning and Installation

Figures

1. Graphical overview of IBM Workload Schedulerenvironment to run static workload . . . . . 4

2. Graphical overview of IBM Workload Schedulerdynamic environment . . . . . . . . . 6

3. Distributed workload environment with staticscheduling capabilities . . . . . . . . . 10

4. Distributed workload environment withdynamic scheduling capabilities. . . . . . 12

5. Distributed workload environment with staticand dynamic scheduling capabilities . . . . 14

6. Workload environment integrated withexternal systems . . . . . . . . . . . 16

7. Distributed-driven workload environment forz/OS. . . . . . . . . . . . . . . 17

8. Dockerized environment configuration . . . 189. Single domain topology . . . . . . . . 21

10. Single domain topology on multiple sites 2211. Multiple domain topology . . . . . . . 2312. Typical IBM Workload Scheduler architecture 4213. SSL server and client keys . . . . . . . 95

vii

\\

\\\\

viii IBM Workload Scheduler: Planning and Installation

Tables

1. Features partially or not supported fordynamic scheduling. . . . . . . . . . 13

2. Symbolic link options . . . . . . . . . 253. DB2 Setup files . . . . . . . . . . . 364. Required information . . . . . . . . . 665. Valid values for -lang and LANG parameter 696. Required information . . . . . . . . . 717. Valid values for -lang and LANG parameter 818. Installation syntax for agent installation with

agents in the same network zone . . . . . 889. Installation syntax for agent installation with

agents in different network zones . . . . . 8910. Changes allowed in IBM Workload Scheduler

keystore and truststore . . . . . . . . . 9511. Required information . . . . . . . . . 10412. Required information . . . . . . . . . 11113. Valid values for -lang and LANG parameter 11714. Windows operating system agent return

codes . . . . . . . . . . . . . . 11915. UNIX or Linux operating system agent return

codes . . . . . . . . . . . . . . 12016. IBM Workload Automation containers' system

requirements . . . . . . . . . . . . 128

17. IBM Workload Automation Containersoffering . . . . . . . . . . . . . 129

18. Components inside the Helm chart . . . . 13019. Required information . . . . . . . . . 18120. Required information . . . . . . . . . 19121. Required information . . . . . . . . . 20522. Required information . . . . . . . . . 21623. Required information . . . . . . . . . 21924. Windows operating system agent return


codes . . . . . . . . . . . . . . 23326. Required and optional attributes for the

definition of a centralized agent update job . 23727. Windows operating system agent return


codes . . . . . . . . . . . . . . 29029. Valid values for -lang and LANG parameter 31630. Valid values for -lang and LANG parameter 32731. Valid values for -lang and LANG parameter 331

ix

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

\\\\\\\\\\\\\\\\\\\\\\\\

\\\\\\

x IBM Workload Scheduler: Planning and Installation

About this publication

About this task

This IBM Workload Scheduler Planning and Installation provides information forplanning, installing, migrating, and configuring an IBM Workload Schedulernetwork.

What is new in this releaseLearn what is new in this release.

For information about the new or changed functions in this release, see IBMWorkload Automation: Overview, section Summary of enhancements.

For information about the APARs that this release addresses, see the IBM WorkloadScheduler Release Notes at IBM Workload Scheduler Release Notes and theDynamic Workload Console Release Notes at Dynamic Workload Console ReleaseNotes. For information about the APARs addressed in a fix pack, refer to thereadme file for the fix pack.

New or changed content is marked with revision bars.

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 theinterface. You can also use the keyboard instead of the mouse to operate allfeatures of the graphical user interface.

For full information, see the Accessibility Appendix in the IBM Workload SchedulerUser's Guide and Reference.

Technical trainingCloud & Smarter Infrastructure provides technical training.

For Cloud & Smarter Infrastructure technical training information, see:http://www.ibm.com/software/tivoli/education

Support informationIBM provides several ways for you to obtain support when you encounter aproblem.

If 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:v Searching knowledge bases: You can search across a large collection of known

problems and workarounds, Technotes, and other information.

xi

http://www.ibm.com/support/docview.wss?uid=ibm10733052http://www.ibm.com/support/docview.wss?uid=ibm10733054http://www.ibm.com/support/docview.wss?uid=ibm10733054http://www.ibm.com/software/tivoli/education

v Obtaining fixes: You can locate the latest fixes that are already available for yourproduct.

v Contacting IBM Software Support: If you still cannot solve your problem, andyou need to work with someone from IBM, you can use a variety of ways tocontact IBM Software Support.

For more information about these three ways of resolving problems, see theappendix about support information in IBM Workload Scheduler: TroubleshootingGuide.

xii IBM Workload Scheduler: Planning and Installation

Part 1. Planning

An overview of the IBM Workload Automation environment and describes how toplan for the installation.

1

2 IBM Workload Scheduler: Planning and Installation

Chapter 1. Network planning

Network planning on IBM Workload Automation.

About this task

How to plan your IBM Workload Scheduler network.

IBM Workload Scheduler environmentAn IBM Workload Scheduler network consists of a set of linked workstations onwhich you perform job processing. A network is composed of one or moredomains, each having a domain manager workstation acting as a management hub,and one or more agent workstations.

About this task

Using IBM Workload Scheduler you can run your workload in one of thefollowing ways:

StaticallyTo run existing job types, for example docommand and scripts on specificworkstations of fault-tolerant agent or standard agent type.

DynamicallyTo run existing job types and job types with advanced options, allowingthe product to assign it to the workstation that best meets both thehardware and software requirements needed to run it.

Job types with advanced options are both those supplied with the productand the additional types implemented through the custom plug-ins. Forexample, those supplied with the product are DB2®, file transfer, and webservices. Those implemented through the custom plug-ins are the ones youdeveloped using the Integration Workbench of the Software DevelopmentKit (SDK).

Depending on how you want to run your workload you have to install andconfigure different components in your network.

Figure 1 on page 4 gives a graphical overview of a typical IBM WorkloadScheduler environment to run static workload:

3

In Figure 1 the master domain is shown with the principle components to runworkload statically, and two levels of subdomain. The available user interfaces arealso indicated. An example is provided of the basic domain hierarchical structure,where each domain is named "D1", "D2, and so on. All of these concepts areexplained in the following section:

To run your workload statically install the following components:

Master domain managerThe master domain manager is the highest level workstation of a IBMWorkload Scheduler network. It contains or connects to the relationaldatabase that stores scheduling object definitions. It creates or updates aproduction file when the plan is created or extended and then distributesthe file to the network. It performs all logging and reporting for thenetwork. It can perform the role of event processing server for theevent-driven workload automation feature.

Backup master domain manager

Child domain(Dn) - and so on

MD

D1 D2

D3 D4 D5

User Interfaces

Master Domain(MD)

Example domain hierarchyFault-toleant

Agents

Database

Master domainmanager

Dynamic Workload

Console

Command-line

client (remote)

Backup masterdomain manager

(agent)Fault-toleant

Agents

Child domainmanager(agent)

Child domainmanager(agent)

Command

line

Web browser

D6

Backup domainmanager (agent)

Figure 1. Graphical overview of IBM Workload Scheduler environment to run static workload


Define a backup master domain manager at installation to point to eitherthe database being used by the master domain manager or to a mirror ofthat database. In this way the backup master domain manager has thelatest data available to it at all times.

Domain managerInstall this component if you need a multi-domain network and you wantto manage workload by assigning it to a predefined workstation that is torun your workload statically. In a multi-domain network all domainsbelow the master domain have fault-tolerant agents configured to be adomain manager to manage the workstations in its domain. A domainmanager can manage fault-tolerant, standard, and extended agents. Eachdomain manager is a fault-tolerant agent in the domain of the next higherlevel. To define a domain manager, install a fault-tolerant agent on yourworkstation and then define it as manager in the workstation definition.

Backup domain managerInstall this component if you want a backup to your domain manager. Ifyour domain manager experiences problems, you can configure anyfault-tolerant agent as the domain manager and switch to it with a simpleprocedure.

Agent An agent is a workstation in the network that runs the jobs which arecontrolled by the IBM Workload Scheduler master domain manager. Afterinstalling an agent, you define its type by using the workstation definition.

Fault-tolerant agentAn fault-tolerant agent can resolve local dependencies and launchjobs in the absence of a domain manager. It has a copy of theproduction control file. This allows fault-tolerant agents to continueprocessing even if the dynamic domain manager or the networkconnection is down. With a simple reconfiguration, they can serveas subordinate domain managers. To define a fault-tolerant agent,install a fault-tolerant agent on your workstation and then define itas fault-tolerant in the workstation definition.

Standard agentAn agent that launches jobs only under the direction of its domainmanager. It is not fault-tolerant. To define a standard agent, installa fault-tolerant agent on your workstation and then define it as astandard agent in the workstation definition.

Extended agentExtended agents are logical definitions (hosted by a physical workstation)used to extend job processing to selected applications (SAP R/3,PeopleSoft, and z/OS®). For information about installing an extendedagent, see IBM Workload Automation: Scheduling Applications with IBMWorkload Automation.

Note: All agents with special roles (master domain manager, backup masterdomain manager, domain manager, backup domain manager) can also work asfault-tolerant agents with jobs scheduled on them.

Figure 2 on page 6 gives a graphical overview of a typical IBM WorkloadScheduler environment to run dynamic workload:

Chapter 1. Network planning 5

In Figure 2 the master domain is shown with the principle components to runworkload dynamically, and two levels of dynamic subdomain. The available userinterfaces are also indicated. An example is provided of the basic domainhierarchical structure, where each domain is named "D1", "D2, and so on. All ofthese concepts are explained in the following section.

If you want to run your workload dynamically install the following components:

Master domain managerThe master domain manager is the highest level workstation of a IBMWorkload Scheduler network. It contains or connects to the relationaldatabase that stores scheduling object definitions. It creates or updates aproduction file when the plan is created or extended and then distributesthe file to the network. It performs all logging and reporting for thenetwork. It can perform the role of event processing server for theevent-driven workload automation feature.

Backup master domain manager

Child domain(Dn) - and so on

MD

D1 D2

D3 D4 D5

User Interfaces

Master Domain(MD)

Example domain hierarchy

Database

Master domainmanager

Dynamic Workload

Console

Command-line

client (remote)

Backup masterdomain manager

(agent)Dynamic

agents

Child dynamicdomain

manager

Child dynamicdomain

manager

Command

line

Web browser

D6

Backup dynamicdomain

manager

Dynamic

agents

Figure 2. Graphical overview of IBM Workload Scheduler dynamic environment


Define a backup master domain manager at installation to point to eitherthe database being used by the master domain manager or to a mirror ofthat database. In this way the backup master domain manager has thelatest data available to it at all times.

Dynamic Domain managerInstall this component if you need a multi-domain network and you wantto manage your workload both statically that dynamically. All domainsbelow the master domain have dynamic domain managers to manage theworkstations in its domain. Each dynamic domain manager is an agent inthe domain of the next higher level. To define a dynamic domain manager,install a dynamic domain manager and then perform the Chapter 10,“Configuring a dynamic domain manager,” on page 149 procedure.

Backup dynamic domain managerInstall this component if you want a backup to your dynamic domainmanager. If your dynamic domain manager experiences problems, you canswitch to it with a simple procedure.

Agent An agent is a workstation in the network that runs the jobs which arecontrolled by the IBM Workload Scheduler master domain manager.

Dynamic agentAn agent that has the following capabilities:

Run workload dynamicallyIt communicates with the server the status of its resources.In this way the product is able to dynamically run yourworkload to the best available resources by:v Automatically discovering scheduling environment

resources.v Automatically following resource changesv Requesting additional resources when neededv Matching job requirements to available resourcesv Controlling and optimizing use of resources

The characteristics listed above provide high availabilityand load balancing potentialities to your environment andwell suit virtualized environments.

When a job is submitted, either as part of a job stream inthe plan or through ad hoc submission, IBM WorkloadScheduler checks the job requirements, the availableresources and the related characteristics and submits thejob to the resource that best meets the requirements to runit.

Run both existing job types and job types with advancedoptions

It can run:v Existing job types. For example docommand and scripts.v Job types with advanced options, both those supplied

with the product and the additional types implementedthrough the custom plug-ins. For example, thosesupplied with the product are DB2, file transfer, and webservices. Those implemented through the customplug-ins are the ones you developed using the


Integration Workbench of the Software Development Kit(SDK). To run these job types you must also install theJava™ run time.

Manage dynamic workload broker logical resourceIt can remotely run, from the agent, the dynamic workloadbroker resource command on the server. To manage theresource command you must also install the Java run time.

After installing the agent, you define its type by using Chapter 13,“Configuring a dynamic agent,” on page 155.

In a simple configuration, dynamic agents connect directly to themaster domain manager or to the dynamic domain manager.However, in more complex network topologies, if the networkconfiguration prevents the master domain manager or the dynamicdomain manager from directly communicating with the dynamicagent, for example, if the agents are behind a firewall and need tocommunicate through the internet, or if they need to communicatewith a Network Address Translation (NAT) process, then you canconfigure your dynamic agents to use a local or remote gateway. Inthis way, communication is concentrated in a single connection,reducing the number of connections to the master domain manageror to the dynamic domain manager. For more information aboutthe gateway parameters specified when installing a dynamic agent,see “Agent installation parameters - twsinst script” on page 78.For more information about gateway configuration, see thenetwork communications information in the Administration Guide.

Extended agentExtended agents are logical definitions (hosted by a physicalworkstation) used to extend job processing to selected applications(SAP R/3, PeopleSoft, and z/OS). For information about installingan extended agent, see IBM Workload Automation: SchedulingApplications with IBM Workload Automation.

IBM Workload Scheduler interfacesThe IBM Workload Scheduler has user interfaces from which you can manage yourproduction environment.

About this task

You can manage your production environment from the following user interfaces:

Master domain manager command linesThe master domain manager command lines are installed automaticallywhen you install the master domain manager. This command linesinterface are run only from the workstation serving as the master domainmanager. From the command lines, you can administer the master specificbinaries and options. A backup master domain manager command linesalso exist on the master domain manager configured as backup instance.

Dynamic Workload ConsoleThe web-based interface for creating, modifying, monitoring, controlling,and deleting IBM Workload Scheduler objects. You can interface with theconsole from any system in the network where a supported web browser isinstalled. When you install a Dynamic Workload Console also the z/OS


Connector is installed, which is a component that connects IBM ZWorkload Scheduler and the Dynamic Workload Console. For moreinformation, see IBM Z Workload Scheduler: Planning and Installation Guide.

Command-line clientA component of IBM Workload Scheduler installed only with afault-tolerant agent that allows you to implement the following commandson the master domain manager from another workstation: The commandsyou can use are the following:v Composerv Optmanv Planman showinfo and unlock (the other planman commands must be

run locally on the master domain manager)

dynamic workload broker command lineInstalled and configured automatically when you install a master domainmanager. It includes commands to directly submit and manage jobs fordynamic scheduling, manage job JSDL definitions and resources, and more.See IBM Workload Scheduler: Scheduling Workload Dynamically for reference.

For a more detailed description of the IBM Workload Scheduler components, seeIBM Workload Automation: Overview.

Planning the environmentTypical installation scenarios for products and components.

These typical scenarios for IBM Workload Automation show how to deployspecific solutions on the minimum possible system resources.

Distributed workload environment with static schedulingcapabilities

Configuration to run workload statically across your distributed network.

Use this configuration to run workload statically across your distributed network.Figure 3 on page 10 shows the system resources needed to install a fully-workingIBM Workload Scheduler environment for managing your distributed workload.


Distributed workload environment with dynamic schedulingcapabilities

Use this configuration to run workload dynamically across your distributednetwork.

MasterDomainManager

DBserver

ServerSystem

Components share infrastructure

DWCserver

Workload Scheduler instance

Workload Scheduler agentnetwork

FTA FTA

Figure 3. Distributed workload environment with static scheduling capabilities


The run time environment is used to:v Run on the agent job types with advanced options, both those supplied with the

product and the additional types implemented through the custom plug-ins.v Enable the capability to remotely run, from the agent, the dynamic workload

broker resource command on the server.

For information about dynamic scheduling, how to run application job plug-insand the dynamic workload broker resource command on the server, see IBMWorkload Scheduler: Scheduling Workload Dynamically.

In this configuration, you can choose whether or not to add the run timeenvironment for Java jobs to the agent.

Figure 4 on page 12 shows the system resources required to install a fully workingIBM Workload Scheduler environment for running your distributed workloaddynamically.

Note: A dynamic agent can be directly connected to its master domain manager orthrough a dynamic domain manager as shown in “Distributed workloadenvironment with static and dynamic scheduling capabilities” on page 13. In morecomplex network topologies where the master domain manager or the dynamicdomain manager cannot directly communicate with the dynamic agent, you canconfigure your dynamic agents to use a local or remote gateway. For moreinformation about the gateway parameters specified when installing a dynamicagent, see “Agent installation parameters - twsinst script” on page 78. For moreinformation about the gateway parameters specified when installing a dynamicagent, see “Agent installation parameters - twsinst script” on page 78.

For more information about gateway configuration, see the networkcommunications information in the Administration Guide.


Dynamic scheduling supports most of the IBM Workload Scheduler features forstatic scheduling. The Table 1 on page 13 lists some features or properties that arepartially or not supported.

MasterDomainManager

DBserver

ServerSystem


TDWCserver


Workload Scheduler agentnetwork

DynamicAgent

JavaRuntime

DynamicAgent

DWCserver

DynamicAgent

Gateway

Figure 4. Distributed workload environment with dynamic scheduling capabilities


Table 1. Features partially or not supported for dynamic scheduling

Feature agent and IBM® Z Workload Scheduler agent

Event-driven workload automation.Note: For more details about the eventstype, see IBM Workload Scheduler User'sGuide and Reference: Appendixes -Event-driven workload automation event andaction definitions

TivoliWorkloadSchedulerObjectMonitorevents supported.

FileMonitor events supported, except for IBMi systems.

TivoliWorkloadSchedulerApplicationMonitorevents not supported.

Utility commands (datecalc, jobinfo, and soon).

Not supported.

Distributed workload environment with static and dynamicscheduling capabilities

Use this configuration to run workload both statically and dynamically across yourdistributed network.

The run time environment is used to:v Run on the agent job types with advanced options, both those supplied with the

product and the additional types implemented through the custom plug-ins.v Enable the capability to remotely run, from the agent, the dynamic workload

broker resource command on the server.

For information about dynamic scheduling, how to run application job plug-insand the dynamic workload broker resource command on the server, see IBMWorkload Scheduler: Scheduling Workload Dynamically.

In this configuration, you can choose whether or not to add the run timeenvironment for Java jobs to the agent.

Figure 5 on page 14 shows the system resources required to install a fully workingIBM Workload Scheduler environment for running your distributed workload bothstatically and dynamically. IBM Workload Scheduler requires a fault-tolerant agentand a dynamic agent to be installed on every system where jobs are to scheduledstatically or dynamically.

Note: A dynamic agent can be directly connected to its master domain manager orthrough a dynamic domain manager as shown in Figure 5 on page 14. In morecomplex network topologies where the master domain manager or the dynamicdomain manager cannot directly communicate with the dynamic agent, you canconfigure your dynamic agents to use a local or remote gateway. For moreinformation about the gateway parameters specified when installing a dynamicagent, see “Agent installation parameters - twsinst script” on page 78.

For more information about gateway configuration, see the networkcommunications information in the Administration Guide.


For a list of features partially or not supported in a mixed environment, see Table 1on page 13.

End-to-end workload environmentIn an End-to-end workload environment (agent connected to the z/OS system),you can define the types of configurations.

You can define the following types of configurations:

To run your workload statically:

MasterDomainManager

DBserver

ServerSystem


DWCserver


Workload Scheduleragent network

DomainManager

DynamicDomainManager

FTA

FTA

FTA

DynamicAgent

DynamicAgent

DynamicAgent

DBserver

JavaRuntime

DynamicAgent

Gateway

Figure 5. Distributed workload environment with static and dynamic scheduling capabilities


Using fault-tolerant agentsUse the fault-tolerant end-to-end scheduling environment toschedule and control static workload from the mainframe todistributed systems. On the distributed system, you installfault-tolerant agents and connect them to the z/OS server. Fordetails, see Scheduling End-to-end with Fault Tolerance Capabilities .

Using IBM Z Workload Scheduler Agents (z-centric)Use the z-centric end-to-end scheduling environment to scheduleand control static workload from the mainframe to distributedsystems with a low cost of ownership. On the distributed system,you install IBM Z Workload Scheduler Agents and connect them tothe z/OS controller. For information about how to install the IBMZ Workload Scheduler Agent, see IBM Z Workload Scheduler:Planning and Installation. For information about how to use the IBMZ Workload Scheduler Agent, see Scheduling End-to-end withz-centric Capabilities for more details.

To run your workload dynamically:

Using IBM Z Workload Scheduler Agents (z-centric) with dynamiccapabilities

Use the z-centric end-to-end scheduling environment to scheduleand control dynamic workload from the mainframe to distributedsystems with a low cost of ownership. On the distributed system,you install IBM Z Workload Scheduler Agents , add dynamicscheduling capabilities and connect them to a dynamic domainmanager that must be connected to the z/OS controller. Forinformation about how to:v Install a dynamic domain manager see “Installing dynamic

domain components” on page 105.v Install IBM Z Workload Scheduler Agents, see IBM Z Workload

Scheduler: Planning and Installation.v Use IBM Z Workload Scheduler Agents, see Scheduling End-to-end

with z-centric Capabilities.

Workload environment integrated with external systemsConfiguration to extend IBM Workload Scheduler capabilities for scheduling onexternal applications.

Use this configuration to extend IBM Workload Scheduler capabilities forscheduling on external applications, such as SAP and PeopleSoft using IBMWorkload Scheduler.

Figure 6 on page 16 shows a sample environment including the agents needed toextend IBM Workload Scheduler scheduling capabilities on one or more externalapplications using IBM Workload Scheduler. You can install IBM WorkloadScheduler on the master domain manager, on a fault-tolerant agents, on dynamicagents, and on IBM Z Workload Scheduler Agents.

For information about IBM Workload Scheduler, see the IBM Workload Scheduler:User's Guide documentation.


Note: Installing IBM Workload Scheduler on an agent (master domain manager,domain manager, fault-tolerant agent, standard agent, dynamic agent, IBM ZWorkload Scheduler Agent ) is the correct deployment scenario in an end-to-endenvironment.

Distributed-driven workload environment for z/OSConfiguration used when submitting from the IBM Workload Scheduler.

Use this configuration to submit from the IBM Workload Scheduler (using thedynamic workload broker component installed with the master domain manageror the dynamic domain manager) workload to be processed by JES2, withouthaving to define the workload on the z/OS system.

Figure 6 shows the minimum system resources needed to install adistributed-driven environment, where the IBM Workload Scheduler

Workload Scheduleragent

network

WSFTA

z/OS

Oracle

PeopleSoft

SAP R/3

WSfor

Applications

Applications

WSfor

Applications

WSfor

Applications

Workload SchedulerServer system

WSDynamic

Agent

WSfor Z/OS

Agent

JavaRuntime

Figure 6. Workload environment integrated with external systems


distributed-Agent for z/OS represents a lightweight end-to-end schedulingsolution where you define and manage on the distributed side the workload that isto be processed by JES2.

For information about IBM Workload Scheduler distributed-Agent for z/OS, seethe IBM Workload Scheduler: Scheduling with the Agent for z/OS documentation.

Dockerized environmentUse this configuration to implement a Dockerized environment.

DBserver

ServerSystem

DWCserver



MDM

z/OSSystem

Distributed-Agentfor z/OS

Figure 7. Distributed-driven workload environment for z/OS


\

\

Use this configuration to benefit of the IBM Workload Automation on a dockerizedenvironment. Three containers are delivered and they can be deployed on the sameengine or on different ones.

In the Figure 1, server and console components have been deployed on the sameDocker engine and the dynamic agent component on a separated engine.

The database is always external to the Docker engine and a connection isestablished with server and console.

Planning domainsA IBM Workload Scheduler network contains at least one master domain managerthat acts as a management hub for the product. Additional domains can be used todivide a widely-distributed network into locally-managed groups of workstations.

In a single domain configuration, the master domain manager maintainscommunications with all of the workstations in the network.

In a multiple domain configuration, the master domain manager communicateswith the workstations in its domain and all immediately subordinate domainmanagers. The subordinate domain managers communicate with the workstationsin their domains and their immediately subordinate domain managers, and so on.Domain managers report all of the activities of the domain to the master. Usingmultiple domains reduces network traffic and the load on the master by reducing

Figure 8. Dockerized environment configuration


\

\\\

\\\

\\

\\

\

the number of direct communications between the master domain manager andworkstations. Multiple domains also provide fault-tolerance by limiting the outagecaused by losing a domain manager in a single domain. To limit the effects further,you can designate backup domain managers to take over if domain managers fail.

When you define a new domain, you must identify the parent domain and thedomain manager. The parent domain is the domain directly above the new domainin the domain hierarchy. All communications to and from a domain are routedthrough the parent domain manager.

Localized processing in your domainLocalized processing is separating your scheduling needs based on a common setof characteristics, such as geographical locations, business functions, andapplication groupings.

Group related processing can limit the amount of interdependency informationthat needs to be communicated between domains. The benefits of localizeddomains are:

Decreased network trafficKeeping processing localized to domains eliminates the need for frequentinter-domain communication.

Tighter security and simplified administrationSecurity and administration can be defined at and limited to the domainlevel. Instead of network-wide or workstation-specific administration, youcan have domain administration.

Optimized network and workstation fault-toleranceIn a multiple domain network, you can define backups for each domainmanager so that problems in one domain do not disrupt operations inother domains.

Considerations in planning domainsThere are a number of considerations that are to be taken into account whenplanning domains.

In planning your IBM Workload Scheduler network, consider the following:

Number of workstations, applications, and jobsConsider the number of workstations that comprise the network and thenumber of applications and jobs that the network runs. If you have a smallnumber of workstations, or a small number of applications to control, youdo not need multiple domains.

Number of geographic locationsConsider the number of geographic locations covered by your network andthe reliability and efficiency of communication between the locations.Multiple geographic locations is one of the primary reasons for choosing amultiple domain architecture. One domain for each geographical location isa common configuration. A single domain architecture relies on thenetwork maintaining continuous processing.

Time zonesWhen your network is spread across multiple geographic locations indifferent time zones, decide whether to activate the time zone feature. See“Time zone considerations” on page 24.


Centralized or decentralized managementYou can manage single or multiple domain networks from a single masterdomain manager. If you want to manage multiple locations separately, youcan consider the installation of a separate IBM Workload Schedulernetwork at each location. Some decentralized management is possible in astand-alone IBM Workload Scheduler network by mounting or sharing filesystems.

Types of applicationsConsider the types of applications that are run by IBM WorkloadScheduler. If you have multiple applications that are distinctly separatefrom each other, you might choose to put them in separate domains.

Windows networkWhen you have a Windows network, you might want your IBM WorkloadScheduler domains to mirror your Windows domains.

System performance and other criteriaYou can define multiple domains to localize systems based on performanceor operating system type.

Amount of network trafficIf your network traffic is manageable, having multiple domains is lessimportant.

Dependencies between jobsConsider if you need to plan for job dependencies that cross systemboundaries, geographical boundaries, or application boundaries. Forexample, does the start of Job1 on workstation1 depend on the completionof Job2 running on workstation2. The degree of interdependence betweenjobs is an important consideration when planning your network. If you usemultiple domains, try to keep interdependent objects in the same domainto decrease network traffic and improve the use of the domain architecture.See User's Guide and Reference.

Level of fault-tolerance requiredA disadvantage of the single domain configuration is the reliance on asingle domain manager. In a multi-domain network, the loss of a singledomain manager affects only the agents in its domain.

FirewallsWhen your network contains firewalls, plan the structure of your domainsaround the firewalls. See Administration Guide.

Secure Sockets Layer (SSL) or IBM Global Security Kit (GSKit) encryptionIf you want to use SSL or GSKit encryption in your network, plan yourdomains in accordance with the protocol.

Note: If you want to be compliant with Federal Information ProcessingStandards (FIPS), you must use GSKit. See Administration Guide.

Single domain networkA single domain network consists of a master domain manager and any number ofagents.

Figure 9 on page 21 shows an example of a single domain network. A singledomain network is well-suited to companies that have few locations and businessfunctions. All communication in the network is routed through the master domain


manager. With a single location, you are concerned only with the reliability of yourlocal network and the amount of traffic it can handle.

Single domain networks can be combined with other networks, single or multipledomain, to meet multiple site requirements. IBM Workload Scheduler supportsinternetwork dependencies between jobs running on different networks.

MasterDomainManager

Agents

Figure 9. Single domain topology


Example 1 shows a single domain network. The master domain manager is locatedin Atlanta, along with several agents. There are also agents located in Denver. Theagents in Denver depend on the master domain manager in Atlanta to resolve allinteragent dependencies, even though the dependencies might be on jobs that runin Denver. An alternative would be to create separate single domain networks inAtlanta and Denver, as shown in example 2.

Multiple domain networkMultiple domain networks are especially suited to companies that span multiplelocations, departments, or business functions.

DynamicWorkload Console

MasterDomainManager

Atlanta

Denver

Atlanta Denver

Agent

Backup MasterDomain Manager

Or:

MasterDomainManager

MasterDomainManager

Agent Agent

Agent

Agent Agent Agent

Example 1

Example 2

BackupMasterDomainManager

Agent

Figure 10. Single domain topology on multiple sites


A multiple domain network consists of a master domain manager, any number oflower tier domain managers, and any number of agents in each domain. Agentscommunicate only with their domain managers, and domain managerscommunicate with their parent domain managers. The hierarchy of domains cango down to any number of levels.

As Figure 11 illustrates, the master domain manager is located in Atlanta. Themaster domain manager contains the database files used to document thescheduling objects, and distributes the Symphony file to its agents and the domainmanagers in Denver and Los Angeles. The Denver and Los Angeles domainmanagers then distribute the Symphony file to their agents and subordinate

DynamicWorkload Console

MasterDomainManager

Master domain

Denver

Backup MasterDomain Manager

Agent

DomainManager

Agent Agent Agent

Second-leveldomains

LosAngeles

DomainManager

Agent

Agent

NewYork

DomainManager

Agent Agent

AuroraDomainManager

Agent Agent

Burbank

DomainManager

Agent Agent

Third-leveldomains

Atlanta

Figure 11. Multiple domain topology


domain managers in New York, Aurora, and Burbank. The master domainmanager in Atlanta is responsible for broadcasting inter-domain informationthroughout the network.

All communication to and from the New York domain manager is routed throughits parent domain manager in Denver. If there are schedules or jobs in the NewYork domain that are dependent on schedules or jobs in the Aurora domain, thosedependencies are resolved by the Denver domain manager. Most inter-agentdependencies are handled locally by the lower tier domain managers, greatlyreducing traffic on the network.

Workstation classesWorkstations are organized into domains to make your network managementeasier and more efficient. However, the domain name is not one of the selectioncriteria when choosing where to run a job or job stream.

If you want to group workstations together because they have similar jobscheduling characteristics, use a workstation class. Any number of workstationscan be grouped in a class, and a workstation can be in many classes. Jobs and jobstreams can be assigned to run on a specific workstation class.

For example, you could set up workstation classes to group workstations accordingto:v Your internal departmental structure, so that you could define a job that would

be run on all the workstations in a departmentv The software installed on them, so that you could define a job that would be run

on all the workstations that had a particular application installedv The role of the user, so that you could define a job that would be run on all the

workstations belonging to, for example, managers

In this example, an individual workstation could be in one workstation class for itsdepartment, another for its user, and several others for the software installed on it.

Time zone considerationsTime zone support is an optional feature that is enabled by default.

It allows you to manage workloads at a global level. Time zone implementationalso enables easy scheduling across multiple time zones.

For a description of how the time zone implementation works, see User's Guide andReference.

For information about how to set the time zone implementation, see IBM WorkloadScheduler: Administration Guide.


Chapter 2. Installation considerations

Some considerations that need to be taken into account before installation.

About this task

Before you begin the installation using the installation wizard, consider thefollowing items that might apply to your specific environment.

Installing on Windows operating systems

If you are installing on Windows, consider the following items.v If you are using Windows Terminal Services, set the install user with the

command: change user /installv If is a domain user, Microsoft Computer Browser Service

must be active.v If is a domain user, the user performing the installation

must be a domain administrator.

Remote installationYou cannot install IBM Workload Scheduler on a Windows workstationfrom a remote Samba-mounted file system.

Installing for end-to-end scheduling

If you are installing IBM Workload Scheduler on a workstation used as adistributed agent (that is either a standard agent, fault-tolerant agent, ordomain manager) for end-to-end scheduling, specify OPCMASTER as thename of the master domain manager during the installation process. Forfurther information about installing for end-to-end scheduling, seeScheduling End-to-end with Fault Tolerance Capabilities.

Create symbolic linksUNIX and Linux. The installation wizard installs all executable files in itsown .bin directory. Before running any IBM Workload Schedulercommands, you run a script that sets the command-line environment toaccess these files. To avoid having to set the environment each time youwant to run any of the commands from within a script, you can select aninstallation option to create symbolic links to those commands or utilitiesmost frequently used from within scripts. Table 2 shows the binary pathsand the symbolic links.

Table 2. Symbolic link options

TWS binary path Symbolic link

/bin/at usr/bin/mat

/bin/batch usr/bin/mbatch

/bin/datecalc usr/bin/datecalc

/bin/jobstdl usr/bin/jobstdl

/bin/maestro usr/bin/maestro

/bin/mdemon usr/bin/mdemon

/bin/morestdl usr/bin/morestdl

/bin/muser usr/bin/muser

25

Table 2. Symbolic link options (continued)

TWS binary path Symbolic link

/bin/parms usr/bin/parms

Installation pathsIBM Workload Automation is the name of a family of products and components,which includes the following:v IBM Workload Schedulerv IBM Z Workload Schedulerv IBM Workload Scheduler for Applicationsv Dynamic Workload Console

Many IBM Workload Scheduler components are installed in what is called an IBMWorkload Automation instance.

This section describes the installation paths of the IBM Workload Schedulercomponents:

TWA_home installation pathMany of the components are installed in an IBM Workload Automationinstance. Although this is a notional structure it is represented on thecomputer where you install IBM Workload Automation components by acommon directory referred to in the documentation as TWA_home. Thepath of this directory is determined when you install an IBM WorkloadScheduler component for the first time on a computer. You have theopportunity to choose the path when you make that first-time installation,but if you accept the default path, it is as follows:

On UNIX operating systems/opt/wa/server_

On Windows operating systems%Program Files%\wa\server

where is an integer value ranging from 0 for the first instanceinstalled, 1 for the second, and so on.

This path is called, in the publications, TWA_home. For details about thedirectories created outside of TWA_home, see the section about directoriescreated outside of TWA_home in Planning and Installation Guide.

TWA_DATA_DIR and DWC_DATA_dir configuration directories

To simplify administration, configuration, and backup and recovery, a newdefault behavior has been implemented with regard to the storage ofproduct data and data generated by IBM Workload Scheduler, such as logsand configuration information. These files are now stored by default in the directory, which you can optionally customize at installationtime.


\

\\

\

\

\

\

\\

\\

\\\\\\\\\

\\

\\

\\

\\\

\

\\\\\\

By default, this directory is TWA_home/TWSDATA for the server and agentcomponents, and DWC_home/DWC_DATA for the Dynamic Workload Console.The product binaries are stored instead, in the installation directory.

You can optionally customize the directory at installation timeby setting the --data_dir argument when you install using thecommand-line installation. If you want to maintain the previous behavior,you can set the --data_dir argument to the IBM Workload Schedulerinstallation directory.

If you deploy the product components using Docker containers, the is set to the default directory name and location, and it cannotbe modified.

To retrieve the TWA_DATA_DIR and DWC_DATA_dir location in case youhave modified the default path, check the values for the TWS_datadir andDWC_datadir properties stored in thetwainstance.TWA.properties file. The file is located inthe following paths:

UNIX and Linux operating systems/etc/TWA

Windows operating systems%windir%\TWA

On the master domain manager, you can also proceed as follows:1. Browse to /TWS path.2. Source the . ./tws_env.sh shell script.3. Type echo $UNISONWORK. As a result, the path to the TWA_DATA_DIR is

returned.

IBM Workload Scheduler installation pathYou can install more than one IBM Workload Scheduler component (masterdomain manager, backup master domain manager, domain manager, orbackup domain manager) on a system, but each is installed in a separateinstance of IBM Workload Automation, as described above.

The installation path of IBM Workload Scheduler is:/TWS

DWC_home installation pathThe Dynamic Workload Console can be installed in the path of yourchoice, but the default installation path is as follows:

On UNIX operating systems/opt/wa/DWC

On Windows operating systems%ProgramFiles%\wa\DWC

IBM Workload Scheduler agent installation pathThe agent also uses the same default path structure, but has its ownseparate installation directory:

/TWS/ITA/cpa

Chapter 2. Installation considerations 27

\\\

\\\\\

\\\

\\\\\

\\

\\

\

\

\

\\

\\\\\

\

\

\\\

\\

\\

\\\

\

Note: The agent also installs some files outside this path. If you have toshare, map, or copy the agent files (for example when configuring supportfor clustering) share, map, or copy these files, as well:

On UNIX operating systems/etc/teb/teb_tws_cpa_agent_.ini/opt/IBM/CAP/EMICPA_default.xml/etc/init.d/tebctl-tws_cpa_agent_

(on Linux and Solaris)/etc/rc.d/init.d/tebctl-tws_cpa_agent_

(on AIX)/sbin/init.d/tebctl-tws_cpa_agent_

(on HP-UX)

On Windows operating systems%windir%\teb\teb_tws_cpa_agent_.ini%ALLUSERSPROFILE%\IBM\CAP\EMICPA_default.xml

The agent uses the following configuration files which you might need tomodify:

JobManager.iniThis file contains the parameters that tell the agent how to runjobs. You should only change the parameters if advised to do so inthe IBM Workload Scheduler documentation or requested to do soby IBM Software Support. Its path is:

On UNIX operating systemsTWA_DATA_DIR/ITA/cpa/config/JobManager.ini

On Windows operating systemsTWA_home\TWS\ITA\cpa\config\JobManager.ini

JobManagerGW.iniWhen a dynamic agent is installed and -gateway local|remote isspecified, then this file contains the same parameters as theJobManager.ini file except for the following differences:v The ResourceAdvisorUrl parameter points to the dynamic

workload broker, and not the master domain manager.

The JobManagerGW.ini file is installed in the following location:

On UNIX operating systemsTWA_DATA_DIR/ITA/cpa/config/JobManagerGW.ini

On Windows operating systemsTWA_home\TWS\ITA\cpa\config\JobManagerGW.ini

ita.ini This file contains parameters which determine how the agentbehaves. Changing these parameters may compromise the agentfunctionality and require it to be reinstalled. You should onlychange the parameters if advised to do so in the IBM WorkloadScheduler documentation or requested to do so by IBM SoftwareSupport. Its path is:


\\\

\\\\\\\\\

\\\

\\

\\\\\

\\

\\

\\\\

\\

\

\\

\\

\\\\\\\

On UNIX operating systemsTWA_DATA_DIR/ITA/cpa/ita/ita.ini

On Windows operating systemsTWA_homeTWS\ITA\cpa\config\ita.ini

Installation path for files giving the dynamic scheduling capabilityThe files that give the dynamic scheduling capability are installed in thefollowing path:

/TDWB

The command line client installation pathThe command line client is installed outside all IBM Workload Automationinstances. Its default path is:

TWA_home/TWS/CLI

However, the information above supplies only the default paths. To determine theactual paths of products and components installed in IBM Workload Automationinstances, see “Finding out what has been installed in which IBM WorkloadAutomation instances”

Finding out what has been installed in which IBM WorkloadAutomation instances

About this task

If you are not the installer of IBM Workload Scheduler and its components, youmight not know what components have been installed, and in which instances ofIBM Workload Automation. Follow this procedure to find out:1. Access the following directory:

UNIX and Linux operating systems/etc/TWA

Windows operating systems%windir%\TWA

2. List the contents of the directory. Each IBM Workload Automation instance isrepresented by a file called: twainstance.TWA.properties.These files are deleted when all the products or components in an instance areuninstalled, so the number of files present indicates the number of validinstances currently in use.

3. Open a file in a text viewer.Attention: Do not edit the contents of this file, unless directed to do so byIBM Software Support. Doing so might invalidate your IBM WorkloadScheduler environment.

The contents are similar to this on a master domain manager :#TWAInstance registry#Tue Feb 26 09:28:08 EST 2019TWA_path=/opt/wa/server_twsuserTWA_componentList=TWS


\\

\\

\\\

\

\\\

\

\\\\

TWS_version=9.5.0.00TWS_counter=1TWS_instance_type=MDMTWS_basePath=/opt/wa/server_twsuser/TWSTWS_user_name=twsuserTWS_wlpdir=/opt/wa/wlpEngine/wlpTWS_datadir=/opt/wa/server_twsuser/TWSDATATWS_jdbcdir=/opt/wa/server_twsuser/TWS/jdbcdrivers/db2

The contents are similar to this on the Dynamic Workload Console:#TWAInstance registry#Tue Feb 26 09:42:10 EST 2019TWA_path=/opt/wa/DWCTWA_componentList=DWCDWC_version=9.5.0.00DWC_counter=1DWC_instance_type=DWCDWC_basePath=/opt/wa/DWCDWC_user_name=dwcadminDWC_wlpdir=/opt/wa/wlpDWC/wlpDWC_datadir=/opt/wa/DWC/DWC_DATADWC_jdbcdir=/opt/wa/DWC/jdbcdrivers/derby

The important keys to interpret in this file are:

TWA_pathThis is the base path, to which the installation added one or more of thefollowing directories, depending on what was installed:

TWS Where the IBM Workload Scheduler component is installed

DWC Where the Dynamic Workload Console is installed

ssm Where the Netcool® SSM monitoring agent is installed (used inevent management)

TWA_componentListLists the components installed in the instance of IBM WorkloadAutomation.

TWS_counterIndicates if an IBM Workload Scheduler component is installed in thisinstance of IBM Workload Automation (when the value=1).

TWS_instance_typeIndicates which component of IBM Workload Scheduler is installed in thisinstance:

MDM Master domain manager

BKM Backup master domain manager

DDM dynamic domain manager

FTA Fault-tolerant agent or domain manager

TWS_user_nameThe ID of the of the IBM Workload Scheduler component.

TWS_wlpdirThe installation directory of the WebSphere Application Server Liberty Baseinstance used by IBM Workload Scheduler.


TWS_datadirThe directory containing product data and data generated by IBMWorkload Scheduler, such as logs and configuration information.

DWC_counterIndicates if an instance of Dynamic Workload Console is installed in thisinstance of IBM Workload Automation (when the value=1)

DWC_user_nameThe ID of the Dynamic Workload Console user.

DWC_wlpdirThe installation directory of the WebSphere Application Server Liberty Baseinstance used by Dynamic Workload Console.

DWC_datadirThe directory containing product data and data generated by DynamicWorkload Console, such as logs and configuration information.

Directories created outside of TWA_home at installation timeThe following list shows the directories that are created outside of TWA_homewhen you install IBM Workload Scheduler.

Windows operating systems%WINDIR%\TWA

%WINDIR%\system32\TWSRegistry.dat (32 bits)%WINDIR%\sysWOW64\TWSRegistry.dat (32 bits on 64 bits)%WINDIR%\TWSRegistry.dat (64 bits on 64 bits)%WINDIR%teb%WINDiR%\cit%ProgramFiles%\tivoli\cit (or the path specified by %WINDiR%\cit\cit.ini)

UNIX/etc/TWA/etc/TWS/etc/teb/etc/cit/etc/init.d/tebclt-tws_cpa_agent_/usr/Tivoli/TWS/usr/ibm/tivoli/common/CIT/logs/opt/tivoli/cit (or the path specified by /etc/tivoli/cit/cit.ini)

Windows servicesWhen installing on the Windows operating system the Windows Service ControlManager registers services.

About this task

An installation on Windows operating systems registers the following services onthe Windows Service Control Manager:v IBM Workload Scheduler (for )v Netman (for )v Token Service (for ) - includes the In-Flight Tracing facility servicev IBM Workload Scheduler SSM Agent (for )


v WebSphere Application Server Liberty Base (for )v IBM Common Platform Agent: tws_cpa_agent_ (for )

Note: An existing service that has the same name as the new service will beoverwritten during installation.

The Service Control Manager maintains its own user password database. If the password is changed after installation, you must use the Servicesapplet in the Control Panel to assign the new password for the Token Service andIBM Workload Scheduler (for ). For more information, see the sectionabout changing the password of the TWS_User in IBM Workload Scheduler:Administration Guide.


Part 2. Installing IBM Workload Scheduler

Available installation methods

About this task

This section provides the information required before you install the product. Theavailable installation methods are listed, together with some considerations:

Advantages of the command-line installationThe command-line installation is a very simple procedure, which supportsinstalling all components (master domain manager, backup domainmanager, dynamic domain manager, backup dynamic domain manager,Dynamic Workload Console, and agents) using dedicated commands. Youcan choose to maintain the default values already defined in the propertiesfile, specify all or part of the parameters in the command line when typingthe command, or edit all or part of the parameters stored in the propertiesfile. To proceed with the command-line installation, skip to Chapter 3,“Installing from the CLI,” on page 35.

Advantages of the Docker installationThe Docker installation is comprised of a set of pre-installed images for themaster domain manager, the Dynamic Workload Console, and the DB2database. All you have to do is launch the Docker installation commands.

Docker is a state-of-the-art technology which creates, deploys, and runsapplications by using containers. Packages are provided containing anapplication with all of the components it requires, such as libraries, specificconfigurations, and other dependencies, and deploy it in no time on anyother Linux or Windows workstation, regardless of any different settingsbetween the source and the target workstation.

Docker adoption ensures standardization of your workload schedulingenvironment and provides an easy method to replicate environmentsquickly in development, build, test, and production environments,speeding up the time it takes to get from build to production significantly.Install your environment using Docker to improve scalability, portability,and efficiency.To proceed with the Docker installation, skip to “Deployingwith Docker compose” on page 124.

Advantages of the installation on IBM Cloud Private

The IBM Workload Automation Server, IBM Workload AutomationConsole, and IBM Workload Automation Agent components can bedeployed into IBM Cloud Private, an application platform for developingand managing on-premises, containerized applications.

IBM Cloud Private provides an integrated environment for managingcontainers that includes the container orchestrator Kubernetes, a privateimage repository, a management console, and monitoring frameworks.With IBM Cloud Private, you can deploy the IBM Workload Automationcomponents as Helm charts to quickly configure and run them as Dockercontainer applications in a Kubernetes cluster. You can then manage theIBM Workload Automation components from the IBM Cloud Privatedashboard or from the command-line interface.

33

\

\

\

\

\\

\\\\\\\\\\

\\\\

\\\\\\

\\\\\\\

\

\\\\

\\\\\\\\

Docker adoption ensures standardization of your workload schedulingenvironment and provides an easy method to replicate environments quickly indevelopment, build, test, and production environments, speeding up the time ittakes to get from build to production significantly. Install your environment usingDocker to improve scalability, portability, and efficiency.

To proceed with the Docker installation, skip to “Deploying IBM WorkloadAutomation in IBM Cloud Private” on page 127.


\\\\\

\\

Chapter 3. Installing from the CLI

Install, upgrade and uninstall IBM Workload Scheduler from the command-lineinterface.

Downloading installation imagesSteps to take when downloading images on your workstation.

About this task

To perform a fresh install at the latest product version, download the installationimages from IBM Fix Central.

Procedure1. Ensure that your workstation has sufficient space to store the compressed file

containing the installation images. For more information about systemrequirements, see IBM Workload Scheduler Detailed System Requirements.

2. From IBM Fix Central, download the compressed file, containing both theGeneral Availability version 9.5 image and the latest fix pack image, to atemporary directory.

3. Extract the installation image from the downloaded file and verify that theinstallation image is complete. Extract the content of the ZIP files into adirectory, using one of the extraction tools available on your system or that canbe downloaded from the internet. The tool you use must be able to keep thefile permissions on the extracted files, for example, infozip. On Windowssystems, ensure that you extract the image into a path that is not very long,otherwise, the file name might be truncated. The maximum length allowed is255 characters. If you are installing on a UNIX operating system, run thefollowing command:chmod -R 755

Note: To extract the .zip file onto a Windows 64-bit system, ensure that theimage is not located on the desktop because the Windows operating systemextract tool has a problem. Choose another directory into which to extract theFix Pack image.For more information about eImages, see the Download Document at IBMWorkload Scheduler download document and Fix Pack readmes

PrerequisitesWhen installing a master domain manager or a dynamic domain manager considerthe following prerequisites.

The master domain manager or a dynamic domain manager installation have thefollowing prerequisites:

To produce a dynamic report that lists the supported operating systems, clickSupported operating systems.

35

\

\

\\

\\

\

\

\\

\

\\\

\\\

\\\\\\\\\

\

\\\\

\\

\\

\\

\\

\\

https://www-945.ibm.com/support/fixcentralhttp://www.ibm.com/support/docview.wss?uid=ibm10742497https://www-945.ibm.com/support/fixcentralhttp://www.ibm.com/support/docview.wss?uid=ibm10742761http://www.ibm.com/support/docview.wss?uid=ibm10742761https://www.ibm.com/software/reports/compatibility/clarity-reports/report/html/osForProduct?deliverableId=E9230C00CE1611E78F8FA93481EF6122&osPlatforms=AIX|HP|IBM%20i|Linux|Solaris|Windows|z/OS&duComponentIds=S004|S005|A001|A003|A002

For a complete list of system requirements (disk spaces, temporary spaces andRAM usage), see IBM Workload Scheduler Detailed System Requirements.

The following requirements apply to the RDBMS systems:

DB2

You can install DB2 in the following ways:

DB2 Enterprise Server Edition

A version of DB2 is bundled with the installation image. You caninstall DB2 in the following ways:

Server Install DB2 Server and the master domain manager on thesame workstation.

Client Install DB2 Server on one workstation. DB2 client and themaster domain manager or the dynamic domain manageron a different workstation. The advantage of thisconfiguration is that you can easily switch between yourmaster domain manager and its backup or switch betweenyour dynamic domain manager or its backup, if necessary.

You can install DB2 manually.

To install DB2 manually, run the DB2 server or client installation programon the product image. The setup files for DB2 are on the product images asfollows:

Table 3. DB2 Setup files

Operating System Setup file

AIX®, HP-UX/IA64, SunOS/SPARC,SunOS/SPARC64, all Linux operatingsystems

DB2/server/db2setup

SunOS/AMD64 DB2/wse/db2setup

Windows/x86 and Windows/AMD64 DB2\SERVER\setup.exe

Oracle

You can install Oracle in the following ways:

Oracle Enterprise EditionThe advantage of choosing Oracle Enterprise Edition is that youcan implement the Oracle Partitioning feature to improve theperformance of event-driven workload automation. This improvesrule management performance, in particular the following queries:event_rule_instance, action_run, and operator_messages. Forinformation about event-driven workload automation, seeOverview.

Oracle Standard EditionOracle Standard Edition does not include the Oracle Partitioningfeature. Installing this edition does not improve the performance ofevent-driven workload automation.

For supported versions, see the IBM Workload Scheduler SystemRequirements Document at IBM Workload Scheduler Detailed SystemRequirements.

Note:


\\

\

\

\

\

\\

\\\

\\\\\\\

\

\\\

\\

\\

\\\

\

\\

\\\

\

\

\\\\\\\\

\\\\

\\\

\

http://www.ibm.com/support/docview.wss?uid=ibm10742497http://www.ibm.com/support/docview.wss?uid=ibm10742497http://www.ibm.com/support/docview.wss?uid=ibm10742497

v When installing the product on a 64-bit library operating system, use anOracle database on a 64-bit library.

v When upgrading:– If you already have an RDBMS installed and you want to upgrade it,

you must upgrade it after you upgrade IBM Workload Scheduler.– Use an Oracle database on a 64-bit library when installing the product

on a 64-bit library.

For information about upgrading the RDBMS, see the data maintenancechapter in the Administration Guide.

Informix

You must have Informix Dynamic Server installed already before youinstall IBM Workload Scheduler for the first time. Also, before you createthe IBM Workload Scheduler schema on the database, you must havecreated the following db and sb spaces:v A db space sized 100 MB and with a page size of 8K or greater, referred

to as DBSPNAME in the properties file customization steps.v A db space space sized 20 MB, referred to as TWS_DBSP_LOG in the

properties file customization steps.v An sb space for blob and clob data, sized 100 MB, referred to as

TWS_SBSP in the properties file customization steps.

MSSQL

Before you install IBM Workload Scheduler for the first time, you musthave Microsoft SQL Server installed. Ensure you downloaded the JDBCdriver for Microsoft SQL Server, including the following prerequisiteslibraries and class library files :v sqljdbc_auth.dllv sqljdbc4.jarv sqljdbc.jar

Also, before you create the IBM Workload Scheduler schema on thedatabase, you must have created the directory where the IBM WorkloadScheduler table spaces will be placed when the IBM Workload Schedulerschema is created. The default is C:\MSSQL.

For a complete list of the correct versions to install, see the System RequirementsDocument at IBM Workload Scheduler Detailed System Requirements.

IBM Workload Scheduler user managementThe IBM Workload Scheduler user management on UNIX and Windows operatingsystems

About this task

Consider the following constraints and properties for the IBM Workload Scheduleruser:

On Windows operating systems:The installation process automatically creates the IBM Workload Scheduleruser. If your security policies do not allow user creation during the

Chapter 3. Installing from the CLI 37

\\

\

\\

\\

\\

\

\\\\

\\

\\

\\

\

\\\\

\

\

\

\\\\

\\

\

\\

\

\\

\\\

http://www.ibm.com/support/docview.wss?uid=ibm10742497

installation process, create the user and give it the necessary right asdescribed in “Windows user domain rights and structure.”

On UNIX and Linux operating systems:Regardless of the method of installation you choose, the IBM WorkloadScheduler user must be created manually before running the installation.Use the appropriate UNIX and Linux operating system commands tocreate the user.

Note: Some operating systems require that for users with a password, thepassword must be changed at the first login. If this is your situation, for asuccessful installation, you will need to log in as the user and change thepassword for the first time.

Windows user domain rights and structureAbout this task

If you install on Windows operating systems, consider thefollowing information.

For the installation:

v You cannot have a local user and a domain user with the same name.For example, you cannot have user1 as local user and at the same timeuser1@domain1 and domain\user1.

v The Windows user performing an agent installation must:– For a local TWS user, be a member of the local administrative group– For a domain TWS user, be a member of the domain "users" group in

the domain controller and be a member of the local administrativegroup.

For Windows IBM Workload Scheduler users:All Windows IBM Workload Scheduler users must have the following userpermissions. They can be granted locally. Domain level policies alwaysoverride local policies, so you might be required to grant the permissionsfrom the domain:v Act as part of the operating systemv Allow log on locallyv Impersonate a client after authenticationv Log on as a batch jobv Log on as a servicev Replace a process level tokenv Adjust memory quotas for a process (available on some configurations

only)

Note: These rights are granted during the installation, but you can confirmthem manually.

To run IBM Workload Scheduler command lines:

On Windows operating systems with UAC disabled:In addition to standard Windows permissions, to log on to themachine, the user must have the "Impersonate a client afterauthentication" permission granted. By default, this is granted just


\\

\\\\\

\\\\

\\

\\

\

\\\

\

\

\\\

\\\\\

\

\

\

\

\

\

\\

\\

\

\\\\

to the "Administrators" group members. This permission isrequired to impersonate the TWS user and access the IBMWorkload Scheduler Symphony and Mailbox.

On Windows operating systems with UAC enabled:This is the default value. The "Impersonate a client afterauthentication" is not available to the user, unless the cmd shell isstarted with "Run as administrator" permission. To run IBMWorkload Scheduler command lines, the user must have"Impersonate a client after authentication" permission defined andthen start the shell with the "Run as administrator" permissionauthenticating with its own user ID.

For the Streamlogon user:The user must have the "logon as batch" permission to allow IBMWorkload Scheduler to create the job process. In addition, you must assignto the user "Read" and "Read & execute" permission to cmd.exe. You canassign "Read" and "Read & execute" permission to cmd.exe also to theBATCH built-in group instead of to a single user.

To manage IBM Workload Scheduler agents:The user must be in the Administrators group or must be able to perform"Run as" as twsuser to reset the IBM Workload Scheduler files if a recoveryis needed.

Considerations for Windows domain controllers runningMicrosoft Active DirectoryIf you want to install a IBM Workload Scheduler fault-tolerant agent onworkstations where users who run jobs are domain users and the domaincontroller is running the Microsoft Active Directory, decide how to install theagents and configure the domain to have thejobmon process obtain the correctinformation to allow the users to run jobs.

About this task

Before running a job, jobmon retrieves information about the user running the job.If the user is a domain user and the domain controller is running Microsoft ActiveDirectory, whether the user information can be retrieved depends on theinformation in the access control list (ACL) of that user. The main jobmon processthat runs the job is started as the local system account (AUTHORITY\SYSTEM),but it immediately impersonates the that owns the fault-tolerantagent. This means that for jobmon to successfully launch the job, the must have an access control entry (ACE) in the ACL of the user for which it istrying to retrieve information.

Perform one of the following actions:

Enable the to access a set of users that run jobsOn the domain server, edit the ACL of all users that run jobs on theworkstation and add an ACE for each . In this case, onlyspecified users can run the jobs submitted by jobmon.

Allow all users to run jobs submitted by jobmon by using theTWS_BYPASS_DC=TRUE system variable

Create the TWS_BYPASS_DC=TRUE system variable, with a value not null,and reboot the workstation. In this case,jobmon obtains the userinformation without performing the security check for the ACE in the ACLof the user. All the local and domain users can run the jobs submitted byjobmon.

Chapter 3. Installing from the CLI 39

\\\

\\\\\\\\

\\\\\\

\\\\

\\\\\\\

\

\\\\\\\\\

\

\\\\

\\\\\\\

Allow all users to run jobs submitted by jobmon by setting the as adomain user

Set up the as a Windows domain user and install the instanceof IBM Workload Scheduler using the . In this case, allauthenticated users on the domain controller can access the default ACLfor a domain user. Jobs can then be launched by both local and the domainusers. All the local and the domain users can run the jobs submitted byjobmon.

Exclude the workstation from the security check on users ACLOn the domain server, add the host name of the workstation where thefault-tolerant agent is installed to the Pre-Windows 2000-Compatible AccessGroup. In this way, from a security point of view, the domain controllerinteracts with this workstation as if it is in a Windows domain that doesnot support Active Directory. In this case, all the local and doma

Date post:	23-Jul-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

I B M W o r kl o a d S c h e d ul e r IBM...Befor e using this information and the pr oduct it...

Documents