Engine log and trace customization

Describes how you can customize the CCLog logging and tracing facility. You can modify the appearance of the log and the logging and tracing levels.

You can customize the information written to the log files by modifying selected parameters in its properties file. The changes you can make affect the format of the log or trace file and the logging level or trace level.

Attention: Do not change any parameters in this file other than those detailed here, otherwise you might compromise the logging facility.

The CCLog properties file is located in the following path:

On Windows operating systems: <TWA_home>/TWS
On UNIX operating systems: TWA_DATA_DIR

Parameters

The parameters that can be modified are as follows:

Logging level

tws.loggers.msgLogger.level

This determines the type of messages that are logged. Change this value to log more or fewer messages, as appropriate, or on request from IBM® Software Support. Valid values are:

INFO: All log messages are displayed in the log. The default value.
WARNING: All messages except informational messages are displayed.
ERROR: Only error and fatal messages are displayed.
FATAL: Only messages which cause HCL Workload Automation to stop are displayed.

You can customize the logging and tracing level for conman commands by setting the relevant values for the tws.loggers.trcConman.level property, available in the Conman.ini.

The Conman.ini file is located in the following path:

On UNIX™ operating systems: TWA_DATA_DIR/ITA/cpa/config
On Windows™ operating systems: TWA_home\TWS\ITA\cpa\config

Tracing level

tws.loggers.trc<component>.level

This determines the type of trace messages that are logged. Change this value to trace more or fewer events, as appropriate, or on request from IBM® Software Support. Valid values are:

DEBUG_MAX: Maximum tracing. Every trace message in the code is written to the trace logs.
DEBUG_MID: Medium tracing. A medium number of trace messages in the code is written to the trace logs.
DEBUG_MIN: Minimum tracing. A minimum number of trace messages in the code is written to the trace logs.
INFO: All informational, warning, error and critical trace messages are written to the trace. The default value.
WARNING: All warning, error and critical trace messages are written to the trace.
ERROR: Only error and critical messages are written to the trace.
CRITICAL: Only messages which cause HCL Workload Automation to stop are written to the trace.

Component names used in the tws.loggers.trc property names are for the most part self-explanatory, but the following short explanations might help:

Logger: The main internal component of HCL Workload Automation that performs the scheduling activities.
Sendevnt: The event processor.
Connectr: The connector.

Log format parameters

fomatters.basicFmt.dateTimeFormat: This contains a specification of the date and time format used by CCLog when adding the date and time stamp to the message header. The format uses the standard strftime format convention, used by many programming libraries. The full format details can be found by searching the Internet, but a synthesis of the commonly used definitions is included in Date and time format reference - strftime.
fomatters.basicFmt.separator: This defaults to the pipe symbol "|", and is used to separate the header of each log message, which contains information such as the date and time stamp and the process that issued the error, from the body, which contains the process-specific information such as the issuing process, the message number and the message text. You can change the separator to another character or characters, or set it to null.
twsHnd.logFile.className: This indicates if CCLog uses semaphore memory to write to the log file. The default setting (ccg_filehandler) tells CCLog to write each line of a multiline message separately. Each process interleaves each line of its multiline messages with messages from other processes, if necessary, improving performance. While this approach could potentially make the log files more difficult to read, this interleaving only occurs in extreme situations of very high use, for example when many jobs are running concurrently.
The setting ccg_multiproc_filehandler, defines that each process completes writing any log message, including multiline messages, before freeing the log file for another process to use. This can have an impact on performance when many processes are running concurrently.
tws.loggers.className: This indicates the type of log layout you want to use, determining the number of fields in the log record header. The default setting (ccg_basiclogger) tells CCLog to put just the date/time stamp and the process name in the header. The alternative setting is ccg_pdlogger, which contains more information in the header, thus reducing the length of the log records available for the message text.
tws.loggers.organization: This defaults to IBM® and is used to differentiate between log entries from applications from different suppliers when the same instance of CCLog is being used by more than one software supplier. HCL Workload Automation is supplied with a unique instance, and thus unique log files, so if this value is prefixed to your log messages, you can set the value of this parameter to null to avoid it being displayed.
tws.loggers.product: This defaults to TWS and is used to differentiate when the same log files are used by more than one product. HCL Workload Automation is supplied with unique log files, so if this value is prefixed to your log messages, you can set the value of this parameter to null to avoid it being displayed.

Other parameters

No other parameters must be modified. To do so risks compromising the logging or tracing facility, or both.

Making changes effective

Making your changes effective depends on the type of change:

Changes to log or trace levels: If you change the tws.loggers.msgLogger.level or the tws.loggers.trc<component>.level, the change is immediately effective after the file has been saved.
All other changes: Restart HCL Workload Automation to make overall changes effective; restart a process to make process-specific changes effective.