Monitor objects supplied with MIMIX - assure_mimix - 10.0

Assure MIMIX Monitor Reference

Product type
Product family
Assure MIMIX™ Software
Product name
Assure MIMIX
Assure MIMIX Monitor Reference
First publish date

Assure MIMIX is shipped with a number of ready to use monitor objects that meet a specific need. These monitors can be triggered by any form of event class and may or may not enable you to customize them to your needs. These monitors may also include their own additional menus, commands, and displays.

The retry remote journal link monitor, MMRTYRJLNK, is shipped with MIMIX and will keep remote journal links active as needed. This monitor checks the database reader and remote journal status of data groups and identify whether any of them attempted but failed to restart their associated remote journal. The interval monitor runs periodically and if it discovers that the database reader job is active but the remote journal is not, it will start the remote journal using Start Remote Journal Link (STRRJLNK) command. The MMRTYRJLNK monitor starts with the master monitor and has a default interval time of 15 minutes.

The MIMIX AutoNotify feature within MIMIX uses the shipped monitor for new object notification entries, MMNFYNEWE, to monitor the source system in a replication environment. The AutoNotify feature makes it easier to identify new objects in your production environment that may need to be replicated. The MMNFYNEWE monitor is a journal monitor that watches the security audit journal (QAUDJRN) for newly created libraries, folders, or directories that are not already included or excluded for replication by a data group and sends warning notifications when its conditions are met. This monitor is shipped disabled. User action is required to enable this monitor on the source system within your MIMIX environment. Once enabled, the monitor will automatically start with the master monitor. For more information about the conditions that are checked, see the Assure MIMIX Operations book.

The independent ASP threshold monitor, MMIASPMON, is shipped with MIMIX and will notify you when an independent ASP threshold is exceeded. This monitor improves the capability for detecting potential independent ASP overflow conditions that put your high availability solution at risk due to insufficient storage. This monitor checks the QSYSOPR message queue in library QSYS for messages indicating that the amount of storage used by an independent ASP exceeds a defined threshold. When this condition is detected, the monitor sends a warning notification that the threshold is exceeded. The status of warning notifications is incorporated into overall MIMIX status. The independent ASP threshold monitor is shipped disabled. If you want to use this monitor, user action is required to enable it on all systems in the MIMIX installation that are using independent ASPs.

Note: Each ASP defaults to 90% as the threshold value. To change the threshold value, you must use IBM's iSeries Navigator.

Monitors associated with Assure MIMIX for PowerHA

The following monitors are associated with Assure MIMIX for PowerHA. One or more may be present, depending which license keys are present.

  • The application group status monitor is created when an application group definition is created and has the same name as the application group. This monitor sends a notification if the application group has any status values of *ATTN. Logical replication status is not checked or reported as other mechanisms exist for reporting replication status problems.

  • The switch delay monitor is created when a device CRG is created and has the same name as the device CRG. This monitor sends notifications when conditions exist that may require action to prevent a prolonged switch. Notifications are sent when there are differences in UID values or in GID values between the primary and backup nodes, when the number of independent ASP libraries falls below the value specified in the independent ASP ratio policy, and when a library exists in the ASP group of the switchable independent ASP on the primary node and also exists in SYSBAS on the backup node.

  • The cluster administration domain monitor, named #MCADMDMN, periodically checks for new objects to be added to the IBM cluster administrative domain. The monitor will add a Monitored Resource Entry to the administrative domain for all objects that have been found.

  • The cluster SAN connection monitor, named MCSANCNN, is automatically created when the first data resource group of type of *PPRC or *LUN is created. The monitor watches the QSYSOPR message queue for message CPPEA02 (*Attention Contact your hardware service provider now) which indicates there is a potential problem with the fiber channel connection between the node and the SAN storage device. If CPPEA02 is issued on a backup node and is not noticed, that node can be adversely affected and the independent ASP associated with the *LUN or *PPRC data resource group will not be able to switch to that backup node. When the monitor detects message CPPEA02, it sends a notification to inform you of the potential problem. The monitor is created on each node associated with a data resource group and has a value of *YES for Start with master monitor (AUTOSTR).

Monitor associated with IBM MQ for IBM i

The MQ record image monitor (MQRCDIMG) periodically runs the IBM MQ for IBM i command RCDMQMIMG. When enabled, the monitor automatically starts with the master monitor and the monitor’s event program is triggered daily at midnight. The RCDMQMIMG command is run for each queue manager defined to IBM MQ for IBM i, including queue managers that are not defined for replication. An MQ checkpoint is established for each active queue manager on the system and previous AMQAJRN journal receivers are then eligible to be removed. This allows the older receivers to be deleted with no potential impact to IBM MQ for IBM i’s ability to start or recover any MQ object. Having the shortest possible journal receiver chain can be a key factor in the length of time that is required for MQ to successfully start a queue manager following a switch.

The monitor is intended to be used on the source system and should be run while MQ is active and writing to its queues. The monitor is shipped disabled. User action is required to enable the monitor on the source system within your MIMIX environment. Once enabled, the monitor will automatically start with the master monitor. For queue managers that are not active when the monitor runs, a message indicates that the event program could not run the RCDMQMIMG command.

It may be beneficial to change the monitor to run during periods of lower system use, since running the command does require some resources from MQ, especially in very large and very busy MQ environments. Additionally, you may not want to use the monitor if you are required or want to exert your own control over the production MQ environment.

Monitor associated with Application Group Type *DB2MIRROR

The application group status monitor for DB2 Mirror is created when an application group definition of type *DB2MIRROR is created and has the same name as the application group. This monitor checks the replication status of the DB2 Mirror environment to ensure that the replication is taking place between the primary nodes of the different DB2 Mirror sites.