Handler Options

An event's HANDLER_OPTIONS option can be used to establish standard I/O redirection for every event handler process executed for the event. These options are specified using the HANDLER_OPTIONS option of the event definition or the HANDLER_OPTIONS command line option of the UEM Manager. In both implementations, the value specified for this parameter is appended to the command line that the UEM Server constructs to execute the specified user command or script.

This option has the same issues regarding unique file names as those described above in the Command Execution section. If it is possible that multiple, concurrently tracked event occurrences will result in the simultaneous execution of the event's handlers, all output generated by all handlers will be written to the same file. If output from each handler process needs to be captured in unique files, the method described in the Script Execution section above is a better alternative.

One advantage to using an event's handler options parameter is that an event's triggered, rejected, and/or expired event handlers can be changed without changing the way output is captured by the respective event handler process.

An event's handler options parameter may also be used to redirect standard input from a file. Capturing output may then be handled with the handler options parameter or by using one of the other methods described above.

The examples in the following figure demonstrate the use of this parameter for event definitions and event handlers added with the UEMLoad utility, and for events defined and executed from a UEM Manager's command line.

Using Handler Options when Storing Event Definitions

For each of the event definitions shown above, the OS installed on the host rmthost can be either Windows or UNIX. If the UEM Manager is executed from z/OS, the name of the executable (that is, uem) would be omitted. However, the rest of the parameters would be entered as shown in the JCL's SYSIN DD statement.

Example 1

The first example shows an event of type file that will monitor a file named uemtest.dat. If an occurrence of this file is detected, the netstat command will be executed when the occurrence enters a triggered state. If the event expires, an "Event expired" message is issued. In both situations, the output from the command is written to a file named netstat.txt.

Example 2

The second example also shows an event of type file that is set up to monitor a file named uemtest.dat. If an occurrence of this file is triggered, the application someapp will be executed. According to the -handler_options parameter, this application will receive input redirected from a file named appinput.dat. All output, including output destined for standard error, is written to a file named applog.txt.

Example 3

Finally, the last example is also monitors a file named uemtest.dat. This event executes an event handler process only if an occurrence of the file is detected and that file fails to complete by midnight on 31 December 2011. The handler process executed is named dailybkup. All messages issued by the application that are destined for standard output are written at the end of a file named backup.log. All messages destined for standard error are appended to a file named backup_err.log. One or both files are created if they do not exist when the handler process is executed.