Interval monitors use an interval (in seconds) to determine how often to run condition and event programs. Interval monitors are different from time monitors because interval monitors are based on a number of seconds passing, not on time of day.
Subclasses - Interval monitors support the concept of subclasses to check that the communications link or object being monitored is active. When a subclass is specified on an interval monitor, additional predefined conditions are checked after the time specified in the interval has passed. You can specify retry attempts so that the monitor will retry the communications link or object, attempt recovery where possible, and call the condition program multiple times before the event program is called.
The following subclasses are supported:
-
Configuration object - for the configuration object subclass (*CFG), the status of a line, controller, or device object is checked after the time specified in the interval is past. If the object is not active, the monitor attempts recovery if the value of retry attempts parameter is other than zero. If the object can be recovered on a retry attempt, the condition and event programs are not called and the monitor continues to monitor the object. If the object cannot be recovered on a retry attempt, the condition program is called. If the object is not recovered after the specified number of retry attempts, the event program is called.
-
TCP/IP interface - for the TCP/IP subclass (*TCP), the status of a host address or alias is checked after the time specified in the interval is past. If there is no response, the condition and event programs are triggered. When a value other than zero is specified for the retry attempts parameter, the monitor will check the status of the host address or alias and call the condition program multiple times before the event program is called. No recovery is attempted.
-
System definition - a system definition contains a transfer definition, so when you specify a system definition, the communication link defined by the transfer definition is verified. The subclass of system definition (*SYSDFN) interacts with system definitions and transfer definitions used in MIMIX replication configurations. For information on configuring a system definition, refer to the Assure MIMIX Administrator Reference book.
-
Transfer definition - a transfer definition defines a communications link that can be used to determine if the two systems that define the link are able to communicate. The subclasses of transfer definition (*TFRDFN) interact with transfer definitions used in MIMIX replication configurations. For information on configuring a transfer definition, refer to the Assure MIMIX Administrator Reference book.
For *SYSDFN and *TFRDFN subclasses of an interval monitor, the communications link is verified when the time interval has passed. If the communications link is not responding, the condition and event programs are run. When a value other than zero is specified for the retry attempts parameter, the monitor will check the communications link and call the condition program multiple times before the event program is called. No recovery is attempted on the communications link.
Process type - Interval monitors also support the concept of asynchronous and synchronous processing. You choose what is used by the value you specify for the Process type (PRCTYPE) parameter. The interval master monitor controls all asynchronous interval monitors. Asynchronous interval monitors are monitors that, each time an interval passes, use a separate process to run the condition and event programs. The interval for an asynchronous interval monitor begins when the interval master monitor is started, or if the interval master monitor is already active, when the interval master monitor handles the start request. For example, a monitor with a 300 second interval defined will cause the interval master monitor to start a separate process to run the condition and event programs after 300 seconds and every 300 seconds thereafter. (300 seconds is the smallest valid value for an asynchronous interval.) Several processes can be simultaneously running for the same monitor if the interval time is reached before the first separate process has completed running the condition and event programs. The running of the event program is dependent on the success of the condition program. The Retry attempts parameter is not allowed when asynchronous processing is used.
Synchronous interval monitors run as a separate process where the condition and event programs are called in-line after the interval has passed. The next time interval does not begin until the condition and event programs have completed. With synchronous interval monitors, the concept of retry attempts requires that the predefined conditions, the passing of the time interval, the sub-class checking, and user-defined conditions (the condition program) must be met multiple times before the event program is called.