Performing problem determination

If you encounter problems during your verification of the controller, correct the errors and verify that the problem has been fixed. For more information on problem determination, see Tivoli® Workload Scheduler for z/OS®: Diagnosis Guide and Reference.

Dialog problems

Various errors can occur when you are running Tivoli Workload Scheduler for z/OS dialogs. These errors cause the terminal alarm to sound and a short message to appear in the upper-right corner of your terminal screen. The message text for errors that cause the terminal alarm to sound usually contains the ALARM=YES flag. If this happens when you are trying to verify that Tivoli Workload Scheduler for z/OS dialogs are correctly installed, press the Help key (usually PF1) in ISPF. ISPF then displays a more complete error message in the long message area on your terminal. The following examples show two dialog error messages. The message number in each example is followed by the long message text and an explanation of the error. The examples highlight two errors. They are related to the dialog interface module, EQQMINOx.

EQQX115
EQQX115E TSO Service Facility RC: 20, RSNC: 40

The EQQMINOx load module is not installed in a library that can be reached by TSO. EQQMINOx must be present either in the STEPLIB library of the current TSO session or in a library in the current LINKLIB LNKLSTnn concatenation. If EQQMINOx has been installed in a LINKLIB library, either an LLA refresh process or an IPL is required to make the module accessible by z/OS users.

EQQX120
The EQQMINOx program can only be called by an APF-authorized task

The EQQMINOx load module must be APF authorized. It must reside in a data set that is defined in SYS1.PARMLIB as being an APF-authorized library. Also, EQQMINOx must be defined to TSO as being an APF-authorized program. Ensure that you have followed the instructions in Modifying TSO parameters.

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. A Tivoli Workload Scheduler for z/OS 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 Tivoli Workload Scheduler for z/OS 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 Tivoli Workload Scheduler for z/OS 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 Tivoli Workload Scheduler for z/OS RACF resource class has been defined to the Tivoli Workload Scheduler for z/OS started task in the AUTHDEF statement. You can check this by browsing the controller message log (EQQMLOG).
  3. Verify the definition of the Tivoli Workload Scheduler for z/OS 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 Appendix A. 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 Tivoli Workload Scheduler for z/OS 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 Tivoli Workload Scheduler for z/OS RACF profiles have been refreshed since the Tivoli Workload Scheduler for z/OS subresource profiles were updated.