Access through the HCL Workload Automation for Z subsystem
About this task
- 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: 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.
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 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)
- These subresources are specified on the AUTHDEF statement:
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.