While the configuration of ims54cluster is different from alertg, an alert message from the cluster program is a structurally equivalent message on a transport device, such as the PENDING queue, and becomes the input for alertd.
Typically, alertd uses the same external OT configuration file as alertg. The alertd configuration specifies the parameters to read a message off a transport and invoke a shell script or binary.
The Transport.Alerts stanza
identifies the related properties for the PENDING queue. In the alertg sample
file, the key TransportName has
the value AlertsIn, and
that Transport.AlertsIn specifies the PENDING queue. The net effect
of running alertg with the combined sample configurations
is to place an alert message on the queue named PENDING. The other
queues HISTORY and ERROR are used only by alertd.
Configuring transports
Locate and open a sample file. Go to:
$NNSY_ROOT/samples/alerts
where NNSY_ROOT is the environment variable for the install location.
In the In stanza,
specify the alert message input transport. This name appends to
Transport session entry; for example, Transport.AlertsIn.
In the PollRate stanza,
specify how long to pause before checking the transport after the
transport is emptied.
The value is in seconds for both Windows and UNIX.
(Optional) Specify where to send messages to another queue after processing. For example, you can specify that messages to go to the HISTORY queue, or send failed messages to an ERROR queue.
If this key is not set, then processed alerts are not saved.
In the Command stanza,
specify the script or binary name. This can be simply a text name
or a fully qualified path.
Relative paths are not supported.
If the Command specified
is a shell script, you must set IsScript to TRUE. For
binaries, set it to FALSE.
In the ExecDir stanza,
specify the working directory for the script/binary.
(For Windows) In the Visible stanza,
set to TRUE for the script to launch in a visible command window.
This useful for debugging scripts.
Processing of the next alert does not begin until execution
of the previous script or binary is complete.
In general, the script or binary should not block on stdin (for example, expect input from a user). The only time it makes sense to use an interactive script or binary is when running in foreground mode, for example, not as a Windows service or UNIX daemon.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|
