Version 5.0. MIMIX ha1 and MIMIX ha Lite for IBM i5/os. Using MIMIX. Published: May 2008 level Copyrights, Trademarks, and Notices

Transcription

1 Version 5.0 MIMIX ha1 and MIMIX ha Lite for IBM i5/os Using MIMIX Published: May 2008 level Copyrights, Trademarks, and Notices

2 Product conventions Menus and commands Accessing online help Publication conventions Formatting for displays and commands Sources for additional information How to contact us Chapter 1 MIMIX overview 17 MIMIX concepts Key concepts for MIMIX AutoGuard Audit concepts MIMIX policies Policy descriptions Considerations when choosing policy values When not to use MIMIX AutoGuard Policy settings used by MIMIX AutoGuard, MIMIX Switch Assistant Setting policies - general To change existing installation policies To change policies for a data group To reset a data group-level policy to use the installation level value Setting policies for switching Setting polices for MIMIX Switch Assistant Setting policies for switch compliance for a specific data group Setting policies when MIMIX Switch Assistant is not used Changing the audit level policy for switching Preventing audits from running To restrict audit activity in an installation based on data group state To restrict audit activity for a specific data group based on its state To disable auditing for an installation To disable auditing for a data group Disabling MIMIX AutoGuard for data groups using the MIMIX CDP feature Chapter 2 Common operations 44 Logging in the first time Your location is remembered Areas of the window Additional navigation and selection aids Other useful tips Becoming acquainted with status The Enterprise View - your status shortcut Status on the navigation bar Accessing the MIMIX Main Menu Monitoring data group status on MIMIX Availability Manager Checking replication status with MIMIX Availability Manager Checking audit status on MIMIX Availability Manager Checking status of supporting services on MIMIX Availability Manager Monitoring the status of an installation emulator Using the MIMIX Availability Status display Displaying details with option

3 Troubleshooting with option Additional fields Checking replication status Checking audit and notification status Checking for status of supporting services Working with audits Audit status and compliance status reflected in higher-level status Audit status and results Displaying audit status Running audits immediately Ending audits Displaying audit level differences Working with audit compliance Determining whether auditing is within compliance Using the Work with Data Groups display Problems reflected in the Audits/Recoveries field Problems reflected in the Data Group column Resolving problems highlighted in the Data Group column Replication problems reflected in the Source and Target columns Source system process summaries Target system process summaries Error columns Setting the automatic refresh interval Displaying data group detailed status Detailed status displays emulator Merged view Object detailed status views Database detailed status views Identifying replication processes with backlogs Working with MIMIX managers Resolving status problems with system and journal managers Starting a system manager or a journal manager Ending a system manager or a journal manager Working with message queues Working with the message log Chapter 3 Using MIMIX AutoGuard 109 What are MIMIX AutoGuard best practices? Usage guidelines for auditing How do I get started with MIMIX AutoGuard? New MIMIX installations How audits are scheduled Adjusting audit scheduling When to run the #DGFE audit Changing when audits are scheduled Changing the system where audits are performed Using a different job scheduler for audits Errors handled by automatic database recovery Errors handled by automatic object recovery Interpreting audit results - MIMIX Availability Manager

4 Interpreting audit results emulator Checking the job log of an audit What are rules and how are they used Requirements for using rules Considerations for using rules Replacement variables Rule-generated messages and notifications Behavior when automatic audit recovery is enabled Running rules and rule groups manually Running rules or rule groups from within MIMIX Availability Manager Running rules or rule groups from the Rules window Running rules or rule groups from the Data Groups window Running rules from the 5250 emulator Running rule groups from the 5250 emulator Running user rules and rule groups programmatically Example of creating a monitor to run a user rule MIMIX rule groups Chapter 4 Working with notifications and recoveries 137 What are notifications and recoveries Displaying notifications What information is available for notifications Detailed information Options for working with notifications Notifications for newly created objects Displaying recoveries What information is available for recoveries Detailed information Options for working with recoveries Orphaned recoveries Determining whether a recovery is orphaned Removing an orphaned recovery Chapter 5 Starting and ending replication 150 Choices when starting replication What is started with the STRMMX command Considerations when starting with either command Choices when ending replication What is ended by the ENDMMX command Ending immediately or controlled Controlling how long to wait for a controlled end to complete Ending all or selected processes When to end the RJ link Starting MIMIX Ending MIMIX Ending with default values Ending by prompting the ENDMMX command After you end MIMIX products STRMMX and ENDMMX messages Starting selected data group processes

