Authority problems

It is easiest to verify that the controller has been correctly installed without activating authority checking. Then, when authority checking is activated, some TSO users should no longer be able to do what they could do before. An HCL Workload Automation for Z dialog message should be issued, specifying that they are not authorized to perform a particular dialog function, or that they are not authorized to use any HCL Workload Automation for Z dialog.

If the controller authority functions have not been correctly installed, this will usually enable TSO users to use dialog functions that they are not authorized to use. The symptom of this problem is the absence of an expected error message. If this happens, follow this procedure which assumes the security monitor being used is RACF®.
  1. Verify the APPL class. If the user should not be able to use any HCL Workload Automation for Z dialog, verify that the APPL class is active and that the controller is defined as a resource in the APPL class. Also, verify that the user is not present in the access list to any of these resources and that universal access NONE has been specified. Use the SETR LIST command to display active classes, and use the RLIST command to display access lists in the APPL resource class.
  2. Verify that the name of the HCL Workload Automation for Z RACF® resource class has been defined to the HCL Workload Automation for Z started task in the AUTHDEF statement. You can check this by browsing the controller message log (EQQMLOG).
  3. Verify the definition of the HCL Workload Automation for Z resource class. Check the source of the RACF® class descriptor table, and compare this with the definition supplied by the ICHRRCDE sample in the SEQQSAMP library (see Sample library (SEQQSAMP)).
  4. Verify fixed resources. If the user should not be able to use a specific dialog, such as the Calendar dialog, verify that the HCL Workload Automation for Z RACF® resource class is active and that CL is defined as a resource in this class. Also, verify that the user is not present in the access list to the CL resource and that universal access NONE has been specified.
  5. Verify subresources. If, for example, the user should be able to update only a subset of all applications in the Application Description dialog, but is instead able to update all applications, verify that the SUBRESOURCES keyword has been correctly specified for the controller in the AUTHDEF statement. Also verify that the controller has been restarted since the AUTHDEF statement was changed, and that HCL Workload Automation for Z RACF® profiles have been refreshed since the HCL Workload Automation for Z subresource profiles were updated.