(ZOS) Manage operator message routing

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

We 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, we can use JES2 DD keywords to segment output using the periodic writing of form-feed characters to the output streams.

  If we 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 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> 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, we must do two things:

1. 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

   We 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, we must prefix them with "DAEMON_" and set them at the cell level:

   • DAEMON_ras_default_msg_dd =DEFALTDD
   • DAEMON_ras_hardcopy_msg_dd =HRDCPYDD

2. 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
   

• If we specify the new environment variables, but do not specify the DD cards in the procedure, we will not get an error message indicating that the DD cards are missing and the tracing output will not be written anywhere.

• If we 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 segregate the messages and keep almost all of them off the hardcopy console (SYSLOG):

1. JESMSGLG - a few start-up and shut-down messages
2. JESYSMSG - MVS™ allocation and deallocation messages
3. SYSOUT - a few start-up and shut-down messages
4. SYSPRINT - a few start-up and shut-down messages
5. HRDCPYDD - audit messages that would normally go to SYSLOG
6. DEFALTDD - informational messages that would normally go to SYSLOG

Choosing diagnostic information sources

Diagnose problems (using diagnosis tools)

Use basic or traditional message logs to troubleshoot applications

Application server custom properties for z/OS