5 Ending selected data group processes Ending a data group in a controlled manner Preparing for a controlled end of a data group Performing the controlled end Confirming the end request completed without problems Considerations for starting data groups When to clear pending entries and entries in error Clear pending and clear error processing Clearing pending entries when open commit cycles exist Checking for open commit cycles Resolving open commit cycles to enable a clear pending start Setting the audit level when starting a data group What replication processes are started by the STRDG command Considerations for ending data groups What replication processes are ended by the ENDDG command Chapter 6 Resolving common replication problems 191 Working with user journal replicated files Working with files in error Working with journal transactions for files in error Placing a file on hold Ignoring a held file Releasing a held file at a synchronization point Releasing a held file Releasing a held file and clearing entries Correcting file-level errors Correcting record-level errors Record written in error Working with tracking entries Working with tracking entries from MIMIX Availability Manager Accessing the Data Group Details - Activity window Working with tracking entries from a 5250 emulator Accessing the appropriate tracking entry display Holding journal entries associated with a tracking entry Ignoring journal entries associated with a tracking entry Waiting to synchronize and release held journal entries for a tracking entry Releasing held journal entries for a tracking entry Releasing and clearing held journal entries for a tracking entry Removing a tracking entry Working with objects in error Using the Work with DG Activity Entries display Retrying data group activity entries Retrying a failed data group activity entry Determining whether an activity entry is in a delay/retry cycle Removing data group activity history entries Chapter 7 Starting, ending, and verifying journaling 216 What objects need to be journaled Authority requirements for starting journaling

6 MIMIX commands for starting journaling Journaling for physical files Displaying journaling status for physical files Starting journaling for physical files Ending journaling for physical files Verifying journaling for physical files Journaling for IFS objects Displaying journaling status for IFS objects Starting journaling for IFS objects Ending journaling for IFS objects Verifying journaling for IFS objects Journaling for data areas and data queues Displaying journaling status for data areas and data queues Starting journaling for data areas and data queues Ending journaling for data areas and data queues Verifying journaling for data areas and data queues Chapter 8 Switching 231 MIMIX Model Switch Framework Planned Switch Unplanned switch Switching using MIMIX Switch Assistant Switching from the MIMIX Basic Main Menu Switching to the backup system Synchronizing data and starting MIMIX on the original production system Switching to the production system Determining when the last switch was performed To check the last switch dates from MIMIX Availability Manager To check the last switch date from a 5250 emulator Problems checking switch compliance Performing a data group switch To check the last switch dates for a data group from MIMIX Availability Manager. 240 To perform a data group switch from MIMIX Availability Manager To perform a data group switch from a 5250 emulator Switch Data Group (SWTDG) command Chapter 9 Less common operations 244 Starting the Lakeview TCP/IP server Ending the Lakeview TCP/IP server Working with objects Displaying long object names Considerations for working with long IFS path names Displaying data group spooled file information Viewing status for active file operations Displaying a remote journal link Displaying status of a remote journal link Identifying data groups that use an RJ link Identifying journal definitions used with RJ Disabling and enabling data groups

7 Procedures for disabling and enabling data groups Determining if advanced journaling is configured Determining if IFS objects can be cooperatively processed Determining if data areas or data queues can be cooperatively processed Using file identifiers (FIDs) for IFS objects Operating a remote journal link independently Starting a remote journal link independently Ending a remote journal link independently Chapter 10 Troubleshooting - where to start 269 Gathering information before reporting a problem Obtaining MIMIX and i5/os information from your system Reducing contention between MIMIX and user applications Data groups cannot be ended Verifying a communications link for system definitions Verifying the communications link for a data group Verifying all communications links Checking file entry configuration manually Data groups cannot be started Cannot start or end an RJ link Removing unconfirmed entries to free an RJ link RJ link active but data not transferring Errors using target journal defined by RJ link Verifying data group file entries Verifying data group data area entries Verifying key attributes Working with data group timestamps Automatically creating timestamps Creating additional timestamps Creating timestamps for remote journaling processing Deleting timestamps Displaying or printing timestamps Removing journaled changes Performing journal analysis Removing journal analysis entries for a selected file Appendix A Interpreting audit results - supporting information 297 Interpreting results for configuration data - #DGFE audit Interpreting results of audits for record counts and file data What differences were detected by #FILDTA What differences were detected by #MBRRCDCNT Interpreting results of audits that compare attributes What attribute differences were detected Where was the difference detected What attributes were compared Attributes compared and expected results - #FILATR, #FILATRMBR audits Attributes compared and expected results - #OBJATR audit Attributes compared and expected results - #IFSATR audit Attributes compared and expected results - #DLOATR audit Comparison results for journal status and other journal attributes

