Managing operator message routing

Use the product message routing capabilities to control server traffic flow.

You can route many of the BBO prefixed error messages to specific datasets instead of having them go to SYSLOG, which can create a lot of traffic. This is implemented with the use of two environment variables, ras_default_msg_dd and ras_hardcopy_msg_dd, and the specification of the appropriate DD statement in your JCL start procedure.

The following explains, in more detail how messages get routed.

WTO messages issued by the Application Server during initialization are sent to hardcopy, but most can be routed to the data set specified by ras_default_msg_dd (see Log output destinations and characteristics).
The Java™ audit messages are also sent to hardcopy, but can be routed to the data set specified by ras_hardcopy_msg_dd. (see Log output destinations and characteristics).
Trace error, service, and fatal messages are sent to the error log specified by the ras_log_logstreamName. Otherwise, they go to CERR (SYSOUT). Some might also go to hardcopy. At the W500104 service level, the ras_log_logstreamName environment variable is not set to the error logstream name in the was.env variables.
To set this environment variable, on the administrative console, click Environment > WebSphere variables, select a scope, and click New.
Early error messages go to SYSOUT until the product connects to the log stream. A WTO (BBOO0153I) is issued telling you how many messages went to SYSOUT before you connected to the log stream.
Starting with z/OS® Version 1.13, you can use JES2 DD keywords to segment output using the periodic writing of form-feed characters to the output streams.
If you are running on z/OS Version 1.12 or earlier, and using JES2, the SEGMENT= parameter can be added to the SYSPRINT and SYSOUT DD cards if you want to segment output using the periodic writing of form-feed characters to the output streams. Form-feed characters are written to the output streams based on the values of the ras_stderr_ff_interval, ras_stdout_ff_interval, ras_stderr_ff_line_interval, and ras_stdout_ff_line_interval environment variables. These variables are described in more detail in the topic Application server custom properties for z/OS The SEGMENT= parameter is not supported on JES3.

To set these environment variables, on the administrative console, click Environment > WebSphere variables, select a scope, and then click New.
Trace messages are routed to ras_trace_outputLocation.
System.out.println, System.err.println, STDOUT and cout go to SYSPRINT (see the topic Redirectiong SYSPRINT and SYSOUT output to an HFS File for more information.
STDERR and cerr go to SYSOUT

To use these message routing variables, you must do two things:

Add these parameters to the server definitions using the Administrative Console under Environment -> Manage WebSphere® Variables:
- ras_default_msg_dd =DEFALTDD
- ras_hardcopy_msg_dd =HRDCPYDD
You can set these variables for individual control and servant processes, but it is easier to set them in the Environment variables for the entire cell. For the Daemon, you must prefix them with "DAEMON_" and set them at the cell level:
- DAEMON_ras_default_msg_dd =DEFALTDD
- DAEMON_ras_hardcopy_msg_dd =HRDCPYDD
Update the procedures in PROCLIB to add these new DD statements:
```
//* Output DDs
//CEEDUMP DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE
//SYSOUT DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE 
//SYSPRINT DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE 
//DEFALTDD DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE
//HRDCPYDD DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE
```
Additionally, you can use the JES2 SPIN parameter to spin the data at line or time intervals. The following example code spins the data every 5000 lines:
```
SPIN=(UNALLOC,5K)
```
The following example code spins the data at 20-minute intervals:
```
 SPIN=(UNALLOC,'+00:20')
```
For more information about the SPIN parameter, see the SPIN parameter in the z/OS documentation.

Note:

If you specify the new environment variables, but do not specify the DD cards in the procedure, you will not get an error message indicating that the DD cards are missing and the tracing output will not be written anywhere.
If you try to direct the output for multiple streams to the same DD, such as setting both ras_default_msg_dd and ras_hardcopy_msg_dd to DEFALTDD (or to SYSPRINT) then the allocation will fail and output will be sent to the default location (JOBLOG/SYSLOG).

For example, these DD files are used to separate the messages and keep almost all of them off the hardcopy console (SYSLOG):

JESMSGLG - a few start-up and shut-down messages
JESYSMSG - MVS™ allocation and deallocation messages
SYSOUT - a few start-up and shut-down messages
SYSPRINT - a few start-up and shut-down messages
HRDCPYDD - audit messages that would normally go to SYSLOG
DEFALTDD - informational messages that would normally go to SYSLOG