A notification is the resulting automatic report associated with an event that has already occurred. The severity of a notification is reflected in the overall status of the installation.
Notifications can be generated in a variety of ways:
Target journal inspection processes generate notifications when users or programs other than MIMIX have changed objects on the target node.
Recovery processing generates a notification when an object within the replication namespace of a data group cannot be recovered because the object exists only on the target node.
The recovery phase of a virtual switch procedure generates one notification per affected data group when recovery actions for objects changed on the designated test node cannot be performed because the objects do not exist on the source node.
Rules that are not associated with the audits provided by MIMIX also generate notifications to indicate that rule processing either ended in error or, if requested, completed successfully.
Shipped monitors, such as the MMNFYNEWE monitor for the MIMIX® AutoNotify™ feature, generate notifications.
Software install or upgrade processes may generate notifications for specific scenarios within your configuration of which you should be aware.
Custom automation may initiate user-generated notifications when user-defined events are detected. User-generated notifications can be set to indicate a failure, a warning, or a successful operation.
Audits generate notifications as a secondary mechanism for reporting when the activities performed by an audit complete or end in error. These notifications are automatically marked as acknowledged. (The primary mechanism is to report errors through replication processes and the audit summary.) Policies provide considerable control over notifications generated by audits.
Because the manner in which notifications are generated can vary, it is important to note that notifications can represent both real-time events as well as events that occurred in the past but, due to scheduling, are being reported in the present. For example, the ownership of a file is changed on the target system at 8:00 PM. If your audit (CMPFILA) is scheduled to run at 1:00 AM, MIMIX will detect the change and push a notification to the user interface when the audit completes. Previously, detection of the change was contingent upon you viewing a report after the audit completed and noticing the difference.
Recoveries - The term recovery is used in two ways. The most common use refers to the recovery action taken by audits or replication processes to correct a detected difference when automatic recovery polices are enabled. The second use refers to a temporary report that provides details about a recovery action in progress. The report is automatically created when the recovery action starts and is removed when it completes. While it exists, the report identifies what originated the action and what is being acted upon, and may include access to an associated output file (outfile) and the job log for the associated job. The action which generated a report may also generate a notification when the recovery action ends.