8 How configured journaling settings are determined Comparison results for auxiliary storage pool ID (*ASP) Comparison results for user profile status (*USRPRFSTS) How configured user profile status is determined Comparison results for user profile password (*PRFPWDIND) Appendix B System i5 operations that affect MIMIX 339 MIMIX procedures when performing an initial program load (IPL) MIMIX procedures when performing an operating system upgrade Prerequisites for performing an OS upgrade on either system MIMIX-specific steps for an OS upgrade on the backup system MIMIX-specific steps for an i5/os upgrade on the production system with switching 344 MIMIX-specific steps for an i5/os upgrade on the production system without switching MIMIX procedures when upgrading hardware without a disk image change Considerations for performing a hardware system upgrade without a disk image change MIMIX-specific steps for a hardware upgrade without a disk image change Hardware upgrade without a disk image change - preliminary steps Hardware upgrade without a disk image change - subsequent steps MIMIX procedures when performing a hardware upgrade with a disk image change Considerations for performing a hardware system upgrade with a disk image change Handling MIMIX during a system restore Prerequisites for performing a restore of MIMIX Index 354 8

9 9

10 Product conventions Product conventions The conventions described here apply to all Lakeview products unless otherwise noted. Menus and commands Functionality for all Lakeview products is accessible from the product s main menu. For example, all MIMIX products are accessible from a common MIMIX Main Menu. The options you see on a given menu may vary according to which products are installed. When there is a corresponding command for a menu option, the command is shown at the far right of the display. You can use either the menu option or the command to access the function. To issue a command from a command line outside of the menu interface, you can add the product library name to your library list or you can qualify the command with the name of the product library. If you enter a command without parameters, the system will prompt you for any required parameters. If you enter the command with all of the required parameters, the function is invoked immediately. Some commands can be submitted in batch jobs. Accessing online help MIMIX Availability Manager includes online help that is accessible from within the product. From any window within MIMIX Availability Manager, selecting the Help icon will open the help system and access help for the current window. From a 5250 emulator, context sensitive online help is available for all MIMIX commands and displays. Simply press F1 to view help. The position of your cursor determines what you will see. To view general help for a command, a display, or a menu, press F1 when the cursor is at the top of the display. To view help for a specific option, prompt, or column, press F1 when the cursor is located in the area for which you want help. Publication conventions This book uses typography and specialized formatting to help you quickly identify the type of information you are reading. For example, specialized styles and techniques distinguish information you see on a display from information you enter on a display or command line. In text, bold type identifies a new term whereas an underlined word highlights its importance. Notes and Attentions are specialized formatting techniques that are used, respectively, to highlight a fact or to warn you of the potential for damage. The following topics illustrate formatting techniques that may be used in this book. 10

11 Formatting for displays and commands Table 1 shows the formatting used for the information you see on displays and command interfaces: Table 1. Formatting examples for displays and commands Convention Description Examples Initial Capitalization Italic UPPERCASE monospace font Names of menus or displays, commands, keyboard keys, columns. (Column names are also shown in italic). Names of columns, prompts on displays, variables, user-defined values System-defined mnemonic names for commands, parameters, and values. Text that you enter into a 5250 emulator command line. In instructions, the conventions of italic and UPPERCASE also apply. Examples showing programming code. MIMIX Basic Main Menu Update Access Code command Page Up key The Status column The Start processes prompt The library-name value CHGUPSCFG command WARNMSG parameter The value *YES Type the command MIMIX and press Enter. DGDFN(name system1 system2) CHGVAR &RETURN &CONTINUE 11

12 Publication conventions 12

13 Sources for additional information This book refers to other published information. The following information, plus additional technical information, can be located in the IBM System i5 Information Center. From the Information center you can access these IBM eserver System i5 topics, books, and redbooks: Backup and Recovery eserver System i5 Journal management DB2 Universal Database for IBM iseries Database Programming Integrated File System Introduction Independent disk pools OptiConnect for OS/400 TCP/IP Setup IBM redbook Striving for Optimal Journal Performance on DB2 Universal Database for iseries, SG IBM redbook AS/400 Remote Journal Function for High Availability and Data Replication, SG IBM redbook System i5 iasps: A Guide to Moving Applications to Independent ASPs, SG The following information may also be helpful if you use advanced journaling: DB2 UDB for iseries SQL Programming Concepts DB2 Universal Database for iseries SQL Reference IBM redbook AS/400 Remote Journal Function for High Availability and Data Replication, SG

14 Sources for additional information 14

