The engine connection does not work

You define an engine connection, you verify that the values entered for the engine connection are correct, and then you click Test Connection. The test fails and a connection error message is returned.

Cause and solution:

Assuming that system_A is where you installed the Dynamic Workload Console, and system_B is where you installed IBM Workload Scheduler, follow these verification steps to investigate and fix the problem:
  1. Verify that there is no firewall between the two systems as follows:
    1. Make sure the two systems can ping each other. If you are trying to connect to a z/OS® engine you must check that the system where the Dynamic Workload Console is installed and the system where the IBM Workload Scheduler z/OS® connector is installed can ping each other.
    2. Make sure you can telnet from system_A to system_B using the port number specified in the engine connection settings (for example, 31117 is the default port number for distributed engine).
    3. Make sure you can telnet from system_A to system_B using the CSIv2 authentication port numbers specified during installation (for example, 31120 is the default server port number and 31121 is the default client port number).
    If either of these two steps fails then there might be a firewall preventing the two systems from communicating.
  2. Check if you can connect using the composer command line interface, or the Dynamic Workload Console to the IBM Workload Scheduler engine on system_B using the same credentials specified in the engine connection. If you cannot, then check if the user definition on system_B and the user authorization specified in the IBM Workload Scheduler security file are correct.
  3. If you are using LDAP or another User Registry on the Dynamic Workload Console make sure that:
    1. The connection to the user registry works.
    2. The User Registry settings specified on the Integrated Solutions Console in the Security menu under Secure administration, applications, and infrastructure are correct.
    For more information about how to configure the Dynamic Workload Console to use LDAP or about how to test the connection to a User Registry, refer to the chapter on configuring user security in the IBM Workload Scheduler: Administration Guide.
  4. If you set up to use Single Sign-On between the Dynamic Workload Console and the IBM Workload Scheduler engine, make sure you correctly shared the LTPA_keys as described in the chapter on configuring SSL in the Administration Guide.
    Note: Make sure that you correctly shared the LTPA_keys also if you get errors AWSUI0766E and AWSUI0833E. The problem occurs when the realm values are the same for more than one WebSphere Application Server (Dynamic Workload Console, IBM Workload Scheduler z/OS® connector, or IBM Workload Scheduler engine). These steps are usually described only when you configure the Single Sign On, but they are required also when you have the same realm. You have the same realm when you configure all WebSphere Application Server Liberty Base instances with the same LDAP user registry and when you install all WebSphere Application Server Liberty Base instances on the same machine.
If this checklist does not help you in identifying and fixing your problem then activate tracing on the Dynamic Workload Console (adding also the Java™ packages com.ibm.ws.security.*=all:com.ibm.tws.*=all), and on the IBM Workload Scheduler engine. See the procedure in Quick reference: how to modify log and trace levels.
After modifying the traces as necessary, connect to the Dynamic Workload Console again, test the connection to the IBM Workload Scheduler engine, and then check the information stored in the following trace logs:
  • On the Dynamic Workload Console, browse to the following path:
    On Windows operating systems
    DWC_home\stdlist\appserver\dwcServer\logs
    On UNIX operating systems
    DWC_DATA_dir/stdlist/appserver/dwcServer/logs
  • On the IBM Workload Scheduler engine, browse to the following path:
    On Windows operating systems
    TWA_home\TWS\stdlist\appserver\engineServer\logs
    On UNIX operating systems
    TWA_DATA_DIR/stdlist/appserver/engineServer/logs
In these files you see the information about the error that occurred. If useful, compare the connection information stored in the traces with the information set for WebSphere Application Server Liberty Base security on both sides. Refer to the Administration Guide to list the information about the security properties.