Troubleshooting installation, migration, and uninstallation
An overview on troubleshooting installation, migration, and uninstallation of the IBM Workload Scheduler.
Issues dealing with the installation, removal, and configuration of IBM Workload Scheduler and its prerequisites.
For information about issues on the DB2® installation, see the DB2 product documentation.
Installation log files
The type of log files you find on your system depends on the type of installation you performed.
On UNIX operating systems, the storage of data generated by IBM® Workload Scheduler, such as logs and configuration
files, are stored by default in the DATA_DIR>
directory, which you can optionally customize at installation time. By default, this directory
is <TWA_home>/TWSDATA for the server and agent components, and
<DWC_home>/DWC_DATA for the Dynamic Workload Console. The product binaries are stored
instead, in the installation directory. For more information, see Server components installation - serverinst script, Dynamic Workload Console installation - dwcinst script, and Agent installation parameters - twsinst script.Note: If you deployed the
product components using Docker containers, this is the default behavior and it cannot be
modified. However, if you installed the product components using the command-line
installation, the --data_dir parameter can be used to change the path.
- master domain manager or dynamic domain manager and its backup
- <TWA_home>/TWSDATA/installation/logs
- Dynamic Workload Console
- <DWC_home>/DWC_DATA/installation/logs
- Dynamic agents and fault-tolerant agents
- <INST_DIR>/TWSDATA/installation/logs/twsinst_<operating_system>_<TWS_user>^<product_version_number>.log. For more information, see The twsinst log files.
On Windows operating systems, installation log files are stored in the
following paths:- master domain manager or dynamic domain manager and its backup
- <INSTALL_DIR>\logs
- Dynamic Workload Console
- <INSTALL_DIR>\logs
When you install a fix pack, the suffix at the end of the file name lists the fix pack number
in addition to the General Availability version number, for example:
serverinst_<version_number>.0.0<fix_pack_number>.log