15 How to contact us For contact information, visit our Contact CustomerCare web page. If you are current on maintenance, support for MIMIX products is also available when you log in to Support Central. It is important to include product and version information whenever you report problems. If you use MIMIX Availability Manager, you should also include the version information provided at the bottom of each MIMIX Availability Manager window. 15

16 How to contact us 16

17 MIMIX overview Chapter 1 MIMIX overview This book provides operational information and procedures for using MIMIX ha1 and MIMIX ha Lite. For simplicity, this book uses the term MIMIX to refer to the functionality provided by either product unless a more specific name is necessary. MIMIX version 5 provides high availability for your critical data in a production environment on IBM System i5 through real-time replication of changes. MIMIX continuously captures changes to critical database files and objects on a production system, sends the changes to a backup system, and applies the changes to the appropriate database file or object on the backup system. The backup system stores exact duplicates of the critical database files and objects from the production system. MIMIX uses two replication paths to address different pieces of your replication needs. These paths operate with configurable levels of cooperation or can operate independently. The user journal replication path captures changes to critical files and objects configured for replication through a user journal. When configuring this path, shipped defaults use the i5/os remote journaling function to simplify sending data to the remote system. In previous versions, MIMIX DB2 Replicator provided this function. The system journal replication path handles replication of critical system objects (such as user profiles or spooled files), integrated file system (IFS) objects, and document library object (DLOs) using the i5/os system journal. In previous versions MIMIX Object Replicator provided this function. Configuration choices determine the degree of cooperative processing used between the system journal and user journal replication paths when replicating database files, IFS objects, data areas, and data queues. One common use of MIMIX is to support a hot backup system to which operations can be switched in the event of a planned or unplanned outage. If a production system becomes unavailable, its backup is already prepared for users. In the event of an outage, you can quickly switch users to the backup system where they can continue using their applications. MIMIX captures changes on the backup system for later synchronization with the original production system. When the original production system is brought back online, MIMIX assists you with analysis and synchronization of the database files and other objects. You can view the replicated data on the backup system at any time without affecting productivity. This allows you to generate reports, submit (read-only) batch jobs, or perform backups to tape from the backup system. In addition to real-time backup capability, replicated databases and objects can be used for distributed processing, allowing you to off-load applications to a backup system. Typically MIMIX is used among systems in a network. Simple environments have one production system and one backup system. More complex environments have multiple production systems or backup systems. MIMIX can also be used on a single system. 17

18 MIMIX automatically monitors your replication environment to detect and correct potential problems that could be detrimental to maintaining high availability. MIMIX also provides a means of verifying that the files and objects being replicated are what is defined to your configuration. This can help ensure the integrity of your MIMIX configuration. The topics in this chapter include: MIMIX concepts on page 19 describes key concepts that you need to know about MIMIX. Key concepts for MIMIX AutoGuard on page 23 describes concepts related to automatic detection and recovery of problems with MIMIX AutoGuard. MIMIX policies on page 26 describes polices used by MIMIX and how to set them. 18

19 MIMIX concepts The basic concepts associated with MIMIX are identified below. More detailed information is available in the MIMIX Reference book. MIMIX installation - The network of System i5 systems that transfer data and objects among each other using functions of a common MIMIX product. A MIMIX installation is defined by the way in which you configure the MIMIX product for each of the participating systems. A system can participate in multiple independent MIMIX installations. MIMIX Availability Manager - This browser-based user interface to MIMIX supports operational tasks with significant improvements over their 5250 emulator equivalents. With MIMIX Availability Manager, you are guided directly to the highest severity problem in an installation and presented with suggested resolutions for each unique problem. MIMIX AutoGuard - This set of functions within MIMIX provide the ability to automatically detect and correct problems in a MIMIX installation during replication processes and during automatically scheduled audits. Replication path - A replication path is a series of processes used for replication that represent the critical path on which data to be replicated moves from its origin to its destination. MIMIX uses two replication paths to accommodate differences in how replication occurs for user journal and system journal entries. These paths operate with configurable levels of cooperation or can operate independently. Data group - A MIMIX construct that is used to control replication activities. A data group is a logical grouping of database files, data areas, objects, IFS objects, DLOs, or a combination thereof that defines a unit of work by which MIMIX replication activity is controlled. A data group may represent an application, a set of one or more libraries, or all of the critical data on a given system. Application environments may define a data group as a specific set of files and objects. Data group entries - A data group entry is a configuration construct that identifies a source of information to be replicated by or excluded from replication by a data group. Each entry identifies at least one object and its location on the source system. Classes of data group entries are based on object type. MIMIX uses data group entries to determine whether a journal entry should be replicated. Data groups that replicate from both the system journal and a user journal can have any combination of data group entries. Tracking entries - Tracking entries identify objects that can be replicated using advanced journaling techniques and assist with tracking the status of their replication. A unique tracking entry is associated with each IFS object, data area, and data queue that is eligible for replication using advanced journaling. IFS tracking entries identify eligible, existing IFS objects while object tracking entries identify eligible, existing data areas and data queues. Definitions - MIMIX uses several types of named definitions to identify related configuration choices. System definitions identify a systems that participate in a MIMIX installation. Each system definition identifies one system. 19

