MIMIX Monitor manages switch definitions that can be used with monitor objects to enable automated switching between two systems. This switching support enables you to customize:
-
What monitored objects participate in a decision to switch from a production system to a backup system.
-
How the switch will be performed.
-
Which applications will be switched.
When you use a monitor in a switching scenario, MIMIX Monitor uses a switch definition in which you identify:
-
The systems participating in the switch.
-
The parameters associated with how the switch is controlled.
-
The event program that contains your customized switching programming.
The switch definition can specify TCP/IP address impersonation.
The event program identifies and controls what is switched between systems. You can switch users and applications. When used with MIMIX replication processes, you can switch the direction of replication within MIMIX by including the appropriate MIMIX commands.
When the switch definition is created, a group monitor (event class *GROUP) is automatically created to control the switch definition. The group monitor has the same name as the switch definition and will call the event program specified in the switch definition.
While the group monitor controls the switch, any combination of monitor objects can participate in the decision to switch. When the participating monitor objects all agree at a point in time that the objects they are monitoring have failed, the group monitor is triggered to run the switching software. This is usually done by using the Run Switch Framework (RUNSWTFWK) command in the group monitor’s event program.
To form the association between a participating monitor and a group monitor, the name of the group monitor is used as the value of the monitor group parameter (MONGRP) on the participating monitor. Any active monitor that has the group monitor name specified for this parameter will participate in the decision to trigger the switch.
Participating monitor objects can be created to watch and attempt recovery on failed lines, controllers, or devices that communicate with the production system. TCP/IP interfaces that are defined through a transfer definition can also be monitored to ensure that they remain active. Other objects such as message queues or journals can also be monitored if there are messages or transactions that might be appropriate to cause the triggering of a switch. When all participating monitor objects have failed because these objects cannot be recovered, are not communicating, or have received a message or a transaction that indicates the necessity for switching, the group monitor triggers the events necessary to switch users and applications to the backup system.