The TDI product implementation on z/OS provides the ability to redirect the information from the intermediate USS ibmdi.log file within the related HFS file to the TASK SYSOUT of the TDI started task.
Configuring the TDI task to log to its SYSOUT allows z/OS users to have all the relevant information in a single place; it also allows people not fully skilled on Unix System Services to find the logs using SDSF. In addition the full sysout (including product messages) is saved and kept using the normal tool. Using this approach ensures that each start of the TDI TASK stores the information in its own sysout thus preventing any log replacement.
The redirection of the TDI server logs consists of two configuration steps: editing the log4j.properties file and the JCL script starting TDI as z/OS task (ADITASK; also see IBM TDI as z/OS Service). This approach relies on the ability of newer releases of z/OS including the oldest supported by TDI - version 1.6 - to route STDOUT and STDERR to SYSOUT instead of an 'intermediate' USS file. For this purpose all the needed log information should be first made visible from within the standard console. In order to take advantage of this feature the two steps described below should be performed.
This step is required in order to redirect the log messages to the standard console output. For this purpose the log4j.properties file used by the TDI instance must be edited to add a console appender and to use it as default logger (to ensure that all log messages are stored in the task SYSOUT) or specify it as a logger for certain TDI objects like ALs, configurations and the like, so that only relevant information is added.
For example, to add and configure a console appender as default logger:
# Here is an example on how to make a logger that logs to the console log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout log4j.appender.CONSOLE.layout.ConversionPattern=%d [%t] %-5p - %m%n0 log4j.appender.CONSOLE.encoding=IBM-1047
Changing the root logger to the CONSOLE appender:
log4j.rootCategory=INFO, CONSOLE
With this modification the log information is now routed to the standard console and can be further manipulated in the MVS environment.
The second step involves modification of the JCL responsible for starting TDI as normal z/OS started task, so that the messages received from the console are routed to the SDSF visible logs of the task. Note that if the ADITASK JCL shipped as an example with TDI is used, this step is redundant, since its default behavior is to log there.
Edit the JCL, which starts the TDI server as standard z/OS started task, to redirect the log output to the task SYSOUT. This could be done by simply adding the lines:
//STDOUT DD SYSOUT=* //STDERR DD SYSOUT=*
or
//STDOUT DD SYSOUT=(,) //STDERR DD SYSOUT=(,)
Since the z/OS system takes advantage of the Log4J options, it stores all the messages with status ERROR and FATAL in the STDERR associated with the TASK and the others - DEBUG, INFO, and so on. in the STDOUT. The length of the created records in this manner is not fixed to 133 characters, therefore extremely long or multiline messages can be saved without truncation.
The information can be easily routed or copied to another dataset or intermediate USS file. By this means it can be stored both in MVS and USS environment.
Below is an example showing how the STDOUT can be redirected back to the ibmdi.log file from the JCL:
//STDOUT DD PATH='/usr/lpp/itdi/logs/ibmdi.log', // PATHOPTS=(OWRONLY,OCREAT,OTRUNC), // PATHMODE=SIRWXU
By formatting the messages a non-readable character appears between some of the components of the message, for example, the Date and the message ID, which is due to a conversion issue when transferring characters from ASCII to EBCDIC. When using the characters "[" and "]" in the pattern, they are not translated properly in the z/OS native encoding. The "[" character is replaced by the "¦" and "]" is converted to ".