20 MIMIX concepts Transfer definitions identify the communications path and protocol to be used between systems. Journal definitions identify journaling environments that MIMIX uses for replication Each journal definition identifies a system and characteristics of the journaling environment on that system. Data group definitions identify the characteristics of how replication occurs between two systems. Each data group definition determines the direction in which replication occurs between the systems, whether that direction can be switched, and the default processing characteristics for replication processes. Remote journal link (RJ link) - An RJ link is a MIMIX configuration element that identifies an i5/os remote journaling environment used by user journal replication processes. An RJ link identifies the journal definitions that define the source and target journals, primary and secondary transfer definitions for the communications path used by MIMIX, and whether the i5/os remote journal function sends journal entries asynchronously or synchronously. System manager - The system manager is a pair of communications jobs between the management system and a network system which must be active to enable replication. The system manager monitors for configuration changes and automatically moves any configuration changes to the network system. Dynamic status changes are also collected and returned to the management system. The system manager also gathers messages and timestamp information from the network system and places them in a message log and timestamp file on the management system. In addition, the system manager performs periodic maintenance tasks, including cleanup of the system and data group history files. Journal manager - The journal manager is a job on each system that MIMIX uses to maintain the journaling environment on that system. By default, MIMIX performs both change management and delete management for journal receivers used by the replication process. MIMIX Model Switch Framework - The MIMIX Model Switch Framework is a set of programs and commands that are designed to provide a consistent framework to be used when performing planned or unplanned switches. Typically, a model switch framework is customized to your environment through its exit programs. MIMIX Switch Assistant uses your model switch framework to perform switching MIMIX Switch Assistant - Available within MIMIX Availability Manager, the MIMIX Switch Assistant is a guided user interface that guides you through switching using your default MIMIX Model Switch Framework. Production system and backup system - These terms describe the role of a system relative to the way applications are used on that system. A production system is the system currently running the production workload for the applications. In normal operations, the production system is the system on which the principal copy of the data and objects associated with the application exist. A backup system is the system that is not currently running the production workload for the applications. In normal operations, the backup system is the system on which you maintain a copy of the data and objects associated with the application. These roles are not always associated with a specific system. For example, if you switch application processing to the backup system, the backup system temporarily becomes the production system. 20

21 Typically, for normal operations in basic two-system environment, replicated data flows from the system running the production workload to the backup system. Source system and target system - These terms identify the direction in which an activity occurs between two participating systems. A source system is the system from which MIMIX replication activity between two systems originates. In replication, the source system contains the journal entries. Information from the journal entries is either replicated to the target system or used to identify objects to be replicated to the target system. A target system is the system on which MIMIX replication activity between two systems completes. Management system and network system - These terms define the role of a system relative to how the products interact within a MIMIX installation. These roles remain associated with the system within the MIMIX installation to which they are defined. One system in the MIMIX installation is designated as the management system and the remaining one or more systems are designated as network systems. A management system is the system in a MIMIX installation that is designated as the control point for all installations of the product within the MIMIX installation. The management system is the location from which work to be performed by the product is defined and maintained. Often the system defined as the management system also serves as the backup system during normal operations. A network system is any system in a MIMIX installation that is not designated as the management system (control point) of that MIMIX installation. Work definitions are automatically distributed from the management system to a network system. Often a system defined as a network system also serves as the production system during normal operations. Journal - An i5/os system object that identifies the objects being journaled and the journal receivers associated with the journal. The system journal is a specialized journal on the System i5 which MIMIX uses. Journaling and object auditing - Journaling and object auditing are techniques that allow object activity to be logged to a journal. Journaling logs activity for selected objects of specific object types to a user journal. Object auditing logs activity for all objects to the security audit journal (QAUDJRN, the system journal), including those defined to a user journal. MIMIX relies on these techniques and the entries placed in the journal receivers for replicating logged activity. Journal receiver - An i5/os system object that is associated with a journal and contains the log of all activity for objects defined to the journal. Journal entry - A record added to a journal receiver that identifies an event that occurred on a journaled object. MIMIX uses file and record level journal entries to recreate the object on a designated system. Log space - A MIMIX object that provides an efficient storage and manipulation mechanism for replicated data that is temporarily stored on the target system during the receive and apply processes. 21

