Handling output redirection errors and internal errors
If your classes use CICS® facilities to redirect output, they should include appropriate exception handling to deal with errors in using these facilities.
- IOErrorException
- LengthErrorException
- NoSpaceException
- NotOpenException
If your classes direct output to z/OS® UNIX files, they should include appropriate exception handling to deal with errors that occur when writing to z/OS UNIX. The most common cause of these errors is a security exception.
The Java™ programs that will run in JVMs that name
your classes on the USEROUTPUTCLASS options should include appropriate
exception handling to deal with any exceptions that might be thrown
by your classes. The CICS-supplied sample classes handle exceptions
internally, by using a Try/Catch block to catch all throwable exceptions,
and then writing one or more error messages to report the problem.
When an error is detected while redirecting an output message, these
error messages are written to System.err, making
them available for redirection. However, if an error is found while
redirecting an error message, then the messages which report this
problem are written to the file indicated by the STDERR option in
the JVM profile used by the JVM that is servicing the request. Because
the sample classes trap all errors in this way, this means that the
calling programs do not need to handle any exceptions thrown by the
output redirection class. You can use this method to avoid making
changes to your calling programs. Be careful that you do not send
the output redirection class into a loop by attempting to redirect
the error message issued by the class to the destination which has
failed.