Welcome
IBM® Z Workload Scheduler
Welcome to the IBM® Z Workload Scheduler documentation, where you can find information about how to install, maintain, and use the product.
Scheduling End-to-end with Fault Tolerance Capabilities
Overview
An overview of end-to-end scheduling with fault tolerance capabilities.
End-to-end with fault tolerance capabilities environment
End-to-end with fault tolerance capabilities environment.
End-to-end scheduling with fault tolerance capabilities architecture
End-to-end scheduling with fault tolerance capabilities architecture.
Direct agent connections
Standard agents can be connected directly to OPCMASTER. The jobs that are scheduled to run on these workstations are added to the Symphony file and managed by the batchman component of the end-to-end server.

Product requirements
This section contains links to the IBM® Workload Scheduler Download Documents, System Requirements, and Release Notes.
Fix Pack readmes
For the latest information about a Fix Pack, see the appropriate Readme File.
Product Library in PDF format
This section contains links to the PDF versions of all the publications provided in IBM Documentation for IBM Workload Automation.
Considerations for GDPR readiness
Overview
Mobile Applications Userʼs Guide
Dynamic Workload Console User's Guide
AI Data Advisor (AIDA) User's Guide
Scheduling Job Integrations with IBM Workload Automation
IBM® Workload Scheduler
Welcome to the IBM® Workload Scheduler documentation, where you can find information about how to install, maintain, and use IBM Workload Scheduler. The documentation has been updated for IBM Workload Scheduler Version 10.1 Fix Pack 6.
IBM® Z Workload Scheduler
Welcome to the IBM® Z Workload Scheduler documentation, where you can find information about how to install, maintain, and use the product.
- Memo to Users
- Program Directory
- Dynamic Workload Console Readmes
  For the latest information about a Dynamic Workload Console fix pack, see the appropriate Readme File.
- Planning and Installation
- Customization and Tuning
- Managing the Workload
  You can plan when and how your workload runs and manage it as part of a plan.
- Scheduling End-to-end with z-centric Capabilities
- Scheduling End-to-end with Fault Tolerance Capabilities
  - About this publication
  - Overview
    An overview of end-to-end scheduling with fault tolerance capabilities.
    - End-to-end with fault tolerance capabilities environment
      End-to-end with fault tolerance capabilities environment.
      - The IBM Z Workload Scheduler end
        The main characteristics of the fault-tolerant end-to-end scheduling on the IBM Z Workload Scheduler system is the addition of the end-to-end server, a started task on the mainframe that works closely with the controller.
      - The IBM Workload Scheduler end
      - Distributed agents
        A distributed agent is a computer that is part of an IBM Workload Scheduler network on which you can schedule jobs from IBM Z Workload Scheduler.
      - IBM Workload Scheduler domains
        An IBM Workload Scheduler network consists of at least one domain, the master domain, in which the master domain manager is the management hub.
      - End-to-end scheduling with fault tolerance capabilities architecture
        End-to-end scheduling with fault tolerance capabilities architecture.
        Direct agent connections
        Standard agents can be connected directly to OPCMASTER. The jobs that are scheduled to run on these workstations are added to the Symphony file and managed by the batchman component of the end-to-end server.
        Choosing the agents
        What are the advantages of connecting agents directly over setting up domains? And when should standard agents be preferred to fault-tolerant ones?
    - End-to-end with fault tolerance capabilities functions
      Some actions that can be performed with end-to-end with fault tolerance capabilities.
    - Integration with IBM Workload Scheduler
    - The Symphony file
      In a native IBM Workload Scheduler network, the Symphony file, also known as the production control file, is the daily plan. The Symphony file contains the scheduling information needed by the production control process named batchman. It is typically created during the pre-production phase before the start of each new planning period by a process named Jnextplan on the master domain manager.
    - Basic server configuration example
      Example of a basic server configuration of IBM Z Workload Scheduler. IBM Z Workload Scheduler connects distributed agents to the server through TCP/IP.
    - Functional comparison between end-to-end and single scheduling environments
      Functional comparison between end-to-end and single scheduling environments
    - Terminology mapping
      Because of legacy reasons, the two scheduling engines and the Dynamic Workload Console use different names for the same scheduling objects or attributes.
  - Installing
  - Customizing
  - Managing end-to-end scheduling
  - Changing the topology of the network
- Quick Reference
- Diagnosis Guide and Reference
- Workload Automation Programming Language for z/OS User's Guide and Reference
- Driving IBM Z Workload Scheduler
Messages and Codes
Glossary
Installing IBM® Workload Scheduler
How to monitor your IBM® Workload Scheduler using the Dynamic Workload Console
How to create your scheduling environment using the Dynamic Workload Console
Notices

Direct agent connections

Standard agents can be connected directly to OPCMASTER. The jobs that are scheduled to run on these workstations are added to the Symphony file and managed by the batchman component of the end-to-end server.

Because standard agents are not fault-tolerant, when they are linked directly to OPCMASTER and active, the controller decides when their jobs must start. This allows for lighter configurations when your business needs do not require fault-tolerance on the distributed part and you want to keep the architecture of your distributed agents at a simple level.

Non-full status fault-tolerant agents also can be connected directly to OPCMASTER. They can be used together with mailman servers on the end-to-end server to improve performance. In fact, you can allocate dedicated mailman servers to critical standard or fault-tolerant agents that require extra communication resources (this feature is available also for agents not linked directly to the end-to-end server). For details about how to configure extra mailman servers, see the CPUSERVER parameter of the CPUREC statement.

There is no set limit on the maximum number of direct connections supported. The number of direct connection and mailman server definitions and the required memory allocation on the end-to-end server have been found to increase in a straight line. Benchmarking tests run on z/OS® version 1.7 have yielded the following results:

Table 1. z/OS® memory requirements for directly connected agents and mailman servers
Number of directly connected fault-tolerant and standard agents	Number of mailman servers	Size of the memory region used on the end-to-end server (MB)
100	10	85
200	20	144

The average number of mailman servers in the test configurations was one for every ten agents. The effective number in your configuration must be calibrated to respond to real needs, such as:

Compensating for particularly slow TCP/IP connections
Giving an extra resource to agents that run particularly critical workloads
Reducing the impact on the network caused by connection losses between the end-to-end server mailman and a particular unstable agent

Mailman servers should not be abused of, since they are additional processes with dedicated message queues that are bound to increase processing and disk I/O.