22 MIMIX concepts 22

23 Key concepts for MIMIX AutoGuard Audit concepts The key concepts associated with MIMIX AutoGuard are identified below. Compliance - Compliance is checked for auditing and for switching. MIMIX determines compliance by verifying whether successfully completed audits or regular switches occur within a time range defined in policies. The default policy values are set at what is considered the best practice for maintaining switch-readiness. Policies - A policy is a mechanism used to enable, disable, or provide input to a function or an attribute of MIMIX AutoGuard or MIMIX Switch Assistant. The initially shipped values for policies apply to an installation. However, installation-level policies can be changed and can also be overridden for individual data groups. Automatic recovery - MIMIX is shipped so that automatic recovery is enabled for database replication, object replication, and auditing. This means that, if MIMIX AutoGuard detects any of a set of scenarios during these activities which are known to interfere with maintaining your MIMIX environment, it will automatically start recovery actions to correct them. Through policies, you have the ability to disable automatic recovery in any of these areas at the installation or data group level. Recoveries - The term recovery is used in two ways. The most common use refers to the recovery action taken by MIMIX AutoGuard 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 that is created when the recovery action starts and is removed when it completes. Audits - Audits are predetermined programs that are used to check for known conditions, preferably at regularly scheduled intervals. Audits use all of the concepts described here as well as additional concepts of their own, described in Audit concepts on page 23. Notifications - Notifications are a secondary mechanism used to report when the activities performed by MIMIX AutoGuard complete or end in error. (The primary mechanism is to report errors through replication processes and the audit summary.) Shipped values for policies result in notifications for successful completion of audits. Through policies, you have options for controlling whether successful recoveries send notifications and for controlling the severity level of notifications used to report MIMIX rules ending in error. Each audit identifies a data group to be checked and the MIMIX rule used to check it. Multiple audits exist for each data group. Each audit also identifies the audit level in effect, its compliance status and status of actions performed by its MIMIX rule. When a phase completes, its timestamps and statistics are also available. The process of auditing consists of a compare phase and a recovery phase. In the compare phase of an audit, the identified MIMIX rule initiates a specific compare command against the data group. If there are detected differences when the compare completes, the audit enters its recovery phase to start automatic recovery actions as needed. The recovery phase can be optionally disabled through policies. 23

