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. The documentation has been updated for version 10.2 SPE (Revised July 2025).
Customization and Tuning
Customizing IBM Z Workload Scheduler
Implementing security
This chapter explains how you use IBM Z Workload Scheduler security features to protect IBM Z Workload Scheduler functions and data.
Examples of security strategies
A decentralized security strategy
Most IBM Z Workload Scheduler work is delegated to representatives of the user departments. They perform all IBM Z Workload Scheduler functions (including reruns and JCL corrections during the day) but only for the applications in their own department.

Product requirements
This section contains links to the IBM® Workload Scheduler Download Documents, System Requirements, and Release Notes.
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.2.5.
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. The documentation has been updated for version 10.2 SPE (Revised July 2025).
- 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
  - About this publication
  - Customizing IBM Z Workload Scheduler
    - Defining initialization statements
      The initialization statements determine the tasks that IBM Z Workload Scheduler starts, how IBM Z Workload Scheduler processes work, and the functions that you can use.
    - Identifying related initialization-statement parameters
    - Implementing security
      This chapter explains how you use IBM Z Workload Scheduler security features to protect IBM Z Workload Scheduler functions and data.
      - Planning security implementation
        Consider the tasks in this section when determining your security requirements.
      - Customizing TLS to connect components with IBM Z Workload Scheduler
      - Controlling access to IBM Z Workload Scheduler
      - Functions and data that you can protect
        You can use fixed resources and subresources to protect IBM Z Workload Scheduler functions and data.
      - Access requirements to fixed resources for dialog users
        To use an IBM Z Workload Scheduler dialog, you need the authority to access the required resources.
      - Examples of security strategies
        A centralized security strategy
        All IBM Z Workload Scheduler users are gathered in one area. They have at least a working knowledge of all the major functions of IBM Z Workload Scheduler. Because they share the same tasks, there is little need to divide authority.
        A decentralized security strategy
        Most IBM Z Workload Scheduler work is delegated to representatives of the user departments. They perform all IBM Z Workload Scheduler functions (including reruns and JCL corrections during the day) but only for the applications in their own department.
        External access to IBM Z Workload Scheduler
        Access through the IBM Z Workload Scheduler subsystem
    - IBM Z Workload Scheduler exits
      Read the following information to understand General-use Programming Interface and Associated Guidance Information. It describes exits that are called by IBM Z Workload Scheduler. Your own programs can use the information passed by the exits to perform a variety of functions.
    - Open Systems Integration
    - Reporting Events
    - Using the Job Completion Checker
    - Using the data store
    - Miscellaneous customization
  - Data integrity
  - Tuning
  - IBM Z Workload Scheduler macros
  - Sample library (SEQQSAMP)
- 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
- 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
Notices

A decentralized security strategy

Most IBM Z Workload Scheduler work is delegated to representatives of the user departments. They perform all IBM Z Workload Scheduler functions (including reruns and JCL corrections during the day) but only for the applications in their own department.

During the second and third shifts, machine-room operators take care of reruns and JCL corrections for all departments.

These RACF® groups are defined:

Group: Contains
OPCGROUP: Most of the IBM Z Workload Scheduler users. Unlike the users in a centralized installation, these users work alone and perform all IBM Z Workload Scheduler functions on a limited number of applications.
OPCSPEC: The schedulers and system support people who keep IBM Z Workload Scheduler running continuously.
OPER: The people who correct jobs that end in error overnight.

The major difference from a centralized installation is that authority is divided by department, not by IBM Z Workload Scheduler function. The decentralized location relies mainly on IBM Z Workload Scheduler subresources for security. This makes name standards more important if the number of profiles is to be kept to a minimum. The administrator must decide which subresource names to use. For example, access to applications could be restricted by job name, owner ID, or authority group ID. Critical functions such as REFR (refresh) should not be decentralized.