Home
HCL Workload Automation for Z
Welcome to the HCL Workload Automation for Z documentation, where you can find information about how to install, maintain, and use the product.
Customization and Tuning
Customizing HCL Workload Automation for Z
Implementing security
This chapter explains how you use HCL Workload Automation for Z security features to protect HCL Workload Automation for Z functions and data.
Examples of security strategies
A decentralized security strategy
Most HCL Workload Automation for Z work is delegated to representatives of the user departments. They perform all HCL Workload Automation for Z functions (including reruns and JCL corrections during the day) but only for the applications in their own department.

HCL Workload Automation for Z
Welcome to the HCL Workload Automation for Z documentation, where you can find information about how to install, maintain, and use the product.
- 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 HCL Workload Automation for Z
    - Defining initialization statements
    - Identifying related initialization-statement parameters
    - Implementing security
      This chapter explains how you use HCL Workload Automation for Z security features to protect HCL Workload Automation for Z functions and data.
      - Planning security implementation
        Consider the tasks in this section when determining your security requirements.
      - Controlling access to HCL Workload Automation for Z
      - Functions and data that you can protect
        You can use fixed resources and subresources to protect HCL Workload Automation for Z functions and data.
      - Access requirements to fixed resources for dialog users
        To use an HCL Workload Automation for Z dialog, you need the authority to access the required resources.
      - Examples of security strategies
        A centralized security strategy
        All HCL Workload Automation for Z users are gathered in one area. They have at least a working knowledge of all the major functions of HCL Workload Automation for Z. Because they share the same tasks, there is little need to divide authority.
        A decentralized security strategy
        Most HCL Workload Automation for Z work is delegated to representatives of the user departments. They perform all HCL Workload Automation for Z functions (including reruns and JCL corrections during the day) but only for the applications in their own department.
        External access to HCL Workload Automation for Z
        Access through the HCL Workload Automation for Z subsystem
    - HCL Workload Automation for Z exits
      Read the following information to understand General-use Programming Interface and Associated Guidance Information. It describes exits that are called by HCL Workload Automation for Z. 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
  - HCL Workload Automation for Z 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 HCL Workload Automation for Z

A decentralized security strategy

Most HCL Workload Automation for Z work is delegated to representatives of the user departments. They perform all HCL Workload Automation for Z 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 HCL Workload Automation for Z users. Unlike the users in a centralized installation, these users work alone and perform all HCL Workload Automation for Z functions on a limited number of applications.
OPCSPEC: The schedulers and system support people who keep HCL Workload Automation for Z 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 HCL Workload Automation for Z function. The decentralized location relies mainly on HCL Workload Automation for Z 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.

Have feedback?
Google Analytics is used to store comments and ratings. To provide a comment or rating for a topic, click Accept All Cookies or Allow All in Cookie Preferences in the footer of this page.