24 Key concepts for MIMIX AutoGuard Rules - A rule defines a command to be invoked by the MIMIX Run Rule (RUNRULE) command and options for notifying you of the result. Rules come in two varieties: shipped MIMIX rules and user-defined rules. MIMIX rules - MIMIX AutoGuard uses MIMIX rules as the mechanism for defining and invoking audits. Each shipped MIMIX rule pre-defines a command invoked by the compare phase of an audit and the possible actions that can be initiated, if needed, in the recovery phase of an audit. MIMIX rules have names which begin with the pound sign (#) character. While the name of a MIMIX rule and its command and recovery actions cannot be changed, through policies and scheduling, you have considerable control over audits that use MIMIX rules. Monitors - For each MIMIX rule, an associated shipped monitor on each system provides automatic scheduling through MIMIX Monitor. Policies 1 determine the system on which monitors run. For new installations, shipped monitors provide everything you need to have auditing scheduled without further intervention. A key benefit to using shipped monitors for any installation is that your audits and any associated jobs in progress are appropriately handled when you use the Start MIMIX and End MIMIX commands (STRMMX, ENDMMX). Audit levels - The audit level determines how aggressively an audit checks your environment during its compare phase. Each MIMIX rule has the capability of providing multiple audit levels. If a MIMIX rule provides more than one audit level, each level provides increasingly more checking capability. Through policies, you have control over the audit level used for rules that provide more than one level. 1. The Run rule on system policy was introduced in V4R4 service pack SP If you are monitoring a system that is running V4R4 service pack SP , the scheduled audits are run from the management system; each monitor s condition program determines the system on which the scheduled audits should be run 24

25 25

26 MIMIX policies MIMIX policies Policy descriptions MIMIX policies control whether functions provided by MIMIX AutoGuard and MIMIX Switch Assistant are enabled and specify when and how you are notified about problems that may occur. The shipped default settings for policies apply to all systems and data groups within an installation. With the Set MIMIX Policy (SETMMXPCY) command, you can change the values in effect for the installation as well as specify policies for an individual data group. When a policy is set for a data group, it takes precedence over the installation policy. Policies must be changed from the management system. Changing policies requires that you have management-level authority to the Set MIMIX Policy (SETMMXPCY) command. When policies apply to an area in MIMIX Availability Manager, an option to change them is available as an action. From a 5250 emulator, you can set policies from a command line or from the Work with Audits, the MIMIX Availability Status, and the Work with DG Definitions displays. There are minor differences in the names of policies between MIMIX Availability Manager and the 5250 emulator. The names shown here are those used in MIMIX Availability Manager. For a complete description of all policy values, see online help for the command. Policy values may affect data throughout your entire environment, not just a single installation or data group. This is of particular concern in environments that have more than two systems or which have replication occurring simultaneously in more than one direction. Be sure to review Considerations when choosing policy values on page 31 and When not to use MIMIX AutoGuard on page 32. See Table 2 for the shipped defaults for policies. Data group definition - Select the scope of the policies to be set. When the value *INST is specified, the policies apply to all systems and data groups in the installation. When a three-part qualified name of a data group is specified, the policies apply to only that data group and overrides the installation-level policy values. Automatic system journal recovery - Select whether to enable functions that automatically check for common object errors that occur during replication from the system journal and automatically start recovery actions to correct detected errors. Automatic user journal recovery - Select whether to enable functions that automatically check for common file errors that occur during replication from the user journal and automatically start recovery actions to correct detected errors. Automatic audit recovery - Select whether to enable audits to start automatically recovery actions to correct differences detected during their compare phase. System journal recovery notify on success - Select whether automatic object recovery actions send an informational (*INFO) notification upon successful 26

27 completion. This policy is only valid when the Automatic system journal recovery policy is enabled. User journal recovery notify on success - Select whether automatic database recovery actions send an informational (*INFO) notification upon successful completion. This policy is only valid when the Automatic user journal recovery policy is enabled. Audit notify on success - Select whether activity initiated by audits, including recovery actions, should automatically send an informational (*INFO) notification upon successful completion. If an audit is run when the Automatic audit recovery policy is disabled, successful notifications are sent only for the compare phase of the audit. Notification severity - Select the severity level of the notifications sent when a rule ends in error. This policy determines the severity of the notification that is sent, not the severity of the error itself. The policy is in effect whether the rule is invoked manually or automatically. This policy is useful for setting up an order precedence for notifications at the data group level. For example, if you set this policy for data group CRITICAL to be *ERROR when the value for the installation-level policy is *WARNING, any error notifications sent from data group CRITICAL will have a higher severity than those from other data groups. Object only on target action - Select how the recovery action for specific audits should handle objects that are configured for replication but exist only on the target system. The following rules check for the only-on-target error: #OBJATR, #IFSATR, #DLOATR, #FILATR, and #FILATRMBR. When the Automatic audit recovery (AUDRCY) policy is enabled, these rules use the value from this policy to attempt recovery for this error. See Considerations when choosing policy values on page 31 for additional information. Regardless of how this policy is set, extra file members on the target system are always deleted. Journaling attribute difference action - Specify the recovery action to take for scenarios in which audits have detected differences between the actual and configured values of journaling attributes for objects journaled to a user journal. This type of difference can occur for the Journal Images attribute and the Journal Omit Open/Close attribute. Differences found on either the source or target object are affected by this policy. MIMIX configured higher - Specify the recovery for correcting a difference in which the MIMIX configuration specifies an attribute value that results in a higher number of journal transactions than the object's journaling attribute. MIMIX configured lower - Specify the recovery action for correcting a difference in which the MIMIX configuration specifies an attribute value that results in a lower number of journal transactions than the object's journaling attribute. User journal apply threshold action - Select what action to pass to the Compare File Data (CMPFILDTA) command or the Compare Record Count (CMPRCDCNT) command when it is invoked with *DFT specified for its DB apply threshold (DBAPYTHLD) parameter. The command s parameter determines what to do if the 27

28 MIMIX policies database apply session backlog exceeds the threshold warning value configured for the database apply process. This policy applies whenever these commands are used and the backlog exceeds the threshold. The shipped default for this policy causes the requested command to end and may cause the loss of repairs in progress or inaccurate counts for members. You can also set this policy to allow the request to continue despite the exceeded threshold. Maximum rule runtime - Select a value or specify the maximum number of minutes a MIMIX rule can run when the Automatic audit recovery policy is enabled. When the time elapsed since the rule started exceeds the value specified, any recovery actions in progress will end. The compare phase of the rule is always allowed to complete regardless of this policy s value. The shipped default for this policy of 1440 minutes (24 hours) prevents running multiple instances of the same MIMIX rule within the same day. Valid values are 60 minutes through minutes (1 week). The time is checked when the audit starts, when the recovery phase starts, and periodically during the recovery phase. Audit warning threshold - Select a value or specify how many days can elapse after an audit was last performed before an indicator is set. When the number of days that have elapsed exceeds the threshold, the indicator is set to inform you that auditing needs your attention. The shipped default value of 7 days is at the limit of best practices for auditing. In MIMIX Availability Manager, this indicator appears as an Attention icon next to Compliance in the Details section of the navigation bar and next to the audit in the Audit Compliance window. In the 5250 emulator, the indicator appears as the Audits and notifications activity on the MIMIX Availability Status (WRKMMXSTS) window. Note: It is recommended that you set this value to match the frequency with which you perform audits. It is possible for an audit to be prevented from running for several days due to environmental conditions or the Action for running audit policy. You may not notice that the audit did not run when expected until the Audit warning threshold is exceeded, potentially several days later. If you run all audits daily, specify 1 for the Audit warning threshold policy. If you do not run audits daily, set the value to what makes sense in your MIMIX environment. For example, if you run the #FILDTA audit once a week and run all other audits daily, the default value of 7 would cause all audits except #FILDTA to have exposure indicated. The value 1 would be appropriate for the daily audits but the #FILDTA audit would be identified as approaching out of compliance much of the time. Audit action threshold - Select a value or specify how many days can elapse after an audit was last performed before an indicator is set. When the number of days that have elapsed exceeds the threshold, the indicator is set to inform you that action is required because the audit is out of compliance. The shipped default of 14 days is the suggested value for this threshold, which is 7 days beyond the limit of best practices for auditing. In MIMIX Availability Manager, this indicator appears as an Action Required icon next to Compliance in the Details section of the navigation bar and next to the audit in the Audit Compliance window. In the 5250 emulator, the indicator appears as the Audits and notifications activity on the WRKMMXSTS window. 28

29 Note: It is recommended that you set this value to match the frequency with which you perform audits. It is possible for an audit to be prevented from running for several days due to environmental conditions or the Action for running audit policy. You may not notice that the audit did not run when expected until the Audit action threshold is exceeded, potentially several days later. If you run all audits daily, specify 1 for the Audit action threshold policy. If you do not run audits daily, set the value to what makes sense in your MIMIX environment. For example, if you run the #FILDTA audit once a week and run all other audits daily, the default value of 14 would cause all audits except #FILDTA to have exposure indicated. The value 2 would be appropriate for the daily audits but the #FILDTA audit would be identified as approaching out of compliance much of the time. Audit level - Select the level of comparison that an audit will perform when a MIMIX rule which supports multiple levels is invoked against a data group. The policy is in effect regardless of how the rule is invoked. The amount of checking performed increases with the level number. This policy makes it easy to change the level of audit performed without changing the audit scheduling or rules. No auditing is performed if this policy is set to *DISABLED. Note: Best practice is to use level 30 to perform the most extensive audit. If you use a lower level, consider its effect on how often you need to be certain that data is synchronized between source and target systems. For additional information, see Changing the audit level policy for switching on page 38. Run rule on system - Select the system on which to run audits. 1 This policy is used when audits are invoked with *YES specified for the value of the Use run rule on system policy (USERULESYS) parameter on the Run Rule (RUNRULE) or Run Rule Group (RUNRULEGRP) command. When *YES is specified in these commands, this policy determines the system on which to run audits. The policy s shipped default is to run audits from the management system. You can also set the policy to run audits from the network system, the source or target system, or from a list of system definitions. When both systems of a data group are in the specified list, the target system is used. While this policy is intended for audits, any rule that meets the same criteria will use this policy. Action for running audits - Select a value for each condition 2. This policy determines the type of audit actions permitted when certain conditions exist in the data group. If a condition exists at the time of an audit request, audit activity is restricted to the specified action. If multiple conditions exist and the values specified are different, only the most restrictive of the specified actions is allowed. If none of the conditions are present, the audit requests are performed according to other policy values in effect. Inactive data group - Specify the type of auditing actions allowed when any replication process required by the data group is inactive. For example, a data group of TYPE(*ALL) is considered inactive if any of its database or object replication processes is in a state other than active. 1. Users will see this policy only on systems running V4R4 service pack SP or higher. 2. Users will see this policy only on systems running version 5 service pack or higher. 29