How to protect actions and command in Workload Scheduler for z/OS

Workload Scheduler allows now to protect not only its resources like Applications, Special resources, Jobs or all the objects present in the Current Plan or in the Database, but also actions and commands.

For example, the Workload Scheduler execution information are stored in a VSAM file called  Current Plan. The execution workflows are defined through Applications including Operations (jobs), Dependencies and other resources. Currently an WSz user can either have READ or UPDATE access to the Current plan. A user with UPDATE access can add new workload, edit occurrences, restart jobs, hold, nop, un-nop, release jobs and many other actions and commands.

With the enhancement provided in the Security feature it is possible to address to implement different access levels (actions, commands) based on the User role. So now you can easily address scenarios like the following:
Allow the System Administrator to:

• authorize the Scheduler to add operations to the Current Plan, but preventing him from adding new occurrences.
• authorize the application developer to perform a recovery action, but to prevent her from editing a job.
• authorize Jason, the scheduler, to Complete and Rerun an existing occurrence, but to prevent him from adding new occurrences.
  

​How to implement?
The old instrument of AUTHDEF parameter with its SUBRESOURCES has been extended with the addition of new subresources. So the implementation steps are still two: 

Communicate to the WSz controller which resources you want to control. You do this through the AUTHDEF parameter.

​Associate users to the resource to be authorized or denied.

​For example, if you have RACF as SAF product: 

Using the new subresources you can implement scenarios like those described above.  

The previous example shows how you can create more User Profiles that group several commands so that a number of users, with similar profiles, can be associated to a certain COMMANDx. 

​The new subresources, available to authorize specific command actions on the CP occurrences and operations, are the following:

​…and the commands that can be grouped in each COMMANDx subresource are the following:

Note that both Occurrence and Operation commands can be specified in the same COMMANDx parameter.

Raffaella Viola
Software Engineer
Workload Automation for z/OS Development