Common parameters on the CRTMONOBJ command - assure_mimix - 10.0

Assure MIMIX Monitor Reference

Product type
Software
Portfolio
Integrate
Product family
Assure
Product
Assure MIMIX™ Software
Version
10.0
Language
English
Product name
Assure MIMIX
Title
Assure MIMIX Monitor Reference
Copyright
2023
First publish date
1999
ft:lastEdition
2024-03-12
ft:lastPublication
2024-03-12T10:35:16.085994

The following information describes parameters on the Create Monitor Object (CRTMONOBJ) command that apply to monitors of more than one event class. Unless noted, these parameters can be used to define a monitor of any event class.

Monitor - The Monitor parameter specifies the name of the monitor definition. Each name in the list of monitors for an installation must be unique.

Event class - The event class parameter specifies the event class type for the monitor. The event class identifies the type of event that triggers the monitor. For detailed information, see Event classes.

Monitor group - The Monitor group parameter specifies a group to which the monitor belongs. The default value *DFT indicates that the monitor belongs to the default group of monitors. This parameter can be used in two ways when you specify a name:

  • To create a logical grouping of similar monitors so that you can subset the list of monitors that appears on the Work with Monitors display. For example, you may want to place all monitors that perform security checking activities into the same group.

    To create a group of monitors that participate in the event triggering of a monitor of event class *GROUP (a group monitor).

If the name you specify for the Monitor group parameter is in use as the name of an existing group monitor, or if a group monitor is created with the name you specify, the monitor automatically becomes part of the triggering criteria for the group monitor.
Note: When you define a group monitor, the value of the Monitor group parameter must be either *DFT or the same name as the monitor. If *DFT is used, the value will be changed to the name of the monitor when the monitor definition record is created.

Interface exit program - The use of the Interface exit program parameter provides an optional way to perform additional programming associated with the monitor object. If you specify an interface exit program, then it is called both before and after an operation is performed on a monitor.

If you want a monitor to run a particular command as the triggered event without having to write an exit program, specify *CMD for the Interface exit program and *NONE for the Event program. After the monitor is created you will be prompted for the command information on the Add Monitor Information display. The running of the command is performed when the event is triggered.

Refer to the appropriate source for information about the required parameters of any command that you call in this way. Online help (F1 key) is available for operating system commands and MIMIX commands.

Condition program - The Condition program parameter specifies the name and library of the user program that will be called when the predefined monitor conditions are met. The condition program can be used to check additional conditions before the event program is run. If a condition program is defined for the monitor object, it must specify a '0' in the return code in order for the condition to be met and the event program to be called.

Event program - The Event program parameter specifies the name and library of the user program that is called when the predefined monitor conditions and user-defined conditions are met. An event program is used to handle the triggered event.
Note: If no condition and event programs are defined, the triggered event does nothing.

Job description - The Job description parameter specifies the name and library of the job description that is used when the monitor job is submitted or when asynchronous jobs are started for the monitor. Default values use the MIMIXOWN job description in library MIMIXQGPL.

Retry attempts - The Retry attempts parameter specifies how many times the predefined condition and the user-defined conditions within a condition program must be met before the event program is called. This parameter allows the condition program the opportunity to recover from or recheck the condition that triggered the event.

The Retry attempts parameter can be used for interval monitors, message queue monitors, and journal monitors that use synchronous processing. The parameter is ignored by time monitors and group monitors.

When the value of the Retry attempts parameter is 0, the predefined condition is checked once and the condition program is called. If the user-defined conditions in the condition program are met, the event program is called.

When you specify a value and a condition program, if the condition in the program is not met on a given call to the program, the retry attempts are reset. Both the predefined condition and the user-defined conditions in the condition program must be met the number of times specified before the event program is called. When no condition program is specified, only the predefined condition is checked the number of times specified before the event program is called.

If you specify a value when no event program is specified, the parameter has no meaning and the monitor will run until it is manually ended.

If you specify a Process type of asynchronous, you must specify 0 for the Retry attempts. Asynchronous processing does not allow the concept of retrying conditions.

Exercise caution when using this parameter. It may not be appropriate to set the retry attempts to a value other than 0. For a message queue monitor the message IDs to be monitored must arrive on the queue and the conditions in the condition program must be met as many times as the retry value before the event program is called. This parameter is most appropriate for an interval monitor which specifies a subclass, where the process of an interval passing, a communications object being checked, and the condition program checking a user-defined condition is repeated multiple times before the event program is run.

Process type - The Process type parameter specifies the way in which journal monitors and message queue monitors run the condition and event programs and how interval monitors operate. The default value is *SYNC.

For journal monitors and message queue monitors that are processed synchronously, the condition and event programs are run synchronously in the monitor. When a received message ID or journal entry meets the monitoring criteria the condition and event programs are run within the monitor job. The next message ID or journal entry is not received until the condition and event programs complete.

For interval monitors processed synchronously, the interval master monitor does not control the monitor. Instead, a separate job is started that waits for the specified time interval and optionally checks a communications object before it runs the condition and event programs. The interval wait time does not begin again until after the exit programs are completed.

When you specify the value *ASYNC on a journal monitor or a message queue monitor, the condition and event programs are run asynchronously by starting a separate job to run them. When a received message ID or journal entry meets the monitoring criteria, the monitor starts a separate job to run the condition and event programs. The next message ID or journal entry is immediately received. Multiple jobs can be running condition and event programs simultaneously.

When you specify the value *ASYNC on an interval monitor, the monitor is controlled by the interval master monitor. When the time interval is reached, the interval master monitor starts a separate job for the monitor to run the condition and event programs. The next time interval is immediately processed without waiting for the exit programs to complete. Multiple jobs can be running condition and event programs simultaneously.

When you specify *ASYNC for an interval monitor, the monitor must have a minimum time interval of 5 minutes (300 seconds) to reduce the number of launched jobs.

Start with master monitor - The Start with master monitor parameter specifies whether a monitor should be started when the master monitor is started. When you specify *YES, if the monitor’s status is INACTIVE or FAILED when the master monitor is started, the monitor will be started automatically. Monitors that have a DISABLED status are never started with the master monitor.

ASP group - The ASP group parameter specifies the name of the auxiliary storage pool (ASP) group that is associated with the monitor object. Valid only for journal monitors and message queue monitors, use this parameter to specify the name of the ASP group where the journal or message queue library exists.

Description - Use the Description parameter to provide a description of the monitor that will appear in the Work with Monitors display.