Access through the HCL Workload Automation for Z subsystem

About this task

These authorization layers are defined:

Subsystem access: All groups are given update access to the HCL Workload Automation for Z subsystem in the APPL class. This lets all users update most HCL Workload Automation for Z functions (fixed resources) for their own department. The APPL class specification is the default if a fixed resource is defined.
Another way to handle fixed resources is to define them individually and give update access to OPCGROUP and OPCSPEC. But the OPER group needs update access only to CP, JS, and RL (for JCL corrections and reruns). They could have ACCESS(NONE) to the rest of the fixed resources. This would prevent them from entering any HCL Workload Automation for Z dialog that they do not need for their work.
Critical functions: Some fixed resources, such as JSUB and REFR, represent functions that have a serious impact on HCL Workload Automation for Z operation, and can be turned on or off with a single keystroke. Access to these functions should not be decentralized. Access is restricted to OPCSPEC to reduce the risk of accidental errors:
```
 RDEFINE (OPCCLASS) ARC UACC(NONE)
 PERMIT ARC ID(OPCSPEC) ACCESS(UPDATE) CLASS(OPCCLASS)
```
These steps are repeated for ETAC, JSUB, and REFR.

Subresource protection: The installation protects access to applications and JCL using subresources. But the installation does not have consistent naming conventions for applications. So subresource protection is implemented through the owner ID and job name, which have consistent naming conventions.

These subresources are specified on the AUTHDEF statement:

Table 1. Subresources specified on the AUTHDEF statement
subresources
AD.JOBNAME	LT.OWNER
AD.OWNER	JS.JOBNAME
CP.JOBNAME	JS.OWNER
CP.OWNER	RL.OWNER.

The subresources AD.JOBNAME, CP.JOBNAME, and JS.JOBNAME are used to prevent users from specifying unauthorized job names when they create an application. Otherwise, HCL Workload Automation for Z could be used to submit a job with a job name that the users do not normally have access to.

The RACF® resource names are defined with ACCESS(NONE), so the default access for all users to these subresources is NONE:
```
 RDEFINE (OPCCLASS) ADJ.* UACC(NONE)
```
This is repeated for ADO.*, CPJ.*, CPO.*, LTO.*, JSJ.*, JSO.*, and RLO.* resource names.
When profiles are created, OPCGROUP members receive the authority to decide the access list to their own subresources.
OPCSPEC is given update access in case this is needed for support:
```
 PERMIT ADO.* ID(OPCSPEC) ACCESS(UPDATE) CLASS(OPCCLASS)
```
This is repeated for each subresource.

OPER is given access to the CP.OWNER, CP.JOBNAME, JS.JOBNAME, JS.OWNER, and RL.OWNER subresources so that operators can work during night shifts:

 PERMIT CPO.* ID(OPER) ACCESS(UPDATE) CLASS(OPCCLASS)
 PERMIT CPJ.* ID(OPER) ACCESS(UPDATE) CLASS(OPCCLASS)
 PERMIT JSJ.* ID(OPER) ACCESS(UPDATE) CLASS(OPCCLASS)
 PERMIT JSO.* ID(OPER) ACCESS(UPDATE) CLASS(OPCCLASS)
 PERMIT RLO.* ID(OPER) ACCESS(UPDATE) CLASS(OPCCLASS)

If many resources with similar names have the same access list, the resources can be grouped under generic profiles with the percent sign (%). For example, the ADO, CPO, JSO, LTO™, and RLO profiles could be specified as one profile, %%O.*. Note that *O.* is an invalid RACF® entity.

Many RACF® resource names must be defined in the OPCCLASS resource class to protect the data of every owner. Each subresource has its own profile, unless some subresources can be grouped under generic profiles. For example, the owner IDs PAYROLL, PAYROLL-A, and PAYROLL-02, can be grouped as PAYROLL*.

Defining profiles might seem like a lot of work, but the number of owners is usually limited, and you can often use generic profiles. Because you can have many more job names than owner IDs, generic definitions of job names are even more important. Most jobs can be handled with a small number of generic profiles.