Version 6.

0 MIMIX ha1 and MIMIX ha Lite for IBM i

Using MIMIX

Published: December 2009 level 6.0.15.00

Copyrights, Trademarks, and Notices

Product conventions.................................................................................................... 9 Menus and commands .......................................................................................... 9 Accessing online help............................................................................................ 9 Publication conventions............................................................................................... 9 Formatting for displays and commands .............................................................. 10 Sources for additional information............................................................................. 11 How to contact us...................................................................................................... 12 Chapter 1 MIMIX overview 13 MIMIX concepts......................................................................................................... 15 MIMIX AutoGuard overview ...................................................................................... 18 Key concepts for MIMIX AutoGuard .................................................................... 18 Auditing overview ................................................................................................ 19 What are MIMIX AutoGuard best practices? ....................................................... 20 How do I get started with MIMIX AutoGuard? ..................................................... 20 New MIMIX installations ................................................................................ 21 MIMIX policies ........................................................................................................... 22 Considerations when choosing policy values ...................................................... 22 When not to use MIMIX AutoGuard .................................................................... 23 Setting policies - general ..................................................................................... 24 To change existing installation policies ......................................................... 24 To change policies for a data group .............................................................. 25 To reset a data group-level policy to use the installation level value............. 25 Disabling MIMIX AutoGuard for data groups using the MIMIX CDP feature ....... 26 Policy descriptions............................................................................................... 27 Policies for recovery during replication...................................................................... 33 Errors handled by automatic database recovery ................................................. 33 Errors handled by automatic object recovery ...................................................... 34 Logging in to MIMIX Availability Manager ................................................................. 37 Your location is remembered .............................................................................. 37 Areas of the window in MIMIX Availability Manager.................................................. 37 Additional navigation and selection aids ............................................................. 39 Other useful tips .................................................................................................. 41 Accessing the MIMIX Main Menu from a 5250 emulator........................................... 42 Working with status 44 Becoming acquainted with status.............................................................................. 45 Status in MIMIX Availability Manager .................................................................. 45 The Enterprise View - your status shortcut.................................................... 45 Status on the navigation bar.......................................................................... 46 Monitoring status with MIMIX Availability Manager ................................................... 48 Checking replication status with MIMIX Availability Manager.............................. 48 Checking audit status with MIMIX Availability Manager ...................................... 48 Checking status of supporting services with MIMIX Availability Manager ........... 49 Monitoring status with MIMIX Availability Status ....................................................... 50 Checking replication status - 5250 emulator ....................................................... 52 Checking audit and notification status - 5250 emulator....................................... 52 Checking for status of supporting services - 5250 emulator ............................... 53 The Work with Data Groups display - 5250 emulator................................................ 54 Problems reflected in the Audits/Recov./Notif. field ............................................ 56

Chapter 2

Problems reflected in the Data Group column .................................................... 56 Resolving problems highlighted in the Data Group column........................... 57 Replication problems reflected in the Source and Target columns ..................... 59 Setting the automatic refresh interval .................................................................. 60 Working with the detailed status of data groups........................................................ 61 Displaying data group detailed status with MIMIX Availability Manager.............. 61 Variations of the Data Group Details - Activity window ................................. 64 Displaying data group detailed status from a 5250 emulator .............................. 64 Merged view .................................................................................................. 65 Object detailed status views .......................................................................... 69 Database detailed status views ..................................................................... 71 Identifying replication processes with backlogs......................................................... 76 Chapter 3 Working with audits and rules 79 What are rules and how they are used by auditing ................................................... 80 Requirements for using audits and rules................................................................... 81 Guidelines and recommendations for auditing .......................................................... 81 Considerations and recommendations for rules .................................................. 82 Replacement variables .................................................................................. 83 Rule-generated messages and notifications ................................................. 84 Where audit status and compliance status is reported.............................................. 85 Working with audits ................................................................................................... 87 Displaying audit status ........................................................................................ 90 Running audits immediately ................................................................................ 91 Ending audits....................................................................................................... 91 Displaying audit level differences ........................................................................ 92 Resolving audit problems - MIMIX Availability Manager ..................................... 93 Resolving audit problems - 5250 emulator .......................................................... 95 Checking the job log of an audit .......................................................................... 96 Working with audit compliance.................................................................................. 98 Determining whether auditing is within compliance........................................... 100 Working with audit schedules.................................................................................. 102 How audits are scheduled automatically ........................................................... 104 Shipped default audit schedules ....................................................................... 104 Considerations for changing audit scheduling................................................... 105 When to run the #DGFE audit ..................................................................... 106 Changing when audits are scheduled ............................................................... 106 Schedule parameter notes .......................................................................... 107 Changing the system where audits are performed............................................ 108 Considerations for using a different job scheduler for audits ............................ 108 Policies for auditing ................................................................................................. 109 Preventing audits from running ......................................................................... 110 To restrict audit activity in an installation based on data group state .......... 110 To restrict audit activity for a specific data group based on its state ........... 111 To disable auditing for an installation .......................................................... 112 To disable auditing for a data group ............................................................ 113 To disable automatic scheduling of an audit ............................................... 113 Running rules and rule groups manually................................................................. 115 Running rules or rule groups from within MIMIX Availability Manager .............. 115 Running rules or rule groups from the Rules window.................................. 115

Running rules or rule groups from the Data Groups window....................... 116 Running rules from the 5250 emulator .............................................................. 116 Running rule groups from the 5250 emulator .................................................... 117 Checking results of a user-defined rule................................................................... 118 Chapter 4 Working with notifications and recoveries 119 What are notifications and recoveries ..................................................................... 119 Displaying notifications............................................................................................ 120 What information is available for notifications ................................................... 121 Detailed information..................................................................................... 122 Options for working with notifications ................................................................ 122 Notifications for newly created objects .................................................................... 124 Displaying recoveries .............................................................................................. 125 What information is available for recoveries...................................................... 126 Detailed information..................................................................................... 127 Options for working with recoveries .................................................................. 127 Orphaned recoveries ......................................................................................... 128 Determining whether a recovery is orphaned.............................................. 128 Removing an orphaned recovery ................................................................ 129 Starting and ending replication 131 Choices when starting replication............................................................................ 133 What is started with the STRMMX command.................................................... 133 Considerations for starting data groups .................................................................. 135 When to clear pending entries and entries in error ........................................... 136 Clear pending and clear error processing ................................................... 136 Clearing pending entries when open commit cycles exist ................................. 139 Checking for open commit cycles................................................................ 139 Resolving open commit cycles to enable a clear pending start................... 140 Setting the audit level when starting a data group ............................................ 140 Choices when ending replication............................................................................. 141 What is ended by the ENDMMX command ....................................................... 142 Ending immediately or controlled ...................................................................... 143 Controlling how long to wait for a controlled end to complete ..................... 144 Ending all or selected processes....................................................................... 144 When to end the RJ link .................................................................................... 144 Considerations for ending data groups ................................................................... 146 Starting MIMIX......................................................................................................... 147 Ending MIMIX.......................................................................................................... 147 Ending with default values................................................................................. 147 Ending by prompting the ENDMMX command.................................................. 148 After you end MIMIX products ........................................................................... 148 STRMMX and ENDMMX messages ....................................................................... 149 Starting selected data group processes .................................................................. 150 Ending selected data group processes ................................................................... 151 Ending a data group in a controlled manner ........................................................... 152 Preparing for a controlled end of a data group .................................................. 152 Performing the controlled end ........................................................................... 152 Confirming the end request completed without problems ................................. 153 What replication processes are started by the STRDG command.......................... 155

Chapter 5

What replication processes are ended by the ENDDG command .......................... 159 Chapter 6 Resolving common replication problems 163 Working with MIMIX managers ............................................................................... 164 Resolving status problems with system and journal managers......................... 164 Starting a system manager or a journal manager ............................................. 165 Ending a system manager or a journal manager .............................................. 165 Working with message queues ............................................................................... 167 Working with the message log ................................................................................ 168 Working with user journal replicated files ................................................................ 170 Working with files in error .................................................................................. 170 Working with journal transactions for files in error....................................... 173 Placing a file on hold ......................................................................................... 174 Ignoring a held file ............................................................................................. 174 Releasing a held file at a synchronization point ................................................ 175 Releasing a held file .......................................................................................... 176 Releasing a held file and clearing entries.......................................................... 176 Correcting file-level errors ................................................................................. 176 Correcting record-level errors............................................................................ 177 Record written in error ................................................................................. 177 Working with tracking entries .................................................................................. 179 Working with tracking entries from MIMIX Availability Manager........................ 179 Accessing the Data Group Details - Activity window ................................... 179 Working with tracking entries from a 5250 emulator ......................................... 180 Accessing the appropriate tracking entry display ........................................ 180 Holding journal entries associated with a tracking entry.............................. 182 Ignoring journal entries associated with a tracking entry............................. 182 Waiting to synchronize and release held journal entries for a tracking entry .... 183 Releasing held journal entries for a tracking entry ...................................... 183 Releasing and clearing held journal entries for a tracking entry.................. 184 Removing a tracking entry........................................................................... 184 Working with objects in error ................................................................................... 185 Using the Work with DG Activity Entries display ............................................... 186 Retrying data group activity entries ................................................................... 188 Retrying a failed data group activity entry ................................................... 188 Determining whether an activity entry is in a delay/retry cycle .......................... 189 Removing data group activity history entries........................................................... 190 Starting, ending, and verifying journaling 191 What objects need to be journaled.......................................................................... 192 Authority requirements for starting journaling.................................................... 193 MIMIX commands for starting journaling................................................................. 194 Journaling for physical files ..................................................................................... 195 Displaying journaling status for physical files .................................................... 195 Starting journaling for physical files ................................................................... 195 Ending journaling for physical files .................................................................... 196 Verifying journaling for physical files ................................................................. 197 Journaling for IFS objects........................................................................................ 198 Displaying journaling status for IFS objects ...................................................... 198

Chapter 7

Starting journaling for IFS objects ..................................................................... 198 Ending journaling for IFS objects ...................................................................... 199 Verifying journaling for IFS objects.................................................................... 200 Journaling for data areas and data queues............................................................. 201 Displaying journaling status for data areas and data queues............................ 201 Starting journaling for data areas and data queues .......................................... 201 Ending journaling for data areas and data queues............................................ 202 Verifying journaling for data areas and data queues ......................................... 203 Chapter 8 Switching 204 About switching ....................................................................................................... 204 MIMIX Model Switch Framework....................................................................... 205 Planned Switch.................................................................................................. 205 Unplanned switch .............................................................................................. 206 Setting policies for switching ............................................................................. 208 Specifying a default switch framework in policies........................................ 208 Setting polices for MIMIX Switch Assistant ................................................. 208 Setting policies for switch compliance for a specific data group.................. 209 Setting policies when MIMIX Switch Assistant is not used.......................... 210 Changing the audit level policy for switching..................................................... 210 Switching using MIMIX Switch Assistant................................................................. 212 Switching from the MIMIX Basic Main Menu........................................................... 212 Switching to the backup system ........................................................................ 213 Synchronizing data and starting MIMIX on the original production system ....... 214 Switching to the production system ................................................................... 214 Determining when the last switch was performed ................................................... 215 Checking the last switch dates from MIMIX Availability Manager ..................... 215 Checking the last switch date from a 5250 emulator......................................... 216 Problems checking switch compliance.................................................................... 216 Performing a data group switch............................................................................... 217 Performing a data group switch from MIMIX Availability Manager .................... 217 Performing a data group switch from a 5250 emulator ..................................... 217 Switch Data Group (SWTDG) command................................................................. 219 Less common operations 221 Starting the TCP/IP server ...................................................................................... 222 Ending the TCP/IP server........................................................................................ 223 Working with objects ............................................................................................... 224 Displaying long object names............................................................................ 224 Considerations for working with long IFS path names ................................ 224 Displaying data group spooled file information.................................................. 224 Viewing status for active file operations .................................................................. 226 Displaying a remote journal link .............................................................................. 227 Displaying status of a remote journal link................................................................ 228 Identifying data groups that use an RJ link ............................................................. 230 Identifying journal definitions used with RJ ............................................................. 231 Disabling and enabling data groups ........................................................................ 232 Procedures for disabling and enabling data groups .......................................... 233 Determining if non-file objects are configured for user journal replication............... 234 Determining how IFS objects are configured .................................................... 234

Chapter 9

Determining how data areas or data queues are configured ............................ 235 Using file identifiers (FIDs) for IFS objects .............................................................. 236 Operating a remote journal link independently........................................................ 237 Starting a remote journal link independently ..................................................... 237 Ending a remote journal link independently ...................................................... 237 Chapter 10 Troubleshooting - where to start 239 Gathering information before reporting a problem .................................................. 241 Obtaining MIMIX and IBM i information from your system ................................ 241 Reducing contention between MIMIX and user applications................................... 242 Data groups cannot be ended ................................................................................. 243 Verifying a communications link for system definitions ........................................... 244 Verifying the communications link for a data group................................................. 245 Verifying all communications links..................................................................... 245 Checking file entry configuration manually.............................................................. 246 Data groups cannot be started ................................................................................ 248 Cannot start or end an RJ link................................................................................. 249 Removing unconfirmed entries to free an RJ link.............................................. 249 RJ link active but data not transferring .................................................................... 250 Errors using target journal defined by RJ link.......................................................... 251 Verifying data group file entries............................................................................... 252 Verifying data group data area entries .................................................................... 252 Verifying key attributes ............................................................................................ 252 Working with data group timestamps ...................................................................... 254 Automatically creating timestamps .................................................................... 254 Creating additional timestamps ......................................................................... 254 Creating timestamps for remote journaling processing ..................................... 255 Deleting timestamps .......................................................................................... 256 Displaying or printing timestamps ..................................................................... 256 Removing journaled changes.................................................................................. 257 Performing journal analysis ..................................................................................... 258 Removing journal analysis entries for a selected file ........................................ 260

Appendix A Interpreting audit results - supporting information 262 Interpreting results for configuration data - #DGFE audit........................................ 263 Interpreting results of audits for record counts and file data ................................... 265 What differences were detected by #FILDTA.................................................... 265 What differences were detected by #MBRRCDCNT ......................................... 267 Interpreting results of audits that compare attributes .............................................. 268 What attribute differences were detected .......................................................... 269 Where was the difference detected................................................................... 271 What attributes were compared ........................................................................ 272 Attributes compared and expected results - #FILATR, #FILATRMBR audits.... 273 Attributes compared and expected results - #OBJATR audit ............................ 278 Attributes compared and expected results - #IFSATR audit ............................. 286 Attributes compared and expected results - #DLOATR audit ........................... 288 Comparison results for journal status and other journal attributes .................... 290 How configured journaling settings are determined .................................... 293 Comparison results for auxiliary storage pool ID (*ASP)................................... 294 Comparison results for user profile status (*USRPRFSTS) .............................. 297

How configured user profile status is determined........................................ 298 Comparison results for user profile password (*PRFPWDIND)......................... 300 302 Appendix B IBM Power Systems operations that affect MIMIX MIMIX procedures when performing an initial program load (IPL) .......................... 302 MIMIX procedures when performing an operating system upgrade........................ 303 Prerequisites for performing an OS upgrade on either system ......................... 304 MIMIX-specific steps for an OS upgrade on the backup system....................... 305 MIMIX-specific steps for an OS upgrade on the production system with switching 307 MIMIX-specific steps for an OS upgrade on the production system without switching............................................................................................................................ 308 MIMIX procedures when upgrading hardware without a disk image change .......... 310 Considerations for performing a hardware system upgrade without a disk image change..................................................................................................................... 310 MIMIX-specific steps for a hardware upgrade without a disk image change..... 311 Hardware upgrade without a disk image change - preliminary steps .......... 311 Hardware upgrade without a disk image change - subsequent steps ......... 312 MIMIX procedures when performing a hardware upgrade with a disk image change... 313 Considerations for performing a hardware system upgrade with a disk image change..................................................................................................................... 313 Handling MIMIX during a system restore ................................................................ 314 Prerequisites for performing a restore of MIMIX ............................................... 314 Index 316

Product conventions

Product conventions
The conventions described here apply to all MIMIX products unless otherwise noted.

Menus and commands

Functionality for all MIMIX products is 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.

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 Description 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 Examples 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

Convention Initial Capitalization Italic

UPPERCASE

System-defined mnemonic names for commands, parameters, and values.

monospace font

Text that you enter into a 5250 emulator command line. In instructions, the conventions of italic and UPPERCASE also apply. Examples showing programming code.

10

Sources for additional information

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 i and i5/OS Information Center. From the Information center you can access these IBM PowerTM Systems topics, books, and redbooks: Backup and Recovery Journal management DB2 Universal Database for IBM PowerTM Systems 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, SG24-6286 IBM redbook AS/400 Remote Journal Function for High Availability and Data Replication, SG24-5189 IBM redbook PowerTM Systems iASPs: A Guide to Moving Applications to Independent ASPs, SG24-6802

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, SG24-5189

11

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.

12

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 6 provides high availability for your critical data in a production environment on IBM PowerTM Systems 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 remote journaling function of the operating system 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, program objects, or spooled files), integrated file system (IFS) objects, and document library object (DLOs) using the 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

13

MIMIX overview

multiple production systems or backup systems. MIMIX can also be used on a single system. 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 15 summarizes key concepts that you need to know about MIMIX. MIMIX AutoGuard overview on page 18 describes concepts related to automatic detection and recovery of problems with MIMIX AutoGuard and provides an introduction to auditing. MIMIX policies on page 22 describes polices used by MIMIX and how to set them. Policies for recovery during replication on page 33 identifies the policies associated with automatic error detection and correction during replication and identifies the common object and file error situations that can be automatically recovered. Logging in to MIMIX Availability Manager on page 37 describes what to expect the first time you log in to MIMIX Availability Manager. Areas of the window in MIMIX Availability Manager on page 37 describes the layout of the MIMIX Availability Manager window, what each area is for, and useful tips for working with this user interface. Accessing the MIMIX Main Menu from a 5250 emulator on page 42 describes the MIMIX Basic Main menu and the MIMIX Intermediate Main Menu. The MIMIX Basic Main menu is used to access the MIMIX Availability Status (WRKMMXSTS) display.

14

MIMIX concepts

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 IBM PowerTM Systems 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. Additional concepts associated with MIMIX AutoGuard are described in Key concepts for MIMIX AutoGuard on page 18. 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.

15

System definitions identify a systems that participate in a MIMIX installation. Each system definition identifies one system. 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 IBM i 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 IBM i 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

16

MIMIX concepts

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. 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 IBM i 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 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 IBM i 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.

17

MIMIX AutoGuard overview

MIMIX AutoGuard significantly simplifies the amount of time and effort required to maintain your MIMIX environment for availability and switch-readiness. MIMIX AutoGuard does this by automatically checking for differences in the data and object attributes that you replicate between systems and correcting detected differences. The checks and corrections are performed during replication processes and during a series of scheduled audits. MIMIX is shipped with these capabilities of MIMIX AutoGuard enabled. During replication, MIMIX AutoGuard resolves any differences detected between your source and target systems to ensure up-to-the-minute accuracy. During a series of automatic, regularly scheduled audits, MIMIX AutoGuard checks for differences between the source and target systems and resolves any detected differences to ensure that you are switch-ready at all times. MIMIX AutoGuard helps you comply with best practices for maintaining availability and switch-readiness, and therefore is key to ensuring that your MIMIX environment is in tip-top shape for protecting your data. MIMIX AutoGuard incorporates best practices with user interfaces and underlying functionality so that you can fine-tune policies, see compliance information reflected in status, and access the reports and results of actions MIMIX AutoGuard takes to keep your environment synchronized.

Key concepts for MIMIX AutoGuard

All businesses run under a set of rules or guidelines. While some rules may be informally enforced, others are strictly enforced by a company's business processes or by the applications in use. In a MIMIX environment, maintaining availability and switch-readiness at all times also requires following a set of guidelines or rules. MIMIX provides the framework necessary to incorporate the business rules necessary to support your availability requirements. This framework provides the means by which to define, enforce, and report rules. The functions provided by MIMIX AutoGuard use this rule framework because it enables earlier and easier detection of problems known to adversely affect availability or your ability to switch in a MIMIX environment. The key concepts associated with MIMIX AutoGuard are identified below. 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 Auditing overview on page 19. 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.

18

MIMIX AutoGuard overview

Compliance - Compliance is an indication of whether best practices are being followed in the MIMIX environment. 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 switchreadiness. Policies - A policy is a mechanism used to enable, disable, or provide input to a function such as replication, MIMIX AutoGuard, or MIMIX Switch Assistant. For most policies, the initially shipped values apply to an installation. However, policies can be changed and can also be overridden for individual data groups. Some policies, such as audit schedule, apply only to individual data groups. 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. 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.

Auditing overview
Multiple audits exist for each data group. Each audit identifies a data group to be checked and the MIMIX rule used to check it. MIMIX rules are the mechanism by which audits are defined and invoked. Each shipped MIMIX rule pre-defines a compare command to be invoked and the possible actions that can be initiated, if needed, to correct detected problems. MIMIX ships with default scheduling information associated with each MIMIX rule. MIMIX uses this scheduling information to automatically schedule audit requests on a regular basis. Scheduling can be adjusted for individual audits through policies. When MIMIX submits an audit request, a job is run on both systems associated with the data group being checked. MIMIX first checks the Run rule on system policy to determine where the audit should run and immediately ends the request that is not on the appropriate system. 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. The audit level policy 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

19

capability.Through policies, you have control over the audit level used for rules that provide more than one level. If there are detected differences when the compare phase completes, the audit enters its recovery phase to start automatic recovery actions as needed. MIMIX attempts to correct the differences and sends generated reports, called recoveries, to the user interface. MIMIX removes these generated reports when the recovery action completes successfully. If the recovery job fails to correct the problem, MIMIX removes the recovery and sends an error notification to the user interface. Most MIMIX rules support a recovery phase. MIMIX is shipped with defaults that enable audits to enter the recovery phase automatically when needed.The recovery phase can be optionally disabled. The information available about each audit identifies the status of actions performed by its MIMIX rule, its compliance status, policy values which affect the actions of each phase, and scheduling information. When a phase completes, its timestamps and statistics are also available. When audit recoveries are enabled, you can specify the severity level of the notifications that are returned when the rule ends in error. This is controlled by the Notification severity policy. You can also view job logs associated with notifications and recoveries. Job logs are accessible from the system on which the audit comparison or recovery job ran.

What are MIMIX AutoGuard best practices?

A set of best practices are incorporated in MIMIX AutoGuard. These are: Allow MIMIX to automatically correct differences detected during database and object replication processes that would otherwise result in errors. If MIMIX is unable to perform the recovery, the problem is reported as a replication error (a file is placed in held error or an object is in error). Allow MIMIX to automatically schedule and perform all audits of data groups on a daily basis and automatically recover any differences detected by audits. An audit summary reports the audit results and indicates whether MIMIX is unable to recover an object. Perform switches on a regular basis. Best practice is to switch every three to six months. Because you need to control when planned switches occur, MIMIX is shipped to enable compliance indicators for switching with a default MIMIX Model Switch Framework. The MIMIX Model Switch Framework requires configuration with your Certified MIMIX Consultant.

How do I get started with MIMIX AutoGuard?

Getting started is easier than ever. Little or no customizing is needed. Customization through policies or audit scheduling is only required if you determine that best practices do not meet your auditing needs. MIMIX ships with policies and audit schedule settings defaulted to best practices. When you use the Start MIMIX command, MIMIX starts the master monitor, which in

20

MIMIX AutoGuard overview

turn starts a job that automatically schedules and submits audits a regular basis. The Start MIMIX command also starts replication processes, which invoke recovery processes as needed.

New MIMIX installations

When you create a new installation of MIMIX, best practices for auditing and replication recovery during replication processes are enabled and ready to start when you use the Start MIMIX (STRMMX) command. To use MIMIX Switch Assistant, you need to work with your Certified MIMIX Consultant to configure a default MIMIX Model Switch Framework.

21

MIMIX policies
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.

Considerations when choosing policy values

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 (bi-directional). Specifically, be aware of the following: In these environments, the value *DISABLED for the Objects only on target policy is recommended. When the policy is disabled, audits will detect that objects exist only on the target system but will not attempt to correct them. The commands used by an audit are aware of all objects on the target system, not just those which originate from the source system of the data group associated with the audit. In these environments, the values *DELETE and *SYNC must be used with care. When the policy value is Delete, audits will delete objects which may have originated from systems not associated with the data group being audited. When the policy value is Synchronize, audits will synchronize the objects to the source system of the data group being audited, which may not be the source system from which they originated. Synchronization of user profiles and authorization lists associated with an object will occur unless the user profiles and authorization lists are explicitly excluded from the data group configuration. In the environments mentioned, this may result in user profiles and authorization lists being synchronized to other systems in your configuration. This behavior occurs whenever any of the automatic recovery policies are enabled (database, object, audit). To prevent this from occurring, you must explicitly exclude the user profiles and authorization lists from replication for any data group for which you do not want them synchronized. In a simultaneously bi-directional environment, determine which system wins in the event of a data conflict, that is, which system will be considered as having the correct data. Choose one direction of replication that will be audited and allow auditing for those data groups. Disable audits for data groups that replicate in the

22

MIMIX policies

opposite direction. For example, data groups AB and BA are configured for bidirectional replication between system A and system B. Data group AB replicates from system A to system B and data group BA replicates the opposite direction. System B is also the management system for this installation. You chose system A as the winning system and want to permit auditing in the direction from A to B. The Audit level policy for data group AB must be set to a level that permits audits to run (level 10 or higher). The Audit level policy for data group BA must be set to disable audits. The results of audits of data group AB will be available on system B, because system B is the management system and default policy values cause rules to be run from the management system. In environments with three or more systems in the same installation, you need to evaluate each pair of systems. For each pair of systems, evaluate the directions in which replication is permitted. If any pair of systems supports simultaneous bidirectional replication, determine the winning system in each pair and determine the direction to be audited. Set the audit level policy to permit auditing for the data group that replicates in the chosen direction. Disable auditing for the data group which replicates in the other direction. You may also want to consider changing the values of the Run rule on system policy for the installation or the audited data groups to balance processing loads associated with auditing. In environments that permit multiple management systems in the same installation, in addition to evaluating the direction of replication permitted within each pair of systems, you must also consider whether the systems defined by each data group are both management systems. If any pair of systems supports simultaneous bi-directional replication, choose the winning system and change the Audit level policies for each data group so that only one direction is audited. You may need to change the Run rule on system policy to prevent certain data groups from being audited from specific management systems.

When not to use MIMIX AutoGuard

At times, you may need to disable automatic auditing for certain data groups because a feature in use or an application being replicated may interact with auditing in an undesirable way. Features - Do not use MIMIX AutoGuard with any data group that is using functions provided by the MIMIX CDP feature. This feature, which requires an additional access code, permits you to perform operations associated with maintaining continuous data protection. By configuring a recovery window for a data group, you introduce an automatic delay into when the apply processes complete replication. By setting a recovery point for a data group, you identify a point that, when reached, will cause the apply processes to be suspended. In both cases, source system changes have been transferred to the target system but have not been applied. In such an environment, MIMIX AutoGuard comparisons will report differences and attempt recovery for items that have not completed replication. To prevent this from occurring, disable comparisons and automatic recoveries for any data group which uses the MIMIX CDP feature. For details, see Disabling MIMIX AutoGuard for data groups using the MIMIX CDP feature on page 26.

23

Applications - At times, data groups for some applications will encounter problems if the application cannot acquire locks on objects that are defined to MIMIX. These data groups may need to be excluded from auditing. MIMIX acquires locks occasionally to save and restore objects within the replication environment. Some applications may fail when they cannot acquire a lock on an object. Refer to our Support Central for FAQs that list specific applications whose data groups should be excluded from auditing. For those excluded data groups, you can still run compares to determine if objects are not synchronized between source and target systems. Care must be taken to recover from these unsynchronized conditions.The applications may need to be ended prior to manually synchronizing the objects. To exclude a data group from audits, use the instructions in Disabling MIMIX AutoGuard for data groups using the MIMIX CDP feature on page 26.

Setting policies - general

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 you are viewing a management system from within MIMIX Availability Manager, several windows have actions available for changing policies. Actions to change policies are available from the windows resulting from your selection of any of the following from the Details area of the navigation bar: Data Groups, Services, Switching, Summary, or Compliance. If you select Policies, the MIMIX Policies window displays current settings and the Details action can be used to change policies. The following procedures describe the basic procedures for setting policies. For procedures specific to setting policies for auditing and switching environments, see Policies for auditing on page 109 and Setting policies for switching on page 208.

To change existing installation policies

Note: This procedure changes a policy value at the installation level. The installation level value can be overridden by a data group level policy value. Therefore, if a data group has value other than *INST for this policy, that value remains in effect. From MIMIX Availability Manager, the action to change installation policies is only available when the system you are viewing is the management system 1. Select the Change Installation Policies action and click .

2. You will see Installation Policy near the top of the window. The current values of policies are displayed. Specify a value for the policy you want to change. 3. To accept the changes, click OK. From a 5250 emulator, do the following from the management system: 1. From the command line type SETMMXPCY and press F4 (Prompt). 2. Verify that the value specified for Data group definition is *INST.

24

MIMIX policies

3. Press Enter to see all the policies and their current values. 4. Specify a value for the policy you want. Use F1 (Help) to view descriptions of possible values. 5. To accept the changes, press Enter.

To change policies for a data group

From MIMIX Availability Manager, the action to change policies for a data group is only available when the system you are viewing is the management system 1. For the data group you want, select the Change Policies action and click .

2. The selected data group is listed near the top of the window and current values of its policies are displayed. Select a value for the policy you want to change. 3. To accept the changes, click OK. From a 5250 emulator, do the following from the management system: 1. From the command line type SETMMXPCY and press F4 (Prompt). 2. For the Data group definition, specify the full three-part name. 3. Press Enter to see all the policies and their current values. 4. Specify a value for the policy you want defined for the data group. Use F1 (Help) to view descriptions of possible values. 5. To accept the changes, press Enter.

To reset a data group-level policy to use the installation level value

From MIMIX Availability Manager, the action to change policies for a data group is only available when the system you are viewing is the management system 1. For the data group you want, select the Change Policies action and click .

2. The selected data group is listed near the top of the window and current values of its policies are displayed. For the policy you want to change, select Use installation default. 3. To accept the changes, click OK. From a 5250 emulator, do the following from the management system: 1. From the command line type SETMMXPCY and press F4 (Prompt). 2. For the Data group definition, specify the full three-part name. 3. Press Enter to see all the policies and their current values. 4. For the policy you want to reset, specify *INST. 5. To accept the changes, press Enter.

25

Disabling MIMIX AutoGuard for data groups using the MIMIX CDP feature
The functions provided by the MIMIX CDP feature1 create an environment in which source system changes have been transferred to the target system but have not been applied. Any data group which uses this feature must disable automatic comparisons and automatic recovery actions for the data group From MIMIX Availability Manager, the action to change policies for a data group is only available when the system you are viewing is the management system. Do the following: 1. Ensure that you have the management system selected in the navigation bar. If you are not certain which system is the management system, you can select Services to check. 2. Select Data Groups from the navigation bar. From the list of data groups, select the data group that uses the MIMIX CDP feature. 3. From within the Summary area, select the Change Policies action and click .

4. Verify that the expected data group is listed near the top of the window. If you see Installation Policy, close the window and start again. 5. For Automatic system journal recovery, select Disable. 6. For Automatic user journal recovery, select Disable. 7. For Automatic audit recovery, select Disable. 8. For Audit level, select Disable. 9. To accept the changes, click OK. From a 5250 emulator, do the following from the management system: 1. From the command line type SETMMXPCY and press F4 (Prompt). 2. For the Data group definition, specify the full three-part name of the data group that uses the MIMIX CDP feature. 3. Press Enter to see all the policies and their current values. 4. For Automatic object recovery, specify *DISABLED. 5. For Automatic database recovery, specify *DISABLED. 6. For Automatic audit recovery, specify *DISABLED. 7. For Audit level, select *DISABLED. 8. To accept the changes, press Enter.

1. The MIMIX CDP feature requires an additional access code.

26

Policy descriptions
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. Data group definition - Select the scope of the policies to be set. When the value *INST is specified, the policies being set by the command apply to all systems and data groups in the installation, with the exception of any policy for which a data grouplevel override exists. When a three-part qualified name of a data group is specified, the policies being set by the command apply to only that data group and override the installation-level policy values. Audit rule - Select the MIMIX rule for which an audit schedule will be set for the specified data group definition. The Audit schedule policy determines when this rule will audit the data group. The audit rule must specify the value *NONE when changing any policy except the audit schedule. 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 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

27

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 22 for additional information. 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 commands parameter determines what to do if the 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 policys 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 10080 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.

28

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. 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

29

is synchronized between source and target systems. For additional information, see Changing the audit level policy for switching on page 210. Run rule on system - Select the system on which to run audits. 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 policys 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 condition1. 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. Apply in threshold - Specify the type of auditing actions allowed when any of the database apply or object apply processes used by the data group have reached their configured warning threshold. Synchronize threshold size - Select a value or specify the threshold, in megabytes (MB), to use for preventing the synchronization of large objects during recovery actions. When any of the Automatic system journal recovery, Automatic user journal recovery, or Automatic audit recovery policies are enabled, all initiated recovery actions use this policy value for the corresponding synchronize command's Maximum sending size (MB) parameter. This policy is useful for preventing performance issues when synchronizing large objects. Number of third delay retry attempts - Select a value or specify the number of times to retry a process during the third delay/retry interval. This policy is used when the Automatic system journal recovery policy is enabled. Object replication processes use this policy value when attempting recovery of an in-use condition that persists after the data groups configured values for the first and second delay/retry intervals are exhausted. The shipped default is 100 attempts. This policy and its related policy, Third delay retry interval, can be disabled so that object replication does not attempt the third delay/retry interval but still allow recoveries for other errors. Third delay retry interval - Select a value or specify the delay time (in minutes) before retrying a process in the third delay/retry interval. This policy is used when the
1. Users will see this policy only on systems running version 5 service pack 5.0.06.00 or higher.

30

Automatic system journal recovery policy is enabled. Object replication processes use this policy value when attempting recovery of an in-use condition that persists after the data groups configured values for the first and second delay/retry intervals are exhausted. The shipped default is 15 minutes. Switch warning threshold - Select a value or specify how many days can elapse after the last switch was performed before an indicator is set for the installation. When the number of days that have elapsed exceeds this threshold, the indicator is set to inform you that switching may need your attention. In MIMIX Availability Manager, an icon appears next to Switching in the Details area of the navigation bar and next to the Last switch date field on the MIMIX Switch Assistant window. In the 5250 emulator, the indicator appears as the Last switch field on the WRKMMXSTS window. The shipped default is 90 days, which is considered at the limit of best practices for switching. Switch action threshold - Select a value or specify how many days can elapse after the last switch was performed before an indicator is set for the installation. When the number of days that have elapsed exceeds this threshold, the indicator is set to inform you that action is required. In MIMIX Availability Manager, an icon appears next to Switching in the Details area of the navigation bar and next to the Last switch date field on the MIMIX Switch Assistant window. In the 5250 emulator, the indicator appears as the Last switch field on the WRKMMXSTS window. The shipped default of 180 days is the suggested value for this threshold, which beyond the limit of best practices for switching. Default model switch framework - Select a value or specify the default MIMIX Model Switch Framework to use for switching. This value is used by MIMIX Switch Assistant from within MIMIX Availability Manager or from the MIMIX ha Lite Main Menu (option 5). The shipped default value is MXMSFDFT, which is the default model switch framework name for the installation. If the default name is not being used, this value should be changed to the name of the MIMIX Model Switch Framework used to switch the installation. Independent ASP library ratio - Select a value or specify a number for n in a ratio (n:1) of independent ASP libraries (n) on the production system to SYSBAS libraries on the backup system1. For each switchable independent ASP defined to MIMIX by a device resource group, a monitor with the same name as the resource group checks this ratio. When the number of independent ASP libraries falls to a level that is below the specified ratio, the monitor sends a notification to inform you that action may be required. This signals that your recovery time objective could be in jeopardy because of a prolonged independent ASP switch time. CMPRCDCNT commit threshold - Select a value or specify a number that identifies the threshold at which a request to compare record counts (CMPRCDCNT command or #MBRRCDCNT audit) will not perform the comparison due to commit cycle activity on the source system2. The value specified is the maximum number of uncommitted record operations that can exist for files waiting to be applied at the time the compare request is invoked. Each database apply session is evaluated against the threshold
1. The library ratio monitor and the policy it uses require an access code for the MIMIX Cluster product. 2. Users will see this policy only on systems running version 5 service pack 5.0.14.00 or higher.

31

independently. As a result, it is possible that record counts will be compared for files in one apply session but will not be compared for files in another apply session. For additional information see the MIMIX Reference book. Audit schedule - Select the scheduling information that MIMIX uses to automatically submit audit requests for the specified data group and rule. In order to be scheduled, a value other than *NONE must be specified for Frequency, and values must be specified for Scheduled time and either Scheduled date or Scheduled day. Scheduled dates are entered and displayed in job date format. When the job date format is Julian, the equivalent month and day are used to determine when to schedule audit requests. For detailed information about this policy, see Working with audit schedules on page 102.

32

Policies for recovery during replication

Policies for recovery during replication

MIMIX AutoGuard can automatically attempt to correct problems it encounters during replication. Table 2 shows these policies and their shipped default values.
Table 2. Policy Policies associated with automatic recovery during replication, with shipped default values Shipped Values Installation Data group definition Automatic system journal recovery Automatic user journal recovery System journal recovery notify on success User journal recovery notify on success Synchronize threshold size Number of third delay retry attempts Third delay retry interval
1. 2.

MIMIX AutoGuard Object Replication Yes Yes2 Yes Yes Yes Yes Database Replication Yes Yes2 Yes Yes

Data Groups Name1 *INST1 *INST *INST *INST *INST *INST *INST

*INST *ENABLED *ENABLED *YES *YES 9,999,999 100 15

A data group definition value of *INST indicates the policy is installation-wide. A name indicates the policies are in effect only for the specified data group. When this policy is enabled, the other policies in the same column are in effect unless otherwise noted.

When automatic recovery policies are enabled, MIMIX will attempt to recover errors it detects during the replication process. The following topics identify what errors can be recovered in this way: Errors handled by automatic database recovery on page 33 Errors handled by automatic object recovery on page 34

Errors handled by automatic database recovery

MIMIX AutoGuard can detect and correct the most common file error situations that occur during database replication. When the Automatic database recovery policy is enabled, database replication processes detect the types of errors listed in Table 3. When an error is detected, MIMIX automatically attempts to correct the error by starting a job to perform an appropriate recovery action.

33

The recovery action also sends a report of a recovery in progress to the user interface. In MIMIX Availability Manager, these reports are located on the Recoveries page. In a 5250 emulator, the reports are on the Work with Recoveries display (WRKRCY command). When the recovery action completes, the report is removed. The DB rcy. notify on success policy determines whether a successful recovery generates an informational notification. Only when all recovery options are exhausted without success is a file placed in hold error (*HLDERR) status. Recovery actions that end in an error do not generate a separate error notification because the error is already reflected in MIMIX status.
Table 3. Error File level errors - and Unique-key record level error Record level errors Errors detected and corrected during database replication when automatic database recovery is enabled. Description Typically invoked when there is a missing library, file, or member. Also invoked when an attempt to write a record to a file results in a unique key violation. Without database autonomics, these conditions result in the file being placed in *HLDERR status. Invoked when the database apply process detects a data-level issue while processing record-level transactions. Without database autonomics, any configured collision resolution methods may attempt to correct the error. Otherwise, these conditions result in the file being placed in *HLDERR status. Invoked during the priming of IFS tracking entries when replicated IFS objects are determined to be missing from the target system. Priming of tracking entries occurs when a data group is started after a configuration change or when the request to start a data group specifies to clear pending entries. Invoked during the priming of object tracking entries when replicated data area and data queue objects are determined to be missing from the target system. Priming of tracking entries occurs when a data group is started after a configuration change or when the request to start a data group specifies to clear pending entries. Invoked when a temporary lock condition or an operating system condition exists that prevents the database apply process (DBAPY) from opening the file or applying transactions to the file. Without database autonomics, users typically have to release the file so the database apply process (DBAPY) can continue without error.

Errors on IFS objects configured for advanced journaling Errors on data area and data queue objects configured for advanced journaling Errors when DBAPY cannot open the file or apply transactions to the file

Errors handled by automatic object recovery

MIMIX AutoGuard can detect and correct the most common object error situations that occur during replication. When the Automatic object recovery policy is enabled, object replication processes detect the types of errors listed in Table 4. When an error is detected, MIMIX automatically attempts to correct the error by starting a job to perform an appropriate recovery action.

34

Policies for recovery during replication

Unless the object is explicitly excluded from replication for a data group, the autonomic recovery action will synchronize the object to ensure that it is on the target system. Note: Object autonomics does not detect or correct the following problems: Missing spooled files on the target system. Files and objects that are cooperatively processed. Although the files and objects are not addressed, problems with authorities for cooperatively processed files and objects are addressed. Activity entries that are stuck in a perpetual pending status (PR, PS, PA, or PB). The recovery action also sends a report of a recovery in progress to the user interface. In MIMIX Availability Manager, these reports are located on the Recoveries page. In a 5250 emulator, the reports are on the Work with Recoveries display (WRKRCY command). When the recovery action completes, the report is removed. The Obj. rcy. notify on success policy determines whether a successful recovery generates an informational notification. Only when all recovery options are exhausted without success is an activity entry placed in error status. Recovery actions that end in an error do not generate a separate error notification because the error is already reflected in MIMIX status.
Table 4. Error Missing objects on target system1 Errors detected and recoveries attempted by object autonomics during object replication Description An object (library-based, IFS, or DLO) exists on the source system and is within the name space for replication, but MIMIX detects that the object does not exist on the target system. Without object autonomics, this results in a failed activity entry. Notes: Missing spooled files are not addressed. Missing objects that are configured for cooperative processing are not synchronized. However, any problems with authorities (*AUTL or *USRPRF) for the missing objects are addressed. Any operation against an object whose parent object is missing on the target system. Without object autonomics, this condition results in a failed activity entry due to the missing parent object. Any operation that requires a user profile object (*USRPRF) that does not exist on the target system. Without object autonomics, this results in authority or object owner issues that cause replication errors. Any operation that requires a authority list (*AUTL) that does not exist on the target system.Without object autonomics, this results in authority issues that cause replication errors.

Missing parent objects on target system1 Missing *USRPRF objects on target system1 Missing *AUTL objects on target system1

35

Table 4. Error In-use condition

Errors detected and recoveries attempted by object autonomics during object replication Description Applications which hold persistent locks on objects can result in object replication errors if the configured values for delay/retry intervals are exceeded. Default values in the data group definition provide approximately 15 minutes during which MIMIX attempts to access the object for replication. If the object cannot be accessed during this time, the result is activity entries with errors of Failed Retrieve (for locked objects on the source system) and Failed Apply (for locked objects on the target system) and a reason code of *INUSE. Notes: 1. The Number of third delay/retries policy and the Third retry interval policy determine whether automatic recovery is attempted for this error. 2. Automatic recovery for this error is not attempted when the objects are configured for cooperative processing.

1.

The synchronize command used to automatically recover this problem during replication will correct this error any time the command is used.

36

Logging in to MIMIX Availability Manager

Logging in to MIMIX Availability Manager

The first time you log in to MIMIX Availability Manager, you could see one of several windows. If you are logged in to the available systems and there are problems, you will see the system and installation with the highest severity problem. If there are no problems on any of the systems in view, you will see the Enterprise view. If you did not log in to any systems when you logged in to the server, you will see the Login window for the first system. Log in to the system so you can continue. You may be prompted to select an installation.

For many windows, you can adjust the amount of information displayed by changing preferences. You can change preferences at any time. Many tasks can be performed in the main window. Some tasks launch a new window while leaving the main window active. You can easily close the new window by using the Close button.

Your location is remembered

Once you visit a location, MIMIX Availability Manager remembers that you were there. For example, say you viewed notifications for installation ABC, then viewed data group status for installation XYZ. The next time you return to installation ABC, MIMIX Availability Manager will display the notifications. When you select a system in the Enterprise view, your location is reset. You will be taken to the most severe problem. If there are no problems, you will be taken to the first data group on the Data Group Status page. If you are not logged in to the system, you will be taken to the Login window for that system.

Areas of the window in MIMIX Availability Manager

MIMIX Availability Manager uses a similar layout for every window, shown in Figure 1. The primary elements of every window are: Title bar - The title bar includes buttons for accessing online help. It also includes navigational buttons, as needed, to close a secondary window or return to the previously viewed window. Navigation bar - The vertical navigation bar is both a navigational tool and a highlevel status indicator. Labeled areas within the navigation bar enable access to specific areas such as systems, installations, and details. The selections available may be relative to other selections in the navigation bar. For example, the installations available to select are dependent on the system selected. When used in order from top to bottom, labeled areas help you to narrow a selection until the desired information appears in the content area. Status icons quickly identify areas with potential problems. See Status icons - overview on page 40.

37

Note: Some windows may not have the bar or selected areas of the navigation bar. Content area - The content area changes based on your selections in the navigation bar. Typically, your location is identified in the summary at the top and corresponds to selected items in the navigation bar. Many windows display information in list form below the Toolbar. The Toolbar, when available, provides access to functions that are relevant to the displayed information.
Figure 1. Basic window layout

The content area of the Data Group Status window has a unique layout, shown in Figure 2. For this window, a portion of the content area is used as a selection list. The

38

Areas of the window in MIMIX Availability Manager

data group selected is highlighted in gray and its summary status is displayed to its right in the gray-highlighted area.
Figure 2. Unique content area layout for the Data Group Status window.

Additional navigation and selection aids

Navigation within the MIMIX Availability Manager is simple and predictable. Elements such as the navigation bar, buttons, filters, and drop-down lists, function consistently throughout the interface with few exceptions. Flyover help - Flyover help provides the first level of information about a problem or item and often identifies a predetermined action. This type of help is available for most status icons, buttons, and actions. To see flyover help, hover over the interface element with your mouse pointer. In many cases, clicking on the element will take an action that is indicated by its flyover help. For example, flyover help for a problem action button indicates what action is available; clicking on the button takes you to a command that will resolve the problem or takes you directly to the correct window where you can see the error and take steps to resolve the problem. Status icons - Icons always represent status. Each icon has a unique shape and color combination. Many status icons are also links which provide a shortcut to a predetermined action or additional information. Flyover help identifies both the status

39

and the action that will occur when clicked. The following provides an overview of common status icons: Status icons - overview
Status Action required Unknown Partially Active Ended Switching Description An error occurred. Immediate user action is required. Some or all status information is unavailable. Immediate user action is required. Processes are changing state or some processes are active while others are ended. User action may be required. All processes have ended normally due to a user request. User action is necessary to restart the processes. One or more data groups is in the process of switching which system is used as the source for replication. User action may be necessary. A warning condition exists that is either automatically correctable or is a non-critical condition. User action may be necessary. The status is unknown because collector services is not active. User action is necessary to start collector services. Processes are active. The process has been disabled.

Attention Unknown (No icon) Active Disabled

Underlined text - Text that is underlined when you hover over it can be used to navigate to a predetermined area. Flyover help indicates the action. Clicking on underlined text can take a predefined action, display additional selection criteria, such as another navigation area, or change the content in the content area. Selecting listed items with checkboxes - Several windows contain lists from which you can select multiple items to act upon with actions available in the toolbar. Checkboxes next to each item allow selection. A checkbox at the top of a list next to a heading allows selection or deselection of all items in the list at once. Once items are selected, you can use any of the Selected buttons from the toolbar. Selecting actions from drop-down lists - Drop-down lists provide available actions for an item. The location of the drop-down list determines the scope of its available actions. In summary area - When a drop-down list appears in the summary area at the top of a window, its actions apply to all the items on the window. With some notable exceptions, such as starting all or ending all data groups, the actions can affect data groups that may not be visible from MIMIX Availability Manager. Online help notes these exceptions. Next to an item - When a drop-down list appears next to an item, its actions apply to only that item. These drop-down lists cannot be used in conjunction with checkboxes. In some cases, the recommended best action is the default action for the item and can vary from item to item in the list. In a toolbar - Drop-down lists available in toolbars are for filtering. The available

40

Areas of the window in MIMIX Availability Manager

actions can be used to filter the content displayed. Ellipses - Actions that will prompt a command in another window or confirmation box before occurring are always followed by an ellipsis (...). Filtering - Filter buttons on the toolbar and not associated with a drop-down list offer a larger set of filtering criteria. Clicking the Filter button displays a Filter window, from which you can specify filter criteria for items within the current window.

Other useful tips

Actions that can cause changes to your MIMIX environment always have confirmations. Other actions such as displaying more information do not have confirmations. Buttons can appear in the toolbar or within areas of a window. They may include a graphic, text, or both. Buttons are always gray. When selecting an action that prompts a command, MIMIX Availability Manager preselects values on the command based on the item you selected. For example, selecting the action to start system managers from the Services window will prompt the Start MIMIX Managers command and will preselect system managers (*SYSMGR) in the appropriate field.

41

Accessing the MIMIX Main Menu from a 5250 emulator

The MIMIX command accesses the main menu for a MIMIX installation. The MIMIX Main Menu has two assistance levels, basic and intermediate. The command defaults to the basic assistance level, shown in Figure 3, with its options designed to simplify day-to-day interaction with MIMIX. Figure 4 shows the intermediate assistance level. The options on the menu vary with the assistance level. In either assistance level, the available options also depend on the MIMIX products installed in the installation library and their licensing. The products installed and the licensing also affect subsequent menus and displays. Accessing the menu - If you know the name of the MIMIX installation you want, you can use the name to library-qualify the command, as follows: Type the command library-name/MIMIX and press Enter. The default name of the installation library is MIMIX. If you do not know the name of the library, do the following: 1. Type the command LAKEVIEW/WRKPRD and press Enter. 2. Type a 9 (Display product menu) next to the product in the library you want on the Lakeview Technology Installed Products display and press Enter. Changing the assistance level - The F21 key (Assistance level) on the main menu toggles between basic and intermediate levels of the menu. You can also specify the the Assistance Level (ASTLVL) parameter on the MIMIX command. Note: Procedures are written assuming you are using the MIMIX Availability Status (WRKMMXSTS) display, which can only be selected from the MIMIX Basic

42

Accessing the MIMIX Main Menu from a 5250 emulator

Main Menu. We recommend you use the MIMIX Basic Main Menu unless you must access the MIMIX Intermediate Main Menu.
Figure 3. MIMIX Basic Main Menu
MIMIX Basic Main Menu System: MIMIX Select one of the following: 1. Availability status 2. Start MIMIX 3. End MIMIX 5. Start or complete switch 11. Configuration menu 12. Work with monitors 13. Work with messages 31. Product management menu WRKMMXSTS SYSTEM1

WRKMON WRKMSGLOG LAKEVIEW/PRDMGT

Selection or command ===>__________________________________________________________________________ ______________________________________________________________________________ F3=Exit F4=Prompt F9=Retrieve F21=Assistance level F12=Cancel (C) Copyright Vision Solutions, Inc., 1990, 2008.

Figure 4.

MIMIX Intermediate Main Menu

MIMIX Intermediate Main Menu System: SYSTEM1

MIMIX Select one of the following: 1. 2. 3. 4. Work Work Work Work with with with with data groups systems messages monitors WRKDG WRKSYS WRKMSGLOG WRKMON

11. Configuration menu 12. Compare, verify, and synchronize menu 13. Utilities menu 31. Product management menu LAKEVIEW/PRDMGT

Selection or command ===>__________________________________________________________________________ ______________________________________________________________________________ F3=Exit F4=Prompt F9=Retrieve F21=Assistance level F12=Cancel (C) Copyright Vision Solutions, Inc., 1990, 2008.

43

Working with status

CHAPTER 2

Working with status

This chapter describes common MIMIX operations that help keep your MIMIX environment running. In order for MIMIX to provide a hot backup of your critical information, all processes associated with replication must be active at all times. Supporting service jobs must also be active. MIMIX allows you to display and monitor the statuses of these processes. While you can perform common operations, such as monitoring status, from either MIMIX Availability Manager or a 5250 emulator, MIMIX Availability Manager is preferred. MIMIX Availability Manager provides significant benefits over a 5250 emulator, including: Enterprise view of all installations and systems using MIMIX Ability to take you directly to the highest severity problem per installation Suggested resolution for each unique problem

The topics included in this chapter are: Becoming acquainted with status on page 45 describes how status bubbles up within MIMIX Availability Manager to include the highest severity errors. Monitoring status with MIMIX Availability Manager on page 48 describes how to check status of replication processes and supporting services from MIMIX Availability Manager. Monitoring status with MIMIX Availability Status on page 50 describes how to check status of replication processes and supporting services from a 5250 emulator. The Work with Data Groups display - 5250 emulator on page 54 describes the errors reported on this 5250 emulator display and provides procedures for resolving them. Working with the detailed status of data groups on page 61 describes how to access detailed status for a data group from either user interface. Identifying replication processes with backlogs on page 76 describes what fields to check in each user interface for detailed status of a data group.

44

Becoming acquainted with status

Becoming acquainted with status

You can view status from either MIMIX Availability Manager or a 5250 emulator. MIMIX uses the priority assigned to status values to ensure that Items with the highest priority, those for detected problems or situations that require attention, are reflected on the highest level of each user interface. Additional detail and lower priority items can be viewed by drilling down to the next level within the interfaces. In MIMIX Availability Manager, the highest level is the Enterprise View window. In a 5250 emulator, the highest level is the MIMIX Availability Status display.

Status in MIMIX Availability Manager

MIMIX Availability Manager is designed so that problems or actions that require attention are easily detected. From any window in the interface, you can quickly see if problems exist. Status values are prioritized and those requiring immediate attention or intervention have icons to draw your attention. Additionally, these statuses are bubbled up to the next higher windowall the way up to the Enterprise View. Where appropriate, items are sorted to ensure that the highest severity item is at the top of the list.

The Enterprise View - your status shortcut

The Enterprise view, Figure 5, provides at-a-glance recognition of where problems exist and their severity. Systems are listed based on their status from left to right, with the most severe problems listed first.
Figure 5. Enterprise View showing a problem.

45

Status on the navigation bar

The navigation bar provides a quick high level indication of where problems exist and their severity. Default settings list systems and installations in an order based on their status, with the most severe problems listed first. Regardless of which detail you are currently viewing, the navigation bar always reflects current status for all of the systems and installations visible in your session. Figure 6 shows how a problem in data groups and auditing are also reflected at the installation and system level. Without viewing a different detail window, you can see that there is a problem with a data group in installation DEMO1 on system AS01 and that there are audits approaching out of compliance and either running or waiting to run.
Figure 6. Problem areas are represented by icons in the navigation bar.

Figure 7 shows how the severity of the problem is reflected in the content area as well as the navigation bar. The data group with the problem is identified in the list. Also, the Summary area identifies the cause of the problem and an appropriate action for

46

Becoming acquainted with status

resolving it. Displaying details from the Summary area provides access to additional information about replication activity and problems.
Figure 7. A problem reflected on the Data Group Status window.

47

Monitoring status with MIMIX Availability Manager

MIMIX Availability Manager provides specialized windows through which you can quickly and easily view status of data group replication and replication processes, audits, and supporting services. These windows provide easy access to detailed status as well as options for resolving indicated problems.

Checking replication status with MIMIX Availability Manager

The Data Group Status window provides summary information for data groups, provides access to detailed status, displays actions for starting, ending, and switching data groups, and displays actions for resolving problems. If problems with replication exist, an Action required icon appears next to the Data Groups item in the Details area of the navigation bar. Only the data groups that you have selected through Preferences are displayed. To view the details of the replication status, do the following: 1. Select Data Groups from the Details area of the navigation bar. All data groups with problems are listed first, in order of severity. 2. Select a data group to view the summary information for the data group. You will see the following three sections: Summary - Provides information on audit compliance, the date and time of the last switch, and whether remote journaling is configured for this data group. Journal - Provides a Replication Process status overview for the User and System journals. The Replication Process summarizes the Send and Apply statuses of processes used during replication. Icons in this section can be clicked to view the message log for the user or system journal. Problem - Problem icons must be addressed before the data group can replicate successfully. Each problem has a recommended action listed. Flyover help on the Action button describes the action. Click to prompt the recommended action. Note: If you have problems, the data groups are listed in the order of severity. For more information, see Displaying data group detailed status with MIMIX Availability Manager on page 61.

Checking audit status with MIMIX Availability Manager

The Audit Summary window summarizes the status of all audit activity, problems with audit results, and recoveries. To view the audit status, do the following: 1. Select Summary from the Details area of the navigation bar. The Audit Summary window appears and provides a summary of audit status and also lists audits for the data groups selected for viewing in an installation. All audit rules with problems are listed first, in order of severity. 2. Do the following:

48

Monitoring status with MIMIX Availability Manager

a. Use the flyover to determine the recommended action for the selected audit rule. b. From the Actions drop-down menu, select the appropriate action and click Note: You can also click the audit rule to see a detailed description of the audit status. The Rule status field in the Rule Details area contains the message and appropriate action for the specified audit rule. Select the appropriate action and click . For more information, see Working with audits on page 87. .

Checking status of supporting services with MIMIX Availability Manager

The Services window summarizes the status and also reflects potential problems with system managers, journal managers, collector services, and all enabled monitors for the installation. To view the services, do the following: 1. Select Services from the Details area of the navigation bar. The Installation Services window appears and provides the status of the MIMIX services for the selected system and installation. From this window, you can also start or end MIMIX and resolve problems associated with various MIMIX services. 2. Do the following: a. Use the flyover to see information and recommended actions for the System Manager, Journal Manager, Monitor Processes, and Collector Services statuses. Note: Clicking any icon to see the message log for that process. b. For systems with an Action required icon, select the appropriate action from the Actions drop-down and click . If the text in the summary display indicates a problem with a monitor, do the following: 1. Determine the system and installation on which you have monitors with problems. If you are not on that system, select the system from the Systems area of the navigation bar and the installation with which you were working. If the system that has monitor problems is not included in your list of Systems, you will need to add it through Preferences before you can see the monitor details. 2. Select Monitors from the Details area of the navigation bar. After Master Monitor, all monitors with problems are listed first, in order of severity. Each problem has a recommended action listed. 3. Do the following: a. Use the flyover help on the Action button to describe the recommended action. b. Select the appropriate action from the Actions drop-down and click .

49

Monitoring status with MIMIX Availability Status

The MIMIX Availability Status display, shown in Figure 8, provides one location for quickly assessing the overall state of an entire MIMIX installation, reflecting both source and target systems. In addition to determining status, unique features of this display enable its use as the starting point for performing routine actions and resolving problems. To access this display, do one of the following: Select option 1 on the MIMIX Basic Main Menu Enter the command WRKMMXSTS and press Enter.

Figure 8 shows the MIMIX Availability Status display.

Figure 8. MIMIX Availability Status window. This example shows that MIMIX is active but the installation is not complying with best practices for switching (red) and audits (yellow).

Additional fields - In the upper right corner of the display, additional fields report information that is relevant to maintaining the installation. Recoveries - Identifies the total number of recoveries in progress for the installation. Active recoveries represent problems detected and being corrected by MIMIX AutoGuard. Before certain activity, such as ending MIMIX, it is important that there are no recoveries in progress in the installation. If more than 9999 recoveries exist, the field displays ++++. Last switch - This field is only displayed when there is a value specified for the Default model switch framework policy. The date indicates when the last completed switch was performed using the switch framework specified in the policy. If you have not yet performed a switch using the switch framework defined in policies, this date is when the MIMIX environment was first started or when the

50

Monitoring status with MIMIX Availability Status

system managers were started and explicitly reset the configuration. Activity/Status - The main area of the display provides a reporting area for status of activity in key areas. Replication, Audits and notifications, and Services. For each activity area, status represents a summation of multiple processes. The text shown within each activity area changes to identify the most severe problem within its processes. Text, as well as background color, also identify the summarized status and indicate what action is appropriate. Blue indicates there are no problems with the activity and that no action is required. Yellow indicates warnings that may need your attention. Red indicates errors or inactive processes that require immediate action. Options - On this display, the activity you select with an option and the status of the activity determines what you see as the result of using the option. This behavior is unlike that of options on other MIMIX displays. The following subtopics describe the results of using the available options. Option 5 (Display details) from the MIMIX Availability Status display results in a display showing detailed status for the selected activity. Take option 5 next to the item to access detailed information for the activity. For Replication, the result is the Work with Data Groups display. For Audits and notifications, the result is the Summary view of the Work with Audits display. (To see details for notifications, press F20 (Command line), then enter the command WRKNFY.) For Services, the result is the Work with Systems display for status of the MIMIX managers. (To see details for monitors, press F4 (MIMIX Menu), then use option 12 (Work with monitors).)

Option 9 (Troubleshoot) from the MIMIX Availability Status display results in the appropriate display to use as a starting point for troubleshooting the stated problem for the selected activity. The stated problem reflects the highest severity problem present. Other less severe problems may exist, they may be reflected on the subsequent display but will not be reflected on the MIMIX Availability Status display until higher severity problems are resolved.Take option 9 next to the item to access detailed information for the activity. For Replication, the result is the Work with Data Groups display. For Audits and notifications, the result is dependent on the severity of the stated problem. All auditing conditions are prioritized before any notifications. For audits with status conditions, the result is the Summary view of the Work with Audits display. For audits with compliance conditions, the result is the Compliance view of the Work with Audits display. For notifications with errors, the result is the Work with Notifications display. For Services, the result is dependent on the severity of the stated problem. All system manager and journal manager errors are prioritized before any monitor errors. For system manager and journal manager errors, the result is the Work

51

with Systems display. For monitor errors, the result is the Work with Monitors display.

Checking replication status - 5250 emulator

The first activity listed on the MIMIX Availability Status display is Replication. The replication area summarizes status of replication activity for all data groups in the installation. This includes processes required for replication and also reflects potential problems. Status values are shown by color while message text within the highlighted area indicates the nature of any problem. Blue - There are no problems with replication processes and no action is required. Yellow - Warnings exist that may need your attention. Possible causes include: A file is being synchronized by MIMIX AutoGuard. This condition usually resolves itself. A process has a backlog which has reached its threshold. An object on the target system is not journaled as expected. Journal state or cache are not as expected.

Red - Conditions exist that require immediate action or a switch is in progress. Possible scenarios that require immediate action include: Error conditions Processes required for replication are not active Some objects are not journaled and therefore cannot be replicated Journal state or cache is not as expected.

Status may change due to warnings or problems with any of the replication processes, with replication errors associated with data group entries (file, object, IFS tracking, and object tracking), or with a change in switch status. To begin resolving problems, use option 9 (Troubleshoot) to access the Work with Data Groups display, from which you can view detailed information and take action. See The Work with Data Groups display - 5250 emulator on page 54 for more information. Note: Replication status can indicate action required (red) while a switch is in progress. When you are ready to switch from the backup system to the production system, press F4 (MIMIX Menu). From there, use option 5 to continue switching.

Checking audit and notification status - 5250 emulator

The middle activity listed the MIMIX Availability Status display is Audits and notifications. This activity area summarizes status of all audit activity, problems with audit results, audit compliance, and new notifications.

52

Monitoring status with MIMIX Availability Status

Status values are shown by color while message text within the highlighted area indicates the nature of any problem. Blue - No action is required. No audits are active, have differences, or are out of compliance, and there are no new error or warning notifications. Yellow - An audit or notification may need your attention. An out-of-compliance audit is running its compare phase, an audit is approaching an out-of-compliance state, or a new warning notification exists. Red - A condition exists that requires immediate action. An audit has failed, had unresolved differences, is out-of-compliance, was prevented from running because of policy values, or a new error notification exists. Status may change due to the highest severity condition with audits, audit results, audit compliance, or new notifications. To begin resolving problems, use option 9 (Troubleshoot) to access the appropriate display for the indicated problem. For audit status problems, see Resolving audit problems - 5250 emulator on page 95. To resolve audit compliance problems, the audits must be run. See Running audits immediately on page 91 and Working with audit compliance on page 98. For additional information about notifications see Displaying notifications on page 120.

Checking for status of supporting services - 5250 emulator

The last activity listed on the MIMIX Availability Status display is Services. This area summarizes status and also reflects potential problems with system managers, journal managers, collector services, and all enabled monitors for the installation. Status values are shown by color while message text within the highlighted area indicates the nature of any problem. Blue - There are no problems for the managers, collector services, and monitors. No action is required. Red - A system manager, journal manager, collector services, or a monitor is in a state that requires immediate action. The status text indicates which problem occurred and where you can see detailed information. To begin resolving problems, use option 9 (Troubleshoot) to access the appropriate display. When the text in the Services area indicates a problem with system managers, journal managers, or collector services, option 9 will access the Work with Systems display, from which you can view detailed information and take action. See Resolving status problems with system and journal managers on page 164 for more information. When the text in the Services area indicates a problem with a monitor, option 9 will access the Work with Monitors display. For more information about working with monitors, see the Using MIMIX Monitor book.

53

The Work with Data Groups display - 5250 emulator

From the Work with Data Groups display you can start and end replication, track replication status, perform a data group switch, as well as work with files, objects, and tracking entries in error and access displays for data group entries and tracking entries. Do one of the following to access the Work with Data Groups display: From the MIMIX Availability Status display, type 5 (Display details) next to Replication and press Enter. From the MIMIX Intermediate Main menu, select option 1 (Work with data groups) and press Enter.

Figure 9. Sample Work with Data Groups display. The display uses letters and colored highlighting to call your attention to warning and problem conditions. This example shows items in color which would appear with color highlighting on the display. If you are viewing this page in printed form, the color may not be shown.
CHICAGO 11:02:05 Type options, press Enter. Audits/Recov./Notif.: 001 / 002 / 003 5=Display definition 8=Display status 9=Start DG 10=End DG 12=Files not active 13=Objects in error 14=Active objects 15=Planned switch 16=Unplanned switch ... ---------Source----------------Target--------ErrorsOpt Data Group System Mgr DB Obj DA System Mgr DB Obj DB Obj __ APP1 LONDON A I CHICAGO A I __ APP2 LONDON A A A CHICAGO A A A __ APP3 LONDON A I CHICAGO A I 2 __ CRITICALAP LONDON A R A A CHICAGO A A A 1 4 __ RJAPP4 LONDON A L CHICAGO A I Work with Data Groups

F3=Exit F10=Legend

F5=Refresh F13=Repeat

Bottom F7=Audits F8=Recoveries F9=Automatic refresh F16=DG definitions F23=More options F23=More keys

For each data group listed, you can see the current source system and target system processes, and the number of errors reported. The following fields and columns are available. Audit/Recov./Notif. -This field is located in the upper right corner of the Work with Data Groups display. The first number is the total number of audits that require action to correct a problem or that require your attention to prevent a situation from becoming a problem. The second number indicates the number of active recoveries, including those resulting from audits.The third number indicates the number of new notifications that require action or attention. If more than 999 items exist in any field, the field will display +++. When a field is highlighted in red, a problem exists. When a field is

54

The Work with Data Groups display - 5250 emulator

highlighted in yellow, at least one out-of-compliance audit is currently active or an audit is approaching out of compliance. For details, see Problems reflected in the Audits/Recov./Notif. field on page 56. Data group - When a data group name is highlighted, a problem exists. For details, see Problems reflected in the Data Group column on page 56 Source - The following columns provide summaries of processes that run on the source system. For details about status values, see Replication problems reflected in the Source and Target columns on page 59. Mgr - Represents a summation of the system manager and the journal manager. DB - Represents the status of the remote journal link. It is possible to have an active status in this column even though the data group has not been started. When the RJ link is active, database changes will continue to be sent to the target system. MIMIX can read and apply these changes once the data group is started. For data groups configured for source-send replication, this represents the status of the database send process. Obj - Represents a summation of the object processes that run on the source system. These include the object send, object retrieve and container send processes. DA - This column represents the status of the data area polling process when the data group replicates data areas through the data area poller. This column does not contain data when data areas are replicated through the user journal with advanced journaling or through the system journal. Target - The following columns provide summaries of processes that run on the target system. For details about status values, see Replication problems reflected in the Source and Target columns on page 59. Mgr - Represents a summation of the system manager and the journal manager. DB - Represents the summation of the database reader process and the database apply processes. For data groups configured for source-send replication, this column represents the summation of the status of database apply processes. Obj - Represents the object apply processes. Errors - When any errors are indicated in the following columns (DB and Object), they are highlighted in red. DB - Represents a combination of file entries, IFS tracking entries, and object tracking entries in error for the data group. To work with a subsetted list of errors, use option 12 (Files not active), option 51 (IFS tracking entries not active), or option 53 (Object tracking entries not active). For additional information, see Working with files in error on page 170 and Working with tracking entries on page 179. Obj - Represents a count of the number of objects for which at least one activity entry is in a failed state. To work with a subsetted list, use option 13 (objects in error). For additional information, see Working with objects in error on page 185.

55

Problems reflected in the Audits/Recov./Notif. field

When the Audits field is highlighted in reverse red, at least one audit has failed, has unresolved differences, is out of compliance, or was not run due to a policy. When it is highlighted in reverse yellow, at least one out-of-compliance audit is currently active or an audit is approaching out of compliance. For more information about audits, see Where audit status and compliance status is reported on page 85. The Recov. (recoveries) field indicates the number of active recoveries, including those resulting from audits. Active recoveries are an indication of problems detected by MIMIX AutoGuard which is attempting to correct them. For more information about recoveries, see Displaying recoveries on page 125. When the Notif. (notifications) field is highlighted in reverse red, at least one new notification with a severity of *ERROR exists. When it is highlighted in reverse yellow, at least one new notification with a severity of *WARNING exists. For more information about notifications, see Displaying notifications on page 120.

Problems reflected in the Data Group column

When a data group name is highlighted in color, journaling problems exist that affect replication of one or more types of data.
Table 5. Color Red Conditions which highlight the data group name in color. Possible Problems One of the following conditions exists: FIles, IFS tracking entries, or object tracking entries defined to the data group are not journaled or not journaled correctly on the source system. The source side journal is in standby or inactive state. One of the following conditions exists: Files, IFS tracking entries, or object tracking entries defined to the data group are not journaled or journaled correctly on the target system. This is only enforced if the data group is set up to journal on the target system as defined in the data group definition. Data group file entries, IFS tracking entries, or object tracking entries are on hold for reasons other than an error. The journal cache value for the source journal does not match the configured value in the journal definition. The journal cache value for the target journal does not match the expected cache value and the database apply session is active. If another data group is using the journal definition as a source journal, the actual journal cache value may be different than the configured value. The target journal state value for the target journal does not does not match the expected state value and the database apply session is active. If another data group is using the journal definition as a source journal, the actual state may be different than the configured value.
Note: In a cooperative processing environment, files, IFS tracking entries, or object tracking entries being added dynamically to the configuration for user journal replication may reflect an intermediate state of not journaled until they have been synchronized and become active to MIMIX.

Yellow

56

The Work with Data Groups display - 5250 emulator

Resolving problems highlighted in the Data Group column

Journaling problems: If the data group name is highlighted in red or yellow, do the following to check for and resolve journaling problems: 1. Check for not journaled conditions for each of the following: To determine which files are not journaled, use option 17 (File entries) for the data group. Then press F10 (journaled view) to see journaling status. To determine which IFS tracking entries are not journaled, use option 50 (IFS tracking entries) for the data group. Then press F10 (journaled view) to see journaling status. To determine which object tracking entries are not journaled, use option 52 (object tracking entries) for the data group. Then press F10 (journaled view) to see journaling status.

2. To start journaling for a file or a tracking entry, use option 9 (Start journaling) to start journaling. 3. You can use option 11 (Verify journaling) to verify that journaling has started. Journal cache or journal state problems: If the data group name is highlighted in red or yellow, do the following to check for and resolve problems: 1. From the Work with Data Groups display, use option 8 (Display status). 2. From the Data Group Status display, press F8 (Database). 3. The Jrn State and Cache Src and Tgt fields are located In the upper left corner of the Data Group Database Status display. For each system (Src or Tgt) status of the journal state is shown first, followed by the status of the journal cache. The example below shows v for value in all for status positions. Based on the status displayed in these fields, you can take the actions described in the following steps to correct the problem:
Jrn State and Cache Src: v v Tgt: v v

4. Source system journal state (first Src: value) - If the source system state is red and the value for the journal state is standby (S) or inactive (I), the journal state must be changed and all data replicated through the user journal must be synchronized. Do the following: a. Press F12 (Cancel) to return to the Work with Data Groups display. Note which system is specified as the source system for the data group. b. Use option 45 (Journal Definitions) to view the journal definitions used for the data group in error. c. On the Work with Journal Definitions display, determine the journal name and library specified for the system that is the source system for the data group. d. Specify the name and library of the source system journal in the following command:
CHJRN CHGJRN JRN(library/name) JRNSTATE(*ACTIVE)

57

e. All data replicated through the user journal must be synchronized. For detailed information about synchronizing a data group, refer to your Runbook or to the MIMIX Reference book. 5. Source system journal cache (second Src: value) - If the source system cache is yellow, the actual status does not match the configured value in the journal definition used on the source system. Do the following: a. Press F12 (Cancel) to return to the Work with Data Groups display. Note which system is specified as the source system for the data group. b. Use option 45 (Journal Definitions) to view the journal definitions used for the data group in error. c. On the Work with Journal Definitions display, use option 5 (Display next to the journal definition listed for the source system. d. Check the value of the Journal caching (JRNCACHE) parameter. e. Determine which value is appropriate for journal cache, the configured value or the actual status value. Once you have determined this, either change the journal definition value or change the journal state (CHGJRN command) so that the values match. 6. Target system state (first Tgt: value) or Target system cache (second Tgt: value) - If the target system state or cache is yellow, the actual value for state or cache does not match the configured value. Do the following: a. Press F12 (Cancel) to return to the Work with Data Groups display. Note which system is specified as the target system for the data group. b. Use option 45 (Journal Definitions) to view the journal definitions used for the data group in error. c. On the Work with Journal Definitions display, use option 5 (Display next to the journal definition listed for the target system. d. Check the value of the following parameters, as needed: Target journal state (TGTSTATE) Journal caching (JRNCACHE) e. Determine why the actual status of the journal state or journal cache does not match the configured value of the journal definition used on the target system. f. Determine which values are appropriate for journal state and journal cache, the configured value or the actual status value. Once you have determined this, either change the journal definition value or change the journal state or cache (CHGJRN command) so that the values match.

58

The Work with Data Groups display - 5250 emulator

Replication problems reflected in the Source and Target columns

The status of each process is represented by a status letter and the color of the box surrounding the letter. Table 6 describes the letters and colors used for status of the replication process summaries shown in the Source and Target columns.
Table 6. I L Possible status values for source and target process summaries Inactive (highlighted red) The process is currently not active. Inactive RJ link (highlighted red) The RJ link is currently not active. This status is only displayed in the database source column when a data group uses MIMIX RJ support. Active (highlighted blue) The process is currently active. For the database source column, this value indicates that the send/receive processes are active. RJ Catch-up mode (highlighted blue) The remote journal is currently in catch-up mode. This status can only be displayed in the database source column for data groups that use remote journaling. Catch-up mode indicates that the operating system is transferring journal entries from the source system journal to the remote journal as quickly as possible. When the database reader process is active, MIMIX processes the journal entries as they reach the target system. Active RJ link (highlighted blue) The RJ link is currently active. This status is only displayed in the database source column when a data group uses MIMIX RJ support. Unknown (highlighted white) The status of the process cannot be determined possibly because of an error or communications problem. RJ Link in Threshold (highlighted turquoise) The RJ link has fallen behind its configured threshold. View detailed status to determine the extent of the backlog. Threshold reached (highlighted turquoise) A process has fallen behind a configured threshold. View detailed status to determine which process has exceeded its backlog threshold and to determine the extent of the backlog. See Working with the detailed status of data groups on page 61 Switch mode (highlighted red) The data group is in the middle of switching the data source system and status may not be retrievable or accurate. Partially active (highlighted red) - At least one subprocess is active, but one or more subprocesses is not active. This status is only displayed in process columns that represent multiple processes. The data group name may also be shown in a highlighted field of red. Disabled The process is currently not active and the data group is disabled.
Note: The status value for a disabled data group is the letter D displayed in standard format. No colored blocks are used.

A C

U J T

X P

Waiting at a recovery point (highlighted red) - The process is currently suspended at a recovery point.

Note: Use F10 (Legend) to view a pop-up window that displays the status values and colors. To remove the pop-up window, press Enter or F12 (Cancel).

59

Setting the automatic refresh interval

You can control how frequently the data shown on the Work with Data Groups display is refreshed by doing the following: 1. Press F9 (Automatic refresh). 2. The Automatic Refresh Value pop-up appears. Specify how long you want the system to wait before refreshing the information and press Enter. The status displayed will automatically refresh when the specified interval passes. To end the automatic refresh process, press Enter.

60

Working with the detailed status of data groups

Working with the detailed status of data groups

MIMIX Availability Manager provides robust support for displaying detailed status for a data group. Basic support for data group status is available in the 5250 emulator interface. Certain functions may only be available from MIMIX Availability Manager.

Displaying data group detailed status with MIMIX Availability Manager

When you display detailed status for a data group from within MIMIX Availability Manager, the Data Group Details window opens. Several variations of this window are possible based on the configuration of the data group. The variation you see is determined by MIMIX Availability Manager and is based on the severity of problems in the selected data group. The possible variations of the Data Group Details window are: Activity - Provides detailed information about replication activity that is experiencing problems. For additional information, see Variations of the Data Group Details - Activity window on page 64. Status - Provides detailed status of the processes required for replication. This is shown in Figure 10. User Journal - Provides detailed information about replication of user journal transactions, including journal progress, performance, and recent activity. This information represents database replication performed by user journal replication processes, as well as IFS objects, data areas, or data queues being replicated through the user journal. This is shown in Figure 11. System Journal - Provides detailed information detailed information about replication of system journal transactions, including journal progress, performance, and recent activity. This information represents object replication performed by system journal replication processes. This is shown in Figure 12.

If the view you want is not initially displayed, you can select it from the navigation bar. Online help is available for all views. From MIMIX Availability Manager, do the following to display a data group detailed status: 1. Select Data Groups from the Details area of the navigation bar. 2. From the list of data groups, select the data group you want. Status for this selected data group is displayed in the Summary area. 3. Select Display Details and click .

Note: The window displayed may be any of the following Data Group Details windows: Activity, Status, User Journal, or System Journal. MIMIX Availability Manager determines which window to display based on the severity of problems in the selected data group. Figure 10 shows an example of the Details - Status window. 4. If necessary, select Status from the Details area of the navigation bar. 5. To see additional details for this data group, use the left navigation bar to select

61

the information you want to view.

Figure 10. Detailed replication process status for a data group in MIMIX Availability Manager

62

Working with the detailed status of data groups

Figure 11. User journal detailed status for a data group within MIMIX Availability Manager

Figure 12. System journal detailed status for a data group within MIMIX Availability Manager

63

Variations of the Data Group Details - Activity window

The Data Group Details - Activity window identifies replication activity for the selected data group that is experiencing problems. Several variations of the are possible depending on the configuration of the data group. The variations available for the selected data group are listed in the Activity Types area of the navigation bar and can be selected. The possible variations include: Object - Object activity in the system journal File - File activity in the user journal IFS Tracking - IFS tracking activity for IFS objects replicated through the user journal Object Tracking - Object tracking activity for data areas and data queues replicated through the user journal

Object and File support actions which enable viewing additional detail for a specified file or object. Figure 13 shows an example of the window when File activity with replication problems is displayed.
Figure 13. Example of file information shown in the Data Group Details - Activity window

Displaying data group detailed status from a 5250 emulator

The Data Group Status display (DSPDGSTS command) uses multiple views to present status of a single data group. The views identify and provide status for each of the processes used by the data group. Error conditions for the data group as well as process statistics and information about the last entry processed by each replication process are included. Some fields are repeated on more than one view. The data group configuration determines what fields are visible. If the data group is database only, the object fields are not shown. Similarly, if the data group is object only, the database fields are not shown. From a 5250 emulator, do the following to access detailed status for a data group: 1. From the MIMIX Basic Main Menu, select option 1 (Availability status) and press Enter. 2. From the MIMIX Availability Status display, type 5 (Display details) next to the

64

Working with the detailed status of data groups

Replication activity and press Enter. 3. The Work with Data Groups display appears. Type an 8 (Display status) next to the data group you want and press Enter. 4. The Data Group Status display shows a merged view of data group activity on the source and target systems. (See Figure 14.) Only fields for the type of information replicated by the data group are displayed. For example, if the data group replicates only objects from the system journal, you will only see fields for system journal replication. If the data group replicates from both the system journal and the user journal, you will see fields for both. To see additional status information for object processes or database processes, do the following: If the data group contains object information, press F7 (Object) to view additional object status displays. The Data Group Object Status display appears. If the data group contains database information, press F8 (Database) to view additional database status displays. The Data Group Database Status display appears. Tracking entry information for advanced journaling is also available.

5. For object information, there are three views. For database information, there are four views available. Use F11 to change between views. Note: If the data group contains both database and object information, you can toggle between object details and database details by using the F7 and F8 keys.

Merged view
The initial view displayed is the merged view. This view summarizes status for the replication paths configured for the data group. The status of each process is represented by the color of the box surrounding the process and a status letter. Table 7 shows possible status values. Figure 14 shows a sample of the merged view of the Data Group Status display. The data group in this view is configured for user journal replication using remote journaling and for system journal replication.
Figure 14. Merged view of data group status. The inverse highlighted blocks are not shown in

65

this example.
Data Group Status 17:39:36 Data group . . . . : CRITICALAP Database errors . . . . : 1 Elapsed time . . . : 00:52:51 Objects in error/active : 4 / 0 Transfer definition: PRIMARY-A State. . . . . . . . . : *ASYNCPEND --------------------------- Source Statistics --------------------------System: LONDON-A Journal Manager-A RJLNK Monitor- A Receiver Sequence # Date Time Trans/Hour Database Source Jrn. LONDN0002 >0,000,002,591 4/20/08 11:02:35 Link-A RJ Tgt Jrn. LONDN0002 >0,000,002,591 4/20/08 11:02:35 Last Read . LONDN0002 >0,000,002,591 4/20/08 11:02:35 Entries not read: 0 Est. time to read: Object Current . . AUDRCV0108 22,314,732 4/22/08 17:37:13 748 Send-I Last Read . AUDRCV0103 22,175,464 4/21/08 11:05:56 Entries not read : 139,268 Est. time to read: --------------------------- Target Statistics --------------------------System: CHICAGO-A Journal Manager-A Reader-A RJLNK Monitor- A Last Received Unprocessed Entry Count Est Time Sequence # Entry Count Trans/Hour To Apply DB Apply-A >0,000,002,590 Obj Apply-A 22,023,868 4 F3=Exit F5=Refresh F10=Restart statistics F7=Object view F12=Cancel F8=Database F14=Start DG F9=Automatic refresh F15=End DG

Note: Journal sequence numbers shown in the Source Statistics and Target Statistics areas may be truncated if the journal supports *MAXOPT3 for the receiver size and the journal sequence number value exceeds the available display field. When truncation is necessary, the most significant digits (leftmost) are omitted. Truncated journal sequence numbers are prefixed by '>'. This is shown in Figure 14.
Table 7. Color and Status Red Red - I Red - W Yellow Yellow - P Turquoise - T Possible values for detailed status. Not all statuses are used by each process. Description When displayed on the Data group, Database errors, or Objects in error fields, a problem exists that requires action. The process is inactive. The process is suspended at a recovery point. This status is only available for apply processes. When displayed on the Data group field, a problem exists that may require attention. One or more of the processes is active but others are inactive. On the merged view, this status is only possible for the Object Send field. The process has a backlog which exceeds its configured threshold. On fields which summarize status for multiple processes, use F7 and F8 to view the specific threshold. The -T is not shown in statistical fields. If a threshold condition persists over time, refer to the MIMIX Reference book for information about possible resolutions. The status of the process is unknown

White - U

66

Working with the detailed status of data groups

Table 7. Color and Status Blue - A Blue - C

Possible values for detailed status. Not all statuses are used by each process. Description The process is active. The RJ Link is in catch-up mode.This status is only possible for the Database Link process in the merged view and the RJ link field in some database views. The data group is disabled. This also means the data group is currently inactive.

Green - D

Top left corner: The top left corner of the Data Group Status display identifies the data group, the elapsed time, and the status of the transfer definition in use. The elapsed time is the amount of time that has elapsed since you accessed this display or used the F10 (Restart statistics) key. Top right corner: The top right corner of the display identifies the number of errors identified by MIMIX. If the workstation supports colors, the number files and objects in error will be displayed in red. The Database errors field identifies the number of errors in user journal replication processes. This includes all file entries, IFS tracking entries, and object tracking entries in error. The Objects in error/active fields indicate the number of objects that are failed and the number of objects with pending activity entries. The first number in these fields indicates the number of objects defined to the data group that have a status of *FAILED. The second number indicates the number of objects with active (pending) activity entries. The State field identifies the state of the remote journal link. The values for the state field are the same as those which appear on the Work with RJ Links display. This field is not shown if the data group uses source-send processes for user journal replication.

Source statistics: The middle of the display shows status and summarized statistics for the journals being used for replication and the processes that read from them. The following process fields are possible: System - Identifies the current source system definition. The status value is an indication of the success in communicating with that system. Journal Manager - Displays the status of the journal manager process for the source system. DTAARA Poller - Displays the status of the data area poller. This field is present only if the data group replicates data areas using this process. RJLNK Monitor - Displays status of the RJLNK monitor on the source system. This field is present only for data groups that use remote journaling. Database (Link or Send) - Identifies the status of the process which transfers user

67

journal entries from the source system to the target system. Link - Displayed when the data group is configured for remote journaling. The status is that of the of the RJ link. Send -Displayed when the data group id configured for MIMIX source-send processes. The status is that of the database send process. Object Send - Displays a summation of status from the object send, object retrieve, and container send processes. The highest priority status from each process determines the status displayed. Use F7 (Object view) to see the individual processes. For the Database and Object processes, additional fields identify current journal information, the last entry that has been read by the process, and statistics related to arrival rate, entries not read, and estimating the time to read. Current - For the Database Send and Object Send processes, this identifies the last entry in the currently attached journal receiver. This information is used to show the arrival rate of entries to the journals. Note: If the data group uses remote journaling, current information is displayed in two rows, Source jrn and RJ tgt jrn. The source journal sequence number refers to the last sequence number in the local journal on the source system. The remote journaling target journal sequence number refers to the last sequence number in the associated remote journal on the target system. Transactions per hour - For current journal information, this is based on the number of entries to arrive on the journal over the elapsed time the statistics have been gathered. For last read information, this is based on the actual number of entries that have been read over the elapsed time the statistics have been gathered. Last Read - Identifies the journal entry that was last read and processed by the object send, database send, or database reader. Transactions per hour - For current journal fields, this is based on the number of entries to arrive on the journal over the elapsed time the statistics have been gathered. For last read fields, this is based on the actual number of entries that have been read over the elapsed time the statistics have been gathered and will change due to elapsed time and the rate at which entries arrive in the journal. Entries not read - This a calculation of the number of journal entries between the last read sequence number and the sequence number of the last entry in the current receiver for the source journal. An asterisk (*) preceding this field indicates that the journal receiver sequence numbers have been reset between the last entry in the current receiver and the last read entry. Estimated time to read - This is a calculation using the entries not read and the transactions per hour rate. This calculation is intended to provide an estimate of the length of time it may take the process (database reader, database send, or object send) to complete reading the journal entries. Target statistics: The lower part of the display shows status and summarized statistics for all target system processing. The following process fields are possible:

68

Working with the detailed status of data groups

System - Identifies the current target system definition. The status value is an indication of the success in communicating with that system. Journal Manager - Displays the status of the journal manager process for the target system. Reader - Displays status of the database reader. This field is present only for data groups that use remote journaling. RJLNK Monitor - Displays status of the RJLNK monitor on the target system. This field is present only for data groups that use remote journaling. DB Apply and Obj Apply - Each field displays the combined status for the apply jobs in use by the process. For each process, additional fields show statistics for the last received journal sequence number, number of unprocessed entries, approximate number of transactions per hour being processed, and the approximate amount of time needed to apply the unprocessed transactions for all database or object apply sessions.

Object detailed status views

Figure 15, Figure 16, and Figure 17 show samples of the information available when you use F7 (Object) to view the detailed object information. Use F11 to move between the three views of detailed object status. On each view, you can use the F1 (Help) key to see a description of that views contents. In all object views, journal sequence numbers may be truncated if the journal supports *MAXOPT3 for the receiver size and the journal sequence number value exceeds the available display field. When truncation is necessary, the most significant digits (leftmost) are omitted. Truncated journal sequence numbers are prefixed by '>'. The possible status values are indicated in Table 7, with the following additional status values that are unique to several system journal replication processes. The Min, Act, and Max fields for the Retrieve, Send, and Apply processes indicate the minimum, active, and maximum number of jobs for each process. The number of active jobs vary based on the work load. The active count is highlighted with color for the following conditions: Red - The number of active jobs is zero (0). Yellow - The number of active jobs is greater than zero (0) but less than the minimum number of processes. Turquoise - The process has a backlog that exceeds its configured threshold. When this occurs, the backlog field for the process is also highlighted in the color turquoise. Blue - The number of active jobs is equal to or greater than the minimum number of processes.

69

Figure 15 and Figure 18 show the active count highlighted.

Figure 15. Data group detail status, object view 1.
Data Group Object Status Data group . . . . : Elapsed time . . . : CRITICALAP 00:52:51 System: CHICAGO 17:50:00 4

Objects in error . .

Send Process -I Jrn Manager -A Receiver Sequence # Date Time Trans/Hour Current . . AUDRCV0108 10,022,314,732 4/22/08 17:37:13 748 Last Read . AUDRCV0103 10,022,175,464 4/21/08 11:05:56 Entries not read: 139,268 Est. time to read: --------------------- Object Retrieve/Container Send ---------------------Retrievers Retrieve Senders Send Containers Containers Min Act Max Backlog Min Act Max Backlog Sent Per Hour 1 0 5 1 0 5 1,145 ------------------------------- Object Apply ------------------------------Applies Apply Active Entries Entries Min Act Max Backlog Objects Sequence # Applied Per Hour 1 1 5 4 >0,022,023,871 1,133 F3=Exit F5=Refresh F9=Automatic refresh F7=Merged view F11=View 2 F8=Database view F12=Cancel F24=More keys

Figure 16. Data group detail status, object view 2.

Data Group Object Status Data group . . . . : Elapsed time . . . : CRITICALAP 00:52:51 System: CHICAGO 17:57:31 4

Objects in error . .

Send Process -I Jrn Manager -A Receiver Sequence # Date Time Trans/Hour Current . . AUDRCV0108 10,022,314,732 4/22/08 17:37:13 748 Last Read . AUDRCV0103 10,022,175,464 4/21/08 11:05:56 Entries not read: 139,268 Est. time to read: --------------------- Object Retrieve/Container Send ---------------------Retrievers Retrieve Senders Send Containers Containers Min Act Max Backlog Min Act Max Backlog Sent Per Hour 1 0 5 1 0 5 1,145 ------------------------------- Object Apply ------------------------------Applies Apply ------------- Last Applied ------------Min Act Max Backlog Sequence # Type Object 1 1 5 0 >0,022,023,871 *DOC BVT#I/PBBDOCXX.002 F3=Exit F5=Refresh F9=Automatic refresh F7=Merged view F11=View 3 F8=Database view F12=Cancel F24=More keys

70

Working with the detailed status of data groups

Figure 17. Data group detail status, object view 3.

DG Object Journal Entry Detail Data group . . . . : Source system: Current entry Last read entry Last received CRITICALAP System: CHICAGO 18:01:20

LONDON-A Entry TSF -

Sequence # 10,022,314,732 10,022,175,464

Receiver AUDRCV0108 AUDRCV0103 -

Date Time 4/22/08 17:37:13 4/21/08 11:05:56

Target system: CHICAGO-A ------------------------------- Object Send ------------------------------Entry Sequence # Date Time Type Object Active TCO >0,022,023,868 4/20/08 13:59:23 *DOC BVT#I/PBBDOCXX.002 Processed TCO >0,022,023,868 4/20/08 13:59:23 *DOC BVT#I/PBBDOCXX.002 ------------------------------- Object Apply ------------------------------Entry Sequence # Date Time Type Object Processed TCA >0,022,023,871 4/20/08 13:59:23 *DOC BVT#I/PBBDOCXX.002

F3=Exit F5=Refresh F9=Automatic refresh

F7=Merged view F11=View 1

F8=Database view F12=Cancel F24=More keys

Database detailed status views

Figure 18, Figure 19, Figure 20, and Figure 21 show samples of the information available when you use F8 (Database) to view the detailed database information. On each view, you can use the F1 (Help) key to see a description of that views contents. In database views that include sequence numbers, the journal sequence numbers may be truncated if the journal supports *MAXOPT3 for the receiver size and the journal sequence number value exceeds the available display field. When truncation is necessary, the most significant digits (left-most) are omitted. Truncated journal sequence numbers are prefixed by '>'. For most fields, the possible status values are indicated in Table 7. The possible values for the Jrn State and Cache (Src and Tgt) fields are indicated in Table 8 (journal state) and Table 9 (journal cache). As on the merged view, the data group configuration determines whether the Send process field is replaced by the RJ Link field. When remote journaling is configured, the RJ Link and Reader fields are shown. In the top right corner of database views 1 and 2 (Figure 18 and Figure 19), the values of the File and Tracking entries, Not journaled on source, Not journaled on target, Held due to error, and Held for other reasons fields are combined counts of file entries, IFS tracking entries, and Object tracking entries. Database view 4 (Figure 21) separates the this information into columns for file entries, IFS tracking entries, and object tracking entries. If a data group has multiple database apply sessions you will see an entry for each session in the Apply Status column on database views 1, 2, and 3 (Figure 18, Figure

71

19, and Figure 20). Each session has its own status value. In these sample figures there is only one apply session (A) which is active (-A). The Jrn State and Cache (Src and Tgt) fields reflect journal standby state and journal caching actual values for the journals when the IBM high availability performance enhancements are installed on the systems defined to the data group. These fields appear on database views 1 and 2 (Figure 18 and Figure 19). The target journal state and cache values are set on the journal when the database apply session is started. Journal State - The status values indicate the actual state value for the source and target journals. Table 8 shows the possible values for each field. Journal Cache - The status indicate the actual cache value for the source and target journals. Table 9 shows the possible values for each field. For each system (Src or Tgt) status of the journal state is shown first, followed by the status of the journal cache. If a problem exists with journal state or journal cache, the data group name is also highlighted with the same color. For information about resolving journal cache or journal state problems, see Resolving problems highlighted in the Data Group column on page 57.
Table 8. Field Either system Possible status values for Journal State fields Color and Status White No color No color U A X Description Unknown. MIMIX was not able to retrieve values, possibly because the journal environment has not yet been built. Journal state is active The required IBM feature, IBM i option 42 - High Availability Journal Performance, is not installed on this system Journal is in standby state as expected Source journal is in standby state but that state is not expected. Source journal in inactive state but that state is not expected. Target journal state or cache is not as expected and the database apply session is active Target journal state is inactive but that state is not expected. The IBM feature is installed but the data group is configured to not journal on the target system.

No color Source Red Red Target Yellow Yellow

S S I S I

blank blank

72

Working with the detailed status of data groups

Table 9. Field

Possible status values for Journal Cache fields Color and Status White U X Description Unknown. MIMIX was not able to retrieve values, possibly because the journal environment has not yet been built The required IBM feature, IBM i option 42 - High Availability Journal Performance, is not installed on this system Caching is active Caching is not active. Source journal cache value is not as expected. Source journal cache value is not as expected. Target journal cache value not as expected and the database apply session is active. Target journal cache value not as expected and the database apply session is active. The IBM feature is installed but the data group is configured to not journal on the target system.

Either System

No color

No color No color Source Yellow Yellow Target Yellow Yellow

Y N Y N Y N

blank blank

Figure 18. Data group detail statusdatabase view 1. In this example, the Link status of -A and the presence of the Reader status indicate that the data group uses remote journaling. The display also shows that journal standby state is active and journal caching is not active. The unprocessed entry count indicates that the final journal entry has not been applied. The > character preceding sequence numbers for the apply session indicate truncated sequence

73

numbers that are associated with *MAXOPT3 support.

CHICAGO 18:07:02 Data group . . . . : CRITICALAP File and Tracking entries : 12 Elapsed time . . . : 00:52:51 Not journaled on source . : 1 Jrn State and Cache Src: A N Tgt: A N Not journaled on target . : 1 RJ Link -A Held due to error . . . . : 1 Jrn Manager -A Reader -A Held for other reasons . . : 0 Receiver Sequence # Date Time Trans/Hour Source Jrn. LONDN0002 12,345,678,900,000,002,591 4/20/08 11:02:35 Rj Tgt Jrn. LONDN0002 12,345,678,900,000,002,591 4/20/08 11:02:35 Last Read . LONDN0002 12,345,678,900,000,002,591 4/20/08 11:02:35 Entries not read: 0 Est. time to read: ------------------------------- Database Apply --------------------------Apply Received Processed Unprocessed Entry Count Est Time Open Status Sequence # Sequence # Entry Count Trans/Hour To Apply Commit A-A >0,000,002,593 >0,000,002,592 1 *NO Data Group Database Status System:

F3=Exit F5=Refresh F9=Automatic refresh

F7=Object view F11=View 2

F8=Merged view F12=Cancel

F24=More keys

Figure 19. Data group database statusview 2. In this example, the Link status of A and the presence of the Reader status indicates that the data group uses remote journaling. The display also shows that journal standby state is active and journal caching is not active.
CHICAGO 16:07:03 Data group . . . . : CRITICALAP File and Tracking entries. : 12 Elapsed time . . . : 00:52:51 Not journaled on source . : 1 Jrn State and Cache Src: A N Tgt: A N Not journaled on target . : 1 RJ Link -A Held due to error . . . . : 2 Jrn Manager -A Reader -A Held for other reasons . . : 0 Receiver Sequence # Date Time Trans/Hour Source Jrn. LONDN0002 12,345,678,900,000,002,591 4/20/08 11:02:35 Rj Tgt Jrn. LONDN0002 12,345,678,900,000,002,591 4/20/08 11:02:35 Last Read . LONDN0002 12,345,678,900,000,002,591 4/20/08 11:02:35 Entries not read: 0 Est. time to read: ------------------------------- Database Apply --------------------------Apply Received Apply point Clock Time Hold MIMIX Log Open Status Sequence # Sequence # Difference Sequence # Commit Id A-A >0,000,002,590 >0,000,002,590 Data Group Database Status System:

F3=Exit F5=Refresh F9=Automatic refresh

F7=Object view F11=View 3

F8=Merged view F12=Cancel

F24=More keys

74

Working with the detailed status of data groups

Figure 20. Data group database status, view 3.

DG Database Jrn Entry Detail Data group . . . . : Source system: Current entry RJ target entry Last read entry Last received CRITICALAP System: CHICAGO 18:16:04

LONDON-A Entry Sequence # UMX 12,345,678,900,000,002,591 UMX 12,345,678,900,000,002,591 UMX 12,345,678,900,000,002,591 - 12,345,678,900,000,002,590

Receiver LONDN0002 LONDN0002 LONDN0002 -

Date 4/20/08 4/20/08 4/20/08 4/20/08

Time 11:02:35 11:02:35 11:02:35 11:01:04

Target system: CHICAGO-A ------------------------------- Database Apply ----------------------------Apply Entry Sequence # Date Time Object Library Member A-A UMX >0,000,002,590 4/20/08 11:01:04

F3=Exit F5=Refresh F9=Automatic refresh

F7=Object view F11=View 1

F8=Merged view F12=Cancel

F24=More keys

Figure 21. Data group detail statusdatabase view 4. In this example, the combined number of file and tracking entries shown in Figure 18 and Figure 19 are separated into separate columns for file entries, IFS tracking entries, and object tracking entries.
File and Tracking Entry Status Data group . . . . : CRITICALAP File Entries 7 1 0 0 0 IFS Trk Entries 3 0 1 1 0 Obj Trk Entries 2 0 0 1 0 System: CHICAGO 16:07:03

Number of entries . . . . : Not journaled on source . : Not journaled on target . : Held due to error . . . . : Held for other reasons . .:

F3=Exit F5=Refresh F9=Automatic refresh

F7=Object view F11=View 1

F8=Merged view F12=Cancel

F24=More keys

75

Identifying replication processes with backlogs

Identifying replication processes with backlogs

If replication processes are active and have no reported error conditions, a replication process that has exceeded its backlog threshold will have a status that reflects this condition. However, if a replication process is inactive or has an error condition with a higher priority status, the threshold condition will not be visible in the process status until the process is started or the problem is resolved. Also, a backlog may exist but not be large enough to exceed the threshold setting, or the threshold warning setting may have been disabled (set to *NONE). Do the following to check for a backlog condition: 1. To access the details for a data group, use the procedures in Working with the detailed status of data groups on page 61. 2. Locate the appropriate window or view for the process you want to check. Table 10 identifies this information and the appropriate fields for each process.
Table 10. Process

In MIMIX Availability Manager, you may need to select User Journal or System Journal from the Details area of the navigation bar to access the appropriate window. In a 5250 emulator, use F7 or F8 on the Data Group Status display to locate the appropriate view.

Location of fields in each user interface which identify backlogs and threshold conditions for replication processes Description User Interface Window / View Fields to Check for Backlog Fields Highlighted when Threshold Exceeded

RJ Link

The backlog is the quantity of source journal entries that have not been transferred from the local journal on the source system to the remote journal on the target system. The time difference between the last entry in each journal can also be an indication of a backlog. MIMIX Availability Manager 5250 emulator Data Group Status Details -User Journal window Merged view, Database views 1 and 2 Not Sent Differences between transactions identified for Source and Target. Differences between journal entries identified by Source Jrn and RJ Tgt jrn for the database link. Not Sent 1

RJ tgt jrn Sequence # 3 RJ tgt jrn Date and Time 4

76

Identifying replication processes with backlogs

Table 10. Process

Location of fields in each user interface which identify backlogs and threshold conditions for replication processes Description User Interface Window / View Fields to Check for Backlog Fields Highlighted when Threshold Exceeded

DB Reader or DB Send

The backlog is the quantity of journal entries that are waiting to be read by the process. The time difference between the last entry that was read by the process and the last entry in the journal on the source system can also be an indication of a backlog. MIMIX Availability Manager 5250 emulator Data Group Status Details -User Journal window Merged view, Database views 1 and 2 Not Read Differences between transactions identified for Target (or Current) and Last Read. For remote journaling configurations, differences between journal entries identified by Source Jrn and Last read. For MIMIX source-send configurations, differences between journal entries identified by Current and Last Read. Not Read 1

Entries not read Sequence # 3 Last Read Date and Time 4

DB Apply

The backlog is the number of entries waiting to be applied to the target system. Each apply session is listed as a separate entry with its own backlog. MIMIX Availability Manager 5250 emulator Data Group Status Details -User Journal window Database views 1, 2, and 3 Unprocessed Entries Unprocessed Entries 2

Unprocessed Entry Count

Apply Status Unprocessed Entry Count

Object Send

The backlog is the quantity of journal entries that have not been read from the system journal. The time difference between the last entry that was read by the process and the last entry in the system journal can also be an indication of a backlog. MIMIX Availability Manager 5250 emulator Data Group Status Details -System Journal window Merged view, Object views 1, 2, and 3 Not Processed Differences between transactions identified for Current and Last Read. Differences between transactions identified for Object Current and Last Read Not Processed 1

Entries not read Sequence # 3 Last Read Date and Time 4

77

Identifying replication processes with backlogs

Table 10. Process

Location of fields in each user interface which identify backlogs and threshold conditions for replication processes Description User Interface Window / View Fields to Check for Backlog Fields Highlighted when Threshold Exceeded

Object Retrieve

The backlog is the number of entries for which MIMIX is waiting to retrieve objects. MIMIX Availability Manager 5250 emulator Data Group Status Details -System Journal window Object views 1 and 2 Retrievers, Backlog column Retrievers, Backlog column

Retrieve Backlog

Retrievers, Act column Retrieve Backlog

Container Send

The backlog is the number of packaged objects for entries that are waiting to be sent to the target system. MIMIX Availability Manager 5250 emulator Data Group Status Details -System Journal window Object views 1 and 2 Containers, Backlog column Containers, Backlog column

Container Send Backlog

Senders, Act column Container Send Backlog

Object Apply

The backlog is the number of entries waiting to be applied to the target system. MIMIX Availability Manager 5250 emulator Data Group Status Details -System Journal window Object views 1 and 2 Apply, Backlog column Apply, Backlog column

Apply Backlog

Applies, Act column Apply Backlog

Notes: 1. When the threshold is exceeded, the field also includes text which indicates whether the backlog was exceeded by time or by entries and by how much. 2. When the threshold is exceeded, the field also includes text which indicates the number of entries by which the threshold is exceeded. 3. When highlighted, the threshold journal entry quantity criterion is exceeded. 4. When highlighted the threshold time criterion is exceeded.

78

CHAPTER 3

Working with audits and rules

Audits are defined by and invoked through rules and influenced by policies. Aspects of audits include schedules, status, reported results, and their compliance status. MIMIX is shipped so that auditing can occur automatically. For day-to-day operations, auditing requires minimal interaction to monitor audit status and results. MIMIX user interfaces separate audit runtime status, compliance status, and scheduling information onto different views to simplify working with audits. Compliance errors and runtime errors require different actions to correct problems. This chapter provides information and procedures to support day-to-day operations as well as to change aspects of the auditing environment. The following topics are included. What are rules and how they are used by auditing on page 80 defines the differences between MIMIX rules used for auditing and user-defined rules. Requirements for using audits and rules on page 81 identifies the policy required for automatic audit recovery and the authority levels needed for working with rules when additional product and command security functions provided through License Manager are used. Guidelines and recommendations for auditing on page 81 provides considerations for effectively auditing a replication environment and recommendations for using both MIMIX rules and user-defined rules. Where audit status and compliance status is reported on page 85 describes where audit runtime and compliance status information is reported in higher-level status in the user interfaces. Working with audits on page 87 identifies the Audit Summary interfaces and provides procedures for common activities with audits, such as running audits immediately and resolving reported problems. Working with audit compliance on page 98 identifies the Audit Compliance interfaces and describes how to determine if an audit has a compliance problem. Working with audit schedules on page 102 identifies the Audit Schedule interfaces and the shipped default schedule information for MIMIX rules, provides considerations and procedures for changing an audit schedule, changing the system on which audits are performed, and provides considerations for using a different job scheduling mechanism. Policies for auditing on page 109 identifies all of the policies that can influence audits and provides procedures to prevent audits from running in common scenarios. Running rules and rule groups manually on page 115 describes how to run rules and rule groups manually and how to check the results of a user-generated rule. Checking results of a user-defined rule on page 118 describes how to view the results of running a user-defined rule.

79

What are rules and how they are used by auditing

A rule provides the construct for defining and processing an action to detect a problem that is inconsistent with your availability requirements. In other words, a rule is a check for compliance. Specifically, a rule defines a command to be invoked by the MIMIX Run Rule (RUNRULE) command and options for notifying you of the result. There are two types of rules: 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 MIMIX rules cannot be changed, you have considerable control over audits that use MIMIX rules through policies and scheduling. MIMIX rules require job scheduling support, such as that provided by MIMIX. User-defined rules - User-defined rules are those that you create for a specific purpose either by copying a MIMIX rule or by creating a rule in MIMIX Availability Manager. You specify the command or program to be invoked by the rule. Userdefined rules provide a way of incorporating other types of checks into your MIMIX environment. When user-defined rules are run, the rules framework automatically generates indicators, called notifications, that are available in the MIMIX user interface and incorporates the severity of detected errors into MIMIX status. Userdefined rules do not include the automatic job scheduling support available for MIMIX rules. Also, user-defined rules do not support automatic recovery actions, even if the specified command was copied from a MIMIX rule. You can create MIMIX monitors to handle job scheduling or use a different job scheduling mechanism. Two commands, Run Rule (RUNRULE) and Run Rule Group (RUNRULEGRP), enable programmatic scheduling of rule activity. MIMIX invokes the RUNRULE command when submitting automatically scheduled audits. You can also run rules on demand by using user interface options for audits and rules or by using these commands interactively.

80

Requirements for using audits and rules

Requirements for using audits and rules

To take advantage of automatic recoveries that audits invoke through MIMIX rules, you must have the Automatic audit recovery policy enabled. If you take advantage of the additional product and command security functions provided through License Manager, you may need different authority levels to work with rules. Viewing rules requires display (*DSP) authority. Running rules requires operator (*OPR) authority. Changing rules requires management (*MGT) authority. (MIMIX rules cannot be changed.) For more information about these provided security functions, see the License and Availability Manager book.

Guidelines and recommendations for auditing

To effectively audit a replication environment, there are a number of things to consider. This section highlights the main considerations but does not make specific recommendations or provide full examples. MIMIX service providers are specifically trained to provide a robust audit solution that meets your needs. The following are key considerations: How much time or system resource can you dedicate to audit processing each day, week, or month? How often should all data within the database be audited? In addition to regularly scheduled audits, consider when you may need to run audits manually. For example: Before switching, you should run all audits at audit level 30. See audit level. if you make configuration changes, you should run the #DGFE audit to check actual configuration data against what is defined to your configuration. For additional information, see When to run the #DGFE audit on page 106. In some environments using commitment control, the #MBRRCDCNT audit may be long-running. Refer to the MIMIX Reference book for information about improve performance of this audit.

Audit level: Best practice for auditing is to run the most extensive comparison possible. Specifying level 30 for the Audit level policy enables this. If you choose to run daily audits at a lower audit level, you should be aware of the risks, especially when switching. The level you choose for daily audits depends on your environment, and especially on the data compared by the #FILDTA and #IFSATR audits. When choosing a value, consider how much data there is to compare, how frequently it changes, how long the audit runs, how often you run the audit, and how often you need to be certain that data is synchronized between source and target systems. The #FILDTA audit compares all file member data defined for file members defined to a data group only when audit level 30 is used. Level 10 and level 20 compare 5 percent and 20 percent of data, respectively. Lower audit levels may take days or

81

weeks to completely audit file data. New files created during that time may not be audited. The #IFSATR audit compares data when audit level 20 or 30 is used. At level 10, only attributes are compared. Regardless of the level you use for daily operations, Vision Solutions strongly recommends that you perform audits at audit level 30 before the following events to ensure that 100 percent of that data is valid on the target system: Before performing a planned switch to the backup system. Before switching back to the production system.

Recommendations when automatic audit recovery is enabled: You should also consider the following when you use audit recoveries: MIMIX rules support recoveries only when the automatic audit recovery policy is enabled. Automatic recovery is not supported for user-defined rules. It may take multiple iterations of running audits with recoveries before the results are clean. Recovering from one error may result in a different error surfacing the next time the audit is performed. For example, a recovery that adds data group file entries may result in detecting a database relationship difference (*DBRIND) error the next time the audit is performed, where the root problem is that a library of logical files is not identified for replication. Always review the results of the audits. Audit results reflect only what was actually compared. Some objects may not have been compared due to object activity or due to the audit level policy value in effect, even when no differences (*NODIFF) are reported. You may need to take actions other than running an audit to correct detected issues. For example, you may need to change a procedure so that target system objects are only updated by replication processes. Watch for trends in the audit results. Trends may indicate situations that need further investigation. For example, objects that are being recovered for the same reason every time you run an audit can be an indication that something in your environment is affecting the objects between audits. In this case, investigating the environment for the cause may determine that a change is needed in the environment, in the MIMIX configuration, or in both. Trends may also indicate a MIMIX problem, such as reporting an object as being recovered when it was not. Report these scenarios to MIMIX CustomerCare. You can do this by creating a new case using the Case Management page in Support Central.

Considerations and recommendations for rules

The following considerations apply to MIMIX rules used by audits as well as to userdefined rules unless explicitly noted otherwise. Rules can be run from either user interface. Certain activities, such as creating new user-defined rules or rule groups, are only supported from MIMIX Availability Manager. Note: Rules are not allowed to run against disabled data groups.

82

Guidelines and recommendations for auditing

General recommendations: Run MIMIX rules from a management system. For most environments, the management system is also the target system. If you cannot run rules from the management system due to physical constraints or because of complex configurations, you can change the Run rule on system policy to meet your needs. See Changing the system where audits are performed on page 108. When choosing the value for the Run rule on system policy, consider your switching needs. Run MIMIX rules on a scheduled basis. This will help you detect problems in a timely manner and when you have time to address them. When running a rule or rule group from MIMIX Availability Manager, you should ensure that you have selected the appropriate systems for viewing in the browser preferences. Otherwise, you will not see the message log entries, notifications, and possible recoveries from the rule.

Considerations for the run rule commands: The RUNRULE command allows you to run multiple rules concurrently, with each specified rule running in an independent process. A limit of 100 unique rules can be specified per RUNRULE request. The RUNRULEGRP command only allows you to specify one rule group at a time. Otherwise, this command is like the RUNRULE command. When prompting the RUNRULE or RUNRULEGRP commands, consider the following: For the Data group definition prompts, the default value, *NONE, means the rule will not be run against a data group. If *NONE is specified on the command when the rule uses the &DGDFN replacement variable, running the RUNRULE command results in an error condition in the audit status and a message log entry. When a data group name or *ALL is specified, any instance of the &DGDFN replacement variable is replaced with the data group name and each data group is run in a separate process. For the Job description and Library prompts, the default value, MXAUDIT, submits the request using the default job description, MXAUDIT.

Replacement variables
Replacement variables are used to simplify the configuration and management of rules by allowing rule actions to be used for multiple data groups. They can also simplify outfile generation and cleanup. Replacement variables begin with an ampersand (&) and are used to pass in a value when a rule action is run. Some commonly used replacement variables include: The &PRDLIB replacement variable passes in the library from which the command specified in the rule is initiated. The &DGDFN replacement variable identifies the data group the rule is to act upon. In order to run a rule that contains &DGDFN, you must specify the value for the data group definition on the RUNRULE command. The &OUTFILE replacement variable passes in the name of a MIMIX generated

83

output file (outfile). The outfile is placed in a library whose name is the name of the MIMIX installation library followed by the characters _0. The outfile is managed by MIMIX. When &OUTFILE is specified in a rule, you will be able to view the resulting outfile from the user interface.

Rule-generated messages and notifications

For audits, the primary interface for checking results is the Audit Summary interface. This topic describes additional, secondary messaging for rules. When the action identified in a rule is started, an informational message appears in the message log. An informational message also appears when a rule action completes successfully. When an action initiated by a rule ends in error or runs successfully but detects differences, an escape message appears in the message log and an error notification is sent to the notifications user interface. Rules that call MIMIX commands may result in an error notification and a message log entry if you not have a valid access code for the MIMIX product or if the access code expired. Rule-related messages are marked with a Process value of *NOTIFY to facilitate the filtering of rules- and notification-related messages.

84

Where audit status and compliance status is reported

Where audit status and compliance status is reported

Audit status and compliance status values are prioritized and are bubbled up to the Installation status, the next higher level in the user interface. In MIMIX Availability Manager, the navigation bar provides a quick high level indication of current status and the severity of any problem for all of the systems and installations visible in your session. Icons appear in the navigation bar next to Summary or Compliance if any problems exist that require immediate attention or action. For example, the navigation bar in Figure 22 shows that at least one audit is in progress and at least one audit is approaching out of compliance. Select Summary or Compliance from the Details box in the navigation bar To view additional information or to work with audits, select Summary or Compliance from the Details box in the navigation bar to access the Audit Summary or Audit Compliance window, respectively.
Figure 22. The Navigation bar shows Audit Summary and Compliance

In a 5250 emulator, audit status and compliance status are reflected on the MIMIX Availability Status display (WRKMMXSTS command), shown in Figure 23. The Audits and notifications area in the middle of this display provides a high-level indication of current status and the severity of any problem for a MIMIX installation. Color and the text of the message displayed indicate when problems exist that require immediate

85

attention (yellow) or action (red). When audit information is identified in the message, both options will access the Work with Audits display. The example in Figure 23 shows that attention may be required to prevent an audit from becoming out of compliance. In this example, using option 9 next to the Audits and notifications field will take you to the Compliance view of the Work with Audits display.
Figure 23. MIMIX Availability Status display highlighting a problem with audit compliance

Also, the Work with Data Groups display also provides an indication of the number of audits that require action or attention. Figure 24 shows the Audits/Recov./Notif. fields

86

Working with audits

in the upper right of the display. If more than 999 items exist in any field, the field will display +++.
Figure 24. Work with Data Groups display highlighting audits that require action (red)
CHICAGO 10:49:06 Type options, press Enter. Audits/Recov./Notif.: 015 / 000 /002 5=Display definition 8=Display status 9=Start DG 10=End DG 12=Files not active 13=Objects in error 14=Active objects 15=Planned switch 16=Unplanned switch ... ---------Source----------------Target--------ErrorsOpt Data Group System Mgr DB Obj DA System Mgr DB Obj DB Obj __ TESTDG34 LONDON A A A CHICAGO A A A __ TESTDG43 LONDON A A A CHICAGO A A A Work with Data Groups

F3=Exit F10=Legend

Bottom F5=Refresh F7=Audits F8=Recoveries F9=Automatic refresh F16=DG definitions F23=More options F24=More keys

The first number is the total number of audits that require action to correct a problem or that require your attention to prevent a situation from becoming a problem. The second number indicates the number of active recoveries, including those resulting from audits. The third number indicates the number of new notifications that require action or attention. When the Audits field is highlighted in reverse red, at least one audit has failed, has unresolved differences, or is out of compliance. When highlighted in reverse yellow, at least one out-of-compliance audit is currently active or an audit is approaching out of compliance. For additional information and to work with audits, use either F7 (Audits) or option 57 (Audits) to access the Work with Audits display. For additional information see Working with audits on page 87 and Working with audit compliance on page 98.

Working with audits

Most interaction with audits and their results begin on the Audit Summary window within MIMIX Availability Manager (Figure 25) or the equivalent audit summary view of the Work with Audits display from a 5250 emulator (Figure 26). Audits are sorted and displayed so that the highest severity item is at the top of the list. Note: Certain functions for working with audits may only be available from MIMIX Availability Manager.

87

MIMIX Availability Manager - On the Audit Summary window you can quickly see the status of any audits in progress. The status of audits in progress is reflected with an icon in overall status in the navigation bar and in icons next to audits. When there is no icon present, as in Figure 25, there are no audits in progress and no known problems. When problems exist, the Action required field is highlighted and the audits requiring immediate attention or intervention have icons to draw your attention.
Figure 25. Audit Summary window in MIMIX Availability Manager.In this example, there are no problems with audit status. However, there is an audit compliance problem.

88

Working with audits

5250 emulator - The Summary view of the Work with Audits display (Figure 26) shows audit runtime status and audit results status in the Audit Status column.
Figure 26. Audit Summary View - data group definition view
Work with Audits System: Type options, press Enter 5=Display 6=Print 7=Notification 8=Recoveries 36=Change DG policies 37=Change audit schedule Audit Status *CMPACT *CMPACT *CMPACT *RCYACT *QUEUED *QUEUED *NOTRUN *NODIFF AS01

9=Run rule 10=End 46=Mark recovered Object Differences 0 0 0 0 0 0 0 0

Opt __ __ __ __ __ __ __ __

Rule #DLOATR #FILATR #FILATRMBR #FILDTA #IFSATR #MBRRCDCNT #OBJATR #DGFE

---------Definition--------DG Name System 1 System 2 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02

Bottom Parameters or command ===> _________________________________________________________________________ F3=Exit F4=Prompt F5=Refresh F9=Retrieve F10=Compliance summary F11=View 2 F16=Inst. policies F18=Subset F21=Print list F24=More keys

Note: If audit compliance problems exist, you may see a different view of the Work with Audits display. Use F10 to access the Summary view. Use F11 to view information about policies in effect when the audit was last run. The Last Run column in Figure 27 shows the values of policies in effect at the time the audit was last run through its compare phase. Recovery identifies the value of the automatic audit recovery policy. When this policy is enabled, after the comparison completes, MIMIX automatically starts recovery actions to correct differences detected by the audit. Recovery may also indicate a value of *DISABLED if a condition checked by the Action for running audits (RUNAUDIT) policy existed and the policy value for that condition specified *CMP, preventing audit recoveries from running. Level identifies the value of the audit level policy. The audit level determines

89

the level of checking performed during the compare phase of the audit. If an audit was never run, the value *NONE is displayed in both columns.
Figure 27. Audit Summary View - last run policies view
Work with Audits System: Type options, press Enter 5=Display 6=Print 7=Notification 8=Recoveries 36=Change DG policies 37=Change audit schedule Audit Status *CMPACT *CMPACT *CMPACT *RCYACT *QUEUED *QUEUED *NOTRUN *NODIFF ------Last Recovery *ENABLED *ENABLED *ENABLED *ENABLED *ENABLED *ENABLED *ENABLED *ENABLED AS01

9=Run rule 10=End 46=Mark recovered Object Differences 0 0 0 0 0 0 0 0

Opt __ __ __ __ __ __ __ __

Rule #DLOATR #FILATR #FILATRMBR #FILDTA #IFSATR #MBRRCDCNT #OBJATR #DGFE

DG Name EMP EMP EMP EMP EMP EMP EMP EMP

Run------Level *LEVEL30 *LEVEL30 *LEVEL30 *LEVEL30 *LEVEL30 *LEVEL30 *LEVEL30 *LEVEL30

Bottom Parameters or command ===> _________________________________________________________________________ F3=Exit F4=Prompt F5=Refresh F9=Retrieve F10=Compliance summary F11=View 1 F12=Cancel F13=Repeat F18=Subset F21=Print list

Displaying audit status

You can view audit status from either interface. From MIMIX Availability Manager, do the following: 1. Select the installation you want from the navigation bar. 2. Select Audit Summary from the navigation bar. 3. The Audit Summary window shows all audits for the data groups that are selected for viewing for the installation. Check the following: Icons next to the Rule column indicate overall audit status. The State column indicates the current state of audit activity. The Results column summarizes the result of the last audit.

Click Help to see descriptions of values for these fields and icons. 4. To view additional details, select the Details action and click From a 5250 emulator, do the following: 1. Doing one of the following to access the Summary view of the Work with Audits display: Enter the command: installation-library/WRKAUD VIEW(*AUDSTS) .

90

Working with audits

From the MIMIX Availability Status display, use option 5 (Display details) next to Audits and notifications. Then, if necessary, use F10 to access the Summary view.

2.Check the value shown in the Audit Status column. Press F1 (Help) for a description of status values. 3. To view additional information about an audit, use option 5 (Display).

Running audits immediately

You always have the option of running an audit immediately. You can do this by running the MIMIX rule associated with the audit. In most cases, you want to run the audit from the management system. Policies determine whether a request to run an audit can be performed on the requesting system. From MIMIX Availability Manager, ensure that you have the installation and system you need selected. To run a rule immediately, do the following: 1. Select Audit Summary in the navigation bar. 2. For the audit you want, select the Run action and click .

For more information, see, Resolving audit problems - MIMIX Availability Manager on page 93. From a 5250 emulator, most users should perform these procedures form the management system. To run a rule immediately, do the following: 1. Enter the command: installation-library/WRKAUD 2. Type option 9 (Run rule) next to the audit you want and press Enter. For more information, see, Resolving audit problems - MIMIX Availability Manager on page 93.

Ending audits
Only active or queued audits can be ended. This includes audits with the following statuses: Currently comparing (*CMPACT), Currently recovering (*RCYACT), or Currently waiting to run (*QUEUED). You must end active or queued audits from the system that originated the audit. From MIMIX Availability Manager, you can end active or queued audits from the Audit Summary and Audit Compliance windows as well as from the Audit Details window when viewing an active or queued audit.

91

To end an active or queued audit, do the following: 1. Select Audit Summary or Audit Compliance from the navigation bar. 2. The list in the resulting window shows all audits for data groups selected for viewing for the installation. Check the following: Icons next to the Rule column indicate overall audit status. The State column indicates the current state of audit activity.

Click Help to see descriptions of values for these fields and icons. 3. For the active or queued audit you want, select the End Audit action and click .

4. For queued audits and audits in the compare phase at the time of the request, status is changed to their previous values. Status for audits in the recovery phase is set according to the completed comparison result as well as the results of any completed recovery actions. From a 5250 emulator, you can end active or queued audits from any view of the Work with Audits display. This procedure uses the Status view. To end an active or queued audit, do the following: 1. Enter the command: installation-library/WRKAUD VIEW(*AUDSTS) 2. Check the value shown in the Audit Status column. Press F1 (Help) for a description of status values. 3. Type option 10 (End) next to the active or queued audit you want to end and press Enter. 4. Audits in *CMPACT or *QUEUED status are set back to their previous status values. Audits in *RCYACT status are set according to the completed comparison result as well as the results of any completed recovery actions.

Displaying audit level differences

You can see the differences between audit levels for a MIMIX rule from MIMIX Availability Manager. This capability is not available in a 5250 emulator. 1. Select Audit Summary from the navigation bar. 2. Locate the audit you want. Select the Rule Details action and click .

3. The MIMIX Rule Details window displays the available audit levels. For each audit level, the command used in the compare phase is shown. The Differences column identifies what parameters are different from the command used in the previous audit level.

92

Resolving audit problems - MIMIX Availability Manager

When viewing results of audits, the starting point is the Audit Summary window. You may also need to view the output file or the job log, which are only available from the system where the audits ran. In most cases, this is the management system. Do the following: 1. Ensure that you have selected the management system for the installation you want from the navigation bar. If you are not certain which system is the management system, you can select Services to check. 2. From the management system, select Audit Summary from the navigation bar. 3. In the Audit Summary window, check the State and Results columns for the values shown in Table 11. Audits with potential problems are at the top of the list. 4. For each audit, flyover text for the status icon identifies the appropriate action to take. Table 11 provides additional information.
Table 11. State Rule Failed Addressing audit problems - MIMIX Availability Manager Results (blank) Action Check the job log or run the rule for the audit again. To run the audit, select Run from the action list and click . To see the job log, refer to Checking the job log of an audit on page 96 for more information. Confirm that data group processes are active and run the rule for the audit again. 1. Check the data group status. Select Data Groups from the navigation bar. Then select the data group from the list. 2. In the Summary area, confirm that replication processes are active. If necessary, select the Start action and click . 3. When processes are active, select Summary from the navigation area. 4. Locate the audit in question. Select the Run action and click .

Rule Failed

User journal replication is not active

93

Table 11. State

Addressing audit problems - MIMIX Availability Manager Results Differences detected, recovery disabled Action The detected differences must be manually resolved. Either the Automatic audit recovery policy is disabled or the Action for running audits policy prevented recovery actions while the data group was inactive or had an apply process which exceeded its threshold. To determine the cause, select Notifications from the action list and click . If the Automatic audit recovery policy is disabled, the differences must be manually resolved. If the Action for running audits policy was the cause, correct any problems with the data group status. You may need to start the data group and wait for threshold conditions to clear. Then run the audit again. To manually resolve differences, do the following: 1. Select Output File from the action list and click . 2. The detected differences are displayed. Look for items with a Difference Indicator value of *NC or *NE. You can display details about the error or attempt the possible recovery action available. 3. Select the action you want and click . To have MIMIX recover differences on subsequent audits, change the value of the automatic audit recovery policy. The remaining detected differences must be manually resolved.
Note: For audits using the #MBRRCDCNT rule, automatic recovery is not possible. Other audits, such as #FILDTA, may correct the detected differences.

Completed Successfully

Completed Successfully

Differences detected, some objects not recovered

Do the following: 1. Select Output File from the action list and click . 2. The detected differences are displayed. Look for items with a Difference Indicator value of *NE, *NC, or *RCYFAILED. If automatic audit recovery is disabled, you may see other values as well. For the #MBRRCDCNT results, also look for values of: *HLD, *LCK, *NF1, *NF2, *SJ, *UE, and *UN. You can display details about the error or attempt the possible recovery action available. 3. Select the action you want and click . Not run due to policy (any value) The audit was prevented from running by the Action for running audits policy. Either the data group was inactive or an apply process exceeded its threshold. This may be expected during periods of peak activity or when data group processes have been ended intentionally. However, if the audit is frequently not run due to this policy, action may be needed to resolve the cause of the problem.

For more information about the values displayed in the audit results, see Interpreting audit results - supporting information on page 262.

94

Resolving audit problems - 5250 emulator

When viewing results of audits, the starting point is the Summary view of the Work with Audits display. You may also need to view the output file or the job log, which are only available from the system where the audits ran. In most cases, this is the management system. Do the following from the management system: 1. Do one of the following to access the Work with Audits display. From a command line, enter WRKAUD VIEW(*AUDSTS) From the MIMIX Availability Status display, use option 5 (Display details) next to Audits and notifications. Then, if necessary, use F10 to access the appropriate view.

2. Check the Audit Status column for values shown in Table 12. Audits with potential problems are at the top of the list. Take the action indicated in Table 12.
Table 12. Status *FAILED Addressing audit problems - 5250 emulator Action The audit failed for these possible reasons. Reason 1: The rule called by the audit failed or ended abnormally. To run the rule for the audit again, select option 9 (Run rule). To check the job log, see Checking the job log of an audit on page 96. Reason 2: The #FILDTA audit or the #MBRRCDCNT audit which required replication processes that were not active. 1. From the MIMIX Availability Status display, check whether there are any problems indicated for replication processes. 2. If there are no problems with replication processes, use F20 to access a command line and type WRKAUD. Then skip to Step 6. 3. If there are replication problems, use option 9 (Troubleshoot) next to the Replication activity. 4. On the Work with Data Groups display, if processes for the data group show a red I, L, or P in the Source and Target columns, use option 9 (Start DG). 5. When processes are active, use F7 to view audits. 6. From the Work with Audits display, use option 9 (Run rule) to run the audit.

95

Table 12. Status

Addressing audit problems - 5250 emulator Action The comparison performed by the audit detected differences. No recovery actions were attempted. Either the Automatic audit recovery policy is disabled or the Action for running audits policy prevented recovery actions while the data group was inactive or had an apply process which exceeded its threshold. To determine the cause, use option 7 to view notifications for the audit. A subsetted list of the notifications for the audit appears. If the Automatic audit recovery policy is disabled, the differences must be manually resolved. If the Action for running audits policy was the cause, correct any problems with the data group status. You may need to start the data group and wait for threshold conditions to clear. Then run the audit again. To manually resolve differences, from the notification do the following: 1. Use option 8 to view the results in the output file. 2. Check the Difference Indicator column for values of *NC and *NE. For any of these differences, you will need manually resolve these problems. To have MIMIX recover differences on subsequent audits, change the value of the automatic audit recovery policy. The comparison performed by the audit detected differences. Some of the differences were not automatically recovered. The remaining detected differences must be manually resolved.
Note: For audits using the #MBRRCDCNT rule, automatic recovery is not possible. Other audits, such as #FILDTA, may correct the detected differences.

*DIFFNORCY

*NOTRCVD

Do the following: 1. Use option 7 to view notifications for the audit. 2. A subsetted list of the notifications for the audit appears. Use option 8 to view the results in the output file. 3. Check the Difference Indicator column for values of *NC, *NE, and *RCYFAILED. If automatic audit recovery is disabled, you may see other values as well. For the #MBRRCDCNT results, also look for values of: *HLD, *LCK, *NF1, *NF2, *SJ, *UE, and *UN. For any of these differences, you will need to manually resolve these issues. *NOTRUN The audit was prevented from running by the Action for running audits policy. Either the data group was inactive or an apply process exceeded its threshold. This may be expected during periods of peak activity or when data group processes have been ended intentionally. However, if the audit is frequently not run due to this policy, action may be needed to resolve the cause of the problem.

For more information about the values displayed in the audit results, see Interpreting audit results - supporting information on page 262.

Checking the job log of an audit

An audits job log can provide more information about why an audit failed. If it still exists, the job log is available on the system where the audit ran. Typically, this is the management system.

96

From MIMIX Availability Manager, to check the job log for an audit, do the following: 1. For the audit in question, select the Job logs action and click only available when viewing audits from the sending system. . This choice is

2. The Job Log window opens. Look at the most recent messages to determine the cause of the audit failure. Note: If you see no data available instead, you may still be able to view the job log from the 5250 emulator as described below. From a 5250 emulator, you must display the notifications from an audit in order to view the job log. Do the following: 1. From the Work with Audits display, type 7 (Notification) next to the audit and press Enter. 2. The notifications associated with the audit are displayed on the Work with Notifications display. Use option 5 (Display) or F22 to view the description in the Notification column. 3. If the notification is not sufficient to determine the problem, use option 12 (Display job) next to the notification. 4. The Display Job menu opens. Select option 4 (Display spooled files). Then use option 5 (Display) from the Display Job Spooled Files display. 5. Look for a completion message from the rule with the text indicated from Step 2. Usually the most recent messages are at the bottom of the display.

97

Working with audit compliance

Compliance for an audit determines whether the date of the last successful compare completed by an audit is within the range set by policies. The Audit warning threshold policy and the Audit action threshold policy define when to indicate that an audit is approaching or exceeding that range. Compliance is checked based on the last successful compare date because the benefit of regular auditing comes from checking for differences. MIMIX AutoGuard provides the extra benefit of being able to automatically recover detected differences, but you always have the option of correcting differences manually. MIMIX Availability Manager - Figure 28 shows an example of where audit compliance status appears within MIMIX Availability Manager. Any problems with compliance status are reflected with an icon in overall status in the navigation bar. You can quickly see the compliance status of any audit from the Audit Compliance window. Notice how compliance status is reflected in counts in the summary area of the window and as icons next to audits that have exceeded compliance thresholds Figure 28. The Audit Compliance window also uses icons next to audits to indicate when an audit is in progress.
Figure 28. Audit Compliance window in MIMIX Availability Manager.

5250 emulator - From a 5250 emulator, audit compliance status is reflected in the Audits and notifications row on the MIMIX Availability Status display (Figure 23). You can quickly see whether any audits have reached their compliance policies. The Audits and notifications row is highlighted when any audit reaches its warning or

98

Working with audit compliance

action threshold policy. When a compliance problem exists, this row is highlighted in red or yellow. When audit compliance information is identified in the message, both options will access Compliance view of the Work with Audits display (Figure 29). Note: If other audit problems exist, you may see a different view of the Work with Audits display. Use F10 to access the Compliance view.
Figure 29. Audit Compliance View - data group definition view
Work with Audits System: Type options, press Enter 5=Display 6=Print 7=Notification 8=Recoveries 36=Change DG policies 37=Change audit schedule 9=Run rule AS01 10=End

Opt __ __ __ __ __ __ __ __

Compliance *OK *OK *OK *OK *OK *OK *OK *OK

Rule #DGFE #DLOATR #FILATR #FILATRMBR #FILDTA #IFSATR #MBRRCDCNT #OBJATR

---------Definition--------DB Name System 1 System 2 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02

---Compare End--Date Time 09/25/08 12:15:34 09/25/08 12:15:34 09/25/08 12:15:34 09/25/08 12:15:35 09/25/08 12:15:38 09/25/08 12:15:36 09/25/08 12:15:38 09/25/08 12:15:37

Bottom Parameters or command ===> _________________________________________________________________________ F3=Exit F4=Prompt F5=Refresh F10=Schedule summary F11=View 2 F16=Inst. policies F17=Sort sched. time F18=Subset F24=More keys

99

An audit with a compliance problem must be run to resolve the problem. Use F11 to view when the audits are next scheduled to run (Figure 30).
Figure 30. Audit Compliance View - scheduled time view.
Work with Audits System: Type options, press Enter 5=Display 6=Print 7=Notification 8=Recoveries 36=Change DG policies 37=Change audit schedule 9=Run rule AS01 10=End

Opt __ __ __ __ __ __ __ __

Compliance *OK *OK *OK *OK *OK *OK *OK *OK

Rule #DGFE #DLOATR #FILATR #FILATRMBR #FILDTA #IFSATR #MBRRCDCNT #OBJATR

DG Name EMP EMP EMP EMP EMP EMP EMP EMP

-Scheduled Time-Date Time 09/26/08 02:00:00 09/26/08 02:25:00 09/26/08 02:10:00 09/26/08 02:20:00 09/26/08 02:35:00 09/26/08 02:15:00 09/26/08 02:30:00 09/26/08 02:05:00

---Compare End--Date Time 09/25/08 12:15:34 09/25/08 12:15:34 09/25/08 12:15:34 09/25/08 12:15:35 09/25/08 12:15:38 09/25/08 12:15:36 09/25/08 12:15:38 09/25/08 12:15:37

Bottom Parameters or command ===> _________________________________________________________________________ F3=Exit F4=Prompt F5=Refresh F10=Schedule summary F11=View 2 F16=Inst. policies F17=Sort sched. time F18=Subset F24=More keys

In both views, the list is initially sorted by compliance status. To sort the list by scheduled time, use F17.

Determining whether auditing is within compliance

Regular auditing with MIMIX AutoGuard detects and often repairs problems in the replication environment. Compliance with the best practice of regular auditing is determined for each individual audit based on the date when the audit last completed its compare phase. In both user interfaces, audit compliance problems are identified with a status value or an icon, as follows: (*ATTN) -The audit is approaching an out of compliance state as determined by the Audit warning threshold policy. Attention is required to prevent the audit from becoming out of compliance. (*ACTREQ) - The audit is out of compliance with the Audit action threshold policy. Action is required. Perform an audit of the data group. From MIMIX Availability Manager, do the following to check for compliance problems: 1. Select Compliance from the Details area. A list of audit rules on the system appear, in order of severity. 2. Icons next to the rule name indicate compliance status. Flyover help for the rule name provides information on the compliance status.

100

Working with audit compliance

3. Click on the rule name to display additional details, including compliance information, when the audit last ran successfully, and when it is next scheduled to run. 4. Select the appropriate action and click .

5. To resolve a problem with audit compliance, the audit in question must be run and complete its compare phase. To run the audit now see Running audits immediately on page 91. From a 5250 emulator, do the following to check for compliance problems: 1. Do one of the following to access the Compliance view of the Work with Audits display: Enter the command: installation-library/WRKAUD VIEW(*COMPLY) From the MIMIX Availability Status display, use option 5 (Display details) next to Audits and notifications. Then, if necessary, use F10 to access the Compliance view.

2. Check the Compliance column for values of *ATTN and *ACTREQ. 3. To resolve a problem with audit compliance, the audit in question must be run and complete its compare phase. To see when the audit is next scheduled to run press F11. To run the audit now, see Running audits immediately on page 91.

101

Working with audit schedules

The auditing interfaces support a Schedule view from which you can view the scheduling information for each audit. Note: To see when an audit last ran, see the Compliance view. Figure 31 shows the Audit Schedule window within MIMIX Availability Manager.
Figure 31. Audit Schedule window in MIMIX Availability Manager

Similar information is available from a 5250 emulator on the audit schedule view of the Work with Audits display (Figure 32).

102

Working with audit schedules

Note: The Work with Audits display may open to a different view. Use F10 to access the Schedule view.
Figure 32. Audit Schedule View - scheduled time view
Work with Audits System: Type options, press Enter 5=Display 6=Print 7=Notification 8=Recoveries 36=Change DG policies 37=Change audit schedule ---------Definition--------DG Name System 1 System 2 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02 EMP AS01 AS02 9=Run rule AS01 10=End

Opt __ __ __ __ __ __ __ __

Rule #DGFE #DLOATR #FILATR #FILATRMBR #FILDTA #IFSATR #MBRRCDCNT #OBJATR

Frequency *WEEKLY *WEEKLY *WEEKLY *WEEKLY *WEEKLY *WEEKLY *WEEKLY *WEEKLY

-Scheduled Time-Date Time 09/25/08 02:00:00 09/25/08 02:25:00 09/25/08 02:10:00 09/25/08 02:20:00 09/25/08 02:35:00 09/25/08 02:15:00 09/25/08 02:30:00 09/25/08 02:05:00

Bottom Parameters or command ===> _________________________________________________________________________ F3=Exit F4=Prompt F5=Refresh F10=Audit summary F11=View 2 F17=Sort sched. time F18=Subset F21=Print list F24=More keys

View 1 shows the date and time of the next scheduled audit. Use F11 to view the settings in the Schedule policy.
Figure 33. Audit Schedule View - schedule policy values
Work with Audits System: Type options, press Enter 5=Display 6=Print 7=Notification 8=Recoveries 36=Change DG policies 37=Change audit schedule 9=Run rule AS01 10=End

Opt __ __ __ __ __ __ __ __

Rule #DGFE #DLOATR #FILATR #FILATRMBR #FILDTA #IFSATR #MBRRCDCNT #OBJATR

DG Name EMP EMP EMP EMP EMP EMP EMP EMP

Frequency *WEEKLY *WEEKLY *WEEKLY *WEEKLY *WEEKLY *WEEKLY *WEEKLY *WEEKLY

Date *NONE *NONE *NONE *NONE *NONE *NONE *NONE *NONE

Weekday SMTWTFS SMTWTFS SMTWTFS SMTWTFS SMTWTFS SMTWTFS SMTWTFS SMTWTFS SMTWTFS

Rel.Day 12345L

Time 02:00:00 02:25:00 02:10:00 02:20:00 02:35:00 02:15:00 02:30:00 02:05:00

Bottom Parameters or command ===> _________________________________________________________________________ F3=Exit F4=Prompt F5=Refresh F10=Audit summary F11=View 1 F17=Sort sched. time F18=Subset F21=Print list F24=More keys

In both views, the list is initially sorted by rule and data group name.To sort the list by scheduled time, use F17.

103

How audits are scheduled automatically

The MIMIX rules used by auditing functions are shipped with default scheduling information that MIMIX will use to automatically schedule audit requests. When you use the Start MIMIX (STRMMX) command, the command starts all the MIMIX processes and functions needed for replication and for auditing, including system managers, data groups, and the master monitor. The master monitor will start job scheduling activities for auditing.This ensures that your MIMIX rules run on a regularly scheduled basis. Alternatively, if you start replication with the Start Data Group (STRDG) command, you also need to use the Start Master Monitor (STRMSTMON) command from all systems in your installation. For each audit, a job is initiated on both systems specified in the data group. When the scheduled time occurs, MIMIX uses the Run rule on system policy to determine where the audit should run and immediately ends the audit which is not on the appropriate system.

Shipped default audit schedules

A default schedule is shipped for each MIMIX rule (Table 13). All audits of all data groups that are performed with a specific rule will use that rules default schedule unless you take explicit action to change the scheduling of that rule for a specific data group. Shipped values for audits result in running all audits daily. The audit start times are staggered, beginning at 2 a.m., as shown in Table 13. It is recommended that you keep the same order and staggered timing as shown in Table 13 and that you allow MIMIX to run all audits even if you do not replicate certain object types (such as DLOs). This ensures that if you add new objects in the future, you will be automatically auditing them. Audits that do not have any objects to check complete quickly with little use of system resources.
Table 13. Shipped Schedule 2:00 a.m. daily Shipped MIMIX rules and schedule for corresponding shipped audit monitor Rule Name #DGFE Description Checks configuration for files using cooperative processing. Uses the Check Data Group File Entries (CHKDGFE) command. Compares all attributes for all object types supported for replication. Uses the Compare Object Attributes (CMPOBJA) command Compares all file attributes. Uses the Compare File Attributes (CMPFILA) command. Job Name sdn_DGFE

2:05 a.m. daily

#OBJATR

sdn_OBJATR

2:10 a.m. daily

#FILATR

sdn_FILATR

104

Working with audit schedules

Table 13. Shipped Schedule

Shipped MIMIX rules and schedule for corresponding shipped audit monitor Rule Name #IFSATR Description Compares IFS attributes. Uses the Compare IFS Attributes (CMPIFSA) command. Compares basic file attributes at the member level. Uses the Compare File Attributes (CMPFILA) command. Compares all DLO attributes. Uses the Compare DLO Attributes (CMPDLOA) command. Compares the number of current records (*CURRDS) and the number of deleted records (*NBRDLTRCDS) for physical files that are defined to an active data group. Uses the Compare Record Counts (CMPRCDCNT) command.
Note: Equal record counts suggest but do not guarantee that files are synchronized. This audit does not have a recovery phase. Differences detected by this audit appear as not recovered in the Audit Summary.

Job Name sdn_IFSATR

2:15 a.m. daily

2:20 a.m. daily

#FILATRMBR

sdn_MBRATR

2:25 a.m. daily

#DLOATR

sdn_DLOATR

2:30 a.m daily

#MBRRCDCNT

sdn_RCDCNT

2:35 a.m. daily

#FILDTA1

Compares file contents. Uses the Compare File Data (CMPFILDTA) command.

sdn_FILDTA

1.

The #FILDTA audit, and the Compare File Data (CMPFILDTA) command require TCP/IP communications.

Considerations for changing audit scheduling

Audit schedules are set for each data group through the Set MIMIX Policies (SETMMXPCY) command. Each audit is a combination of a MIMIX rule and data group and has its own schedule. You can vary the times at which an individual audit runs by adjusting its scheduling information. For example, you may want to change the default audit time or stagger intervals in the following circumstances: If other jobs are running that could lock files needing to be accessed during recovery If scheduled time conflicts with regularly scheduled backups If there are a large number of objects to be compared If there are a large number of objects for which a rule is expected to attempt recovery

Note: While you may decide to vary the scheduled times, it is recommended that you always run all audits every day and maintain the same order shown in Table 13.

105

When to run the #DGFE audit

In addition to regularly scheduled audits, there are times when you should check your configuration using the #DGFE audits for your data groups. The #DGFE audit or the CHKDGFE command should be run whenever you make configuration changes, such as adding an application or creating a library. Running the rule or command prior to the Compare Attribute commands ensures that the Compare Attribute commands compare the objects and attributes you expect to be present in your environment. The #DGFE audit (or the CHKDGFE command) should be run during periods of minimal MIMIX activity to ensure that replication is caught up and that added or deleted objects are reflected correctly in the journal. If the command is run during peak activity, it may contain errors or indicate that files are in transition.

Changing when audits are scheduled

A change to an audits schedule is effective immediately. If an audit is in progress at the time its schedule is changed, the change is effective on the next scheduled run of the audit. From MIMIX Availability Manager, do the following: 1. Ensure that you have selected the management system for the installation you want from the navigation bar. If you are not certain which system is the management system, you can select Services to check. 2. From the management system, select Schedule from the Details area on the navigation bar. Select the Change Schedule action and click . 3. The Set MIMIX Policies window opens, showing the current policy values for the selected audit rule and data group. Specify the values you want and click OK. From a 5250 emulator, do the following from the management system: 1. Do one of the following to access the Schedule view of the Work with Audits display: Enter the command:
installation-library/WRKAUD VIEW(*SCHEDULE)

From the MIMIX Availability Status display, use option 5 (Display details) next to Audits and notifications. Then, if necessary, use F10 to access the Schedule view.

2. Type 37 (Change audit schedule) next to the audit you want to change and press Enter. 3. The Set MIMIX Policies (SETMMXPCY) command appears, showing the current policy values for the selected audit rule and data group. Specify the values you want and press Enter.

106

Working with audit schedules

Schedule parameter notes

In order to be scheduled, a value other than *NONE must be specified for Frequency, and values must be specified for Scheduled time and either Scheduled date or Scheduled day. Frequency is qualified by the values specified in the other elements. Scheduled dates are entered and displayed in job date format. When the job date format is Julian, the equivalent month and day are used to determine when to schedule audit requests. Frequency - Specify how often the audit request is submitted. Scheduled date - Select a value or specify a date, in job date format, on which the audit request is submitted. Scheduled day -Select the day or days of the week on which the audit request is submitted. If today is the day of the week that is specified and the scheduled time has not passed, the audit request is submitted today. Otherwise, the job is submitted on the next occurrence of the specified day. For example, if it is 11:00 a.m. on a Friday when you set the audit schedule to specify Friday for Scheduled day and 12:00:00 for Scheduled time, the audit request is submitted today. If you are setting the policy at 4:00 p.m. on a Friday or at 11:00 a.m. on a Monday, the audit request is submitted the following Friday. Scheduled time - Select a value or specify a time in 24-hour format at which the audit request is submitted on the scheduled date or day. Although the time can be specified to the second, the activity involved in submitting a job and the load on the system may affect the exact time at which the job is submitted. Time can be specified with or without a time separator. Without a time separator, specify a string of 4 or 6 digits (hhmm or hhmmss) where hh = hours, mm = minutes, and ss = seconds. Valid values for hh range from 00 to 23. Valid values for mm and ss range from 00 to 59. With a time separator, specify a string of 5 or 8 digits where the time separator specified for your job is used to separate the hours, minutes, and seconds. If this command is entered from the command line, the string must be enclosed in apostrophes. If a time separator other than the separator specified for your job is used, this command will fail. Relative day of month - Select a value or specify one or more numbers with which to qualify what day a monthly audit request is submitted, relative to its occurrence in the month. A relative day is only valid when the schedule Frequency is Monthly and Scheduled day is a value other than None. For example, if Frequency is Monthly, Scheduled day is Tuesday and Thursday, and Relative day of month is 1, the audit request is submitted on the first Tuesday and first Thursday of every month. If both 1 and 4 are specified for relative day, the audit request is submitted on the first Tuesday, first Thursday, fourth Tuesday, and fourth Thursday of the month.

107

Changing the system where audits are performed

Note: This procedure changes a policy value at the installation level. The installation level value can be overridden by a data group level policy value. Therefore, if a data group has value other than *INST for this policy, that value remains in effect. The Run rule on system policy determines the system on which audits run. The shipped default is to run all audits for the installation from the management system. To change the policy for the installation, do the following 1. On the management system type the following command and press F4 (Prompt) installation-library/SETMMXPCY 2. Verify that the value *INST appears for the Data group definition. 3. Locate the Run rule on system policy. Specify the value you want. 4. Press Enter.

Considerations for using a different job scheduler for audits

If you do not want to use the job scheduling capabilities within MIMIX to schedule audits, you need to ensure that all of the MIMIX rules are scheduled to run on a regular basis using your preferred scheduling mechanism. It is recommended that you do the following: Schedule the audits to run from the management system. Schedule all audits to run every day in the same order shown in Table 13. Specify the same Run Rule command that is visible when you display the rule details for an audit. This information is available when you use the Rule Details action for an audit in MIMIX Availability Manager. Address starting and ending the scheduling jobs in your operations at points where you need to start or end MIMIX. The Start MIMIX (STRMMX) and End MIMIX (ENDMMX) commands only address audits scheduled by MIMIX. Put appropriate checks in place to prevent scheduled jobs from starting when MIMIX would otherwise need to be ended (such as during installation). Disable MIMIX scheduling for all audits. Specify *NONE for the Frequency value in the audit schedule policy of every audit.

108

Policies for auditing

Policies for auditing

Table 14 identifies the policies used by audits and their shipped default values. When the Set MIMIX Policies command specifies a data group definition value of *INST the policies being changed are effective for all data groups in the installation, unless a data group-level override exists. When the data group definition specifies a name, policies which specify the value *INST inherit their value from the installationlevel policy value and polices which specify other values are in effect for only the specified data group. The Audit rule and Audit schedule policies do not have a shipped value for the installation level. At the data group level, each shipped MIMIX rule has a default schedule. For more information, see Shipped default audit schedules on page 104.

Table 14. Policy

How policies correlate to function Shipped Values Installation Data Groups Name Varies by rule *INST *INST *INST *INST *INST *INST *INST *INST *INST *INST *INST *INST *INST *INST *INST Yes Yes Yes Yes2 Yes2 Yes Yes Yes *NONE *NONE 9,999,999 Yes Yes Yes Yes Yes Yes Yes *CHGOBJ *NOCHG *END 1440 7 14 *LEVEL30 *MGT Auditing

Data group definition Audit rule Automatic audit recovery Audit notify on success Notification severity Object only on target action Journal attribute differences action1 MIMIX configured higher MIMIX configured lower User journal apply threshold action Maximum rule runtime Audit warning threshold Audit action threshold Audit level Run rule on system Action for running audits1 Inactive data group Apply in threshold Synchronize threshold size

*INST *ENABLED *RULE *RULE *DISABLED

109

Table 14. Policy

How policies correlate to function Shipped Values Installation Data Groups *INST *WEEKLY *NONE *ALL Varies by rule Yes Yes Auditing

CMPRCDCNT commit threshold3 Audit schedule Frequency Scheduled date Scheduled day Scheduled time Relative day of month
1. 2. 3.

*NOMAX

Users will see this policy only on systems running version 5 service pack 5.0.06.00 or higher. These policies are not limited to recovery actions. Users will see this policy only on systems running version 5 service pack 5.0.14.00 or higher.

Preventing audits from running

Scenarios in which you may want to prevent audits from running include the following: You may want to control when audits are allowed to run based on the state of the data group at the time of the audit request. For example, if you end MIMIX so that a batch process can run, you may want to prevent audits from running while data groups are inactive. If a data group has a backlog during peak activity, you may want to prevent audits from running while the backlog exists. Or, you may want to prevent only automatic recovery from occurring during a backlog or when the data group is inactive. The Action for running audits policy1 provides the ability to define what audit activity will be permitted based on the state of the data group at the time of audit request. This policy can be set for an installation or for a specific data group. There may be scenarios when you need to disable auditing completely for either an installation or a specific data group. The Audit level policy can be used disable auditing by preventing audit comparisons from ever occurring. By default, audits are automatically scheduled to run daily. However, there may be times when automatic audit scheduling is not desirable, such as on a test data group or during system or network maintenance. When you need to prevent the automatic scheduling from occurring, you can do so for specific audits at the data group level by specifying *NONE for the frequency value in the Audit schedule policy.

To restrict audit activity in an installation based on data group state

Note: This procedure changes a policy value at the installation level. The installation level value can be overridden by a data group level policy value. Therefore, if

1. The Action for running audits policy is available on systems running version 5 service pack 5.0.06.00 or higher. Systems running earlier software levels will perform audits regardless of the data group state.

110

Policies for auditing

a data group has value other than *INST for this policy, that value remains in effect. From MIMIX Availability Manager, the action to change installation policies is only available when the system you are viewing is the management system. Do the following: 1. Ensure that you have the management system selected in the navigation bar. If you are not certain which system is the management system, you can select Services to check. 2. Select Data Groups from the navigation bar. At the top of the window, select the Change Installation Policies action and click . 3. You will see Installation Policy near the top of the window. The current values of policies are displayed. For Action for running audits, do the following: a. Select the value for Inactive data group that indicates the audit actions to permit when the data group is inactive. b. Select the value for Apply in threshold that indicates the audit actions to permit when an apply session reaches its configured warning threshold. 4. To accept the changes, click OK. From a 5250 emulator, do the following from the management system: 1. From the command line type SETMMXPCY and press F4 (Prompt). 2. Verify that the value specified for Data group definition is *INST. 3. Press Enter to see all the policies and their current values. 4. For Action for running audits, do the following: a. Specify the value you want for Inactive data group that indicates the audit actions to permit when the data group is inactive b. Specify the value you want for Apply in threshold that indicates the audit actions to permit when an apply session reaches its configured warning threshold. 5. To accept the changes, press Enter.

To restrict audit activity for a specific data group based on its state
From MIMIX Availability Manager, the action to change policies for a data group is only available when the system you are viewing is the management system. Do the following: 1. Ensure that you have the management system selected in the navigation bar. If you are not certain which system is the management system, you can select Services to check. 2. Select Data Groups from the navigation bar. 3. From the Data Group Status window, select the data group you want from the list. 4. From the Summary area of the display, select the Change Policies action and click .

111

5. The selected data group is listed near the top of the window and current values of its policies are displayed. For Action for running audits, do the following: a. Select the value for Inactive data group that indicates the audit actions to permit when the data group is inactive. b. Select the value for Apply in threshold that indicates the audit actions to permit when an apply session reaches its configured warning threshold. 6. To accept the changes, click OK. From a 5250 emulator, do the following from the management system: 1. From the command line type SETMMXPCY and press F4 (Prompt). 2. For the Data group definition, specify the full three-part name. 3. Press Enter to see all the policies and their current values. 4. For Action for running audits, do the following: a. Specify the value you want for Inactive data group that indicates the audit actions to permit when the data group is inactive b. Specify the value you want for Apply in threshold that indicates the audit actions to permit when an apply session reaches its configured warning threshold. 5. To accept the changes, press Enter.

To disable auditing for an installation

Note: This procedure changes a policy value at the installation level. The installation level value can be overridden by a data group level policy value. Therefore, if a data group has value other than *INST for this policy, that value remains in effect. From MIMIX Availability Manager, the action to change installation policies is only available when the system you are viewing is the management system. Do the following: 1. Ensure that you have the management system selected in the navigation bar. If you are not certain which system is the management system, you can select Services to check. 2. Select Data Groups from the navigation bar. At the top of the window, select the Change Installation Policies action and click . 3. Verify that Installation Policy appears near the top of the window. If you see a list of data groups, close the window and start again.

4. For Audit level, select Disable. 5. For Automatic audit recovery, select Disable. 6. To accept the changes, click OK. From a 5250 emulator, do the following from the management system: 1. From the command line type SETMMXPCY and press F4 (Prompt).

112

Policies for auditing

2. Verify that the value specified for Data group definition is *INST. 3. Press Enter to see all the policies and their current values. 4. Specify *DISABLED for the Audit level policy. 5. To accept the changes, press Enter.

To disable auditing for a data group

From MIMIX Availability Manager, the action to change policies for a data group is only available when the system you are viewing is the management system. Do the following: 1. Ensure that you have the management system selected in the navigation bar. If you are not certain which system is the management system, you can select Services to check. 2. Select Data Groups from the navigation bar. 3. From the Data Group Status window, select the data group you want from the list. 4. From the Summary area of the display, select the Change Policies action and click . 5. Verify that expected data group is listed near the top of the window. If you see Installation Policy, close the window and start again. 6. For Audit level, select Disable. 7. To accept the changes, click OK. From a 5250 emulator, do the following from the management system: 1. From the command line type SETMMXPCY and press F4 (Prompt). 2. For the Data group definition, specify the full three-part name. 3. Press Enter to see all the policies and their current values. 4. Specify *DISABLED for the Audit level policy. 5. To accept the changes, press Enter.

To disable automatic scheduling of an audit

Each unique audit, identified by a MIMIX rule and a data group, has its own audit schedule. From MIMIX Availability Manager, the action to change an audit schedule is only available when the system you are viewing is the management system. Do the following: 1. Ensure that you have the management system selected in the navigation bar. If you are not certain which system is the management system, you can select Services to check. 2. Select Schedule from the navigation bar. 3. From the Audit Schedule window, locate the audit you want in the list and select

113

the Change Schedule action and click

4. Verify that expected data group and rule are listed near the top of the window. If not, close the window and start again. 5. For Frequency, select None. 6. To accept the changes, click OK. From a 5250 emulator, do the following from the management system: 1. From the command line type SETMMXPCY and press F4 (Prompt). 2. For the Data group definition, specify the full three-part name. 3. For Audit rule, specify the name of the MIMIX rule. 4. Press Enter to see the current values for the Audit schedule policy. 5. Specify *NONE for the Frequency prompt. 6. To accept the changes, press Enter.

114

Running rules and rule groups manually

Running rules and rule groups manually

User interfaces for auditing provide options to run audits which invoke the Run Rule (RUNRULE) command. There may be times when you may need to run the RUNRULE or the Run Rule Group (RUNRULEGRP) command manually. One example is to run user-defined rules. From within MIMIX Availability Manager, actions to run rules are available from a variety of locations. From a 5250 emulator, you can run the RUNRULE and RUNRULEGRP commands by typing them on a command line. Any notifications or recoveries that result from the rule are displayed in the user interface. Notes: Before running rules, you should be familiar with the information in Requirements for using audits and rules on page 81, Guidelines and recommendations for auditing on page 81, and Considerations and recommendations for rules on page 82. You can verify that your rules are running by checking the message log available from the notifications interface.

Running rules or rule groups from within MIMIX Availability Manager

From within MIMIX Availability Manager, you can run individual rules or rule groups from the Data Groups window or from the Rules window. The Command history window opens after the rule is submitted, if permitted by your general preferences settings.

Running rules or rule groups from the Rules window

Use this procedure to manually run a user-defined rule. Although you can also run a MIMIX rule to perform an audit from this window, using the Audit windows is preferred. Do the following: 1. From the navigation bar, select the System and Installation on which you want to run the rule. Then select Rules. 2. Locate the rule or rule group you want in the list displayed. If necessary, use the Filter to select the type of rules or rule groups to display. For the rule you want, select the Run action and click . 3. A new window opens with the rule or rule group preselected. Select the options you want for this rule or rule group. Select the data group that the rule will run against. 4. Select values for the remaining options. Click Help to see detailed information about possible values for each option. a. Select the severity assigned to the notification that is sent if the rule ends in error. This value overrides values specified in policies or in the rule itself.

115

b. Select whether to send an informational notification when the rule completes successfully. This value overrides values specified in policies or in the rule itself. c. Select whether the rule should use the policy in effect to determine the system on which it will run. This value is only used when a data group is selected. d. Select a value or specify the name and library of the job description used to submit the request for batch jobs. Default values are to use the first MXAUDIT job description found in the library list. 5. To run the rule or rule group, click OK.

Running rules or rule groups from the Data Groups window

Use this procedure to manually run a user-defined rule. Although you can also run a MIMIX rule to perform an audit from this window, using the Audit windows is preferred. Do the following: 1. From the navigation bar, select the System and Installation on which you want to run the rule. Then select Data Groups. 2. Select the data group you want from the list in the Data Group Status window. 3. In the Summary area, select the Run Rules or Run Rule Group action and click . 4. A new window opens. There are two lists of rules or rule groups. The left-hand list identifies the rules or groups to run. The right-hand list contains all the available rules or groups. Use the Add or Remove buttons to adjust your selection. 5. Select values for the remaining options. Click Help to see detailed information about possible values for each option. a. Select the severity assigned to the notification that is sent if the rule ends in error. This value overrides values specified in policies or in the rule itself. b. Select whether to send an informational notification when the rule completes successfully. This value overrides values specified in policies or in the rule itself. c. Select whether the rule should use the policy in effect to determine the system on which it will run. This value is only used when a data group is selected. d. Select a value or specify the name and library of the job description used to submit the request for batch jobs. Default values are to use the first MXAUDIT job description found in the library list. 6. To run the rule or rule group, click OK.

Running rules from the 5250 emulator

This procedure outlines the steps required to run a rule manually from the 5250 emulator.

116

Running rules and rule groups manually

Typically, this procedure should be performed from the system and installation where you wan the rule to run. Do the following: 1. On a command line, type RUNRULE and press F4 (Prompt). The Run Rule (RUNRULE) display appears. 2. At the Rule name prompt, specify the rule names for the rules you want to run. You can specify up to 100 rules to run from the command. 3. At the Data group definition prompt, specify the value you want. The default is *NONE, but you can specify that rules be run against an individual data group or all data groups. 4. Press F10 for additional parameters. 5. At the Notification severity prompt, specify the severity level to assign to the notification that is sent if the rule ends in error. This value overrides values specified in policies or in the rule itself. For a MIMIX rule, the default value *DFT is the same as the value *POLICY, where the Notification severity policy in effect determines the severity of the notification. For a user rule, *DFT is the same as the value *RULE, where the rule determines the severity of the notification. 6. At the Notification on success prompt, specify whether you want the rule to generate a notification when the specified rule ends successfully. This value overrides values specified in policies or in the rule itself. For a MIMIX rule, the default value *DFT is the same as *POLICY, where the Audit notify on success policy in effect determines whether a notification is sent. If the policy is set for both the installation and for the data group, the data group value is used. For a user rule, *DFT is the same as the value *RULE, where the value specified in the rule determines whether a notification is sent. 7. At the Use run rule on system policy prompt, specify whether the rule should use the policy in effect when run.This value is only used when a data group is selected. The default value *NO will run the rule on the local system. 8. At the Job description and Library prompts, specify the name and library of the job description used to submit the batch request. The default value, MXAUDIT, submits the request using the default job description, MXAUDIT. 9. To run the rule, press Enter.

Running rule groups from the 5250 emulator

This procedure outlines the steps required to run a rule group manually from the 5250 emulator. Do the following: 1. On a command line, type RUNRULEGRP and press F4 (Prompt). The Run Rule Group (RUNRULEGRP) display appears. 2. At the Rule group name prompt, specify the rule group name for the rule group you want to run. You can only run individual rule groups. 3. At the Data group definition prompt, specify the value you want. The default is *NONE, but you can specify that rule groups be run against an individual data

117

group or all data groups. 4. Press F10 for additional parameters. 5. At the Notification severity prompt, specify the severity level to assign to the notification that is sent if a rule in the group ends in error. This value overrides values specified in policies or in the rule itself. For a MIMIX rule group, the default value *DFT is the same as the value *POLICY, where the Notification severity policy in effect determines the severity of the notification. For a user rule, *DFT is the same as the value *RULE, where the rule determines the severity of the notification. 6. At the Notification on success prompt, specify whether you want the rule to generate a notification when the specified rules end successfully. This value overrides values specified in policies or in the rule itself. For a MIMIX rule, the default value *DFT is the same as *POLICY, where the Audit notify on success policy in effect determines whether a notification is sent. If the policy is set for both the installation and for the data group, the data group value is used. For a user rule, *DFT is the same as the value *RULE, where the value specified in the rule determines whether a notification is sent. 7. At the Use run rule on system policy prompt, specify whether each rule should use the policy in effect when run.This value is only used when a data group is selected. The default value *NO will run the rule on the local system. 8. At the Job description and Library prompts, specify the name and library of the job description used to submit the batch request. The default value, MXAUDIT, submits the request using the default job description, MXAUDIT. 9. To run the rule group, press Enter.

Checking results of a user-defined rule

These procedures will display the results of a user-defined rule. The output type and report type are determined by what is specified in the rule itself. From MIMIX Availability Manager, do the following: 1. From the navigation bar, select the System and Installation on which you ran the rule. Then select Notifications. 2. Look for a new notification which identifies your user-defined rule as its Source. Select the Output File action and click . 3. The results of the comparison for a user-defined rule are displayed in a new window. From a 5250 emulator, do the following: 1. From the system on which the rule ran, enter the following command: installation_library/WRKNFY 2. Look for a new notification which identifies your user-defined rule as its Source. Type 8 (View results) next to the notification and press Enter.

118

What are notifications and recoveries

CHAPTER 4

Working with notifications and recoveries

This topic describes what notifications and recoveries are and how to work with them. This chapter includes the following topics: What are notifications and recoveries on page 119 defines terms used for discussing notifications and recoveries and identifies the sources that create them. Displaying notifications on page 120 identifies where notifications are viewed in the user interfaces and how to work with them. Notifications for newly created objects on page 124 describes the MIMIX AutoNotify feature which can be used to monitor for newly created libraries, folders, or directories. Displaying recoveries on page 125 identifies where recoveries in progress are viewed in the user interfaces and how to work with them.

What are notifications and recoveries

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: MIMIX AutoGuard generates notifications as a secondary mechanism for reporting when the activities performed by MIMIX AutoGuard 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 MIMIX AutoGuard. Rules that are not associated with the audits provided by MIMIX AutoGuard also generate notifications. Rule processing generates notifications to indicate that processing either ended in error or, if requested, completed successfully. Shipped monitors, such as the MMNFYNEWE monitor for the MIMIX AutoNotify feature, generate notifications. 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.

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

119

Working with notifications and recoveries

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 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. 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.

Displaying notifications
You can check for notifications from either user interface. Note: Notifications from audits are automatically set to a status of acknowledged. Audit status and results should be checked from the Audit Summary window or the Work with Audits (WRKAUD) display. From MIMIX Availability Manager, if there are any new notifications, an icon appears next to the Notifications item in the Details area of the navigation bar. To see a list of notifications or select a notification to view, do the following: 1. Select Notifications from the Details area in the navigation bar. 2. The upper right corner of the Notifications window contains fields showing the number of new and acknowledged notifications for the installation and system you are viewing. 3. Below the toolbar, the notifications are separated into two lists, New and Acknowledged. Expand or collapse the lists as needed. 4. To see details for a notification, select the Display Details action and click From a 5250 emulator, do one of the following: If there are no audit problems in the installation, the MIMIX Availability Status display will indicate whether there are any notifications requiring attention or immediate action that are from sources other than audits. From the MIMIX Availability Status display, type a 5 (Display details) next to Audits and notifications and press Enter. Notifications from all sources are listed on the Work with Notifications display. To access the Work with Notifications display, enter the command WRKNFY. The list is sorted so that new notifications appear at the top. To see details for a notification, type a 5 (Display) next to the notification you want and press Enter. The Work with Data Groups display includes the number of new notifications that require action or attention. From the MIMIX Availability Status display, type 5 (Display details) next to Replication. The Work with Data Groups display appears. The Audit/Recov./Notif. fields are located in the upper right corner. .

120

Displaying notifications

What information is available for notifications

While the presentation within each user interface varies, the following information is available for notifications in the Notifications window (MIMIX Availability Manager) and the Work with Notifications display (5250 emulator). Additional details are available for each notification through the Notification Details window and the Display Notification Details display. Where differences in field or column labels exist, the term used in MIMIX Availability Manager is listed first. Status - The Notifications window and the Work with Notifications display both show lists of notifications, grouped by their status. New notifications have not been acknowledged or removed and their status is reflected in higher level status. Acknowledged notifications are archived as viewed and their status is no longer reflected in higher level status. Severity - Identifies the severity level of the notification. Icons are shown only in MIMIX Availability Manager. The icon shown in the navigation bar represents the highest severity notification present with a status of New. Error - Requires immediate action. Warning - Investigation may be necessary. For example, the MIMIX AutoNotify feature issues notifications with this severity that identify newly created objects that are not identified for replication. Information - No user intervention is required. Notification - Displays the notification text sent by MIMIX AutoGuard audits and automatic recoveries, monitors, user-defined or MIMIX rules, or a user-generated notification. Data group - Identifies the data group associated with the notification. User-defined notifications and notifications from monitors or user-defined rules may indicate that there is no associated data group. In MIMIX Availability Manager, preferences determine whether the three-part name of the data group is displayed. On the Status view of the Work with Notifications display, the F7 key toggles between the Source column and the Data Group column. The full three-part name is available in the Timestamp view (F11). Date - Indicates the date the notification was sent. Time - Indicates the time the notification was sent. Source - Identifies the process, program, command, or monitor that generated the notification. Names that begin with the character # are generated by a MIMIX rule. Names that begin with the characters ## are generated by an automatic recovery action performed within a replication process. Sender or From System - Identifies the name of the system on which the notification was generated. The name From System is used on the Timestamp view (F11) of the Work with Notifications display. When you display the notification details from the 5250 emulator, this is called the Originating system.

121

Working with notifications and recoveries

Detailed information
When you display a notification, you see its description, status, severity, data group, source, and sender as described above. You also have access to the following information: Details - When the source of the notification is a rule, this identifies the command that was initiated by the rule. When the source of the notification is user-generated, this indicates the notification detail text specified when the notification entry was added. When the source of the notification is a monitor, this describes the events that resulted in the notification. Output File - If available, this identifies an associated output file. Output file information associated with a notification is only available from the sender system. For user-generated notifications, output file information is available only if it was specified when the notification was added. Job - If available, this identifies the job that generated the notification. Job information associated with a notification is only available from the sender system. For usergenerated notifications, this information is available only if it was specified when the notification was added.

Options for working with notifications

Table 15 identifies the possible actions you can take for a notification. From the Notifications window, the Actions list for each notification contains only the actions possible for the selected notification.
Table 15. Options available for notifications WRKNFY Option 4=Remove Description Deletes the notification. You are prompted to confirm this choice. For a notification generated by an audit or a MIMIX rule, the associated job and output files are also deleted. This must be performed from the system on which the notification originated. Displays available additional information associated with the notification. Prints the information associated with the notification. Print support in MIMIX Availability Manager is provided by the browser. When the information is available, this provides the Name and Library of the output file (outfile) associated with the notification. This option is only available from the system on which the notification originated.2 Displays the job log for the job which generated the notification, if it is available. This option is only available from the system on which the notification originated

Notifications Window Action Delete

Display Details

5=Display 6=Print

Output File1

8=View results

Job Log1

12=Display job

122

Displaying notifications

Table 15.

Options available for notifications WRKNFY Option 46=Acknowledge 47=Mark as new Description Sets the selected notification status to *ACK (Acknowledged). Sets the selected notification status to *NEW (New). Displays details of the rule that generated the notification, including the substitution variables for the command the rule initiated. This action is only available for notifications generated by a rule.

Notifications Window Action Acknowledge Mark as New Rule Details1

1. 2.

This action may also be available for a notification from the Notification Details window. MIMIX manages an output file associated with a notification from an automatically recovery action or a MIMIX rule when the output file exists in a specific library. The format of the library name for such an output file is MIMIX-installation-library_0.

123

Notifications for newly created objects

The MIMIX AutoNotify feature can be used to monitor for newly created libraries, folders, or directories. The AutoNotify feature uses a shipped journal monitor called MMNFYNEWE to monitor for new objects in an installation that are not already included or excluded for replication by a data group. The AutoNotify feature monitors the security audit journal (QAUDJRN), and when new objects are detected, issues a warning notification. The MMNFYNEWE monitor is shipped in a disabled state. In order to use this feature, the MMNFYNEWE monitor must be enabled on the source system within your MIMIX environment. Once enabled, this monitor will automatically start with the master monitor. Notifications will be sent when newly created objects meet the following conditions: The installation must have a data group configured whose source system is the system the monitor is running on. The journal entry must be a create object (T-CO) or object management change (T-OM). If the journal entry is a create object (T-CO), then the type must be new (N). The journal entry must be for a library, folder, or directory. If the journal entry is for a library, it cannot be a MIMIX generated library since MIMIX generated libraries are not replicated by MIMIX. If the journal entry is for a directory, it cannot be the /LAKEVIEWTECH directory, or any directory under /LAKEVIEWTECH. If the journal entry is for a directory, it must be a directory that is supported for replication by MIMIX. The object is not already known (included or excluded) in the installation. Notifications can be viewed through the MIMIX Availability Manager and the Work with Notifications (WRKNFY) display on a 5250 emulator. The notification message will indicate required actions.

124

Displaying recoveries

Displaying recoveries
Active recoveries are an indication of problems detected and being corrected by MIMIX AutoGuard. Before certain activity, such as ending MIMIX, it is important that no recoveries are in progress in the installation. You can check for recoveries from either user interface. From MIMIX Availability Manager, if there are any recoveries in progress, an icon appears next to the Recoveries item in the Details area of the navigation bar. Recoveries are automatically generated and removed by a recovery action initiated by automatic functions within replication processes and audits. To see a list of recoveries or select a recovery to view, do the following: 1. Select Recoveries from the Details area in the navigation bar. 2. The upper right corner of the Recoveries window contains fields showing the number of active and held recoveries for the installation and system you are viewing. 3. To see details for a recovery, select the Display Details action and click .

From a 5250 emulator, you can see how many recoveries are in progress from the MIMIX Availability Status display or the Work with Data Groups display. The Work with Recoveries display lists recoveries and provides options for working with held recoveries associated with an audit or a MIMIX rule. To see a count of recoveries in progress, do one of the following To access the MIMIX Availability Status display, enter the command WRKMMXSTS. The Recoveries field in the upper right corner of the display shows the number of active recoveries in progress for the installation. To access the Work with Data Groups display, use option 5 (Display details) next to the Replication area.

Figure 34 shows the Audits/Recov./Notif. fields in the upper right corner of the Work with Data Groups display. The first number is the total number of audits that require action to correct a problem or require your attention to prevent a situation from becoming a problem. The second number indicates the number of active recoveries, including those resulting from audits. The third number indicates the number of new notifications that require action or attention. If more than 999 items exist in any field, the field will display +++. A consistently high number of recoveries suggests that there may be configuration issues with one or more data groups. To select a recovery to view or work with a held recovery, do the following: 1. To access the Work with Recoveries display, do one of the following: From the Work with Audits display, use option 8 (Recoveries) to see a list of recoveries associated with an audit. From the Work with Data Groups display, use F8 to see all recoveries. On a command line, enter the command WRKRCY.

2. To see details for a recovery, type a 5 (Display) next to the recovery you want and

125

press Enter.
Figure 34. Work with Data Groups display showing recoveries in progress
CHICAGO 10:49:06 Type options, press Enter. Audits/Recov./Notif.: 001 / 002 / 003 5=Display definition 8=Display status 9=Start DG 10=End DG 12=Files not active 13=Objects in error 14=Active objects 15=Planned switch 16=Unplanned switch ... ---------Source----------------Target--------ErrorsOpt Data Group System Mgr DB Obj DA System Mgr DB Obj DB Obj __ TESTDG34 LONDON A A A CHICAGO A A A __ TESTDG43 LONDON A A A CHICAGO A A A Work with Data Groups

F3=Exit F10=Legend

Bottom F5=Refresh F7=Audits F8=Recoveries F9=Automatic refresh F16=DG definitions F23=More options F24=More keys

What information is available for recoveries

While the presentation within each user interface varies, the following information is available for recoveries in the Recoveries window (MIMIX Availability Manager) and the Work with Recoveries display (5250 emulator). Additional details are available for each recovery through the Recovery Details window and the Display Recovery Details display. Where differences in field or column labels exist, the term used in MIMIX Availability Manager is listed first. Each recovery provides a brief description of the recovery process taking place as well as its current status. Status - Shows the status of the recovery action. The icons appear only on the Recoveries window and the navigation bar in MIMIX Availability Manager. Active - The job associated with the recovery is active. Ending - The job associated with the recovery is ending. Held - The job associated with the recovery is held. A recovery whose source is a replication process cannot be held. Data group - Identifies the data group associated with the recovery. In MIMIX Availability Manager, preferences determine whether the three-part name of the data group is displayed. On the Status view of the Work with Recoveries display, the F7 key toggles between the Source column and the Data Group column. The full three-part name is available in the Timestamp view (F11).

126

Displaying recoveries

Date - Indicates the date the recovery process started. Time - Indicates the time the recovery process started. Source - Identifies the process, program, or command that generated the recovery. Names that begin with the character # are generated by automatic recovery actions for audits or database replication or by a MIMIX rule. Names that begin with the characters ## are generated by automatic recovery actions for object replication. Sender or From System - Identifies the system from which the recovery originated.

Detailed information
When you display a recovery, you see its description, status, data group, source, and sender as described above. You also have access to the following information. Details - When the source of the recovery is a rule, this identifies the command run by the rule in an attempt to recover from the detected error. Output File - If available, this identifies an associated output file that lists the detected errors the recovery is attempting to correct. Output file information associated with a recovery is only available from the sender system. Job - If available, this identifies the job that is performing the recovery action. Job information associated with a recovery is only available from the sender system.

Options for working with recoveries

Table 16 identifies the possible actions you can take for a recovery. From the Recoveries window, the Actions list for each recovery contains only the actions possible for the selected recovery.
Table 16. Options available for recoveries WRKRCY Option 4=Remove Description Removes the specified recovery, if it is not held or active. A confirmation panel is displayed after pressing Enter. Use this option to remove orphaned recoveries whose associated recovery job ended. This option is only available from the system on which the recovery job ran. Displays available additional information associated with the recovery. Prints the information associated with the recovery. Print support in MIMIX Availability Manager is provided by the browser. Displays a filtered view of the output file associated with the recovery. MIMIX updates the output file while the recovery is in progress, identifying the detected errors it is attempting to correct and marking corrected errors as being recovered.This option is only available from the system on which the recovery job is running.

Recoveries Window Action

Display Details

5=Display 6=Print

Output File1

8=View progress

127

Table 16.

Options available for recoveries WRKRCY Option 10=End job Description Ends an active recovery job. This action is valid for recoveries with names that begin with # and is only available from the system on which the recovery job is running. Displays the job log for the recovery job associated in progress. This option is only available from the system on which the recovery job is running. In MIMIX Availability Manager, the job is displayed in the Job Log window. Places an active recovery job on hold. This action is valid for recoveries with names that begin with # and is only available from the system on which the recovery job is running. Releases a held recovery job. This action is valid for recoveries with names that begin with # and is only available from the system on which the recovery job is held. Displays details of the rule that generated the recovery, including the substitution variables for the command the rule initiates. This action is available for recoveries generated by audit activity.

Recoveries Window Action End Recovery

Job Log1

12=Display job

Hold Job

13=Hold job

Release Job

14=Release job

Rule Details1

1.

This action may also be available for a notification from the Recovery Details window.

Orphaned recoveries
There are times when recoveries exist but are no longer associated with a job. The following conditions could cause recoveries to become orphaned: An unplanned switch has occurred The MIMIX subsystem was ended unexpectedly A recovery job was ended unexpectedly

When automatic audit recovery is enabled, orphaned recoveries are converted to error notifications during system cleanup. If the orphaned recovery is older than the cleanup time specified in the system definition, it is deleted. When automatic database recovery or automatic object recovery is enabled, orphaned recoveries are deleted, when possible. Because recoveries are displayed on both systems, but jobs associated with them are only accessible from the originating system, you need to verify that the recovery is orphaned before removing it.

Determining whether a recovery is orphaned

From MIMIX Availability Manager, do the following to determine whether a recovery is orphaned: 1. Select Recoveries from the Details area in the navigation bar. 2. Verify that the system from which you are viewing recoveries is the system

128

Displaying recoveries

identified in the Sender column on the Recoveries window. You may need to change Preferences to view the Sender column. 3. For the recovery in question, select the Display Details action and click .

4. From the Recovery Details window, locate the Job information. Then do the following as needed: If you see the message Job not available on the system. Job available on originating system only, select the correct system from the navigation bar. Then start this procedure again. If you see the message No job information available the recovery is orphaned. Go to Removing an orphaned recovery on page 129. If a job name is displayed, click on the name. The job information is displayed in the Job Log window. If the job is no longer available, you should see the message No data available, which confirms that the recovery is orphaned. Go to Removing an orphaned recovery on page 129

From a 5250 emulator, do the following to determine whether a recovery is orphaned: 1. From the iSeries command line, type WRKRCY and press Enter. 2. Press F11 to display the Timestamp view. This view allows you to see the From System column which lists the system from which the recovery originated. 3. Ensure you are operating from the originating system. Then type a 12 next to the recovery. 4. Do one of the following: If an error message is displayed indicating that the job associated with the recovery is not found, follow the steps in Removing an orphaned recovery on page 129. When the Display Job display appears, type a 10 in the Selection field and press Enter. The status of the job is displayed. If the job associated with the recovery is no longer valid, follow the steps in Removing an orphaned recovery on page 129.

Removing an orphaned recovery

These procedures assume that you have already confirmed that the recovery is orphaned using the procedures in Determining whether a recovery is orphaned on page 128. From MIMIX Availability Manager, do the following to remove an orphaned recovery: 1. Select Recoveries from the Details area in the navigation bar. 2. Verify that the system from which you are viewing recoveries is the same as the system identified in the Sender column on the Recoveries window. You may need to change Preferences to view the Sender column. 3. For the orphaned recovery, select the Remove Recovery action and click .

129

From a 5250 emulator, do the following to remove an orphaned recovery: 1. From the originating system, type WRKRCY on the command line and press Enter. 2. After you have ensured that the recovery is orphaned, type a 4 next to the orphaned recovery you wish to remove and press Enter. 3. Press Enter to confirm your request to remove the recovery.

130

CHAPTER 5

Starting and ending replication

MIMIX uses a number of processes to perform replication. These processes, along with a number of supporting processes must be active to enable MIMIX to function. All of these processes are usually started initially during configuration. Two sets of commands provide the ability to start and stop replication, as follows: The Start MIMIX (STRMMX) and End MIMIX (ENDMMX) commands will start or stop replication processes as well as all supporting processes for the products in a MIMIX installation library in a single operation. These commands are the preferred method for starting and ending MIMIX. The Start Data Group (STRDG) and End Data Group (ENDDG) commands will start or stop data group replication processes.

This chapter provides information about using either set of commands. The following topics are included: Choices when starting replication on page 133 describes the STRMMX and STRDG commands and considerations for using either command. Considerations for starting data groups on page 135 describes considerations and options for using the STRDG command, including setting a new synchronization point by clearing pending and error entries and setting the audit level on objects. Choices when ending replication on page 141 describes the ENDMMX and ENDDG commands and considerations that are common to both commands, such as when to perform a controlled end or when to end the RJ link. Considerations for ending data groups on page 146 describes general information you should know about the behavior of the ENDDG command. Starting MIMIX on page 147 provides a procedure for using the STRMMX command. Ending MIMIX on page 147 provides procedures for using the ENDMMX command and describes when you may also need to end the MIMIX subsystem. STRMMX and ENDMMX messages on page 149 describes the messages returned by these commands. Starting selected data group processes on page 150 provides a procedure using the STRDG command. Ending selected data group processes on page 151 provides a procedure using the ENDDG command. Ending a data group in a controlled manner on page 152 provides procedures for preparing to end, ending, and confirming that the end completed without problems. What replication processes are started by the STRDG command on page 155 describes which replication processes are started with each possible value of the Start processes (PRC) parameter. Both data groups configured for remote

131

Starting and ending replication

journaling and data groups configured for MIMIX source-send processing are addressed. What replication processes are ended by the ENDDG command on page 159 describes what replication processes are ended with each possible value for the End Options (PRC) parameter. Both data groups configured for remote journaling and data groups configured for MIMIX source-send processing are addressed.

132

Choices when starting replication

Choices when starting replication

Both the Start MIMIX (STRMMX) command and the Start Data Group (STRDG) command can be used to start replication. These commands can be run from either MIMIX Availability Manager or a 5250 emulator. The significant differences between these commands are: The STRMMX command will start all MIMIX processes in a MIMIX installation, including those used for replication, in a single operation. Optionally, this command can be used to start all MIMIX processes on the local system only. For more information, see What is started with the STRMMX command on page 133. The STRDG command starts only the replication processes that are specified on the command, and if necessary, the remote journal link. Optionally, this command can specify a starting point in the journals, clear pending or error entries, and set object auditing levels. For additional information, see Considerations for starting data groups on page 135.

Considerations for either command: Before using either STRMMX or STRDG to start replication, consider the following: Before you start data group replication, the database files and objects must be synchronized between the systems defined to the data group. For more information about performing the initial synchronization, see the MIMIX Reference book. If you are using the MIMIX for MQ function, you must use the procedures in the MIMIX for IBM WebSphere MQ book for initial synchronization and initial start of data groups that replicate data for IBM WebSphere MQ. Data groups that are in a disabled state are not started. For more information, see Disabling and enabling data groups on page 232.

What is started with the STRMMX command

The STRMMX command is shipped with default values that will start all MIMIX processes on all systems in the installation. Optionally, the command can be used to start MIMIX processes on only the local system. Processes are started in the following order: Collector services - Starts collector services for MIMIX Availability Manager on the specified systems. MIMIX managers - Starts all system managers and journal managers on the specified systems. Also starts cluster services for systems that are configured for clustering. Data groups - For enabled data groups, starts the replication processes, remote journal links, and automatic recovery processes on the specified systems. Each data group starts from the journal receiver in use when the data group ended and with the sequence number following the last sequence number processed.

133

Master monitor - Starts the master monitor on each of the specified systems. Monitors - On each of the specified systems, the master monitor starts monitors that are not disabled and which are configured to start with the master monitor. Application groups - Starts Cluster Services for all specified systems that use clustering. Also starts any application groups and their associated data groups. Note: The STRMMX command does not start promoter group activity. Start promoter group activity using procedures in the Using MIMIX Promoter book.

134

Considerations for starting data groups

Considerations for starting data groups

The Start Data Group (STRDG) command is used to start replication of database files and objects defined to a data group. This command can be used interactively or programatically. When called by the STRMMX command, the STRDG command is invoked using default values for its parameters. When a STRDG request is processed, MIMIX may take a few minutes while it does the following: Determines whether the RJ link is active and whether all required system managers and journal managers on each system are started. If necessary, the managers and the remote journal function defined by the RJ link are started. Determines the starting point for replication. Locates the starting point in the journal receiver. This will be the starting point for send processes. Reviews data group file entries to determine if there is information you must know. Submits the appropriate start requests for the processes you specified to start.

Starting a data group may take longer if the remote journal function is operating in catchup mode. In addition to the considerations described in Choices when starting replication on page 133, the following considerations apply to using the STRDG command: MIMIX determines which data group replication processes to start based on the value you specify on the Start processes (PRC) parameter. This is fully described in What replication processes are started by the STRDG command on page 155. You can optionally specify the point at which to start replication in the journal receivers. The parameters for database and object journal receivers and sequence numbers provide this capability. You may need to use these parameters when starting data groups for the first time, or when starting a data group in which you have been using the MIMIX CDP feature. For user journal replication, the IBM i remote journal function controls where processing starts in the source journal receiver. The values specified for the Database journal receiver (DBJRNRCV) and Database large sequence number (DBSEQNBR2) identify the starting location for the database reader process and the database apply process. For system journal replication, the value specified for Object journal receiver (OBJJRNRCV) and Object large sequence number (OBJSEQNBR2) identify the starting location for the object send process and the object apply process. Note: The parameters Database sequence number (DBSEQNBR) and Object sequence number (OBJSEQNBR) continue to be valid for journal definitions which specify *MAXOPT2 for the Receiver size option (RCVSIZEOPT) and for values that do not exceed 10 digits. To ensure continued compatibility, the use of parameters DBSEQNBR2 and OBJSEQNBR2 is recommended.

135

There are times when you may need to establish a new synchronization point for a data group by clearing the backlog for the apply processes and clearing identified errors in processing. Topic When to clear pending entries and entries in error on page 136 describes when you may need to start a data group with a new synchronization point. The STRDG command provides the ability to change the object audit level of existing objects configured for replication before starting replication. For more information see Setting the audit level when starting a data group on page 140.

When to clear pending entries and entries in error

Resetting a data group clears the backlog of transactions waiting to be applied on the target system, clears the log of file entries in error, and establishes a new synchronization point at which to begin replication. You need to reset the synchronization point of a data group for the situations listed in Table 17. Note: Before starting your data groups you should determine if there are any file entries on hold. For more information, see Working with journal transactions for files in error on page 173.
Table 17. When to Reset a Data Group Specify the following values on the STRDG command: Specify *YES for the Clear pending prompt. Specify *CLRPND or *YES for the Clear error prompt.
Note: This assumes that you have synchronized the objects and database files and have changed the journal receivers using TYPE(*ALL) on the CHGDGRCV command.

Reason for Resetting Data Group After synchronizing database files and objects between two systems.

After switching the direction of the data group, when starting replication on the system that now becomes the source system. After changing the Number of DB apply sessions (NBRDBAPY) parameter on the data group definition

Specify *YES for the Clear pending prompt. Specify *CLRPND or *YES for the Clear error prompt. Specify *YES for the Clear pending prompt.

Clear pending and clear error processing

The Clear pending and Clear error prompts on the STRDG command provide flexibility when starting a data group by allowing you to optionally reset error status conditions on data group file entries and discard pending journal entries that are

136

Considerations for starting data groups

stored in the journal log space. Clear pending resets the starting point for all data group file entries and object entries. Clear error clears the hold log spaces. MIMIX prevents a start request that specifies CLRPND(*YES) from running if there are open commit cycles present. Instead, message LVE387F is issued. Table 18 shows the processing that occurs based on the selection made for the Clear pending (CLRPND) and Clear error (CLRERR) prompts. The Clear pending and Clear error prompts work independently. For example, when CLRPND(*NO) is selected, no clear pending processing occurs.
Table 18. CLRPND *NO CLRPND and CLRERR processing CLRERR *NO Processing Description Data groups start with regular processing: Data group file entry status remains unchanged. Hold logs remain unchanged. The value selected for the CLRPND parameter is used for CLRERR. Same processing as CLRPND(*NO) CLRERR(*NO). Data group file entries in *HLDERR, *HLDRGZ, *HLDRNM, *HLDPRM, and *HLDRLTD status are cleared. Tracking entries in *HLDERR status are cleared. Hold log space is deleted.
Note: CLRPND(*YES) will not start a data group when there are open commit cycles on files defined to the data group.

Notes

*NO

*CLRPND

*NO

*YES

See File entry states See Log spaces

*YES

*NO

Data group file entries in *HLDRGZ, *HLDRNM, and *HLDPRM status are cleared and reset to active. Data group tracking entries in *HLDRNM are cleared and reset to active. Data group file entries and tracking entries in *HLDERR status remain unchanged. If there is a requested status at the time of starting, it is cleared. Journal, hold, tracking entry hold, and apply history log spaces are deleted. The apply session to which data group file entries are assigned may change.

See File entry apply session assignment See Single apply session processing See Log spaces

137

Table 18. CLRPND *YES

CLRPND and CLRERR processing CLRERR *YES Processing Description

Note: CLRPND(*YES) will not start a data group when there are open commit cycles on files defined to the data group.

Notes See File entry states See File entry apply session assignment See Single apply session processing See Log spaces

Data group file entries in *HLDERR, *HLDRGZ, *HLDRNM, *HLDPRM, and *HLDRLTD status are cleared and reset to active. Tracking entries in *HLDERR and *HLDRNM status are cleared and reset to active. If there is a requested status at the time of starting, it is cleared. Journal, hold, and apply history log spaces are deleted. The apply session to which data group file entries are assigned may change. Data group file entry status in *HLDRTY remains unchanged. *YES *CLRPND
Note: CLRPND(*YES) will not start a data group when there are open commit cycles on files defined to the data group.

The value selected for the CLRPND parameter is used for CLRERR. Same processing as CLRPND(*YES) CLRERR(*YES).

See File entry states See File entry apply session assignment See Single apply session processing See Log spaces

File entry states: Files in specific states will not reset to active when you specify *YES on the Clear Error prompt. If you have set data group file entries to any of these states, the following process exception applies:
Note: The only states that can be set using the Set Data Group File Entry (SETDGFE) command are *HLD, *RLSWAIT, *ACTIVE, and *HLDIGN. All other states are the result of internal processing.

*HLD - Journal entries cached before *YES is specified are discarded. If *ALL or *ALLSRC is specified on the Start processes prompt, all subsequent entries from the specified starting point will be cached again. *RLSWAIT - Journal entries are discarded as they wait for the synchronization point to arrive in the journal stream. This occurs regardless of the value specified for Clear Error or Clear Pending. *HLDIGN - Journal entries are discarded until the file status is changed to something else. *HLDSYNC - Journal entries are ignored since an external process is actively synchronizing the file. When that event completes normally, the file is set to *RLSWAIT. File entry apply session assignment: Clear pending processing attempts to load balance the data group file entries among the defined apply sessions. If the requested apply session in the data group file entry definition is *ANY, or if it is *DGDFT and the requested apply session for the data group definition is *ANY, then the apply session to which the data group file entry is assigned may be changed when processing occurs. For data groups configured to replicate through the user journal, the requested apply session may be ignored to ensure that related files are handled by the same apply session.

138

Considerations for starting data groups

Table 18. CLRPND

CLRPND and CLRERR processing CLRERR Processing Description Notes

Single apply session processing: In most situations, you will perform clear pending processing on all apply sessions belonging to a data group by specifying *ALL or *DBALL on the Start processes (PRC) prompt. MIMIX also supports the ability to perform clear pending processing on a single apply session, which is useful for recovery purposes in certain error situations. To perform clear pending processing on a single apply session, specify PRC(*DBAPY) and the specific apply session (APYSSN). Log spaces: Because they have not been applied, journal entries that exist in the journal log space are considered pending. Journal entries that exist in the hold log space, however, are considered in error. The Clear pending and Clear error prompts affect which log spaces are deleted (and recreated) when a data group is started.

Clearing pending entries when open commit cycles exist

Open commit cycles may be present if a data group was ended immediately, or if a system event or failure occurred. If an open commit cycle was present at the time that a data group was ended, MIMIX will prevent the data group from starting when the start request specifies to clear pending entries. The data group can only be started if the request does not request to clear pending entries.

Checking for open commit cycles

From MIMIX Availability Manager, do the following to check for open commit cycles: 1. Select Data Groups from the navigation bar. 2. From the Data Group Status window, select the data group you want. When the data group is displayed in the Summary area, select the Display details action and click . 3. The Data Group Details window opens. Select User Journal from the Details area of the navigation bar. The Data Group Details - User Journal window will appear. 4. For each apply session listed in the Performance section of the window, check the value of the Oldest Open Commit ID field. If the value is other than None, open commit cycles exist for the data group. From a 5250 emulator, do the following to check for open commit cycles: 1. From the MIMIX Availability Status display, type a 5 (Display details) next to the Replication activity. 2. The Work with Data Group display appears. Type an 8 (Display status) next to the data group you ended and press Enter. 3. Press F8 (Database) to view the Data Group Detail Status display. 4. For each apply session listed, check the value shown in the Open Commit column at the right side of the display. If the value is other than blank, open commit cycles exist for the data group.

139

Resolving open commit cycles to enable a clear pending start

These procedures assume that the data group is ended and that you have confirmed the presence of open commit cycles. 1. Start the data group, specifying *NO for the Clear pending prompt. 2. You must take action tor resolve the open commit cycles, such as ending or quiescing the application or closing the commit cycle. MIMIX will process the open commit cycles when they are resolved. 3. Perform a controlled end of the data group. 4. When the data group is ended, check for open commit cycles again. You may need to repeat this procedure until all open commit cycles have been resolved.

Setting the audit level when starting a data group

When a Start Data Group (STRDG) request includes processes which cause object send (OBJSND) jobs to start, MIMIX may change the object auditing level, if necessary, of existing objects identified by data group object, IFS, and DLO entries. The default value for the Set object auditing level (SETAUD) parameter causes this change to the configured value when the STRDG request occurs after a switch or after a configuration change to data group object, IFS, or DLO entries. Start processes (PRC) which start the object send jobs are: *ALL, *ALLSRC, *OBJALL, or *OBJSRC. The values for the SETAUD parameter are: *YES (default) - If any data group object, DLO, or IFS entry defined to this data group has changed since the last time the data group was started, the audit level of all corresponding replicated objects is set to the values specified in the object, DLO, or IFS entries. *NO - The audit level is not changed by MIMIX. When this value is used, MIMIX assumes that you have correctly set the audit levels for the objects. If the audit levels do not match those specified in the associated data group entries (Object, DLO, IFS), replication errors may occur.

Note: If you are upgrading from a previous version and you have user programs that use the STRDG command you should recompile those programs and specify an option for the SETAUD parameter. For example, you may have an automated switch program that uses the STRDG command. Refer to the STRDG command help text for assistance with setting the audit levels for objects that are replicated by MIMIX. You should be aware of how the processing order for data group entries can affect the auditing value of IFS objects. For examples and for information about manually specifying the audit level of objects, see the MIMIX Reference book.

140

Choices when ending replication

Choices when ending replication

Both the End MIMIX (ENDMMX) command and the End Data Group (ENDDG) command can be used to end replication. The significant differences between these commands are: The ENDMMX command will end all MIMIX processes in a MIMIX installation, including those used for replication, in a single operation. Optionally, this command can be used to end all MIMIX processes on the local system only. For additional information, see What is ended by the ENDMMX command on page 142. The ENDDG command ends only the replication processes that are specified on the command. The ENDDG command is called by the End MIMIX (ENDMMX) to end data groups and by other commands, such as Switch Data Group (SWTDG).

The reason you need to end MIMIX activity determines which command is the best choice to use. Table 19 lists common reasons for ending and the appropriate command to use. Depending on why you are ending replication, you may need to choose values other than the defaults.
Table 19. Choosing the appropriate command to end replication Use Command ENDMMX ENDMMX The save request may not be able to save all the files or objects if they are opened or locked by MIMIX. See controlled end information in Ending immediately or controlled on page 143. Also end the RJ link Also end the RJ link Let MIMIX Switch Assistant or your MIMIX Model Switch Framework end replication. See Ending selected data group processes on page 151. The changes are not available to active replication processes until the data group processes are ended and restarted. Additional Information

Reason for Ending Replication Ending communications for any reason Performing a full save and restore of data that is defined to MIMIX

Preparing to update MIMIX software Performing an IPL of either system Upgrading the operating system release on either system Performing a switch in preparation for performing maintenance on either system Ending only a selected replication process Changing configuration, such as adding or changing data group entries

ENDMMX ENDMMX ENDMMX --ENDDG ENDDG

141

Table 19.

Choosing the appropriate command to end replication Use Command ENDDG Additional Information The save request may not be able to save all the files or objects if they are opened or locked by MIMIX. You may be able to end only processes on the target system. See Ending selected data group processes on page 151.

Reason for Ending Replication Performing a backup.

Considerations when choosing a command: Both ENDMMX and ENDDG commands support options for how processes are ended and for ending the remote journal link. Answering the following questions will help you determine which commands and options are appropriate. Do processes need to end in a controlled manner or can they be ended immediately? Both commands support these options. For more information, see Ending immediately or controlled on page 143 Do you need to end only a subset of the replication processes? Only ENDDG supports ending selected processes. For more information see Ending all or selected processes on page 144. Does the RJ link also need to end? For data groups that use remote journaling you may also choose whether to end the RJ link. In most cases, the RJ link can remain active. For more information, see When to end the RJ link on page 144.

What is ended by the ENDMMX command

The ENDMMX command is shipped with default values that will end all MIMIX processes on all systems in the installation. Optionally, the command can be used to end MIMIX processes on only the local system. Processes are ended in the following order: Data resource groups - If all systems are specified and any of the specified systems in the installation are configured for clustering, data resource groups are ended. Data groups - The end process specified is used to end all enabled data groups and their supporting processes, including automatic recovery, on the specified systems. This includes data groups associated with data resource groups. Remote journal links - If you selected to end remote journaling, all remote journal links associated with the specified systems are ended. MIMIX managers - Ends the system manager and journal manager processes on the specified systems. Collector services - Ends collector services for MIMIX Availability Manager on the specified systems Monitors - Ends all individual monitors currently active in the installation library on

142

Choices when ending replication

the specified systems. Master monitor - Ends the master monitor on each of the specified systems. MIMIX Promoter - Ends promoter group activity on the specified systems. Audits and Recoveries - All queued audits, all audits in progress, and all recoveries in progress, that are associated with the specified systems are ended. This includes jobs with locks on the installation library. Queued audits and audits in comparison phase revert to their previous state. Audits in recovery phase reflect the state of processing at the time of the end request, which may be Not recovered. Note: Cluster services is not ended when MIMIX managers end because cluster services may be necessary for other applications.

Ending immediately or controlled

Both ENDMMX and ENDDG commands provide the ability to choose whether replication processes end immediately or in a controlled manner through the End process (ENDOPT) parameter. However, the default value of this parameter differs on these commands. For ENDMMX, the default is to end controlled (*CNTRLD). For ENDDG, the default is to end immediately (*IMMED). When you perform an immediate end, the processes end independently of each other. For example, it is possible for the apply process to end before the send or receive process. Each replication process verifies that its processing is at a point that will permit ending, then ends. The amount of time it takes for an immediate end varies depending on the delay values set for each manager and what each process is doing at the time. An immediate end does not ensure that all journal entries generated are sent to or applied on the target system. If an incomplete IFS or object tracking entry for a data group is being processed during an immediate end, the entire entry may not be applied. When the data group is restarted, the entire incomplete entry is rewritten to ensure the integrity of the object. When you perform a controlled end, MIMIX creates either a journal entry or log space entry. This entry proceeds through the replication path. The date and time of the entry are compared to the date and time of when the process being considered was started. If the entry is earlier than the process start time, the end request is ignored. If the entry is later than when the process being considered was started, the process is ended. A controlled end ensures that processes end in order and that each process completes any queued or in-progress transactions before the next process is permitted to end. This ensures that you have a known point in each journal at which you can restart replication. If any processes have a backlog of entries, it may take some time for the entry created by the request to be processed through the replication path. Any entries that precede the entry requesting to end are processed first.

143

A data group that is ended in a controlled manner is enabled for a more effective and safer start when the start request specifies to clear pending entries. The existence of commit cycles implies that there is application activity on the source system that should not be interrupted; replication should be allowed to continue through the end of the commit cycle. It is preferable to ensure that commit cycles are resolved or removed before ending a data group. When open commit cycles exist, a data group cannot be started with a request to clear pending entries. The open commit cycles must be resolved before pending entries can be cleared during a start request. If the request to perform a controlled end also includes ending the RJ link, the RJ link is ended after all requested processes end. Either type of end request may be ignored if the request is submitted just before the time that MIMIX jobs are restarted daily. For more information about restarting jobs, see Configuring restart times for MIMIX jobs in the MIMIX Reference book.

Controlling how long to wait for a controlled end to complete

When you request a controlled end you can determine how long to wait for all specified data group processes to end. The Wait time (seconds) (WAIT) parameter specifies how long to wait for all of the specified data group processes to end. MIMIX will attempt to resolve all pending activity entries before ending the data groups. If a numeric value was specified, and the selected processes do not end within the specified time, the action specified for the Timeout option (TIMOUTOPT) will occur. The WAIT parameter also supports special values of *SBMRQS and *NOMAX. When these values are used, the TIMOUTOPT parameter is ignored. Note: If *ALL is specified for any part of the data group definition, the Wait time value must be *SBMRQS (submit request).

Ending all or selected processes

MIMIX determines which data group replication processes to end based on the command specified and options on the command. The ENDMMX command ends all replication processes for all data groups on the systems specified on the end request. Only the ENDDG command supports the ability to end selected replication processes through its Process (PRC) parameter. The default value is to end all replication processes for the specified data groups. The configuration of each data group determines which processes end with each possible value for the PRC parameter. If you choose to use this parameter, be sure that you understand what processes will end. See What replication processes are ended by the ENDDG command on page 159.

When to end the RJ link

The RJ link remains active unless you change the value of the End remote journaling (ENDRJLNK) parameter on the ENDMMX command or the ENDDG command.

144

Choices when ending replication

The RJ link can normally remain active unless you have a need to prevent data from being sent to the target system. Some situations where you need to end the RJ link include: Following a switch, to prevent data from returning to the system on which it originated (round-tripping), and to reduce communications and DASD usage Before performing an IPL on either the source system or target system Before upgrading the IBM i release on either the source system or the target system Before performing a hardware upgrade

145

Considerations for ending data groups

Before you use the End Data Group (ENDDG) command, you should be aware of the following general considerations: MIMIX determines which data group replication processes to end based on the value you specify for the Process (PRC) parameter. This is fully described in What replication processes are ended by the ENDDG command on page 159. The RJ link is controlled separately through the End remote journaling (ENDRJLNK) parameter. The ENDRJLNK parameter allows you to selectively end the IBM i remote journal connection defined by the RJ link. The RJ link is not automatically ended. In most cases, the default value *NO, which keeps the RJ link active, is appropriate. This allows database changes to continue to be sent to the target system even though the data group is not active. For additional information, see When to end the RJ link on page 144. If you have used the MIMIX CDP feature to set a recovery point in a data group and then end the data group, the recovery point will be cleared. When the data group is started again, the apply processes will process any available transactions, including those which may have had corruptions. (Recovery points are set through the Data Recovery window in MIMIX Availability Manager or with the Set DG Recovery Point (SETDGRCYP) command in a 5250 emulator.) If a recovery window is configured for the data group, its configured duration is not affected by requests to end or start the data group. Ending data group replication processes does not automatically end the system manager or journal managers. If any managers must be ended, consider using the ENDMMX command instead. If you use the ENDDG command in this scenario, you must also select the appropriate option from the Work with Systems menu or use the End MIMIX Managers (ENDMMXMGR) command. If the next time you start the data groups requires that you clear pending entries, or if you will be performing a switch, you should verify that no activity is still in progress before you perform these activities. Use the command WRKDGACTE STATUS (*ACTIVE) to ensure all activity entries completed. The ENDDG command cannot be run against a disabled data group. For more information, see Disabling and enabling data groups on page 232.

146

Starting MIMIX

Starting MIMIX
To start all MIMIX products within an installation library, do the following: 1. If you are starting MIMIX for the first time or starting MIMIX after a system IPL, do the following: a. Use the command WRKSBSJOB SBS(MIMIXSBS)to verify that the MIMIX subsystem is running. If the MIMIXSBS is not already active, start the subsystem using the STRSBS SBS(MIMIXQGPL/MIMIXSBS)command. b. If MIMIX uses TCP/IP for system communication, the TCP/IP servers must be running. If TCP/IP is not already active, start TCP/IP using the port number defined in the transfer definitions and the procedures described in Starting the TCP/IP server on page 222. 2. Do one of the following: From the MIMIX Basic Main Menu, select option 2 (Start MIMIX) and press Enter. From the MIMIX Availability Status display, press F13 (Start MIMIX). From a command line type STRMMX and press Enter.

3. The Start MIMIX (STRMMX) display appears. Accept the default value for the System definition prompt and press Enter. 4. If you see a confirmation display, press Enter to start MIMIX.

Ending MIMIX
For most configurations, It is recommended that you end MIMIX products from the management system, which is usually the backup system. If your installation is configured so that the backup system is a network system, you should end MIMIX from the network system. Note: If you are ending MIMIX for a software upgrade or to install a service pack, use the procedures in the softwares ReadMe document. To end MIMIX, use the following procedures: 1. Use one of the following procedures: Ending with default values on page 147 Ending by prompting the ENDMMX command on page 148

2. Complete any needed follow-up actions using the information and procedures in After you end MIMIX products on page 148.

Ending with default values

Use this procedure to end all MIMIX production in an installation library. 1. Do one of the following:

147

From the MIMIX Basic Main Menu, select option 3 (End MIMIX) and press Enter. You will see a confirmation display. From the MIMIX Availability Status display, press F17 (End MIMIX). You will see a confirmation display.

2. From the confirmation display, you can press F1 (Help) to see a description of the default values that will be used. To end MIMIX, press Enter,

Ending by prompting the ENDMMX command

To end all MIMIX processes for the specified systems within an installation library, do the following: 1. From a command line, type ENDMMX and press F4 (Prompt). 2. The End MIMIX display appears. At the End process prompt, specify *CNTRLD for a controlled end or *IMMED for an immediate end. This parameter applies to the application group (ENDAG) and data group (ENDDG) processes only. Note: When ENDMMX ends data groups, it waits for each data group to end before attempting to end the next MIMIX product. 3. At the End remote journaling prompt, specify whether you want to end remote journaling. Note: If you specify *YES, all data groups using the remote journal link in the installation library will be affected. If other data groups are using the same remote journal link, you should specify *NO. 4. If you specified *CNTRLD for Step 2, ensure that the values for the Wait time (seconds) and Timeout option prompts are what you want for the controlled end. 5. At the System definition prompt, indicate the scope of the request by specifying either *ALL or *LOCAL. This determines the systems on which to end MIMIX processes. 6. To end MIMIX processes, press Enter.

After you end MIMIX products

Some pending transactions may not be handled before the end process completes. You may need to ensure that all activity entries are complete before you issue additional commands. Examples of scenarios where it is important to check whether all pending transactions are completed include: Switching a data group (SWTDG command) Starting a data group with clear pending entries (STRDG CLRPND(*YES)).

To check for active entries, use the command WRKDGACTE STATUS(*ACTIVE). When to also end the MIMIX subsystem - You will also need to end the MIMIX subsystem when you need to IPL the system, when upgrading MIMIX software, and when installing a MIMIX software service pack. The MIMIX subsystem must be ended from the 5250 emulator. To end the subsystem, do the following: 1. Log out of MIMIX Availability Manager.

148

STRMMX and ENDMMX messages

Note: Other MIMIX Availability Manager users should also be instructed to log out. 2. From the 5250 emulator, enter LAKEVIEW/ENDMMXAM. 3. Enter the command WRKSBS. The Work with Subsystems display appears. 4. Type an 8 (Work with subsystem jobs) next to subsystem MIMIXSBS and press Enter. 5. End any remaining jobs in a controlled manner. Type a 4 (End) next to the job and press F4 (Prompt). The How to end (OPTION) parameter should have a value of *YES. Press Enter. If you see a confirmation display, press Enter to continue. 6. Press F12 (Cancel) to return to the Work with Subsystems display. 7. Type a 4 (End subsystem) next to subsystem MIMIXSBS and press Enter.

STRMMX and ENDMMX messages

Once you have run the STRMMX or ENDMMX command, one of the following messages is displayed: Completion LVI0902 This message indicates that all MIMIX products were started or ended successfully. Escape LVE0902 This message indicates one or more MIMIX products failed to start or end.

149

Starting selected data group processes

Before you start a data group with this procedure, you should be familiar with the information in the following topics: Considerations for starting data groups on page 135 When to clear pending entries and entries in error on page 136 Clear pending and clear error processing on page 136 Setting the audit level when starting a data group on page 140 What replication processes are started by the STRDG command on page 155

To selectively start processes for a data group, do the following: 1. From the Work with Data Groups display, type a 9 (Start DG) next to the data group that you want to start and press Enter. 2. The Start Data Group (STRDG) display appears. At the Start processes prompt, specify the value for the processes you want to start. To see a list of values, press F4 (Prompt). Note: When you are starting a data group for the first time, specify *ALL. 3. Press Enter. 4. Additional prompts appear. For most situations, you should accept the default values. If you need to establish a new synchronization point, use Table 17 on page 136 to determine the correct values to specify for the Clear pending and Clear error prompts. If you are submitting this command for batch processing, you should specify *NO for the Show confirmation screen prompt.

5. To start the data group, press Enter.

150

Ending selected data group processes

Ending selected data group processes

Before you end a data group with this procedure, you should be familiar with the information in the following topics: Choices when ending replication on page 141 Considerations for ending data groups on page 146 What replication processes are ended by the ENDDG command on page 159

To selectively end processes for a data group, do the following: 1. From the Work with Data Groups display, type a 10 (End DG) next to the data group that you want to end and press Enter. 2. The End Data Group (ENDDG) display appears. At the Process prompt, specify the value for the processes you want to end. To see a list of values, press F4 (Prompt). 3. At the End process prompt, specify the value you want. 4. If the data group uses remote journaling, verify that the value of the End remote journaling prompt is what you want. 5. If you want to end only a selected apply session, press F10 (Additional parameters). Then specify the value for the session you want to end at the Apply session prompt. 6. To end the selected processes, press Enter.

151

Ending a data group in a controlled manner

The following procedures describe how to check for errors before requesting a controlled end of a data group, how to perform the controlled end request, and how to confirm that the end completed. Held files must be released and the apply process must complete operations for journal entries stored in log spaces before you end data group activity.

Preparing for a controlled end of a data group

It is good practice to ensure that errors are resolved before requesting a controlled end of a data group. Do the following: 1. From the Work with Data Groups display, type an 8 (Display status) next to the data group you want to end and press Enter. 2. The Data Group Status display appears. In the upper right of the display, you should see either one or both of the following fields. A non-zero value in these fields will not prevent the end request from completing. Database errors identifies the number of items replicated through the user (database) journal that have a status of *HLDERR. This number should be 0 before you end the data group. Object in error/active identifies two key statistics associated with objects replicated through the system journal. The first number identifies the number of objects that have a status of *FAILED and the second number identifies the number of objects with active (pending) activity entries. Both numbers should be 0 before you end the data group.

Note: Only information for the type of information replicated by the data group appears on the status displays. For example, if the data group does not contain database files, you will only see fields for object information. 3. For data groups which replicate from the user journal, you also need to check for any files that are held for other reasons. Press F8 (Database). The Held for other reasons field In the upper right of the Data Group Database Status display should also be 0 before you end the data group. A non-zero value may or may not prevent the end request from completing. For more information, see topics Working with files in error on page 170.

Performing the controlled end

1. From the Work with Data Groups display, type a 10 (End DG) next to the data group you want to end and press Enter. 2. The End Data Group (ENDDG) display appears. Specify *CNTRLD for the End processes prompt. 3. If the data group uses remote journaling, verify that the value of the End remote journaling prompt is what you want.

152

Ending a data group in a controlled manner

4. Because you specified *CNTRLD in Step 2, you can also use the Wait Time (WAIT) parameter to specify how long MIMIX should try to end the selected processes in a controlled manner. Use F1 (Help) to see additional information about the possible options. Specify *SBMRQS to submit a request to end the data groups. The appropriate actions are issued to end the specified processes and control is returned to the caller immediately. When you specify this value, the TIMOUTOPT parameter (Step 5) is ignored. Specify *NOMAX. When you specify this value, MIMIX will wait until all specified MIMIX processes are ended. Specify a numeric value (number-of-seconds). MIMIX waits the specified time for a controlled end to complete before using the option specified in the TIMOUTOPT parameter.

5. If you specified a numeric value for the WAIT parameter in Step 4, you can also use the Timeout Option (TIMOUTOPT) parameter. You can specify what action you want the ENDDG command to perform if the time specified in the WAIT parameter is reached: The current process should quit and return control to the caller (*QUIT). A new request should be issued to end all processes immediately (*ENDIMMED). When this value is specified, pending activity entries may still exist after the data group processes are ended. An inquiry message should be sent to the operator notifying of a possible error condition (*NOTIFY). If you specify this value, the command must be run from the target system.

6. Press Enter to process the command.

Confirming the end request completed without problems

After you request a controlled end of a data group, the Work with Data Group display appears. Do the following: 1. From the Work with Data Group display appears. Type an 8 (Display status) next to the data group you ended and press Enter. 2. The Data Group Status display appears. In the Target Statistics section near the middle of the display, the Unprocessed Entry Count column should be blank for any database apply processes and any object apply processes. If unprocessed entries exist when you end the data group and perform a switch, you may lose these entries when the data group is started following the switch. Note: To ensure that you are aware of any possible pending or delayed activity entries, enter the WRKDGACTE STATUS(*ACTIVE) command. Any activities that are still in progress will be listed. Ensure that all activities are completed. 3. Ensure there are no open commit cycles if you anticipate that you will need to reset the data group the next time it is started, if you are performing a hardware upgrade with a disk image change, or if you are converting to MIMIX Dynamic

153

Apply. If there are open commit cycles and you restart using CLRPND(*YES), you may lose these transactions. To verify commit cycles, do the following: a. Press F8 (Database) to view the Data Group Detail Status display. b. For each apply session listed, verify that the value shown in the Open Commit column at the right side of the display will be blank. c. If open commit cycles exist, restart the data group. You must take action to resolve the open commit cycles, such as ending or quiescing the application or closing the commit cycle. Then repeat the controlled end again.

154

What replication processes are started by the STRDG command

What replication processes are started by the STRDG command

MIMIX determines how each data group is configured and starts the appropriate replication processes based on the value you specify for the Start processes (PRC parameter). Default configuration values create data groups that use MIMIX Remote Journal support (MIMIX RJ support) for database replication and source-send technology for object replication. The following table shows the correlation between choice text values in MIMIX Availability Manager and the possible values for the PRC parameter on the command.
MIMIX Availability Manager Choice Text All All Source All Target All Database All Object Database Source Database Target Object Source Object Target Database Reader Database Apply Special Value on Command *ALL *ALLSRC *ALLTGT *DBALL *OBJALL *DBSRC *DBTGT *OBJSRC *OBJTGT *DBRDR *DBAPY

Table 20 identifies the processes that are started when MIMIX RJ support is used for database replication for each of the possible values on the PRC parameter. An RJ link identifies the IBM i remote journal function, which transfers data to the target system. On the target system, the data is processed by the MIMIX database reader (DBRDR) before the database apply process (DBAPY) completes replication. For data groups that use MIMIX RJ support, it is standard practice to leave the RJ link active when the data groups are ended. If the RJ link is not already active when starting data groups, MIMIX starts the RJ link when the value specified for the PRC parameter includes database source system processes or all processes. The RJ Link column in Table 20 shows the result of each process when the RJ link is not active while the Notes column identifies behavior that may not be anticipated when the RJ link is already active.

155

What replication processes are started by the STRDG command

Table 20. Value for PRC

Processes started by data groups configured for MIMIX Remote Journal support. This assumes that all replication processes are inactive when the STRDG request is made. Notes Source Processes DB replication RJ Link 1 Object replication OBJSND Starts Starts Inactive Inactive2 Starts Inactive2 Inactive2 Starts Inactive Inactive2 Inactive2 OBJRTV Starts Starts Inactive Inactive2 Starts Inactive2 Inactive2 Starts Inactive Inactive2 Inactive2 CNRSND Starts Starts Inactive Inactive2 Starts Inactive2 Inactive2 Starts Inactive Inactive2 Inactive2 STSRCV Starts Starts Inactive Inactive2 Starts Inactive2 Inactive2 Starts Inactive Inactive2 Inactive2 Target Processes DB replication DBRDR Starts Inactive Starts Starts Inactive3 Inactive Starts Inactive3 Inactive3 Starts Inactive3 DBAPY Starts Inactive Starts Starts Inactive 3 Inactive Starts Inactive3 Inactive3 Inactive Starts3 Object replication OBJRCV Starts Starts Inactive Inactive2 Starts Inactive2 Inactive2 Starts Inactive Inactive2 Inactive2 CNRRCV Starts Starts Inactive Inactive2 Starts Inactive2 Inactive2 Starts Inactive Inactive2 Inactive2 STSSND Starts Starts Inactive Inactive2 Starts Inactive2 Inactive2 Starts Inactive Inactive2 Inactive2 OBJAPY Starts Inactive Starts Inactive2 Starts Inactive2 Inactive2 Inactive Starts Inactive2 Inactive2

*ALL *ALLSRC *ALLTGT *DBALL *OBJALL *DBSRC *DBTGT *OBJSRC *OBJTGT *DBRDR *DBAPY Notes:

E A, E A, B A, E A, C A, C, E A, B A, C A, C A, D A, C

Starts1 Starts1 Inactive1 Starts1 Inactive1 Starts1 Inactive1 Inactive1 Inactive1 Inactive1 Inactive1

A. Data groups which use cooperative processing should have both database and object processes started to prevent objects and data on the target system from becoming not fully synchronized. B. When the RJ link is already active, database replication becomes operational. C. When the RJ link is already active, database journal entries continue to transfer to the target system over the RJ link D. When the RJ link is already active, database journal entries continue to transfer to the target system over the RJ link, where they will be processed by the DBRDR. E. If data group data area entries are configured, the data area polling process also starts when values which start database source processes are selected.
1. This column shows the effect of the specified value on the RJ link when the RJ link is not active. See the Notes for the effect of values when the RJ Link is already active, which is default behavior.

156

What replication processes are started by the STRDG command

2. 3.

These object replication processes are not available in data groups configured for database-only replication. These database replication processes are not available in data groups configured for object-only replication.

Optionally, data groups can use source-send technology instead of remote journaling for database replication. Data groups created on earlier levels of MIMIX may still be configured this way. Table 21 identifies the processes that are started by each value for Start processes when source-send technology is used for database replication. The MIMIX database send (DBSND) process and database receive (DBRCV) process replace the IBM i remote journal function and the DBRDR process, respectively.
Table 21. Value for PRC Processes started by data groups configured for Source Send replication This assumes that all replication processes are inactive when the STRDG request is made. Notes Source Processes DB replication DBSND 1 *ALL *ALLSRC *ALLTGT *DBALL *OBJALL *DBSRC *DBTGT *OBJSRC *OBJTGT *DBRDR 4 *DBAPY Notes: A. Data groups which use cooperative processing should have both database and object processes started to prevent objects and data on the target system from becoming not fully synchronized. A A A A A A A A A Starts 1 Starts 1 Inactive Starts 1 Inactive 3 Starts 1 Inactive Inactive3 Inactive3 Inactive3 Object replication OBJSND Starts Starts Inactive Inactive2 Starts Inactive2 Inactive2 Starts Inactive Inactive2 Inactive2 OBJRTV Starts Starts Inactive Inactive2 Starts Inactive2 Inactive2 Starts Inactive Inactive2 Inactive2 CNRSND Starts Starts Inactive Inactive2 Starts Inactive2 Inactive2 Starts Inactive Inactive2 Inactive2 STSRCV Starts Starts Inactive Inactive2 Starts Inactive2 Inactive2 Starts Inactive Inactive2 Inactive2 Target Processes DB replication DBRCV Starts Starts Inactive Starts Inactive3 Starts Inactive Inactive3 Inactive3 Inactive3 DBAPY Starts Inactive Starts Starts Inactive3 Inactive Starts Inactive3 Inactive3 Starts 3 Object replication OBJRCV Starts Starts Inactive Inactive2 Starts Inactive2 Inactive2 Starts Inactive Inactive2 Inactive2 CNRRCV Starts Starts Inactive Inactive2 Starts Inactive2 Inactive2 Starts Inactive Inactive2 Inactive2 STSSND Starts Starts Inactive Inactive2 Starts Inactive2 Inactive2 Starts Inactive Inactive2 Inactive2 OBJAPY Starts Inactive Starts Inactive2 Starts Inactive2 Inactive2 Inactive Starts Inactive2 Inactive2

157

What replication processes are started by the STRDG command

1. 2. 3. 4.

When the database send (DBSND) process starts, the data area polling process also starts. These object replication processes are not available in data groups configured for database-only replication. These database replication processes are not available in data groups configured for object-only replication The database reader (*DBRDR) process is not used by data groups configured for source-send replication.

158

What replication processes are ended by the ENDDG command

What replication processes are ended by the ENDDG command

MIMIX determines how each data group is configured and ends the appropriate replication processes based on the value you specify for the End options (PRC parameter). Default configuration values create data groups that use MIMIX Remote Journal support (MIMIX RJ support) for database replication and source-send technology for object replication. The following table shows the correlation between choice text values in MIMIX Availability Manager and the possible values for the PRC parameter on the command.
MIMIX Availability Manager Choice Text All All Source All Target All Database All Object Database Source Database Target Object Source Object Target Database Reader Database Apply Special Value on Command *ALL *ALLSRC *ALLTGT *DBALL *OBJALL *DBSRC *DBTGT *OBJSRC *OBJTGT *DBRDR *DBAPY

Table 22 identifies the processes that are ended by each value for End options when MIMIX RJ support is used for database replication. An RJ link identifies the IBM i remote journal function, which transfers data to the target system. On the target system, the data is processed by the MIMIX database reader (DBRDR) before the database apply process (DBAPY) completes replication. The communications defined by the RJ link remains active and is not affected by any value for End options. In most cases, leaving the RJ link active is preferable. If necessary, you can end the RJ link by changing value for End remote journaling (ENDRJLNK parameter). When to end the RJ link on page 144 describes when you need to end the RJ link.

159

What replication processes are ended by the ENDDG command

Table 22. Value for PRC

Processes ended by data groups configured for MIMIX Remote Journal support. This assumes that all replication processes are active when the ENDDG request is made and that the request does not specify to end the RJ link. Notes Source Processes DB replication RJ Link 1 Object replication OBJSND Ends Ends Active Active 2 Ends Active 2 Active 2 Ends Active Active 2 Active 2 OBJRTV Ends Ends Active Active 2 Ends Active 2 Active 2 Ends Active Active 2 Active 2 CNRSND Ends Ends Active Active 2 Ends Active 2 Active 2 Ends Active Active 2 Active 2 STSRCV Ends Ends Active Active 2 Ends Active 2 Active 2 Ends Active Active 2 Active 2 Target Processes DB replication DBRDR Ends Active Ends Ends Active 3 Active Ends Active 3 Active 3 Ends Active DBAPY Ends Active Ends Ends Active 3 Active Ends Active 3 Active 3 Active Ends Object replication OBJRCV Ends Ends Active Active 2 Ends Active 2 Active 2 Ends Active Active 2 Active 2 CNRRCV Ends Ends Active Active 2 Ends Active 2 Active 2 Ends Active Active 2 Active 2 STSSND Ends Ends Active Active 2 Ends Active 2 Active 2 Ends Active Active 2 Active 2 OBJAPY Ends Active Ends Active 2 Ends Active 2 Active 2 Active Ends Active 2 Active 2

*ALL *ALLSRC *ALLTGT *DBALL *OBJALL *DBSRC *DBTGT *OBJSRC *OBJTGT *DBRDR *DBAPY Notes:

E A, E B, E A, B A, B, E B A, B A, B B, C B, D

Active1 Active1 Active1 Active1 Active1 Active1 Active1 Active1 Active1 Active1 Active1

A. Has no effect on database-only replication. New database journal entries continue to transfer to the target system over the RJ link, where they will be processed. B. Data groups that use cooperative processing may be affected by the result of this value. Ending database processes while object processes remain active may result in object activity entries being placed on hold. Similarly, ending object processes while database processes remain active may result in files being placed on hold due to error. C. New database journal entries continue to transfer to the target system over the RJ link. Existing entries stored in the log space on the target system before the end request was processed will be applied. D. New database journal entries continue to transfer to the target system over the RJ link, where they will be processed by the DBRDR. E. The data area polling process ends when values which end database source processes are specified.

160

What replication processes are ended by the ENDDG command

1. 2. 3.

The RJ link is not ended by the End options (PRC) parameter. New database journal entries continue to transfer to the target system over the RJ link. See the Notes column for additional details. These object replication processes are not available in data groups configured for database-only replication. These database replication processes are not available in data groups configured for object-only replication.

Optionally, data groups can use source-send technology instead of remote journaling for database replication. Data groups created on earlier levels of MIMIX may still be configured this way. Table 23 identifies the processes that are ended by each value for End options when source-send technology is used for database replication. The MIMIX database send (DBSND) process and database receive (DBRCV) process are replaced by the IBM i remote journal function and the DBRDR process, respectively.
Table 23. Value for PRC Processes ended by data groups configured for Source Send replication This assumes that all replication processes are active when the ENDDG request is made. Notes Source Processes DB replication DBSND 1 *ALL *ALLSRC *ALLTGT *DBALL *OBJALL *DBSRC *DBTGT *OBJSRC *OBJTGT Notes: A. Data groups that use cooperative processing may be affected by the result of this value. Ending database processes while object processes remain active may result in object activity entries being placed on hold. Similarly, ending object processes while database processes remain active may result in files being placed on hold due to error. 161 A A A A A A Ends 1 Ends 1 Active Ends 1 Active 3 Ends 1 Active Active 3 Active 3 Object replication OBJSND Ends Ends Active Active 2 Ends Active 2 Active 2 Ends Active OBJRTV Ends Ends Active Active 2 Ends Active 2 Active 2 Ends Active CNRSND Ends Ends Active Active 2 Ends Active 2 Active 2 Ends Active STSRCV Ends Ends Active Active 2 Ends Active 2 Active 2 Ends Active Target Processes DB replication DBRCV Ends Ends Active Ends Active 3 Ends Active Active 3 Active 3 DBAPY Ends Active Ends Ends Active 3 Active Ends Active 3 Active 3 Object replication OBJRCV Ends Ends Active Active 2 Ends Active 2 Active 2 Ends Active CNRRCV Ends Ends Active Active 2 Ends Active 2 Active 2 Ends Active STSSND Ends Ends Active Active 2 Ends Active 2 Active 2 Ends Active OBJAPY Ends Active Ends Active 2 Ends Active 2 Active 2 Active Ends

What replication processes are ended by the ENDDG command

Table 23. Value for PRC

Processes ended by data groups configured for Source Send replication This assumes that all replication processes are active when the ENDDG request is made. Notes Source Processes DB replication DBSND 1 Object replication OBJSND Active 2 Active 2 OBJRTV Active 2 Active 2 CNRSND Active 2 Active 2 STSRCV Active 2 Active 2 Target Processes DB replication DBRCV Active 3 DBAPY Ends 3 Object replication OBJRCV Active 2 Active 2 CNRRCV Active 2 Active 2 STSSND Active 2 Active 2 OBJAPY Active 2 Active 2

*DBRDR 4 *DBAPY Notes:

Active 3

A. Data groups that use cooperative processing may be affected by the result of this value. Ending database processes while object processes remain active may result in object activity entries being placed on hold. Similarly, ending object processes while database processes remain active may result in files being placed on hold due to error.
1. 2. 3. 4. When the database send (DBSND) process ends, the data area polling process also ends. These object replication processes are not available in data groups configured for database-only replication. These database replication processes are not available in data groups configured for object-only replication The database reader (*DBRDR) process is not used by data groups configured for source-send replication.

162

CHAPTER 6

Resolving common replication problems

Occasionally, a journaled transaction for a file or object may fail to replicate. User intervention is required to correct the problem. This chapter provides procedures to help you resolve problems that can occur during replication processing. If you are using MIMIX Availability Manager, the best place to start is with the flyover text on the icons representing problems and status. Often, this will direct you to a course of action. If you are using 5250 emulator commands, start at the MIMIX Availability Status display.

You may also need to use problem determination procedures in this chapter. Note: The procedures in this chapter are primarily for use with a 5250 emulator. The following topics are included in this chapter: Working with MIMIX managers on page 164 describes how to start, stop, and resolve problems with the system manager and journal manager. Working with message queues on page 167 describes how to use the MIMIX primary and secondary message queues from a 5250 emulator. Working with the message log on page 168 describes how to access the MIMIX message log from either user interface. Working with user journal replicated files on page 170 includes topics for how to resolve a file that is held due to an error. It also includes topics about options for placing a file on hold and releasing held files. Working with tracking entries on page 179 describes how to use tracking entries to resolve replication errors for IFS objects, data areas, or data queues that are replicated cooperatively with the user journal. It also includes topics about options for placing a tracking entry on hold and releasing held tracking entries. Working with objects in error on page 185 describes how to resolve objects in error by working with the data group activities used for system journal replication. This topic includes information about how to retry failed activity entries and how to determine whether MIMIX is automatically attempting to retry an activity. Removing data group activity history entries on page 190 describes how to manually remove completed entries for system journal replication activity. This may be necessary if you need to conserve disk space.

163

Working with MIMIX managers

MIMIX performs system-level operations using the system manager and journal manager functions. The services provided by these functions are started when MIMIX is started and must remain active in order for replication to occur. System manager and journal manager jobs are ended when MIMIX processes for an installation are ended (ENDMMX command). However, the system manager and journal manager are not ended when only replication processes are ended (ENDDG command). Delay intervals for the system manager and journal manager specified in the system definition determine how frequently these jobs check for work. You may need to start or end one or more MIMIX managers to correct a problem. You can access options for working with MIMIX managers from the Installation Services window in MIMIX Availability Manager and from the Work with Systems display (WRKSYS command) in an 5250 emulator.

Resolving status problems with system and journal managers

From Availability Manager, a problem with a system manager or journal manager is reflected by an Action required icon next to the Services item in the navigation bar. To troubleshoot, do the following: 1. Select Services from the Details area in the navigation bar. The flyover help provides information about the System Manager and the Journal Manager. Note: Click the icon to see the message log for the System Manager or the Journal Manager. 2. For systems with an Action required icon, select Start Managers and click
.

From a 5250 emulator, a problem with a system or journal manager is reflected on the MIMIX Availability Status display and the Work with Systems display. To troubleshoot, do the following: 1. Do one of the following to access the Work with Systems display: From the MIMIX Basic Main Menu, select option 1 (Availability status) and press Enter. If the Services area on the resulting Work with Availability Status display identifies a problem with a manager, use type a 9 (Troubleshoot) next to Services and press Enter. From MIMIX Intermediate Main Menu, select option 2 (Work with Systems) and press Enter.

2. The Work with Systems display appears. The first system definition in the list is for the local system. The status of the system manager and journal manager for the local system should be *ACTIVE. Most installations will not be licensed for Vision Cluster1 and should have *NONE for the Cluster Services status. Note: If the system manager status is *ACTREQ and you want to do more problem isolation, use option 7 (Display status) to view the status of each pair of jobs between systems. This is useful when resolving problems for a

164

Working with MIMIX managers

management system. 3. Type a 9 (Start) next to the system definition you want and press Enter. 4. The Start MIMIX Managers display appears. Any managers that are not running on the system will be selected to start. To submit the request, press Enter.

Starting a system manager or a journal manager

From Availability Manager, to selectively start a system manager or a journal manager for a system, do the following: 1. Select Services from the Details area in the navigation bar. 2. Select Start Managers for the System Definition that you want and click .

3. The Start MIMIX Managers display appears. By default, any manager that is not running will be selected to start. Specify the value for the type of manager you want to start at the Manager prompt and press Enter. From a 5250 emulator, to selectively start a system manager or journal manager for a system, do the following 1. From the MIMIX Availability Status screen, use option 5 (Display details) next to the Services bar. 2. The Work with Systems display appears. Type a 9 (Start) next to the system definition you want and press Enter. 3. The Start MIMIX Managers display appears. By default, any manager that is not running will be selected to start. Specify the value for the type of manager you want to start at the Manager prompt and press Enter.

Ending a system manager or a journal manager

From Availability Manager, to end a system manager or journal manager, do the following: 1. Select Services from the Details area in the navigation bar. 2. Select End Managers for the System Definition you want and click .

3. The End MIMIX Managers display appears. Specify the value for the type of manager you want to end at the Manager prompt and press Enter. The selected managers are ended. From a 5250 emulator, to end a system manager or journal manager, do the following: 1. From the MIMIX Availability Status screen, use option 5 (Display details) next to the Services bar. 2. The Work with Systems display appears with a list of the system definitions defined for the MIMIX installation. Type a 10 (End) next to the system definition you want and press Enter. 3. The End MIMIX Managers display appears. Specify the value for the type of manager you want to end at the Manager prompt and press Enter. The selected

165

managers are ended.

166

Working with message queues

Working with message queues

You can access the MIMIX primary and secondary message queues to display messages or manage the list of messages. Do the following to access a MIMIX message queue: 1. Type the command DSPMMXMSGQ and press F4 (Prompt). 2. Specify either *PRI or *SEC to access the message queue you want and press Enter. 3. The Display MIMIX Message Queue display appears listing all of the current messages. To view all of the information for a message, place the cursor on the message you want and press Enter. You can also use the function keys on this display to perform several message-related tasks. Refer to the help text (F1 key) for information about these function keys. Note: The MIMIX primary and secondary message queues are defined for each system definition. You can control the severity and type of messages to be sent to each message queue through parameters on the system definition.

167

Working with the message log

The MIMIX message log provides a common location for you to see all messages related to MIMIX products. A consolidated list of messages for all systems in the installation library is available on the management system. Note: The target system only shows messages that occurred on the target system. LVI messages are informational messages and LVE messages are error or diagnostic messages. CPF messages are generated by an underlying operating function and may be passed up to the MIMIX product. Do the following to access the message log from MIMIX Availability Manager: 1. From the top of the display, select Message Log and click . The Filter Message Log screen appears. This window allows you to subset the information in the message log. 2. Select the Start and End times you would like to view for the message log in the Date and time range fields. Note: You can also select the Most recent option to view the time range when the message to be filtered was issued. 3. Filter messages using the available Message fields. 4. Filter messages related to a specific data group using the available Data group definition fields. 5. Filter messages by the available Job fields. 6. Indicate additional information using the available Other fields. 7. Click OK to view the filtered message log. Do the following to access the MIMIX message log in the 5250 emulator: 1. Do one of the following to access the message log display: From the MIMIX Basic Main Menu, select option 13 (Work with messages) and press Enter. From the MIMIX Intermediate Main Menu, select option 3 (Work with messages) and press Enter.

2. The Work with Message Log appears with a list of the current messages. The initial view shows the message ID and text. 3. Press F11 to see additional views showing the message type, severity, the product and process from which it originated, whether it is associated with a group (for MIMIX, a data group), and the system on which it originated. 4. You can subset the messages shown on the display. A variety of subsetting options are available that allow you to manage the message log more efficiently. 5. To work with a message, type the number of the option you want and press Enter. The following options are available: 4=Remove - Use this option if you want to delete a message. When you select this option, a confirmation display appears. Verify that you want to delete the

168

Working with the message log

messages shown and press Enter. The message is deleted only from the local system. 5=Display message - Use this option to view the full text of the first level message and gain access to the second level text. 6=Print - Use this option to print the information for the message. 8=Display details - Use this option to display details for a message log entry including its from and to program information, job information, group information, product, process, originating system, and call stack information. 9=Related messages - Use this option to display a list of messages that relate to the selected message. Related messages include a summary and any detail messages immediately preceding it. This can be helpful when you have a large message log list and you want to show the messages for a certain job. 12=Display job - If job information exists on the system, you can use this option to access job information for a message log entry. The Work with Jobs display appears from which you can select options for displaying specific information about the job.

169

Working with user journal replicated files

When a problem occurs while replicating files through the user journal, MIMIX reports the existence of replication errors on higher level windows in MIMIX Availability Manager and on displays in the 5250 emulator. MIMIX also reports the problem in the status of the associated data group file entry. File replication problems are categorized as follows: Held due to error - If a journal transaction is not replicated successfully, the file entry is placed in *HLDERR status. This indicates a problem that must be resolved. Held for other reasons - File entries can also be placed in a variety of other held statuses by user action or by MIMIX. Generally, these statuses are also considered problems; some are transitional conditions that resolve automatically while others require user action. When a data group file entry has a status of *HLD, *HLDERR, or *HLDRLTD, MIMIX retains log spaces so that journal entries that are being held can be released and applied to the target system. File entries should not be left in these states for an extended period. Note: Transactions and hold logs are discarded for file entries with a status of *HLDERR and an error code of IG. Such a file must be synchronized. For information about resolving problems with IFS objects and library-based objects that are cooperatively processed with the user journal, see Working with tracking entries on page 179.

Working with files in error

Data group file entries should not be left in *HLDERR state for any extended period. In MIMIX Availability Manager, file replication errors are reported in the Problem list for the selected data group on the Data Group Status window. Additional detail is available from the file view of the Data Group Details - Activity window. Do the following: 1. From the Data Group Status window, select the data group you want from the list. 2. Locate Files held due to error in the Problem list for the data group and click .

3. The Data Group Details - Activity window opens to display file activity for the data group that is experiencing replication problems. Files that are held due to an error are highlighted in red. The preferred action is displayed in the Action list. Note: If additional errors with higher priorities exist for the file, the preferred action displayed in the Action list will be for the highest priority error. 4. Select the action you want from the Action list and click .

In a 5250 emulator, file replication errors are reported in the DB Errors column on the Work with Data Groups display.

170

Working with user journal replicated files

To access a list of files in error for a data group, do the following: 1. From the MIMIX Basic Main Menu select option 1 (Availability status) and press Enter. The MIMIX Availability Status display appears. 2. Use option 5 (Display details) next to Replication. The Work with Data Groups display appears. 3. The DB Errors column identifies whether a data group has any files held due to errors, as well as any cooperatively processed IFS objects, data areas, and data queues that are on held due to errors. Files on hold for other reasons are not reflected in this column. Notes: To determine if there are files on hold for other reasons, use the procedure in Working with the detailed status of data groups on page 61. For information about cooperatively processed IFS objects, data areas, and data queues, see Working with tracking entries on page 179.

4. Type 12 (Files not active) next to the data group you want and press Enter. 5. The Work with DG File Entries display appears with a list of the file entries in error for the data group you selected. Significant capability is available for addressing common replication problems and journaling problems. Do the following: a. Use F10 to toggle between views showing status, journaling status, database apply session in use, and the journal entry and error code. b. Any entry with a status of *HLD, *HLDERR, *HLDIGN or *HLDRLTD indicates that action is required. Use Table 24 to identify choices based on the file entry status. c. Use options identified in Table 25 to address journaling or replication problems. 6. If necessary, take action to prevent the error from happening again. Refer to the following topics: Correcting file-level errors on page 176 Correcting record-level errors on page 177

Table 24. Status *ACTIVE

Possible actions based on replication status of a file entry Preferred Action1 Unless an error has occurred, no action is necessary. Entries in the user journal for the file are replicated and applied. If necessary, any of the options to hold journal entries can be used. User action is required to release the file entry (option 26) so that held journal entries from the user journal can be applied to the target system. User action is required. Attempt to resolve the error by synchronizing the file (option 16).

*HLD *HLDERR

171

Table 24. Status *HLDIGN

Possible actions based on replication status of a file entry Preferred Action1 User action is required to either synchronize the file (option 16) or to change the configuration if you no longer want to replicate the file. Journal entries for the file are discarded. Replication is not occurring and the file may not be synchronized. Depending on the circumstances, Release may also be an option. These are transitional states that should resolve to *ACTIVE. If these status persist, check the journaling status for the entry. MIMIX retains log spaces for the held journal entries for the duration of these temporary hold requests. The file entry is held because an entry could not be applied due to a condition which required waiting on some other condition (such as inuse). After a short delay, the database apply job will automatically attempt to process this entry again. The preferred action is to allow MIMIX to periodically retry the file entry. By default, the database apply job will automatically attempt to process the entry every 5 minutes for up to 1 hour. Manually releasing the file entry will cause MIMIX to attempt to process the entry immediately User action is required for a file in the same network. View the related files (option 35). A file that is related due to a dependency, such as a constraint or a materialized query table, is held. Resolving the problem for the related held file will resolve this status. The file is waiting to be released by the DB apply process and will be changed to *ACTIVE. If the status does not change to *ACTIVE, check the journaling status. If this status persists, you may need to synchronize (option 16). These are transitional states that should resolve automatically. The file entry represents a member that is being processed cooperatively between the CMPFILDTA command and the database apply process.

*HLDRGZ *HLDRNM *HLDPRM *HLDSYNC *HLDRTY

*HLDRLTD

*RLSWAIT

*CMPACT *CMPRLS *CMPRPR

1.

Evaluate the cause of the problem before taking any action.

Table 25. Option

Options for working with file entries from the Work with DG FIle Entries display Additional Information See Starting journaling for physical files on page 195. See Ending journaling for physical files on page 196. See Verifying journaling for physical files on page 197. See topic Synchronizing database files in the MIMIX Reference book.

9=Start journaling 10=End journaling 11=Verify journaling 16=Sync DG file entry

172

Working with user journal replicated files

Table 25. Option

Options for working with file entries from the Work with DG FIle Entries display Additional Information See topic Working with journal transactions for files in error on page 173. See topic Placing a file on hold on page 174. See topic Ignoring a held file on page 174. See topic Releasing a held file at a synchronization point on page 175. See topic Releasing a held file on page 176. See topic Releasing a held file and clearing entries on page 176. Available for entries with a status of *HLDERR that identify a member. See topic Comparing and repairing file data - members on hold (*HLDERR) in the MIMIX Reference book.

20=Work with file error entries 23=Hold file 24=Ignore file 25=Release wait 26=Release 27=Release clear 31=Repair member data 35=Work with related files

Working with journal transactions for files in error

When resolving problems for a file that is in *HLDERR state, a MIMIX administrator may find it useful to examine the journal entries that are being held by MIMIX. Although you can determine why a file is in error from either the source or target system, to view the actual journal entries, you must be on the target system. If you attempt to view the journal entries from the source system, MIMIX will indicate that you are on the incorrect system to view the information. Do the following: 1. From the subsetted list of files in error for a data group on the Work with DG File Entries display, type 20 (Work with file error entries) next to the file entry you want and press Enter. 2. The Work with DG FE on Hold display appears. A variety of information about the transaction appears on the display. Note: The values shown in the Sequence number column may be truncated if the journal supports *MAXOPT3 for the receiver size and the journal sequence number value exceeds the available display field. When truncation is necessary, the most significant digits (left-most) are omitted. Truncated journal sequence numbers are prefixed by '>'. The First journal sequence number field displays the full sequence number of the first item displayed in the list. a. Locate the transaction that caused the file to be placed on hold. Use the Position to field to position the list to a specific sequence number.

173

b. Select the option (Table 26) you want to use on the journal transaction:
Table 26. 2=Change Options available from the Work with DG FE on Hold display. You can change the contents or characteristics of the journal entry. Use this option with caution. Any changes can affect the validity of data in the journal entry. You can delete the journal entry. You can display details for the specified journal entry associated with the data group file entry in question. You can immediately apply a transaction that has caused a file to go on hold. The entry you selected is immediately applied to the file outside of the apply process. If the apply is successful, the error/hold entry that was applied is removed from the error/hold log. However, if the apply fails, a message is issued and the entry remains in the error/hold log. This process does not release the file; it only applies the selected entry.

4=Delete 5=Display 9=Immediate apply

Placing a file on hold

Use this procedure to hold any journal entries for a file identified by a data group file entry. Avoid leaving a file entry on hold for any extended period. File entries with a status of *ACTIVE, *HLDRGZ, *HLDRNM, *HLDPRM, *HLDSYNC, *HLDRLTD, and *RLSWAIT can be placed on hold. The request changes the file entry status to *HLD. Any journal entries for the associated file are replicated but not applied. If the file is being processed by an active apply session, suspending of the update process can take a short time to complete. You will receive a message when the file is held. MIMIX retains log spaces containing any replicated journal entries in anticipation that the file entry will be released. When the file is released, the accumulated journal entries will be applied. The *HLD status remains until additional action is taken. Do the following: 1. From the MIMIX Basic Main Menu select option 1 (Availability status) and press Enter. The MIMIX Availability Status display appears. 2. Use option 5 (Display details) next to Replication. The Work with Data Groups display appears. 3. Type 17 (File entries) next to the data group you want and press Enter. 4. The Work with DG File Entries display appears. Type 23 (Hold file) next to the entry you want and press Enter.

Ignoring a held file

Use this procedure to ignore any journal entries for an file identified by a data group file entry. The request changes the file entry status to *HLDIGN. Any journal entries for the associated file, including any hold logs, are discarded. The *HLDIGN status remains until additional action is taken.

174

Working with user journal replicated files

Note: Be certain that you want to use the ignore feature. Any ignored transactions cannot be retrieved. You must replace the object on the target system with a current version from the source system. If a file has been on hold for a long time or you expect that it will be, the amount of storage used by the error/hold log space can be quite large. If you anticipate that you will need to save and restore the file or replace it for any other reason, it may be best to just ignore all current transactions. Do the following: 1. From the MIMIX Basic Main Menu select option 1 (Availability status) and press Enter. The MIMIX Availability Status display appears. 2. Use option 5 (Display details) next to Replication. The Work with Data Groups display appears. 3. Type 17 (File entries) next to the data group you want and press Enter. 4. The Work with DG File Entries display appears. Type 24 (Ignore file) next to the entry you want and press Enter. The status of the file is changed to *HLDIGN. The file entry is ignored. Journal entries for the file entry, including any hold logs, are discarded.

Releasing a held file at a synchronization point

Use this procedure to wait for a synchronization point to release any held journal entries for file identified by a data group file entry, then resume replication. The request changes the file entry status to *RLSWAIT. Any journal entries for the associated file are discarded until a File member saved (F-MS) journal entry or a Start of save of a physical file member using save-while-active function (F-SS) is encountered. This is the synchronization point. The file entry status is then changed to *ACTIVE and all journal entries that were held after the synchronization point are applied. If the F-MS or F-SS journal entry is not in the log space, the file entry remains in *RLSWAIT status. If you are unsure as to how many save requests might accumulate for an object, you can synchronize the file associated with the file entry. The entry status will become *ACTIVE. To wait for a synchronization point before releasing a held file, do the following: 1. From the MIMIX Basic Main Menu select option 1 (Availability status) and press Enter. The MIMIX Availability Status display appears. 2. Use option 5 (Display details) next to Replication. The Work with Data Groups display appears. 3. Type 17 (File entries) next to the data group you want and press Enter. 4. The Work with DG File Entries display appears. Type 25 (Release wait) next to the entry you want and press Enter.

175

Releasing a held file

Use this procedure to immediately release any held journal entries for file identified by a data group file entry with a status of *HLD and resume replication. The request changes the file entry status to *ACTIVE. Any held journal entries for the associated file are applied. Normal replication of the file resumes. While a file is being released, the appropriate apply session suspends its operations on other files. This allows the released file to catch up to the current level of processing. If a file or member has been on hold for a long time, this can be lengthy. Do the following to immediately release a held file or file member: 1. From the MIMIX Basic Main Menu select option 1 (Availability status) and press Enter. The MIMIX Availability Status display appears. 2. Use option 5 (Display details) next to Replication. The Work with Data Groups display appears. 3. Type 17 (File entries) next to the data group you want and press Enter. 4. The Work with DG File Entries display appears. Type 26 (Release) next to the entry you want and press Enter

Releasing a held file and clearing entries

Use this procedure to clear any held journal entries for a file identified by a data group file entry, then resume replication. The request changes the file entry status to *ACTIVE. Any held journal entries for the associated file are discarded. Journal entries received after the file entry status became *ACTIVE are applied, resuming normal replication. If a file entry is on hold and its associated file has been synchronized in such a way that the held entries already exist in the restored file, this procedure will ensure that those entries are not re-applied. This procedure will not work if the file is being actively updated on the source system. Do the following to release a held file and clear any journal entries that were replicated but not applied: 1. From the MIMIX Basic Main Menu select option 1 (Availability status) and press Enter. The MIMIX Availability Status display appears. 2. Use option 5 (Display details) next to Replication. The Work with Data Groups display appears. 3. Type 17 (File entries) next to the data group you want and press Enter. 4. The Work with DG File Entries display appears. Type 27 (Release clear) next to the entry you want and press Enter

Correcting file-level errors

Typically, file-level errors can be categorized as one of the following: A problem with the configuration of files defined for replication.

176

Working with user journal replicated files

A discrepancy in the file descriptions between the management and network systems An operational error.

This topic identifies the most common file-level errors and measures that you can take to prevent the problem from recurring. See also Correcting record-level errors on page 177. Once you diagnose and correct a file-level error, the problem rarely manifests itself again. Some of the most common file-level errors are: Authority: The MIMIXOWN user profile defined in the MIMIX job description does not have authority to perform a function on the target system. You can prevent this problem by ensuring that the MIMIXOWN user profile has all object authority (*ALLOBJ). This guarantees that the user profile has all the necessary authority to run IBM i commands and has the ability to access the library and files on the management system. Refer to the License and Availability Manager book for more information about the MIMIXOWN user profile and authority. Objects existence or corruption: MIMIX cannot run a function against a file on the target system because the file or a supporting object (such as logical files) does not exist or has become damaged. System security is the only way to prevent an object from being accidentally deleted from the target system. Make sure that only the correct personnel have the ability to remove objects from the target system where replicated data is applied. Also, ensure that application programs do not delete files on the target system when there are no apply sessions running. MIMIX subsystem ended: If the MIMIX subsystem is ended in an immediate mode while MIMIX processes are still active, files may be placed in a Held status. This is a result of MIMIX being unable to complete a transaction normally. After MIMIX is restarted, you only need to release the affected files.

Correcting record-level errors

Record-level errors occur when MIMIX updates or attempts to update a file and the feedback from the update process indicates a discrepancy between the files on the management and network system. Record-level errors can usually be traced back to problems with one of the following: The system Unique application environments, such as System 36 code running in native IBM i. Operational errors.

Record written in error

This section describes the most common record-level errors. MIMIX DB Replicator was able to write the record on the target system; however, it wrote to the wrong relative record number. In most situations, the IBM i database function writes a new record to the end of a file. MIMIX did so, but it did not match the relative record number of the sending system. Usually this error occurs when transactions (journal

177

entries) are skipped on the send system. Common reasons why records are written in error include the following: Journaling was ended: When journaling is ended, transaction images are not being collected. If users update the files while journaling is not running, no journal entries are created and MIMIX DB Replicator has no way of replicating the missing transactions. The best way to prevent this error is to restrict the use of the Start Journaling Physical File (STRJRNPF) and End Journaling Physical File (ENDJRNPF) commands. User journal replication was restarted at the wrong point: When you change the starting point of replication for a data group, it is imperative that transactions are not skipped. Apply session restarted after a system failure: This is caused when the target system experiences a hard failure. MIMIX always updates its user spaces with the last updated and sent information. When a system fails, some information may not be forced to disk storage. The data group definition parameter for database apply processing determines how frequently to force data to disk storage. When the apply sessions are restarted, MIMIX may attempt to rewrite records to the target system database. Unable to write/update a record: This error is caused when MIMIX cannot access a record in a file. This is usually caused when there are problems with the logical files associated with the file or when the record does not exist. The best way to prevent this error is to make sure that replication is started in the correct position. This error can also be due to one of the problems listed in topic Correcting file-level errors on page 176. Unable to delete a record: This is caused when MIMIX is trying to delete a record that does not exist or has a corrupted logical file associated with the physical file. This error can also be due to one of the problems listed in topic Correcting file-level errors on page 176.

178

Working with tracking entries

Working with tracking entries

Tracking entries identify library-based objects (data areas and data queues) and IFS objects configured for cooperative processing (advanced journaling). MIMIX Availability Manager and the 5250 emulator provide interfaces for viewing status and working with common problems that can occur while replicating objects identified by IFS and object tracking entries. Held tracking entries: Status for the replicated objects is reported on the associated tracking entries. If a journal transaction is not replicated successfully, the tracking entry is placed in *HLDERR status. This indicates a problem that must be resolved. Tracking entries can also be placed in *HLD, *HLDIGN statuses by user action These statuses are reported as held for other reasons and also require user action. When a tracking entry has a status of *HLD or *HLDERR, MIMIX retains log spaces so that journal entries that are being held can be released and applied to the target system. Tracking entries should not be left in these states for an extended period. Additional information: To determine if a data group has any IFS objects, data areas, or data queues configured for advanced journaling, see Determining if non-file objects are configured for user journal replication on page 234. When working with tracking entries, especially for IFS objects, you should be aware of the information provided in Displaying long object names on page 224.

Working with tracking entries from MIMIX Availability Manager

From within MIMIX Availability Manager, you can work with tracking entries that are experiencing replication problems from the Data Group Details - Activity window.

Accessing the Data Group Details - Activity window

The Data Group Details - Activity window provides access to status and actions available for working with object tracking entries and IFS tracking entries. To access the Data Group Details - Activity window, do the following: 1. From the navigation bar, select Data Groups. 2. Select the data group you want from the list so its information is displayed in the Summary area.Then select Display Details and click . 3. The Data Group Details - Activity window opens with the most severe activity displayed. 4. Select Activity from the Details area of the navigation bar. Then select one of the following from the Activity Types area: IFS Tracking Object Tracking

5. The Data Group Details - Activity window opens for the type of tracking entry you selected. Only tracking entries that are experiencing replication problems are displayed.

179

MIMIX customizes the list of actions available for each tracking entry displayed so that only actions that are applicable can be selected. The preferred action is listed first in the available list. Online help provides additional information about the available actions.

Working with tracking entries from a 5250 emulator

From a 5250 emulator, you can access the following displays to work with tracking entries in any status: Work with DG IFS Trk. Entries display (WRKDGIFSTE command) Work with DG Obj. Trk. Entries display (WRKDGOBJTE command)

Accessing the appropriate tracking entry display

To access IFS tracking entry or object tracking entry displays for a data group, do the following: 1. From the MIMIX Basic Main Menu select option 1 (Availability status) and press Enter. The MIMIX Availability Status display appears. 2. Use option 5 (Display details) next to Replication. The Work with Data Groups display appears. 3. Next to the data group you want, type the number for the option you want and press Enter. Table 27 shows the options for tracking entries.
Table 27. Tracking entry options on the Work with Data Groups display Result Lists all IFS tracking entries for the selected data group on the Work with DG IFS Trk. Entries display. Lists IFS tracking entries for the selected data group with inactive status values (*HLD, *HLDERR, *HLDIGN, *HLDRNM, and *RLSWAIT) on the Work with DG IFS Trk. Entries display. Lists all object tracking entries for the selected data group on the Work with DG Obj. Trk. Entries display. Lists object tracking entries for the selected data group with inactive status values (*HLD, *HLDERR, *HLDIGN, and *RLSWAIT) on the Work with DG Obj. Trk. Entries display.

Select Option 50=IFS trk entries 51=IFS trk entries not active 52=Obj trk entries 53=Obj trk entries not active

4. The tracking entry display you selected appears. Significant capability is available for addressing common replication problems and journaling problems. Do the following: a. Use F10 to toggle between views showing status, journaling status, and the database apply session in use. b. Any entry with a status of *HLD, *HLDERR or *HLDIGN indicates that action is required. The identified object remains in this state until action is taken. Statuses of *HLD and *HLDERR result in journal entries being held but not applied. Use Table 28 to identify choices based on the tracking entry status.

180

Working with tracking entries

c. Use options identified in Table 29 to address journaling problems or replication problems.

Table 28. Status *ACTIVE

Possible actions based on replication status of a tracking entry Preferred Action1 Unless an error has occurred, no action is necessary. Entries in the user journal for the IFS object are replicated and applied. If necessary, any of the options to hold journal entries can be used. User action is required to release the entry (option 26) so that held journal entries from user journal can be applied to the target system. User action is required. Attempt to resolve the error by synchronizing the file (option 16). User action is required to either synchronize the object (option 16) or to change the configuration if you no longer want to replicate the object. Journal entries for the object are discarded. Replication is not occurring and the object may not be synchronized. Depending on the circumstances, Release may also be an option. This is a transitional state for IFS tracking entries that should resolve to *ACTIVE. If this status persists, check the journaling status for the entry. Object tracking entries cannot have this status. If the status does not change to *ACTIVE, you may need to synchronize (option 16)

*HLD *HLDERR *HLDIGN

*HLDRNM

*RLSWAIT
1.

Evaluate the cause of the problem before taking any action.

Table 29. Option

Options for working with tracking entries Additional Information See Removing a tracking entry on page 184 Identifies an object, its replication status, journaling status, and the database apply session used. Creates a spooled file which can be printed See Starting journaling for IFS objects on page 198 and Starting journaling for data areas and data queues on page 201. See Ending journaling for IFS objects on page 199 and Ending journaling for data areas and data queues on page 202. See Verifying journaling for IFS objects on page 200 and Verifying journaling for data areas and data queues on page 203.

4=Remove 5=Display 6=Print 9=Start journaling 10=End journaling 11=Verify journaling

181

Table 29. Option

Options for working with tracking entries Additional Information Synchronizes the contents, attributes, and authorities of the object represented by the tracking entry between the source and target systems. For more information, see topic Synchronizing tracking entries in the MIMIX Reference book. See Holding journal entries associated with a tracking entry on page 182. See Ignoring journal entries associated with a tracking entry on page 182. See Waiting to synchronize and release held journal entries for a tracking entry on page 183. See Releasing held journal entries for a tracking entry on page 183. See Releasing and clearing held journal entries for a tracking entry on page 184.

16=Synchronize

23=Hold 24=Ignore 25=Release wait 26=Release 27=Release clear

Holding journal entries associated with a tracking entry

Use this procedure to hold any journal entries for an object identified by a tracking entry. Avoid leaving a tracking entry on hold for any extended period. The request changes the tracking entry status to *HLD. Any journal entries for the associated IFS object, data area, or data queue are replicated but not applied. MIMIX retains log spaces containing any replicated journal entries in anticipation that the tracking entry will be released. When the tracking entry is released, the accumulated journal entries will be applied. The *HLD status remains until additional action is taken. Do the following: 1. Access the IFS or object tracking entry display as described in Accessing the appropriate tracking entry display on page 180. 2. Type 23 (Hold) next to the tracking entry for the object you want and press Enter.

Ignoring journal entries associated with a tracking entry

Use this procedure to ignore any journal entries for an object identified by a tracking entry. The request changes the tracking entry status to *HLDIGN. Any journal entries for the associated IFS object, data area, or data queue, including any hold logs, are discarded. The *HLDIGN status remains until additional action is taken. Note: Be certain that you want to use the ignore feature. Any ignored transactions cannot be retrieved. You must replace the object on the target system with a current version from the source system. If a tracking entry has been on hold for a long time or you expect that it will be, the amount of storage used by the error/hold log space can be quite large. If you

182

Working with tracking entries

anticipate that you will need to save and restore the object or replace it for any other reason, it may be best to just ignore all current transactions. Do the following: 1. Access the IFS or object tracking entry display as described in Accessing the appropriate tracking entry display on page 180. 2. Type 24 (Ignore) next to the tracking entry for the object you want and press Enter.

Waiting to synchronize and release held journal entries for a tracking entry
Use this procedure to wait for a synchronization point to release any held journal entries for an object identified by a tracking entry, then resume replication. The request changes the tracking entry status to *RLSWAIT. Any journal entries for the associated IFS object, data area, or data queue are discarded until an object saved journal entry is encountered. This is the synchronization point. The tracking entry status is then changed to *ACTIVE and all journal entries that were held after the synchronization point are applied. If the object saved journal entry is not in the log space, the tracking entry remains in *RLSWAIT status. If you are unsure as to how many save requests might accumulate for an object, you can synchronize the object associated with the tracking entry. The tracking entry status will become *ACTIVE. Do the following: 1. Access the IFS or object tracking entry display as described in Accessing the appropriate tracking entry display on page 180. 2. Type 25 (Release wait) next to the tracking entry for the object you want and press Enter.

Releasing held journal entries for a tracking entry

Use this procedure to immediately release any held journal entries for an object identified by a tracking entry with a status of *HLD or *HLDERR and resume replication. The request changes the tracking entry status to *ACTIVE. Any held journal entries for the associated IFS object, data area, or data queue are applied. Normal replication of the object resumes. Do the following: 1. Access the IFS or object tracking entry display as described in Accessing the appropriate tracking entry display on page 180. 2. Type 26 (Release) next to the tracking entry for the object you want and press Enter

183

Releasing and clearing held journal entries for a tracking entry

Use this procedure to clear any held journal entries for an object identified by a tracking entry, then resume replication. The request changes the tracking entry status to *ACTIVE. Any held journal entries for the associated IFS object, data area, or data queue are discarded. Journal entries received after the tracking entry status became *ACTIVE are applied, resuming normal replication. If a tracking entry is on hold and its associated object has been synchronized in such a way that the held entries already exist in the restored object, this procedure will ensure that those entries are not re-applied. Do the following: 1. Access the IFS or object tracking entry display as described in Accessing the appropriate tracking entry display on page 180. 2. Type 27 (Release clear) next to the tracking entry for the object you want and press Enter.

Removing a tracking entry

Use this procedure to remove a duplicate tracking entry for an IFS object, data area, or data queue. A tracking entry with a status of *HLDERR cannot be removed. Note: Do not use this procedure to prevent user journal replication of an object represented by a tracking entry. If you need to exclude the object from replication or have it replicated through the system journal instead of the user journal, change or create the appropriate data group IFS entry or object entry. Do the following: 1. Access the IFS or object tracking entry display as described in Accessing the appropriate tracking entry display on page 180. 2. Type 4 (Remove) next to the tracking entry you want to remove and press Enter. 3. You will see a confirmation display. To remove the tracking entry, press Enter.

184

Working with objects in error

Working with objects in error

Use this topic to work with replication errors for objects replicated through the system journal. To access a list of objects in error for a data group, do the following: 1. From the MIMIX Basic Main Menu select option 1 (Availability status) and press Enter. The MIMIX Availability Status display appears. 2. Use option 5 (Display details) next to Replication. The Work with Data Groups display appears. 3. Type 13 (Objects in error) next to the data group you want which has values shown in the Obj Errors column and press Enter. 4. The Work with Data Group Activity display appears with a list of the objects in error for the data group you selected. You can do any of the following: Use F10 (Error view) to see the reason why the object is in error. Use F11 to change between views for objects, DLOs, IFS objects, and spooled files. Use the options identified in Table 30 to resolve the errors. Type the number of the option you want next to the object and press Enter
Options on the Work with Data Group Activity display for working with objects in error. Use this option to remove an entry with a *COMPLETED or *FAILED status from the list. For entries with *FAILED status, this option removes only the failed entry. Prompting is available for extended capability. You may need to take action to synchronize the object associated with the entry.
Note: If an entry with a status of *FAILED has related entries in *DELAYED status, you can remove both the failed and the delayed entries in one operation by using option 14 (Remove related).

Table 30.

4=Remove

For more information, see Removing data group activity history entries on page 190. 7=Display message 8=Retry Use this option to display any error message that is associated with the entry. Use this option to retry the data group activity. MIMIX changes the entry status to pending and attempts the failed operation again.
Note: It is possible to schedule the request for a time when the retry is more likely to be successful. For more information about retrying failed entries, see Retrying data group activity entries on page 188.

185

Table 30.

Options on the Work with Data Group Activity display for working with objects in error. Use this option to access the Work with DG Activity Entries display. From the display you can display additional information about replicated journal transactions for the object, including the journal entry type and access type (if available), as well as see whether the object is undergoing delay retry processing. You can also take options to display related entries, view error messages for a failure, and synchronize the object. For more information, see Using the Work with DG Activity Entries display on page 186. Use this option to remove an entry with a status of *FAILED and any related entries that have a status of *DELAYED. You may need to take action to synchronize the object associated with the entry.

12=Work with entries

14=Remove related

Using the Work with DG Activity Entries display

From the Work with DG Activity Entries display, you can display information about and take actions on activity entries for a replicated object. To access the display, select option 12 (Work with entries) from the Work with Data Group Activity display. Table 31 lists the available options.
Table 31. Options available on the Work with DG Activity Entries display. Use this option to remove an individual entry with a *COMPLETED or *FAILED status from the list. For entries with *FAILED status, this option removes only the failed entry. You may need to take action to synchronize the object associated with the entry.
Note: No prompting is available when using this option from this display. To prompt for additional capability, use the option to remove from the Work with Data Group Activity display. For more information, see Removing data group activity history entries on page 190.

4=Remove

5=Display

Use this option display details about the individual entry. The information available about the object includes whether the object is undergoing delay retry processing, and journal entry information, including access type information for T-SF, T-YC, and T-ZC journal entry types. For more information, see Determining whether an activity entry is in a delay/retry cycle on page 189 Use this option to print the entry. Use this option to display the error message associated with the processing failure for the entry. Use this option to retry the data group activity entry. MIMIX changes the entry status to pending and attempts the failed operation again as soon as possible.

6=Print 7=Display message 8=Retry

186

Working with objects in error

Table 31.

Options available on the Work with DG Activity Entries display. Displays entries related to the specified object. For example, use this option to see entries associated with a move or rename operation for the object. Displays the job that was processing the object when the error occurred, if the still job information exists and is on this system. Use this option to synchronize objects defined to MIMIX for system journal replication (objects that are not configured for cooperative processing). Activity entries with *ACTIVE or *COMPLETED status can be synchronized, as well as entries with a *FAILED status and with the following journal types: T-CO, T-CP, T-OR, T-SE, T-ZC (see notes), T-YC, and T-SF (see notes). A confirmation display allows you to confirm your choices before the request is processed. Entries are placed in a pending synchronization status. When the data group is active, the contents of the object, its attributes, and its authorities are synchronized between the source and target systems. The status of the activity entry is set to completed by synchronization. Notes: To synchronize files defined for cooperative processing, use the Synchronize DG File Entry (SYNCDGFE) command. Spooled files (T-SF journal entries) with the following access types can be synchronized: C = spooled file created; U = spooled file changed. Changed objects (T-ZC journal entries) with the following access types can be synchronized: 1 (Add); 7 (Change); 25 (Initialize); 29 (Merge); 30 (Open); 34 (Receive); 36 (Reorganize); 50 (Set); and 51 (Send).

9=Display related

12=Display job 16=Synchronize

187

Retrying data group activity entries

Data group activity entries that did not successfully complete replication have a status of *FAILED. These failed data group activity entries are also called error entries. You can request to retry processing for these activity entries. Activity entries with a status of *ACTIVE can also be retried in some circumstances. For example, you may want to retry an entry that is delayed but which has no preceding pending activity entry. Or, you may want to retry a pending entry that is undergoing processing in a delay retry cycle. The retry request places the activity entry in the queue for processing by the system journal replication process where the failure or delay occurred. Activity entries with a status of *FAILED or *DELAYED are set to *PENDING until they are processed.

Retrying a failed data group activity entry

You can manually request that MIMIX retry processing for a data group activity entry that has a status of *FAILED. The retry can be requested from either the Work with Data Group Activity display or from the Work with DG Activity Entries display. Note: Only the Work with Data Group Activity supports the ability to schedule the retry request for a time in the future when the request is more likely to be successful. To retry failed (error) activity entries, do the following: 1. From the Work with Data Groups display, type a 13 (Objects in error) next to the data group you want that has values shown in the Obj Errors column and press Enter. 2. The Work with Data Group Activity display appears with a list of the objects in error for the data group selected. Type an 8 (Retry) next to the entry you want and do one of the following: To submit the retry request for immediate processing, press Enter. Then skip to Step 4. To schedule the retry request for a time at which it is more likely to be successful, press F4 (Prompt).

3. On the Retry DG Activity Entries (RTYDGACTE) display, specify a value for the Time of day to retry prompt. Then press Enter. You can specify a specific time within 24 hours. The scheduled time is based on the time on the system from which the request is submitted regardless of the system on which the activity to retry occurs. When you submit a retry request for a scheduled time, MIMIX will make the entry active and will wait until the specified time before retrying the request. The scheduled time is the earliest the request will be processed. Be sure to consider any time zone differences between systems as you determine a scheduled time. For additional information and examples, press F1 (Help). 4. The Confirm Retry of DG Activity display appears. Press Enter. If failed activity entries occur frequently, consider using the third delay retry cycle. When the Automatic object recovery policy is enabled, a third retry cycle is performed

188

using the settings in effect from the Number of third delay/retries and Third retry interval (min.) policies. These policies can be set for the installation or for a specific data group.

Determining whether an activity entry is in a delay/retry cycle

This procedure allows you to check the status of an activity entry to determine whether MIMIX is attempting automatic delay retry cycles for the object. 1. From the Work with Data Groups display, type a 14 (Active objects) next to the data group you want and press Enter. 2. The Work with Data Group Activity display appears with a list of the objects that are actively being replicated. 3. Type a 12 (Work with Entries) next to the list entry for the object you want and press Enter. The Work with DG Activity Entries display appears with the list of activity entries for the object you selected. 4. To view additional details for an entry, type a 5 (Display) next to the activity entry you want and press Enter. The Display DG Activity Details display appears. 5. Check the value listed in the Waiting for retry field. The value *YES is displayed when the activity entry is undergoing automatic delay/retry processing. Delayed or failed activity entries and pending activity entries that are not in a delay retry cycle will always have a value of *NO. 6. When the value of the Waiting for retry field is *YES, the Delay/Retry Processing Information fields are also available and provide the following information: The Retries attempted field identifies the number of times that MIMIX has attempted to process the activity entry. The Retries remaining field identifies the remaining number of times that MIMIX can automatically attempt to retry the activity entry. MIMIX uses only as many of the remaining retry attempts as necessary to achieve a successful attempt. The Delay interval (seconds) field identifies the number of seconds between the previous attempt and the next retry attempt. The Timestamp of next attempt field identifies the approximate date and time that MIMIX will make the next attempt to process the activity entry. Other pending activity may affect when the attempt actually occurs.

189

Removing data group activity history entries

MIMIX maintains history of successfully completed distribution requests to provide a record of all object, DLO, and IFS replication activity completed by system journal replication processes. While MIMIX efficiently uses disk space and removes completed requests according to the value specified in the Keep data group history parameter of the system definition, you may occasionally need to manually remove completed activity entries. One reason to manually remove completed entries may be to conserve disk space, while another may be to clean up entries for an object that has been removed from replication as a result of a configuration change. Note: Your business policies and procedures may require that you archive completed activity entries to tape before you delete them. To remove completed activity entries, do the following: 1. From the Work with Data Groups display, type 28 (Completed objects) next to the data group you want and press Enter. The Work with Data Group Activity display appears with a list of objects with completed entries. 2. Type a 4 (Remove) next to the entry you want and do one of the following: To remove all available completed entries for the selected object, press Enter. Then continue with Step 4. To change the selection criteria to include entries for additional objects or to limit the entries based on a time range, press F4 (Prompt). The Remove DG Activity Entries (RMVDGACTE) display appears.

3. To change the selection criteria, do the following as needed: To remove a subset of completed entries for the selected object based on the timestamp of the replicated journal entries, specify values for Starting date and time and Ending date and time prompts. To expand the set of objects for which completed entries will be removed, change the values of the following prompts as needed: For an expanded set of object types, use the Object type prompt. For a library based object, use the Object and Library prompts. For a DLO, use the Document and Folder prompts. For an IFS object use the IFS object prompt. For a spooled file, use the Spooled file name, Output queue, and Library prompts. 4. A confirmation display appears. Press Enter.

190

CHAPTER 7

Starting, ending, and verifying journaling

This chapter describes procedures for starting and ending journaling. Journaling must be active on all files, IFS objects, data areas and data queues that you want to replicate through a user journal. Normally, journaling is started during configuration. However, there are times when you may need to start or end journaling on items identified to a data group. The topics in this chapter include: What objects need to be journaled on page 192 describes, for supported configuration scenarios, what types of objects must have journaling started before replication can occur. It also describes when journaling is started implicitly, as well as the authority requirements necessary for user profiles that create the objects to be journaled when they are created. MIMIX commands for starting journaling on page 194 identifies the MIMIX commands available for starting journaling and describes the checking performed by the commands. Journaling for physical files on page 195 includes procedures for displaying journaling status, starting journaling, ending journaling, and verifying journaling for physical files identified by data group file entries. Journaling for IFS objects on page 198 includes procedures for displaying journaling status, starting journaling, ending journaling, and verifying journaling for IFS objects replicated cooperatively (advanced journaling). IFS tracking entries are used in these procedures. Journaling for data areas and data queues on page 201 includes procedures for displaying journaling status, starting journaling, ending journaling, and verifying journaling for data area and data queue objects replicated cooperatively (advanced journaling). IFS tracking entries are used in these procedures.

191

What objects need to be journaled

A data group can be configured in a variety of ways that involve a user journal in the replication of files, data areas, data queues and IFS objects. Journaling must be started for any object to be replicated through a user journal or to be replicated by cooperative processing between a user journal and the system journal. Requirements for system journal replication - System journal replication processes use a special journal, the security audit (QAUDJRN) journal. Events are logged in this journal to create a security audit trail. When data group object entries, IFS entries, and DLO entries are configured, each entry specifies an object auditing value that determines the type of activity on the objects to be logged in the journal. Object auditing is automatically set for all objects defined to a data group when the data group is first started, or any time a change is made to the object entries, IFS entries, or DLO entries for the data group. Because security auditing logs the object changes in the system journal, no special action is need. Requirements for user journal replication - User journal replication processes require that the journaling be started for the objects identified by data group file entries. Both MIMIX Dynamic Apply and legacy cooperative processing use data group file entries and therefore require journaling to be started. Configurations that include advanced journaling for replication of data areas, data queues, or IFS objects also require that journaling be started on the associated object tracking entries and IFS tracking entries, respectively. Starting journaling ensures that changes to the objects are recorded in the user journal, and are therefore available for MIMIX to replicate. During initial configuration, the configuration checklists direct you when to start journaling for objects identified by data group file entries, IFS tracking entries, and object tracking entries. The MIMIX commands STRJRNFE, STRJRNIFSE, and STRJRNOBJE simplify the process of starting journaling. For more information about these commands, see MIMIX commands for starting journaling on page 194. Although MIMIX commands for starting journaling are preferred, you can also use IBM commands (STRJRNPF, STRJRN, STRJRNOBJ) to start journaling if you have the appropriate authority for starting journaling. Requirements for implicit starting of journaling - Journaling can be automatically started for newly created database files, data areas, data queues, or IFS objects when certain requirements are met. The user ID creating the new objects must have the required authority to start journaling and the following requirements must be met: IFS objects - A new IFS object is automatically journaled if the directory in which it is created is journaled as a result of a request that permitted journaling inheritance for new objects. Typically, if MIMIX started journaling on the parent directory, inheritance is permitted. If you manually start journaling on the parent directory using the IBM command STRJRN, specify INHERIT(*YES). This will allow IFS objects created within the journaled directory to inherit the journal options and journal state of the parent directory. Database files created by SQL statements - A new file created by a CREATE

192

What objects need to be journaled

TABLE statement is automatically journaled if the library in which it is created contains a journal named QSQJRN. New *FILE, *DTAARA, *DTAQ objects - The operating system will automatically journal a new object if it is created in a library that contains a QDFTJRN data area and the data area has enabled automatic journaling for the object type. The default value (*DFT) for the Journal at creation (JRNATCRT) parameter in the data group definition enables MIMIX to create the QDFTJRN data area in a library and enable the data area for automatic journaling for an object type. When the data group is started, MIMIX evaluates all data group object entries for each object type. (Entries for *FILE objects are only evaluated when the data group specifies COOPJRN(*USRJRN).) Entries properly configured to allow cooperative processing of the object type determine whether MIMIX will create the QDFTJRN data area. MIMIX uses the data group entry with the most specific match to the object type and library that also specifies *ALL for its System 1 object (OBJ1) and Attribute (OBJATR). When the QDFTJRN data area in a library is enabled for an object type, all new objects of that type are journaled, not just those which are eligible for replication. Note: MIMIX prevents the QDFTJRN data area from being created the following libraries: QSYS*, QRECOVERY, QRCY*, QUSR*, QSPL*, QRPL*, QRCL*, QRPL*, QGPL, QTEMP and SYSIB*. For example, if MIMIX finds only the following data group object entries for library MYLIB, it would use the first entry when determining whether to create the QDFTJRN data area because it is the most specific entry that also meets the OBJ1(*ALL) and OBJATR(*ALL) requirements. The second entry is not considered in the determination because its OBJ1 and OBJATR values do not meet these requirements.
LIB1(MYLIB) OBJ1(*ALL) OBJTYPE(*FILE) OBJATR(*ALL) COOPDB(*YES) PRCTYPE(*INCLD) LIB1(MYLIB) OBJ1(MYAPP) OBJTYPE(*FILE) OBJATR(DSPF) COOPDB(*YES) PRCTYPE(*INCLD)

Authority requirements for starting journaling

Normal MIMIX processes run under the MIMIXOWN user profile, which ships with *ALLOBJ special authority. Therefore, it is not necessary for other users to account for journaling authority requirements when using MIMIX commands (STRJRNFE, STRJRNIFSE, STRJRNOBJE) to start journaling. When the MIMIX journal managers are started, or when the Build Journaling Environment (BLDJRNENV) command is used, MIMIX checks the public authority (*PUBLIC) for the journal. If necessary, MIMIX changes public authority so the user ID in use has the appropriate authority to start journaling. Authority requirements must be met to enable the automatic journaling of newly created objects and if you use IBM commands to start journaling instead of MIMIX commands. If you create database files, data areas, or data queues for which you expect automatic journaling at creation, the user ID creating these objects must have the required authority to start journaling.

193

If you use the IBM commands (STRJRNPF, STRJRN, STRJRNOBJ) to start journaling, the user ID that performs the start journaling request must have the appropriate authority requirements.

For journaling to be successfully started on an object, one of the following authority requirements must be satisfied: The user profile of the user attempting to start journaling for an object must have *ALLOBJ special authority. The user profile of the user attempting to start journaling for an object must have explicit *ALL object authority for the journal to which the object is to be journaled. Public authority (*PUBLIC) must have *OBJALTER, *OBJMGT, and *OBJOPR object authorities for the journal to which the object is to be journaled.

MIMIX commands for starting journaling

Before you use any of the MIMIX commands for starting journaling, the data group file entries, IFS tracking entries, or object tracking entries associated with the commands object class must be loaded. The MIMIX commands for starting journaling are: Start Journal Entry (STRJRNFE) - This command starts journaling for files identified by data group file entries. Start Journaling IFS Entries (STRJRNIFSE) - This command starts journaling of IFS objects configured for advanced journaling. Data group IFS entries must be configured and IFS tracking entries be loaded (LODDGIFSTE command) before running the STRJRNIFSE command to start journaling. Start Journaling Obj Entries (STRJRNOBJE) - This command starts journaling of data area and data queue objects configured for advanced journaling. Data group object entries must be configured and object tracking entries be loaded (LODDGOBJTE command) before running the STRJRNOBJE command to start journaling.

If you attempt to start journaling for a data group file entry, IFS tracking entry, or object tracking entry and the files or objects associated with the entry are already journaled, MIMIX checks that the physical file, IFS object, data area, or data queue is journaled to the journal associated with the data group. If the file or object is journaled to the correct journal, the journaling status of the data group file entry, IFS tracking or object tracking entry is changed to *YES. If the file or object is not journaled to the correct journal or the attempt to start journaling fails, an error occurs and the journaling status is changed to *NO.

194

Journaling for physical files

Journaling for physical files

Data group file entries identify physical files to be replicated. When data group file entries are added to a configuration, they may have an initial status of *ACTIVE. However, the physical files which they identify may not be journaled. In order for replication to occur, journaling must be started for the files on the source system. This topic includes procedures to display journaling status, and to start, end, or verify journaling for physical files.

Displaying journaling status for physical files

Use this procedure to display journaling status for physical files identified by data group file entries. Do the following: 1. From the MIMIX Intermediate Main Menu, type 1 and press Enter to access the Work with Data Groups display. 2. On the Work with Data Groups display, type 17 (File entries) next to the data group you want and press Enter. 3. The Work with DG File Entries display appears. The initial view shows the current and requested status of the data group file entry. Press F10 (Journaled view). At the right side of the display, the Journaled System 1 and System 2 columns indicate whether the physical file associated with the file entry is journaled on each system. Note: Logical files will have a status of *NA. Data group file entries exist for logical files only in data groups configured for MIMIX Dynamic Apply.

Starting journaling for physical files

Use this procedure to start journaling for physical files identified by data group file entries. In order for replication to occur, journaling must be started for the file on the source system. This procedure invokes the Start Journal Entry (STRJRNFE) command. The command can also be entered from a command line. Do the following: 1. Access the journaled view of the Work with DG File Entries display as described in Displaying journaling status for physical files on page 195. 2. From the Work with DG File Entries display, type a 9 (Start journaling) next to the file entries you want. Then do one of the following: To start journaling using the command defaults, press Enter. To modify command defaults, press F4 (Prompt) then continue with the next step.

3. The Start Journal Entry (STRJRNFE) display appears. The Data group definition prompts and the System 1 file prompts identify your selection. Accept these values or specify the values you want.

195

4. Specify the value you want for the Start journaling on system prompt. Press F4 to see a list of valid values. When *DGDFN, *SRC, or *TGT is specified, MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) and starts or prevents journaling from starting as required. 5. If you want to use batch processing, specify *YES for the Submit to batch prompt. 6. To start journaling for the physical file associated with the selected data group, press Enter. The system returns a message to confirm the operation was successful.

Ending journaling for physical files

Use this procedure to end journaling for a physical file associated with a data group file entry. Once journaling for a file is ended, any changes to that file are not captured and are not replicated. You may need to end journaling if a file no longer needs to be replicated, to prepare for upgrading MIMIX software, or to correct an error. This procedure invokes the End Journaling File Entry (ENDJRNFE) command. The command can also be entered from a command line. To end journaling, do the following: 1. Access the journaled view of the Work with DG File Entries display as described in Displaying journaling status for physical files on page 195. 2. From the Work with DG File Entries display, type a 10 (End journaling) next to the file entry you want and do one of the following: Note: MIMIX cannot end journaling on a file that is journaled to the wrong journal. For example, a file that does not match the journal definition for that data group. If you want to end journaling outside of MIMIX, use the ENDJRNPF command. To end journaling using command defaults, press Enter. Journaling is ended. To modify additional prompts for the command, press F4 (Prompt) and continue with the next step.

3. The End Journal File Entry (ENDJRNFE) display appears. If you want to end journaling for all files in the library, specify *ALL at the System 1 file prompt. 4. Specify the value you want for the End journaling on system prompt. Press F4 to see a list of valid values. When *DGDFN, *SRC, or *TGT is specified, MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) and ends or prevents journaling from ending as required. 5. If you want to use batch processing, specify *YES for the Submit to batch prompt. 6. To end journaling, press Enter.

196

Journaling for physical files

Verifying journaling for physical files

Use this procedure to verify if a physical file defined by a data group file entry is journaled correctly. This procedure invokes the Verify Journaling File Entry (VFYJRNFE) command to determine whether the file is journaled and whether it is journaled to the journal defined in the journal definition. When these conditions are met, the journal status on the Work with DG File Entries display is set to *YES. The command can also be entered from a command line. To verify journaling for a physical file, do the following: 1. Access the journaled view of the Work with DG File Entries display as described in Displaying journaling status for physical files on page 195. 2. From the Work with DG File Entries display, type a 11 (Verify journaling) next to the file entry you want and do one of the following: To verify journaling using command defaults, press Enter. To modify additional prompts for the command, press F4 (Prompt) and continue with the next step.

3. The Verify Journaling File Entry (VFYJRNFE) display appears. The Data group definition prompts and the System 1 file prompts identify your selection. Accept these values or specify the values you want. 4. Specify the value you want for the Verify journaling on system prompt. When *DGDFN is specified, MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) when determining where to verify journaling. 5. If you want to use batch processing, specify *YES for the Submit to batch prompt 6. Press Enter.

197

Journaling for IFS objects

IFS tracking entries are loaded for a data group after the data group IFS entries have been configured for replication through the user journal (advanced journaling). However, loading IFS tracking entries does not automatically start journaling on the IFS objects they identify. In order for replication to occur, journaling must be started on the source system for the IFS objects identified by IFS tracking entries. This topic includes procedures to display journaling status, and to start, end, or verify journaling for IFS objects identified for replication through the user journal. These references go to different files in different books. You should be aware of the information in Considerations for working with long IFS path names on page 224.

Displaying journaling status for IFS objects

Use this procedure to display journaling status for IFS objects identified by IFS tracking entries. Do the following: 1. From the MIMIX Intermediate Main Menu, type 1 and press Enter to access the Work with Data Groups display. 2. On the Work with Data Groups display, type 50 (IFS trk entries) next to the data group you want and press Enter. 3. The Work with DG IFS Trk. Entries display appears. The initial view shows the object type and status at the right of the display. Press F10 (Journaled view). At the right side of the display, the Journaled System 1 and System 2 columns indicate whether the IFS object identified by the tracking is journaled on each system.

Starting journaling for IFS objects

Use this procedure to start journaling for IFS objects identified by IFS tracking entries. This procedure invokes the Start Journaling IFS Entries (STRJRNIFSE) command. The command can also be entered from a command line. To start journaling for IFS objects, do the following: 1. If you have not already done so, load the IFS tracking entries for the data group. For more information see the MIMIX Reference book. 2. Access the journaled view of the Work with DG IFS Trk. Entries display as described in Displaying journaling status for IFS objects on page 198. 3. From the Work with DG IFS Trk. Entries display, type a 9 (Start journaling) next to the IFS tracking entries you want. Then do one of the following: To start journaling using the command defaults, press Enter. To modify the command defaults, press F4 (Prompt) and continue with the next step.

198

Journaling for IFS objects

4. The Start Journaling IFS Entries (STRJRNIFSE) display appears. The Data group definition and IFS objects prompts identify the IFS object associated with the tracking entry you selected. You cannot change the values shown for the IFS objects prompts1. 5. Specify the value you want for the Start journaling on system prompt. Press F4 to see a list of valid values. When *DGDFN, *SRC, or *TGT is specified, MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) and starts or prevents journaling from starting as required. 6. To use batch processing, specify *YES for the Submit to batch prompt and press Enter. Additional prompts for Job description and Job name appear. Either accept the default values or specify other values. 7. The System 1 file identifier and System 2 file identifier prompts identify the file identifier (FID) of the IFS object on each system. You cannot change the values2. 8. To start journaling on the IFS objects specified, press Enter.

Ending journaling for IFS objects

Use this procedure to end journaling for IFS objects identified by IFS tracking entries. This procedure invokes the End Journaling IFS Entries (ENDJRNIFSE) command. The command can also be entered from a command line. To end journaling for IFS objects, do the following: 1. Access the journaled view of the Work with DG IFS Trk. Entries display as described in Displaying journaling status for IFS objects on page 198. 2. From the Work with DG IFS Trk. Entries display, type a 10 (End journaling) next to the IFS tracking entries you want. Then do one of the following: To end journaling using the command defaults, press Enter. To modify the command defaults, press F4 (Prompt) and continue with the next step.

3. The End Journaling IFS Entries (ENDJRNIFSE) display appears. The Data group definition and IFS objects prompts identify the IFS object associated with the tracking entry you selected. You cannot change the values shown for the IFS objects prompts1. 4. Specify the value you want for the End journaling on system prompt. Press F4 to see a list of valid values. When *DGDFN, *SRC, or *TGT is specified, MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) and ends or
1. When the command is invoked from a command line, you can change values specified for the IFS objects prompts. Also, you can specify as many as 300 object selectors by using the + for more values prompt. 2. When the command is invoked from a command line, use F10 to see the FID prompts. Then you can optionally specify the unique FID for the IFS object on either system. The FID values can be used alone or in combination with the IFS object path name.

199

prevents journaling from ending as required. 5. To use batch processing, specify *YES for the Submit to batch prompt and press Enter. Additional prompts for Job description and Job name appear. Either accept the default values or specify other values. 6. The System 1 file identifier and System 2 file identifier identify the file identifier (FID) of the IFS object on each system. You cannot change the values shown2. 7. To end journaling on the IFS objects specified, press Enter.

Verifying journaling for IFS objects

Use this procedure to verify if an IFS object identified by an IFS tracking entry is journaled correctly. This procedure invokes the Verify Journaling IFS Entries (VFYJRNIFSE) command to determine whether the IFS object is journaled, whether it is journaled to the journal defined in the data group definition, and whether it is journaled with the attributes defined in the data group definition. The command can also be entered from a command line. To verify journaling for IFS objects, do the following: 1. Access the journaled view of the Work with DG IFS Trk. Entries display as described in Displaying journaling status for IFS objects on page 198. 2. From the Work with DG IFS Trk. Entries display, type a 11 (Verify journaling) next to the IFS tracking entries you want. Then do one of the following: To verify journaling using the command defaults, press Enter. To modify the command defaults, press F4 (Prompt) and continue with the next step.

3. The Verify Journaling IFS Entries (VFYJRNIFSE) display appears. The Data group definition and IFS objects prompts identify the IFS object associated with the tracking entry you selected. You cannot change the values shown for the IFS objects prompts1. 4. Specify the value you want for the Verify journaling on system prompt. Press F4 to see a list of valid values. When *DGDFN is specified, MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) and verifies journaling on the appropriate systems as required. 5. To use batch processing, specify *YES for the Submit to batch prompt and press Enter. Additional prompts for Job description and Job name appear. Either accept the default values or specify other values. 6. The System 1 file identifier and System 2 file identifier identify the file identifier (FID) of the IFS object on each system. You cannot change the values shown2. 7. To verify journaling on the IFS objects specified, press Enter. Using file identifiers (FIDs) for IFS objects on page 236.

200

Journaling for data areas and data queues

Journaling for data areas and data queues

Object tracking entries are loaded for a data group after the data group object entries have been configured replication through the user journal (advanced journaling). However, loading object tracking entries does not automatically start journaling on the objects they identify. In order for replication to occur, journaling must be started for the objects on the source system for the objects identified by object tracking entries. This topic includes procedures to display journaling status, and to start, end, or verify journaling for data areas and data queues identified for replication through the user journal.

Displaying journaling status for data areas and data queues

To check journaling status for data areas and data queues identified by object tracking entries. Do the following: 1. From the MIMIX Intermediate Main Menu, type 1 and press Enter to access the Work with Data Groups display. 2. On the Work with Data Groups display, type 52 (Obj trk entries) next to the data group you want and press Enter. 3. The Work with DG Obj. Trk. Entries display appears. The initial view shows the object type and status at the right of the display. Press F10 (Journaled view). At the right side of the display, the Journaled System 1 and System 2 columns indicate whether the object identified by the tracking is journaled on each system.

Starting journaling for data areas and data queues

Use this procedure to start journaling for data areas and data queues identified by object tracking entries. This procedure invokes the Start Journaling Obj Entries (STRJRNOBJE) command. The command can also be entered from a command line. To start journaling for data areas and data queues, do the following: 1. If you have not already done so, load the object tracking entries for the data group. For more information see the MIMIX Reference book. 2. Access the journaled view of the Work with DG Obj. Trk. Entries display as described in Displaying journaling status for data areas and data queues on page 201. 3. From the Work with DG Obj. Trk. Entries display, type a 9 (Start journaling) next to the object tracking entries you want. Then do one of the following: To start journaling using the command defaults, press Enter. To modify the command defaults, press F4 (Prompt) and continue with the next step.

4. The Start Journaling Obj Entries (STRJRNOBJE) display appears. The Data group definition and Objects prompts identify the object associated with the

201

tracking entry you selected. Although you can change the values shown for these prompts, it is not recommended unless the command was invoked from a command line. 5. Specify the value you want for the Start journaling on system prompt. Press F4 to see a list of valid values. When *DGDFN, *SRC, or *TGT is specified, MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) and starts or prevents journaling from starting as required. 6. To use batch processing, specify *YES for the Submit to batch prompt and press Enter. Additional prompts for Job description and Job name appear. Either accept the default values or specify other values. 7. To start journaling on the objects specified, press Enter.

Ending journaling for data areas and data queues

Use this procedure to end journaling for data areas and data queues identified by object tracking entries. This procedure invokes the End Journaling Obj Entries (ENDJRNOBJE) command. The command can also be entered from a command line. To end journaling for data areas and data queues, do the following: 1. Access the journaled view of the Work with DG Obj. Trk. Entries display as described in Displaying journaling status for data areas and data queues on page 201. 2. From the Work with DG Obj. Trk. Entries display, type a 10 (End journaling) next to the object tracking entries you want. Then do one of the following: To verify journaling using the command defaults, press Enter. To modify the command defaults, press F4 (Prompt) and continue with the next step.

3. The End Journaling Obj Entries (ENDJRNOBJE) display appears. The Data group definition and IFS objects prompts identify the object associated with the tracking entry you selected. Although you can change the values shown for these prompts, it is not recommended unless the command was invoked from a command line. 4. Specify the value you want for the End journaling on system prompt. Press F4 to see a list of valid values. When *DGDFN, *SRC, or *TGT is specified, MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) and ends or prevents journaling from ending as required. 5. To use batch processing, specify *YES for the Submit to batch prompt and press Enter. Additional prompts for Job description and Job name appear. Either accept the default values or specify other values. 6. To end journaling on the objects specified, press Enter.

202

Journaling for data areas and data queues

Verifying journaling for data areas and data queues

Use this procedure to verify if an object identified by an object tracking entry is journaled correctly. This procedure invokes the Verify Journaling Obj Entries (VFYJRNOBJE) command to determine whether the object is journaled, whether it is journaled to the journal defined in the data group definition, and whether it is journaled with the attributes defined in the data group definition. The command can also be entered from a command line. To verify journaling for objects, do the following: 1. Access the journaled view of the Work with DG Obj. Trk. Entries display as described in Displaying journaling status for data areas and data queues on page 201. 2. From the Work with DG Obj. Trk. Entries display, type a 11 (Verify journaling) next to the object tracking entries you want. Then do one of the following: To verify journaling using the command defaults, press Enter. To modify the command defaults, press F4 (Prompt) and continue with the next step.

3. The Verify Journaling Obj Entries (VFYJRNOBJE) display appears. The Data group definition and Objects prompts identify the object associated with the tracking entry you selected. Although you can change the values shown for these prompts, it is not recommended unless the command was invoked from a command line. 4. Specify the value you want for the Verify journaling on system prompt. Press F4 to see a list of valid values. When *DGDFN is specified, MIMIX considers whether the data group is configured for journaling on the target system (JRNTGT) and verifies journaling on the appropriate systems as required. 5. To use batch processing, specify *YES for the Submit to batch prompt and press Enter. Additional prompts for Job description and Job name appear. Either accept the default values or specify other values. 6. To verify journaling on the objects specified, press Enter.

203

Switching

CHAPTER 8

Switching

Switching is when you temporarily reverse the roles of the systems. The original source system (production) becomes the temporary target system and the original target system (backup) becomes the temporary source system. When the scenario that required you to switch directions is resolved, you typically switch again to return the systems to their original roles. This chapter provides information and procedures to support switching. The following topics are included: About switching on page 204 provides information about switching with MIMIX including best practice and reasons why a switch should be performed. Subtopics describe: The role of MIMIX Model Switch Framework within switching What is a planned switch and requirements for a planned switch What is an unplanned switch and actions to be completed after the failed source system is recovered How to set policies associated with switching, including compliance thresholds and the default model switch framework How to change the audit level policy to ensure the most complete comparison is performed when auditing before switching Switching using MIMIX Switch Assistant on page 212 describes how to use this tool in MIMIX Availability Manager. Switching from the MIMIX Basic Main Menu on page 212. describes how to switch from a 5250 emulator. Determining when the last switch was performed on page 215 describes how to check the Last switch field which indicates the switch compliance status and provides the date when the last switch was performed. Problems checking switch compliance on page 216 describes problems that can occur with data for the Last switch field. Performing a data group switch on page 217 describes how to switch a single data group using the SWTDG command. Switch Data Group (SWTDG) command on page 219 provides background information about the SWTDG command, which is used in all switch interfaces.

About switching
Replication environments rarely remain static. Therefore, best practice is to perform regular switches to ensure that you are prepared should you need to perform one during an emergency.

204

About switching

MIMIX supports two methods for switching the direction in which replication occurs for a data group. These methods are known as a planned switch and an unplanned switch. You may need to perform a switch for any of the following reasons: The production system becomes unavailable due to an unplanned outage. A switch in this scenario is unplanned. You need to perform hardware or software maintenance on the production system. Typically, you can schedule this in advance so the switch is planned. You need to test your recovery plan. This activity is also a planned switch.

There are three phases to a complete switch: switch to the backup system, synchronize the systems when the production is ready to use, and switch back to the production system. Switching data groups is only a part of performing a switch. Best practice for switching includes performing regular switches. Best practice also includes performing all audits with the audit level set at level 30 immediately prior to a planned switch to the backup system and before switching back to the production system. For performing the switch, best practice is to use the MIMIX Switch Assistant within MIMIX Availability Manager or to switch using option 5 (start or complete switch) from the MIMIX Basic Main Menu.

MIMIX Model Switch Framework

MIMIX provides a customized implementation of MIMIX Model Switch Framework to perform a switch. MIMIX Model Switch Framework is ideally suited for customizing a switching solution that detects the need for an unplanned switch, switches the direction of data group replication, and switches users to the backup system. Typically, if you have a Runbook, it will direct you when to use your MIMIX Model Switch Framework implementation for both planned and unplanned switches. The MIMIX Model Switch Framework calls the Switch Data Group (SWTDG) command. The SWTDG command only switches the direction in which replication occurs for a single data group; it does not switch users or any other facets of your normal operating environment to the backup system. However, MIMIX Model Switch Framework can be configured to address these additional facets of your environment for multiple data groups. If you choose to use the SWTDG command either by invoking it from a command line or by using the options for switching on the Work with Data Groups display, you must take action to switch users to the backup system and address other requirements for operating there. Both the MIMIX Switch Assistant in MIMIX Availability Manager and the switching option from the MIMIX Basic Main menu are implementations of MIMIX Model Switch Framework. The implementation is identified within policies. For additional information see the chapter Using the MIMIX Model Switch Framework in the Using MIMIX Monitor book.

Planned Switch
You can start a planned switch from either system. When using MIMIX Model Switch Framework, you start the switch from the system that MIMIX Model Switch

205

Switching

Framework is on. In a planned switch, MIMIX initiates a controlled shutdown of the data group. Both systems and the communications between them must be active. Before you start a planned switch of a data group, you should ensure that the following actions have been completed. Your enterprise may have additional requirements. Perform an full set of audits with the audit level policy set to level 30. Running the #FILDTA audit at this audit level checks 100 percent of file member data for the data group for synchronization between source and target systems and is strongly recommended. Shut down any applications that use database files or objects defined to the data group. If any users or other non-MIMIX processes remain active while the switch is being performed, the data can become not synchronized between systems and orphaned data may result. Ensure that there are no jobs other than MIMIX currently active on the source system. This may require ending all interactive and batch subsystems other than MIMIX and ending communications. Users should be prevented from accessing either system until after the switch is complete and the data group is restarted. If you use user journal replication processes, you should address any files, IFS tracking entries, or object tracking entries in error for your critical database files. If you use system journal replication processes, you should address any object errors.

You are not required to run journal analysis after a planned switch. MIMIX retains information about where activity ended so that when you restart the data group, it is started at the correct point. When the data group is started, the temporary target system (the production system) is now being updated with user changes that are being replicated from the temporary source system (the backup system). Do not allow users onto the production system until after the production system is caught up with these transactions and you run the switch process again to revert to the normal roles.

Unplanned switch
In an unplanned switch, the source system is assumed to be unavailable. An unplanned switch is generally required when the source system fails and, in order to continue normal operations, you must switch users to a backup system. (Typically MIMIX is configured so that the target for replication is your backup system.) You must run an unplanned switch from the target system. MIMIX performs a controlled shutdown of replication processes on the target system. The controlled shutdown allows all apply processing to catch up before the apply processes are ended. There are default (*DFT) values for several parameters on the SWTDG command that allow the switch operation to continue without intervention from the user. See Planned Switch on page 205 for additional details about these default values.

206

About switching

In an unplanned switch of a data group that uses remote journaling, the default behavior is to end the RJ link. Once the failed source system is recovered, the following actions should be completed: You should perform journal analysis on that system before restarting the data group or user applications. Journal analysis helps identify any possible loss of data that may have occurred when the source system failed. Journal analysis relies on status information on the source system about the last entry that was applied. This information will be cleared when the data group is restarted. Communication between the systems must be active before you restart the data group. The switch process is complete when you restart the data group. When the data group is restarted, MIMIX notifies the source system that it is now the temporary target system. New transactions are created on the temporary source system (the backup system) while the production system (the temporary target system) is unavailable for replication. After you have completed journal analysis, you can send these new transactions to the production system to synchronize the databases. Once the databases are synchronized, you must run the switch process again to revert to the normal roles before allowing users onto the production system.

When the data group is started after a switch, any pending transactions are cleared. The journal receiver is already changed by the switch process and the new journal receiver and first sequence number are used.

207

Setting policies for switching

Table 32 identifies the policies used by switching functions and their shipped default values. For these policies, MIMIX Switch Assistant uses only the policy values specified for the installation. If MIMIX cannot determine whether a MIMIX Model Switch Framework is defined, the switch framework policy is *DISABLED. If the SETMMXPCY command specifies a data group name, the switch framework is required to be *INST. The switch thresholds are *DISABLED by default but can be changed.
Table 32. Policy Shipped values of policies used by MIMIX Switch Assistant. Shipped Values Installation Data group definition Switch warning threshold Switch action threshold Default model switch framework
1.

Data Groups Name1 *DISABLED *DISABLED *INST

*INST 90 180 MXMSFDFT

A data group definition value of *INST indicates the policy is installation-wide. A name indicates the policies are in effect only for the specified data group.

Specifying a default switch framework in policies

MIMIX Switch Assistant requires that you have a configured MIMIX Model Switch Framework and that you specify it in the default model switch framework policy for the installation. You may also want to adjust policies for thresholds associated with MIMIX Switch Assistant. If you do not have a configured MIMIX Model Switch Framework, contact your Certified MIMIX Consultant. From a 5250 emulator, do the following from the management system: 1. From the command line type SETMMXPCY and press F4 (Prompt). 2. Verify that the value specified for Data group definition is *INST. 3. Press Enter to see all the policies and their current values. 4. At the Default model switch framework prompt, specify the name of the switch framework to use for switching this installation. 5. To accept the changes, press Enter.

Setting polices for MIMIX Switch Assistant

If the value of the installation-level policy is disabled, you must change the policy in order to use MIMIX Switch Assistant.

208

From MIMIX Availability Manager, the action to change installation policies is only available when the system you are viewing is the management system. Do the following: 1. Ensure that you have selected the management system for the installation you want from the navigation bar. If you are not certain which system is the management system, you can select Services to check. 2. From the management system, select Switching from the navigation bar. 3. Select Change Installation Policies from the MIMIX Switch Assistant window. 4. Specify values for the following fields: a. For Switch warning threshold, the value 90 is recommended. b. For Switch action threshold, the value 180 is recommended. c. For Default model switch framework, specify the name of your MIMIX Model Switch Framework. 5. To accept the changes, click OK. From a 5250 emulator, do the following from the management system: 1. From the command line type SETMMXPCY and press F4 (Prompt). 2. Verify that the value specified for Data group definition is *INST. 3. Press Enter to see all the policies and their current values. 4. Specify values for the following fields: a. For Switch warning threshold, the value 90 is recommended. b. For Switch action threshold, the value 180 is recommended. c. For Default model switch framework, specify the name of your MIMIX Model Switch Framework. 5. To accept the changes, press Enter.

Setting policies for switch compliance for a specific data group

If you do not want to use MIMIX Switch Assistant for switching or if you have switchable data groups outside of your default model switch framework, you can still have switch compliance included in the high-level data group status within MIMIX Availability Manager. The last switch date, based on the Switch Data Group (SWTDG) command, is displayed in the Last switch field in the Summary area of the Data Group Status window. If the policies for Switch action and warning thresholds have been enabled for a data group, these thresholds will be applied to the last switch date. When the thresholds are reached, compliance status appears as an icon next to the Last switch field and is included in the high-level data group status. To enable this, change the data group-level policies as followings: 1. From the management system, select Data Groups from the navigation bar. 2. From the Data Group Status window, select a data group from the list so its information is displayed in the Summary area.

209

3. Select Change Policies from the action list. 4. Specify values for the following fields: a. For Switch warning threshold, specify a value other than Disabled; 90 or Installation is recommended. b. For Switch action threshold, specify a value other than Disabled; 180 or Installation is recommended. 5. To accept the changes, click OK.

Setting policies when MIMIX Switch Assistant is not used

If you do not use MIMIX Model Switch Framework for switching, you will want to disable the default model switch framework policy at the installation level. Do the following 1. Ensure that you have the management system for the installation you want selected in the navigation bar. If you are not certain which system is the management system, you can select Services to check. 2. From the management system, select Switching from the navigation bar. 3. Select Change Installation Policies from the MIMIX Switch Assistant window. 4. For Default model switch framework, select Disabled. 5. To accept the changes, click OK.

Changing the audit level policy for switching

Regardless of the level you use for daily operations, Vision Solutions strongly recommends that you perform audits at audit level 30 before the following events to ensure that 100 percent of that data is valid on the target system: Before performing a planned switch to the backup system. Before switching back to the production system.

For more information about the risks associated with lower audit levels, see Guidelines and recommendations for auditing on page 81. From MIMIX Availability Manager, the action to change policies is only available when the system you are viewing is the management system. Do the following: 1. Ensure that you have selected the management system for the installation you want from the navigation bar. If you are not certain which system is the management system, you can select Services to check. 2. From the management system, select Policies from the navigation bar. 3. On the MIMIX Policies window, the first entry listed is the installation. Select the Details action and click . 4. On the Set MIMIX Policies window, specify 30 for Audit level and click OK. From a 5250 emulator, do the following from the management system: 1. From the command line type SETMMXPCY and press F4 (Prompt).

210

2. Verify that the value specified for Data group definition is *INST. 3. Press Enter to see all the policies and their current values. 4. For Audit level, specify *LEVEL30. Then press Enter.

211

Switching using MIMIX Switch Assistant

The MIMIX Switch Assistant within MIMIX Availability Manager is designed to simplify switching by using a default implementation of MIMIX Model Switch Framework. Once a default MIMIX Model Switch Framework is defined and specified in your installation-level policy, MIMIX Switch Assistant guides you through the three major steps of completing a switch and keeps track of which step you are in so the steps are always performed in the correct order. MIMIX Switch Assistant provides additional, significant benefits over switching from a 5250 emulator, such as: In each phase, the MIMIX Switch Assistant window describes what you need to do before you start the phase. While a phase is in progress, the window describes what is occurring. Status of the switch is displayed on the MIMIX Switch Assistant window and is integrated into overall status. Fields on the display indicate compliance with switching best practices. Online help describes how to resolve problems with MIMIX Switch Assistant.

For information about policies used by MIMIX Switch Assistant, see Setting policies for switching on page 208. Each step of the switch cycle must be performed from the system on which the MIMIX Model Switch Framework was created. Typically, this is the backup system. To perform a switch, do the following: 1. Select Switching from the Details area in the navigation bar. The MIMIX Switch Assistant window appears. 2. Perform the manual actions listed in the Step area of the MIMIX Switch Assistant window. Some actions include buttons for access to relevant locations. (You must re-select Switching from the navigation bar to return to MIMIX Switch Assistant.) 3. Consult your runbook for any additional required actions for the step. Perform them now. 4. To start the step, click on the button located at the bottom of the text. This will prompt the Run Switch Framework (RUNSWTFWK) command, where you can specify options for the switch. 5. When processing ends for the step, the Command History window opens to display any errors that occurred. For more information, use online Help.

Switching from the MIMIX Basic Main Menu

Option 5 (Start or complete switch) on the MIMIX Basic Main Menu is designed to simplify switching by using a default MIMIX Model Switch Framework implementation. When you use this option, MIMIX keeps track of which phase of the switch process you are in. You will see a confirmation display that is appropriate for each phase.

212

Switching from the MIMIX Basic Main Menu

Each phase will prompt the Run Switch Framework command (RUNSWTFWK) with your default switch framework and appropriate values for the phase. To change the default switch framework to a different implementation, see Setting policies for switching on page 208.

Switching to the backup system

This procedure switches operations to the backup system. Before using this procedure, consult your runbook for any additional procedures that must be performed when switching to the backup system. 1. If this is a planned switch, Vision Solutions strongly recommends that you perform a full set of audits with the audit level policy set to level 30. Running the #FILDTA audit at this audit level checks 100 percent of file member data for the data group for synchronization between source and target systems. 2. Shut down all active applications that are reading or updating replicated objects from the production and backup systems. Do the following from the backup system: 3. Ensure that all transactions have been applied to the backup system by doing the following: a. Select option 1 (Availability status) from the MIMIX Basic Main Menu. b. Select option 5 (Display details) for Replication to access the Work with Data Groups display. c. For each data group, select option 8 (Display status) and ensure that the Unprocessed entry counts for both database and object apply have no values. 4. From the MIMIX Basic Main Menu, select option 5 (Start or complete switch). 5. You will see the Confirm Switch to Backup confirmation display. Press F16 to confirm your choice to switch MIMIX and specify switching options. 6. The Run Switch Framework (RUNSWTFWK) command appears. The default Switch framework and the value *BCKUP for the Switch framework process are preselected and cannot be changed. Do the following: a. You must specify the type of switch to perform, *PLANNED or *UNPLANNED, at the Switch type prompt. b. You can change values for other parameters as needed. c. To start the switch, press Enter. 7. Consult your runbook to determine if any additional steps are needed. After you complete this phase of the switch you must wait until the original production system is available again. Then perform the steps in Synchronizing data and starting MIMIX on the original production system on page 214.

213

Synchronizing data and starting MIMIX on the original production system

This procedure synchronizes data and starts replication from the backup system to the original production system. Synchronizing the data ensures that the data on both systems is equivalent before replication is started. Before using this procedure, consult your runbook for any additional procedures that must be performed when synchronizing and starting replication from the backup system to the original production system Do the following from the backup system: 1. Ensure the original production system is available again. 2. From the MIMIX Basic Main Menu, select option 5 (Start or complete switch). 3. You will see the Confirm Synchronize and Start confirmation display. Press F16 to confirm your choice and specify switching options. 4. The Run Switch Framework (RUNSWTFWK) command appears. The default Switch framework and the value *SYNC for the Switch framework process are preselected and cannot be changed. Do the following: a. Optionally, you can change the value of the Set object auditing level prompt. b. To synchronize and start, press Enter. 5. Once replication has caught up, Vision Solutions strongly recommends that you perform a full set of audits with the audit level policy set to level 30. Running the #FILDTA audit at this audit level checks 100 percent of file member data for the data group for synchronization between source and target systems. 6. Consult your runbook to determine if any additional steps are needed. When you are ready to switch back to the original production system, use Switching to the production system on page 214.

Switching to the production system

This procedure returns operations to the original production system. Before using this procedure, consult your runbook for any additional procedures that must be performed when switching to the production system 1. Shut down all active applications that are reading or updating replicated objects from the production and backup systems. Do the following from the original production system: 2. Ensure that all transactions have been applied by doing the following: a. Select option 1 (Availability status) from the MIMIX Basic Main Menu. b. Select option 5 (Display details) for Replication to access the Work with Data Groups display. c. For each data group, select option 8 (Display status) and ensure that the Unprocessed entry counts for both database and object apply have no values. 3. From the MIMIX Basic Main Menu, select option 5 (Start or complete switch).

214

Determining when the last switch was performed

4. You will see the Confirm Switch to Production confirmation display. Press F16 to confirm your choice to switch MIMIX and specify switching options. 5. The Run Switch Framework (RUNSWTFWK) command appears. The default Switch framework and the value *PROD for the Switch framework process are preselected and cannot be changed. Do the following: a. You can change values for other parameters as needed. b. To start the switch, press Enter. 6. Consult your runbook to determine if any additional steps are needed.

Determining when the last switch was performed

Replication environments rarely remain static. Therefore, best practice is to perform regular switches to ensure that you are prepared should you need to perform one during an emergency. The Last switch field indicates compliance with best practices. The status of the field either contains an icon (MIMIX Availability Manager) or is highlighted (5250 emulator) to indicate the following: or Yellow - The number of days since the last switch is at the limit of what is considered to be best practice. This threshold is determined by the Switch warning threshold policy. or Red - The number of days since the last switch is beyond what is considered to be best practice. This threshold is determined by the Switch action threshold policy.

Checking the last switch dates from MIMIX Availability Manager

MIMIX Availability Manager provides information on checking for the last switch date of an installation or an individual data group. To check the last switch date from MIMIX Availability Manager for an installation, do the following: 1. Select Switching from the Details area of the navigation bar. 2. Check the value of the Last switch field at the top of the MIMIX Switch Assistant window. This field is only displayed when there is value specified for the Default model switch framework policy. As an installation approaches or reaches the compliance threshold, a status icon is also displayed in the Installation area of the navigation bar for that installation. To check the last switch date from MIMIX Availability Manager for a data group, do the following: 1. Select Data Groups from the Details area of the navigation bar. 2. Select a specific data group to view the summary information for that data group. The Last switch field in the Summary section provides the date and time of the last switch for the specified data group.

215

Note: If the date is not listed for a data group, the data group policy may not be configured for switching. Compliance is only checked when you specify the data group policy for Switch warning threshold and Switch action threshold. For more information, see Setting policies for switching on page 208.

Checking the last switch date from a 5250 emulator

A 5250 emulator session provides information on the last switch date for an installation from the Last switch field on the MIMIX Availability Status display. This field is only displayed when a value is specified for the Default model switch framework policy. The date indicates when the last completed switch was performed using the switch framework specified in the policy. To check the last switch date from a 5250 emulator, do the following: 1. Access the MIMIX Basic Main Menu. See Accessing the MIMIX Main Menu from a 5250 emulator on page 42. 2. From the MIMIX Basic Main Menu, select option 1 (Availability status) and press Enter. The MIMIX Availability Status display appears. The last switch date is located in the upper right corner of the display.

Problems checking switch compliance

The Last switch field indicates the switch compliance status and provides the date when the last switch was performed. This field is displayed correctly when certain requirements have been met. The following problems can occur: Approaching or out of compliance - The status of the field either contains an icon (MIMIX Availability Manager) or is highlighted (5250 emulator) to indicate the number of days since the last switch is at the limit of what is considered to be best practice. Schedule and perform a switch to resolve this problem. No Last switch field - This field is only displayed when there is a value specified for the Default model switch framework policy. The date indicates when the last completed switch was performed using the switch framework specified in the policy. Specify the name of the model switch framework you use for switching in policies. See Setting policies for switching on page 208. No Last switch field for a data group (MIMIX Availability Manager) - The data group policy may not be configured for switching. Compliance is only checked when you specify the data group policy for Switch warning threshold and Switch action threshold. Specify the data group policy for Switch warning threshold and Switch action threshold. See Setting policies for switching on page 208.

216

Performing a data group switch

Performing a data group switch

Performing a data group switch changes the direction of replication for a data group through the Switch Data Group (SWTDG) command. Only replication for the selected data group is switched. You may want to perform a data group switch if you are having problems with an application that only affects a specific data group or if you need to manually load balance because of heavily used applications. Note: You cannot switch a disabled data group. For more information, see Disabling and enabling data groups on page 232.

Performing a data group switch from MIMIX Availability Manager

To perform a data group switch from MIMIX Availability Manager, do the following: 1. Select Data Groups from the navigation bar. The Data Group Status window appears. 2. Select the data groups you want to switch. 3. Click on the Switch action button located above the list of data groups. The Switch Data Groups window appears. 4. Select the appropriate values for the options. Refer to the online help for more information. 5. Click OK.

Performing a data group switch from a 5250 emulator

To perform a data group switch from a 5250 emulator, do the following: 1. If you will be performing a planned switch, do the following: a. Shut down any applications that have database file or objects defined to the data group. b. Ensure that you have addressed any critical database files that are held due to error or held for other reasons. c. Ensure there are no pending object activity entries by entering: WRKDGACTE STATUS(*ACTIVE) 2. From the Work with Data Groups display, type the option for the type of switch you want next to the data group you want to switch and press Enter. Use option 15 for a planned switch Use option 16 for an unplanned switch

3. Some of the parameter values that you may want to consider when the Switch Data Group display appears are: If you specified Switch type of *PLANNED and have specified a number for the Wait time (seconds) parameter, you can specify a value for the Timeout Option parameter to specify what action you want the SWTDG command to perform if the time specified in the Wait time (seconds) parameter is exceeded. When

217

you are performing a planned switch you may want to specify the number of seconds to wait before all the active data group processes end. If you specify *NOMAX the switch process will wait until all data group processes are ended. This could delay the switch process. You can use the Conditions that end switch parameter to specify the types of errors that you want to end the switch operation. To ensure that the most comprehensive checking options are used, choose *ALL. For a planned switch, the default value, *DFT, is the same as *ALL. For an unplanned switch, *DFT will prevent the switch only when database apply backlogs exist. Verify that the value for the Start journaling on new source prompt is what you want. If necessary, change the value.

4. After the confirmation screen, press F16 to continue. 5. Press Enter. Messages appear indicating the status of the switch request. When you see a message indicating that the switch is complete, users can begin processing as usual on the temporary source system. 6. If you performed an unplanned switch, perform journal analysis on the original source system as soon as it is available, to determine if any transactions were missed. Use topic Performing journal analysis on page 258. 7. Start the data group, clearing pending entries, using the procedure in Starting selected data group processes on page 150. This starts replication in the new temporary direction.
Updated for 6.0.15.00.

218

Switch Data Group (SWTDG) command

Switch Data Group (SWTDG) command

The Switch Data Group (SWTDG) command provides the following parameters to control how you want your switch operation handled: The Wait time (seconds) parameter (WAIT) is used to specify the number of seconds to wait for all of the active data group processes to end. The function of the default value *DFT is different for planned switches than it is for unplanned switches. For a planned switch, the value *DFT is equivalent to the value *NOMAX. For an unplanned switch, the value *DFT is set to wait 300 seconds (5 minutes) for all of the active data group processes to end. If you specify a value for the WAIT parameter you can use the Timeout option parameter (TIMOUTOPT) to specify what action to take when the wait time you specified is reached. The function of the default value *DFT is different for planned switches than it is for unplanned switches. For a planned switch, the value *DFT is equivalent to the value *QUIT. When the value specified for the WAIT parameter is reached, the current process quits and returns control to the caller. For an unplanned switch, the value *DFT is equivalent to the value *NOTIFY. When the value specified for the WAIT parameter is reached, an inquiry message is sent to notify the operator of a possible error condition. The Conditions that end switch (ENDSWT) parameter is used to specify which conditions should end the switch process. The function of the default value *DFT is different for planned switches than it is for unplanned switches. For a planned switch, the value *DFT is equivalent to the value *ALL. The value *ALL provides the most comprehensive checking for conditions that are not compatible with best practices for switching. Additionally, the value *ALL ensures that your programs will automatically include any future ENDSWT parameter values that may be added to maintain a conservative approach to the switching operation. For an unplanned switch, the value *DFT ends the process if there are any backlogs for the database apply process. However, backlogs on other user journal processes are not checked and switch processing is not ended even though conditions may exist which are not compatible with best practices for switching and may result in the loss of data. The Start journaling on new source (STRJRNSRC) parameter is used to specify whether you want to start journaling for the data group on the new source system. The End journaling on new target (ENDJRNTGT) parameter is used to specify whether you want to end journaling of the data group on the new target system. The End remote journaling (ENDRJLNK) parameter is used in a planned switch of a data group that uses remote journaling. This parameter specifies whether you want to end remote journaling for the data group. The default behavior is to leave the RJ link running. You need to consider whether to keep the RJ link active after a planned switch of a data group. For more information, see When to end the RJ link on page 144. The Change user journal receiver (CHGUSRRCV) parameter is used to specify whether or not you want MIMIX to create and attach a new user (database) journal

219

receiver during the switch operation. If you have applications that are dependent on the receiver name for recovery purposes, It is recommended that you choose CHGUSRRCV(*NO) to prevent a new journal receiver from being created during a data group switch. The Change system journal receiver (CHGSYSRCV) parameter is used to specify whether or not you want MIMIX to create and attach a new journal receiver to the system (audit) journal (QAUDJRN) during the switch operation. If you have applications that are dependent on the receiver name for recovery purposes, it is recommended that you choose CHGSYSRCV(*NO) to prevent a new journal receiver from being created during a data group switch. The End if database errors (ENDDBERR) parameter has been obsoleted by the Conditions that end switch (ENDSWT) parameter. Previously, the ENDDBERR parameter was used to specify whether to switch the data group when data replication errors exist. Use the ENDSWT parameter and specify *DBERR to produce the equivalent of ENDDBERR(*YES), or *NONE to produce the equivalent of ENDDBERR(*NO). The Confirm (CONFIRM) parameter is used to specify if a confirmation panel is displayed. The default is *NO (the confirmation panel is not displayed). Note that options for switching on the Work with Data Groups display call the SWTDG command with *YES specified so that the confirmation panel is automatically displayed and the user must press F16 to continue.

Updated for 6.0.15.00.

220

CHAPTER 9

Less common operations

This chapter describes how to perform infrequently used operations that help keep your MIMIX environment running. The following topics are included: Starting the TCP/IP server on page 222 contains the procedure for starting the TCP/IP server. Ending the TCP/IP server on page 223 contains the procedure for ending the TCP/IP server. Working with objects on page 224 contains tips for working with long object and IFS path names. Viewing status for active file operations on page 226 describes how to check status when replicating database files that you are reorganizing or copying with MIMIX Promoter. Displaying a remote journal link on page 227 describes how to display information about he link between a source journal definition and a target journal definition. Displaying status of a remote journal link on page 228 includes procedures for determining whether a data group uses remote journaling and for checking the status of a remote journal link. Identifying data groups that use an RJ link on page 230 includes the procedure to determine which data groups use a remote journal link. Identifying journal definitions used with RJ on page 231 describes how to determine whether a journal definition is defined to one or more remote journal links. Disabling and enabling data groups on page 232 describes when it can be beneficial to disable and enable data groups. Procedures for these processes are included in this topic. Determining if non-file objects are configured for user journal replication on page 234 provides procedures for determining whether configured for IFS objects, data areas, and data queues are configured to be cooperatively processed through the user journal. Using file identifiers (FIDs) for IFS objects on page 236 describes file identifiers (FIDs) which are used by commands to uniquely identify the correct IFS tracking entries to process. Operating a remote journal link independently on page 237 describes how to configure, start, and end a remote journal link without defining data to be replicated by MIMIX processes.

221

Starting the TCP/IP server

Use this procedure if you need to manually start the TCP/IP server. Once the TCP communication connections have been defined in a transfer definition, the TCP server must be started on each of the systems identified by the transfer definition. You can also start the TCP/IP server automatically through an autostart job entry. Either you can change the transfer definition to allow MIMIX to create and manage the autostart job entry for the TCP/IP server, or you can add your own autostart job entry. MIMIX only manages entries for the server when they are created by transfer definitions. When configuring a new installation, transfer definitions and MIMIX-added autostart job entries do not exist on other systems until after the first time the MIMIX managers are started. Therefore, during initial configuration you may need to manually start the TCP server on the other systems using the STRSVR command. Note: Use the host name and port number (or port alias) defined in the transfer definition for the system on which you are running this command. From a 5250 emulator, do the following on the system on which you want to start the TCP server: 1. From the MIMIX Intermediate Main Menu, select option 13 (Utilities menu) and press Enter. 2. The Utilities Menu appears. Select option 51 (Start TCP server) and press Enter. 3. The Start Lakeview TCP Server display appears. At the Host name or address prompt, specify the host name or address for the local system as defined in the transfer definition. 4. At the Port number or alias prompt, specify the port number or alias as defined in the transfer definition for the local system. Note: If you specify an alias, you must have an entry in the service table on this system that equates the alias to the port number. 5. Press Enter. 6. Verify that the server job is running under the MIMIX subsystem on that system. You can use the Work with Active Jobs (WRKACTJOB) command to look for a job under the MIMIXSBS subsystem with a function of PGM-LVSERVER.
Updated for 6.0.12.00.

222

Ending the TCP/IP server

Ending the TCP/IP server

To end the TCP server, do the following on both systems defined by the transfer definition. One example of why you might end the TCP server is when you are preparing to upgrade the MIMIX products in a product library. Note: Use the host name and port number (or port alias) defined in the transfer definition for the system you on which you are running this command To end the TCP server on a system, do the following: 1. From the MIMIX Main Menu, select option 13 (Utilities menu) and press Enter. 2. The Utilities Menu appears. Select option 52 (End TCP server) and press Enter. 3. The End Lakeview TCP Server display appears. At the Host name or address prompt, specify the host name for the local system as specified in the transfer definition. 4. At the Port number or alias prompt, verify that the value shown is what you want. If necessary change the value. Note: If the configuration uses port aliases, specify the alias for local system. Otherwise, specify the port number for the local system. 5. Press Enter.

223

Working with objects

When working with objects, these tips may be helpful.

Displaying long object names

From MIMIX Availability Manager, object names are fully displayed in the assigned space. To view the IFS tracking name, do the following: 1. Select Data Groups from the Details area of the navigation bar. 2. From the list of data groups, select the data group you want. Status for this selected data group is displayed in the Summary area. 3. Select Display Details and click . The Data Group Detail Status window appears. Ensure the Activity field is highlighted from the area in the navigation bar. 4. Select IFS Tracking from the Activity Types area in the navigation bar. 5. Use the scroll bar to view any information not immediately found within the screen. From the 5250 emulator, the names of some IFS entries cannot be fully displayed in the limited space on a Work with display. These entries are shown with a > character in the right-most column of the Object field. You can display long object names from the following displays: Work with Data Group IFS Entries display Work with Data Group Activity Work with Data Group Activity Entries

To display the entire object name from any of these displays, position the cursor on an entry which indicates a long name and press F22 (Display entire field).

Considerations for working with long IFS path names

MIMIX currently replicates IFS path names of 512 characters. However, any MIMIX command that takes an IFS path name as input may be susceptible to a 506 character limit. This character limit may be reduced even further if the IFS path name contains embedded apostrophes ('). In this case, the supported IFS path name length is reduced by four characters for every apostrophe the path name contains. For information about IFS path name naming conventions, refer to the IBM book, Integrated File System Introduction V5R4.

Displaying data group spooled file information

If spooled files are created as a result of MIMIX replication, you can access the spooled file and the associated data group entry from the Work with Data Group Activity display.

224

Working with objects

To access the spooled file information, do the following: 1. From the MIMIX Basic Main Menu, select option 1 (Availability status) and press Enter. The MIMIX Availability Status display appears. 2. Select option 5 (Display details) in the Replication bar and press Enter. The Work with Data Groups display appears. 3. Select option 14 (Active objects) for the data group you want to view and press Enter. The Work with Data Group Activity display appears.

4. From this display, press F16 (Spooled Files) to access the Display Data Group Spooled Files display. This display lists all of the current spooled files and shows the mapping of their names between the source and target systems.

225

Viewing status for active file operations

If you are replicating database files that you are reorganizing or copying with MIMIX Promoter, you can check on the status of these operations. Do the following: 1. From the MIMIX Basic Main Menu, use F21 (Assistance level) to access the intermediate menu. 2. From the MIMIX Intermediate Main Menu, select option 13 (Utilities menu) and press Enter.

3. From the MIMIX Utilities Menu, select option 63 (Work with copy status) and press Enter. 4. The Work with Copy Status display appears. From this display you can track the status of active copy or reorganize operations, including the replication of physical file data as specified by METHOD(*DATA) on the Synchronize Data Group File Entry (SYNCDGFE) command. Note: You can only see status for the system on which you are working.

226

Displaying a remote journal link

Displaying a remote journal link

To display information about the link between a source journal definition and a target journal definition, do the following: 1. From the Work with RJ Links display, type a 5 (Display) next to the entry you want and press Enter. 2. The Display Remote Journal Link (DSPRJLNK) display appears, showing the current values defined for the link.

227

Displaying status of a remote journal link

From MIMIX Availability Manager, to determine whether a data group uses remote journaling, do the following: 1. Select Data Groups from the Details area of the navigation bar. 2. Select the specific data group you want to check the configuration for remote journaling. 3. See the Remote journaling field in the Summary area. If the field says Yes, remote journaling has been configured for the specified data group. From the 5250 emulator, to check the status of a remote journal link, do the following: 1. Type the command WRKRJLNK and press Enter. 2. The Work with RJ Links display appears with a list of defined links. The Dlvry column indicates configured value for how the IBM i remote journal function sends the journal entries from the source journal to the target journal. The possible values for delivery are asynchronous (*ASYNC) and synchronous (*SYNC). *ASYNC - Journal entries are replicated asynchronously, independent of the applications that create the journal entries. The applications continue processing while an independent system task delivers the journal entries. If a failure occurs on the source system, journal entries on the source system may become trapped because they have not been delivered to the target system. *SYNC - Journal entries are replicated synchronously. The applications do not continue processing until after the journal entries are sent to the target journal. If a failure occurs on the source system, the target system contains the journal entries that have been generated by the applications. The State column represents the composite view of the state of the remote journal link. Because the RJ link has both source and a target component, the state shown is that of the component which has the most severe state. Table 33 shows the possible states of an RJ link, listed in order from most severe to least severe.
Table 33. State Possible states for RJ links, shown in order starting with most severe. Description

The following states are considered to be inactive: *UNKNOWN *NOTAVAIL *NOTBUILT *SRCNOTBLT *TGTNOTBLT Neither journal defined to the remote journal link resides on the local system so the state of the link cannot be checked. The ASP where the journal is located is varied off. The remote journal link is defined to MIMIX but one of the associated journal environments has not been built. The remote journal link is defined to MIMIX but the associated source journal environment has not been built. The remote journal link is defined to MIMIX but the associated target journal environment has not been built.

228

Displaying status of a remote journal link

Table 33. State *FAILED

Possible states for RJ links, shown in order starting with most severe. Description The remote journal cannot receive journal entries from the source journal due to an error condition. The remote journal link is processing a request for a controlled end. The remote journal link is not active.

*CTLINACT *INACTIVE

The following states are considered to be active: *INACTPEND An active remote journal link is in the process of becoming inactive. For asynchronous delivery, this is a transient state that will resolve automatically. For synchronous delivery, one system is inactive while the other system is inactive with pending unconfirmed entries. An active remote journal link is connected using synchronous delivery and is running in catch-up mode. The state will become *SYNC when catch-up mode ends. An active remote journal link is connected using asynchronous delivery and is running in catch-up mode. The state will become *ASYNC when catch-up mode ends. An active remote journal link is connected using synchronous delivery mode. An active remote journal link is connected using asynchronous delivery mode.

*SYNCPEND

*ASYNCPEND

*SYNC *ASYNC

229

Identifying data groups that use an RJ link

Use this procedure to determine which data groups use a remote journal link before you end a remote journal link or remove a remote journaling environment. 1. Enter the command WRKRJLNK and press Enter. 2. Make a note of the name indicated in the Source Jrn Def column for the RJ Link you want. 3. From the command line, type WRKDGDFN and press Enter. 4. For all data groups listed on the Work with DG Definitions display, check the Journal Definition column for the name of the source journal definition you recorded in Step 2. If you do not find the name from Step 2, the RJ link is not used by any data group. The RJ link can be safely ended or can have its remote journaling environment removed without affecting existing data groups. If you find the name from Step 2 associated with any data groups, those data groups may be adversely affected if you end the RJ link. A request to remove the remote journaling environment removes configuration elements and system objects that need to be created again before the data group can be used. Continue with the next step.

5. Press F10 (View RJ links). Consider the following and contact your MIMIX administrator before taking action that will end the RJ link or remove the remote journaling environment. When *NO appears in the Use RJ Link column, the data group will not be affected by a request to end the RJ link or to end the remote journaling environment. Note: If you allow applications other than MIMIX to use the RJ link, they will be affected if you end the RJ link or remove the remote journaling environment. When *YES appears in the Use RJ Link column, the data group may be affected by a request to end the RJ link. If you use the procedure for ending a remote journal link independently in topic Ending a remote journal link independently on page 237, ensure that any data groups that use the RJ link are inactive before ending the RJ link.

230

Identifying journal definitions used with RJ

Identifying journal definitions used with RJ

To see whether a journal definition is defined to one or more remote journal links, do the following: 1. From the MIMIX Basic Main Menu, select option 11 (Configuration menu) and press Enter. 2. The MIMIX Configuration menu appears. Select option 3 (Work with journal definitions) and press Enter. 3. The Work with Journal Definitions display appears. The RJ Link column indicates whether or not the journal definition is used by a remote journal link. A blank value indicates the journal definition is not associated with a remote journal link. Values that indicate the definition is used by a remote journal link are as follows: *SOURCE - The journal definition is a source journal definition in a remote journal link. *TARGET - The journal definition is the target journal definition in a remote journal environment. *BOTH - The journal definition is the source journal definition for one remote journal link and is also a target journal definition for another remote journal link in a cascading environment. *NONE - The journal definition is not used with the MIMIX RJ support. 4. To see the remote journal links associated with a journal definition, type 12 (Work with RJ Links) and press Enter.

231

Disabling and enabling data groups

MIMIX supports the concept of disabled data groups in a replication environment. The ability to disable a data group, and enable it later as desired, can be beneficial in a variety of configuration scenarios. The ability to disable a data group is particularly helpful in advanced cluster scenarios, where inactive data groups may be a necessary component of the replication environment. Because these data groups are inactive as part of the design, the user does not need to be notified when the data groups are in error. Disabling a data group is also useful in non-cluster situations. If you create a data group for testing purposes, for example, you no longer have to delete the data group in order to clean up your environment when testing is complete. Instead, you can simply disable the data group until it is needed again. This provides the benefit of retaining your object, file, IFS, and DLO entries while the data group is not needed. Additionally, the journal manager does not retain journal receivers that have not been processed by a disabled data group, which allows you to save storage space on your system. With support for disabled data groups, you also avoid having to start each data group individually when an installation has data groups configured to replicate in different directions. Let us assume you have two sets of data groups: one set configured to replicate from System A to System B, and another set configured to replicate from System B to System A. To start only those data groups replicating from System A to System B, it was previously necessary to start them individually in order to prevent those replicating from System B to System A from starting as well. Now you can disable the data groups you do not want to start and simply start the remaining data groups using the Start MIMIX (STRMMX) command. Customers with many systems and data groups across varying time zones may find support for disabled data groups useful when performing upgrades. Disabling data groups allows you to stagger upgrades, causing minimal impact to your replication environment. In this situation, you install a new installation and copy the configuration data from the old installation using the Copy Configuration Data (CPYCFGDTA) command. Over a convenient period of time, you can end and disable each data group on the old (original) installation, then enable and start each data group on the new installation. Once all data groups in the old installation are disabled and all data groups in the new installation are enabled, the old installation can be deleted. A disabled data group is initiated by a user and is in a state of *DISABLE. An enabled data group can be active or inactive. The Change Data Group (CHGDG) command can be used to change the state of a data group. Only inactive data groups and data groups that do not have processes suspended at a recovery point can be disabled. To make a data group inactive, you must end the data group. The request to end the data group will clear any recovery point. Once a data group is disabled, it cannot be started, ended, or switched. Disabled data groups are indicated by a status of -D (in green) on the Work with Data Groups (WRKDG) display in the 5250 emulator. In MIMIX Availability Manager, disabled data groups have a status of Disabled. You can optionally not display disabled data groups

232

Disabling and enabling data groups

by specifying a different value on the STATE parameter of the WRKDG command or by specifying preferences in MIMIX Availability Manager.

Procedures for disabling and enabling data groups

From MIMIX Availability Manager, the following procedure allows you to enable or disable a data group by changing its state. To disable or enable an individual data group, do the following: 1. Select Data Group item of the Details area. 2. If the data group is active, end the data group by selecting End from the Action list in the Summary area and prompting the command. A red stop sign icon will appear when the data group has been ended. 3. From the list of data groups, select the inactive data group you want. Status for this selected data group is displayed in the Summary area. 4. To disable an enabled data group, select Disable from the Action list and click 5. To enable a disabled data group, select Enable from the Action list and click . .

From a 5250 emulator the Change Data Group (CHGDG) command allows you to disable or enable a data group by changing its state. This command requires that the system manager is active and communication with the remote system is active. To disable or enable an individual data group, do the following: 1. On a command line, type CHGDG and press Enter. The Change Data Group display appears. 2. At the Data group definition prompts, fill in the values you want or press F4 for a valid list. 3. At the State prompt, do one of the following: To keep the state of the data group the same, specify the default, *SAME. To change the state of an active data group, you must first end the data group by running the End Data Group (ENDDG) command. See Ending selected data group processes on page 151. To disable an enabled data group, specify *DISABLE. When the state of the data group is changed to disabled, the status of the data group changes from *INACTIVE to *DISABLED. To enable a disabled data group, specify *ENABLE. When the state of the data group is changed to enabled, the status of the data group changes from *DISABLED to *INACTIVE.

4. Press Enter to confirm your changes.

233

Determining if non-file objects are configured for user journal replication

MIMIX can take advantage of IBM i journaling functions that provide change-level details in journal entries in a user journal for object types other than files (*FILE). When properly configured, MIMIX can cooperatively process IFS stream files, data areas, and data queues between system journal and user journal replication processes. This enables changes to data or attributes to be replicated through the user journal instead of replicating the entire object through the system journal every time a change occurs.

Determining how IFS objects are configured

In order for IFS objects to be replicated from the user journal, one or more data group IFS entries must be configured to process cooperatively with the user journal. Also, IFS tracking entries must exist for the object identified by the data group IFS entries. To determine if a data group has any IFS objects that are configured for user journal replication and has any corresponding IFS tracking entries, do the following: 1. From the MIMIX Basic Main Menu select option 1 (Availability status) and press Enter. The MIMIX Availability Status display appears. 2. Type 5 (Display details) next to Replication and press Enter. The Work with Data Groups display appears. 3. Next to the data group you want, type 22 (IFS entries) and press Enter. The Work with DG IFS Entries display appears, showing the IFS entries configured for the data group. 4. Press F10 twice to access the CPD view. 5. The values shown in the Coop with DB column indicate how objects identified by the data group IFS entries will be replicated. Entries with the value *YES are configured for user journal replication. Continue with the next step to ensure that IFS tracking entries exist for the IFS objects. Replication cannot occur without tracking entries. Entries the value *NO are configured for system journal replication.

To view additional information for a data group IFS entry, type 5 (Display) next to the entry and press Enter. 6. Press F12 (Cancel) to return to the Work with Data Groups display. Then type 50 (IFS trk entries) next to the data group you want and press Enter. 7. The Work with DG IFS Trk. Entries display appears with a list of tracking entries for the IFS objects identified for replication by the data group. If there are no tracking entries listed but Step 5 indicates that properly configured data group IFS entries exist, the tracking entries must be loaded. For more information about loading tracking entries, see the MIMIX Reference book.

234

Determining if non-file objects are configured for user journal replication

Determining how data areas or data queues are configured

In order for data area and data queue objects to be replicated from the user journal, one or more data group object entries must be configured to process cooperatively with the user journal. Also, object tracking entries must exist for the object identified by the data group object entries. To determine if a data group has any data area or data queue objects that are configured for user journal replication and has any corresponding object tracking entries, do the following: 1. From the MIMIX Basic Main Menu select option 1 (Availability status) and press Enter. The MIMIX Availability Status display appears. 2. Type 5 (Display details) next to Replication and press Enter. The Work with Data Groups display appears. 3. Next to the data group you want, type 20 (Object entries) and press Enter. The Work with DG Object Entries display appears, showing the object entries configured for the data group. 4. For each entry in the list, do the following: a. Type a 5 (Display) next to the entry and press Enter. b. The object entry must have the following values specified in the fields indicated: The Object type field must be *ALL, *DTAARA, or *DTAQ The Cooperate with database field must be *YES The Cooperating object types field must specify *DTAARA to replicate data areas and *DTAQ to replicate data queues. 5. Press F12 (Cancel) to return to the Work with Data Groups display. Then type 52 (Obj trk entries) next to the data group you want and press Enter. 6. The Work with DG Obj. Trk. Entries display appears with a list of tracking entries for the data area and data queue objects identified for replication by the data group. If there are no tracking entries listed but Step 4 indicates that properly configured data group object entries exist, the tracking entries must be loaded. For more information about loading tracking entries, see the MIMIX Reference book.

235

Using file identifiers (FIDs) for IFS objects

Commands used for user journal replication of IFS objects use file identifiers (FIDs) to uniquely identify the correct IFS tracking entries to process. The System 1 file identifier and System 2 file identifier prompts ensure that IFS tracking entries are accurately identified during processing. These prompts can be used alone or in combination with the System 1 object prompt. These prompts enable the following combinations: Processing by object path: A value is specified for the System 1 object prompt and no value is specified for the System 1 file identifier or System 2 file identifier prompts. When processing by object path, a tracking entry is required for all commands with the exception of the SYNCIFS command. If no tracking entry exists, the command cannot continue processing. If a tracking entry exists, a query is performed using the specified object path name. Processing by object path and FIDs: A value is specified for the System 1 object prompt and a value is specified for either or both of the System 1 file identifier or System 2 file identifier prompts. When processing by object path and FIDs, a tracking entry is required for all commands. If no tracking entry exists, the command cannot continue processing. If a tracking entry exists, a query is performed using the specified FID values. If the specified object path name does not match the object path name in the tracking entry, the command cannot continue processing. Processing by FIDs: A value is specified for either or both of the System 1 file identifier or System 2 file identifier prompts and, with the exception of the SYNCIFS command, no value is specified for the System 1 object prompt. In the case of SYNCIFS, the default value *ALL is specified for the System 1 object prompt. When processing by FIDs, a tracking entry is required for all commands. If no tracking entry exists, the command cannot continue processing. If a tracking entry exists, a query is performed using the specified FID values.

236

Operating a remote journal link independently

Operating a remote journal link independently

You can configure, start, and end a remote journal link without defining data to be replicated by MIMIX processes. For example, you might have a need to use remote journals without performing data replication. The Start Remote Journal Link (STRRJLNK) and End Remote Journal Link (ENDRJLNK) commands provide this capability. Note: These commands should only be used by personnel with experience using the IBM i remote journal function. For most needs, support for the RJ link that is integrated in the commands which start and end replication processes (STRMMX, STRDG, ENDMMX, and ENDDG).

Starting a remote journal link independently

To start a remote journal link separately from other MIMIX processes, do the following: 1. To access the Work with Journal Links display, type the command WRKRJLNK and press Enter. 2. From the Work with Remote Journal Links display, type a 9 (Start) next to the link in the list that you want to start and press Enter. 3. The Start Remote Journal Link (STRRJLNK) display appears. Specify the value you want for the Starting journal receiver prompt. 4. To start remote journaling for the specified link, press Enter.

Ending a remote journal link independently

Default values for this command will perform an immediate end for the specified link. Be aware that the actions taken by the ENDOPT parameter on this command are different from the actions taken when you perform an immediate or controlled end of a MIMIX data group. For more information about the differences between this command and the End Data Group (ENDDG) command, see the MIMIX Reference book. For the following situations, an immediate end is always performed (the value specified for the ENDOPT parameter is ignored): The remote journal function is running in synchronous mode (DELIVERY(*SYNC)). The remote journal function is performing catch-up processing.

To end a remote journal link separately from other MIMIX processes, do the following: 1. To access the Work with Journal Links display, type the command WRKRJLNK and press Enter. 2. From the Work with Remote Journal Links display, type a 10 (End) next to the link in the list that you want to end. 3. Do one of the following: To perform an immediate end from the source system, press Enter. This completes the procedure for an immediate end.

237

To perform a controlled end or to end from the target system, press F4 (Prompt), then continue with the next step.

4. The End Remote Journal Link (ENDRJLNK) display appears. Press F10 (Additional parameters). 5. To perform a controlled end, specify *CNTRLD at the End remote journal link prompt. If you need to end from the target system, specify *TGT at the End RJ link on system prompt. To process the request, press Enter.

238

CHAPTER 10

Troubleshooting - where to start

Occasionally, a situation may occur that requires user intervention. This section provides information to help you troubleshoot problems that can occur in a MIMIX environment. If you are using MIMIX Availability Manager, the best place to start is with the flyover text on the icons representing problems and status. Often, this will direct you to a course of action. If you are using 5250 emulator commands, start at the MIMIX Availability Status display.

Note: The procedures in this chapter are primarily for use with a 5250 emulator. You can also consult our website at www.mimix.com for the latest information and updates for MIMIX products. The following topics are included in this chapter: Gathering information before reporting a problem on page 241 describes the information you should gather before you report a problem. A procedure is included to help you gather this information. Reducing contention between MIMIX and user applications on page 242 describes a processing timing issue that may be resolved by specifying an Object retrieval delay value on the commands for creating or changing data group entries. Data groups cannot be ended on page 243 describes possible causes for a data group that is taking too long to end. Verifying a communications link for system definitions on page 244 describes the process to verify that the communications link defined for each system definition is operational. Verifying the communications link for a data group on page 245 includes a process to use before synchronizing data to ensure that the communications link for the data group is active. Checking file entry configuration manually on page 246 includes the process for checking that correct data group file entries exist with respect to the data group object entries. This process uses the Check DG File Entries (CHKDGFE) command. Data groups cannot be started on page 248 describes some common reasons why a data group may not be starting. Cannot start or end an RJ link on page 249 describes possible reasons that can prevent you from starting or ending an RJ link. This topic includes a procedure for removing unconfirmed entries to free an RJ link. RJ link active but data not transferring on page 250 describes why an RJ link may not be transferring data and how to resolve this problem.

239

Troubleshooting - where to start

Errors using target journal defined by RJ link on page 251 describes why errors when using a target journal defined by an RJ link can occur and how to resolve them. Verifying data group file entries on page 252 includes a procedure for verifying data group file entries using the Verify Data Group File Entries (VFYDGFE) command. Verifying data group data area entries on page 252 includes a procedure for verifying data group data area entries using the Verify Data Group Data Area Entries (VFYDGDAE) command. Data area entries are only used when data areas are replicated by the data area poller process, which is not preferred. Verifying key attributes on page 252 includes a procedure for verifying key attributes using the VFYKEYATR (Verify Key Attributes) command. Working with data group timestamps on page 254 describes timestamps and includes information for creating, deleting, displaying, and printing them. Removing journaled changes on page 257 describes the configuration conditions that must be met using the Remove Journaled Changes (RMVJRNCHG) journal entry. Performing journal analysis on page 258 describes and includes the procedure for performing journal analysis of the source system.

240

Gathering information before reporting a problem

Gathering information before reporting a problem

Before you report a problem, you should gather the following information: The MIMIX product, library, installed version, and IBM i operating system level on the system you are using. To determine this information, follow the procedure Obtaining MIMIX and IBM i information from your system on page 241. The Message ID number for any error messages associated with the problem. If you receive error messages, record the message number, any replacement text (such as Process X failed for file Y), and the to and from program information, if available. Since many messages have similar text, this information is much more helpful to us and enables us to handle your call more efficiently. The specific operation you were attempting to perform when the error condition occurred. It is important that we understand what you were trying to do when you encountered the problem. Try to write down the specific sequence of events that you were doing when the error condition occurred, such as the commands entered, the display you were working from, or the program that was running.

Obtaining MIMIX and IBM i information from your system

To obtain the necessary MIMIX and IBM i information before reporting a problem, do the following: 1. Do one of the following to access the Lakeview Technology Installed Products display: If you are configured for a MIMIX replication environment, select option 31 (Product management menu). Then select option 2 (Work with products). From a command line, enter LAKEVIEW/WRKPRD

2. Next to the product you want, type a 6 (About version) and press Enter. The About pop-up appears, showing the Product, Library, Installed version, and the OS/400 level on this system. 3. Press F9 (Fixes) to see the Work with Installed Fixes display. From this display you can determine the latest level of the MIMIX cumulative fix package that is installed. Note: You should know the version and release level (VnRnMn) of the IBM i operating system that is on each system with which you are working. Use the process above on each system.

241

Reducing contention between MIMIX and user applications

If your applications are failing in an unexpected manner, it may be caused by MIMIX locking your objects for object retrieval processing while your applications are trying to access the object. This is a processing timing issue and can be significantly reduced, or eliminated, by specifying an appropriate delay value for the Object retrieval delay element under the Object processing (OBJPRC) parameter on the change or create data group definition commands. Although you can specify this value at the data group level, you can override the data group value at the object level by specifying an Object retrieval delay value on the commands for creating or changing data group entries. For more information see Selecting an object retrieval delay in the MIMIX Reference book. You should use care when choosing the object retrieval delay. A long delay may impact the ability of MIMIX system journal replication processes to move data from a system in a timely manner. Too short a delay may allow MIMIX to retrieve an object before an application is finished with it. You should make the value large enough to reduce or eliminate contention between MIMIX and applications, but small enough to allow MIMIX to maintain a suitable high availability environment.

242

Data groups cannot be ended

Data groups cannot be ended

A controlled end for a data group may take some time if there is a backlog of files to process or if there are a number of errors that MIMIX is attempting to resolve before ending. If you think that a data group is taking too long to end, check the following for possible causes: Check to see how many transactions are backlogged for the apply process. Use option 8 (Display status) on the Work with Data Groups display to access the detailed status. A number in the Unprocessed Entry Count column indicates a backlog. Use F7 and F8 to see additional information. Determine which replication process is not ending. Use the command WRKSBSJOB SBS(MIMIXSBS) to see the jobs in the MIMIXSBS subsystem. Look for jobs for replication processes that have not changed to a status of END. For example, abc_OBJRTV, where abc is a 3-character prefix. Check the QSYSOPR message log to see if there is message that requires a reply. You can use the WRKDGACTE STATUS(*ACTIVE) command to ensure all data group activity entries are completed. If a controlled end was issued, all activity entries must be processed before the object processes are ended.

243

Verifying a communications link for system definitions

Do the following to verify that the communications link defined for each system definition is operational: 1. From the MIMIX Basic Main Menu, type an 11 (Configuration menu) and press Enter. 2. From the MIMIX Configuration Menu, type a 1 (Work with system definitions) and press Enter. 3. From the Work with System Definitions display, type an 11 (Verify communications link) next to the system definition you want and press Enter. You should see a message indicating the link has been verified. Note: If the system manager is not active, this process will only verify that communications to the remote system is successful. You will also see a message in the job log indicating that "communications link failed after 1 request." This indicates that the remote system could not return communications to the local system. 4. Repeat this procedure for all system definitions. If the communications link defined for a system definition uses SNA protocol, do not check the link from the local system. Note: If your transfer definition uses the *TCP communications protocol, then MIMIX uses the Verify Communications Link command to validate the information that has been specified for the Relational database (RDB) parameter. MIMIX also uses VFYCMNLNK to verify that the System 1 and System 2 relational database names exist and are available on each system.

244

Verifying the communications link for a data group

Verifying the communications link for a data group

Before you synchronize data between systems, ensure that the communications link for the data group is active. This procedure verifies the primary transfer definition used by the data group. If your configuration requires multiple data groups, be sure to check communications for each data group definition. Do the following: 1. From the MIMIX Basic Main Menu, type an 11 (Configuration menu) and press Enter. 2. From the MIMIX Configuration Menu, type a 4 (Work with data group definitions) and press Enter. 3. From the Work with Data Group Definitions display, type an 11 (Verify communications link) next to the data group you want and press F4. 4. The Verify Communications Link display appears. Ensure that the values shown for the prompts are what you want. 5. To start the check, press Enter. 6. You should see a message "VFYCMNLNK command completed successfully." If your data group definition specifies a secondary transfer definition, use the following procedure to check all communications links.

Verifying all communications links

The Verify Communications Link (VFYCMNLNK) command requires specific system names to verify communications between systems. When the command is called from option 11 on the Work with System Definitions display or option 11 on the Work with Data Groups display, MIMIX identifies the specific system names. For transfer definitions using TCP protocol: MIMIX uses the Verify Communications Link (VFYCMNLNK) command to validate the values specified for the Relational database (RDB) parameter. MIMIX also uses VFYCMNLNK to verify that the System 1 and System 2 relational database names exist and are available on each system. When the command is called from option 11 on the Work with Transfer Definitions display or when entered from a command line, you will receive an error message if the transfer definition specifies the value *ANY for either system 1 or system 2. 1. From the Work with Transfer Definitions display, type an 11 (Verify communications link) next to all transfer definitions and press Enter. 2. The Verify Communications Link display appears. If you are checking a Transfer definition with the value of *ALL, you need to specify a value for the System 1 or System 2 prompt. Ensure that the values shown for the prompts are what you want and then press Enter. You will see the Verify Communications Link display for each transfer definition you selected. 3. You should see a message VFYCMNLNK command completed successfully.

245

Checking file entry configuration manually

The Check DG File Entries (CHKDGFE) command provides a means to detect whether the correct data group file entries exist with respect to the data group object entries configured for a specified data group in your MIMIX configuration. When file entries and object entries are not properly matched, your replication results can be affected. Note: The preferred method of checking is to use MIMIX AutoGuard to automatically schedule the #DGFE audit, which calls the CHKDGFE command and can automatically correct detected problems. For additional information, see Interpreting results for configuration data - #DGFE audit on page 263. To check your file entry configuration manually, do the following: 1. On a command line, type CHKDGFE and press Enter. The Check Data Group File Entries (CHKDGFE) command appears. 2. At the Data group definition prompts, select *ALL to check all data groups or specify the three-part name of the data group. 3. At the Options prompt, you can specify that the command be run with special options. The default, *NONE, uses no special options. If you do not want an error to be reported if a file specified in a data group file entry does not exist, specify *NOFILECHK. 4. At the Output prompt, specify where the output from the command should be sentto print, to an outfile, or to both. See Step 6. 5. At the User data prompt, you can assign your own 10-character name to the spooled file or choose not to assign a name to the spooled file. The default, *CMD, uses the CHKDGFE command name to identify the spooled file. 6. At the File to receive output prompts, you can direct the output of the command to the name and library of a specific database file. If the database file does not exist, it will be created in the specified library with the name MXCDGFE. 7. At the Output member options prompts, you can direct the output of the command to the name of a specific database file member. You can also specify how to handle new records if the member already exists. Do the following: a. At the Member to receive output prompt, accept the default *FIRST to direct the output to the first member in the file. If it does not exist, a new member is created with the name of the file specified in Step 6. Otherwise, specify a member name. b. At the Replace or add records prompt, accept the default *REPLACE if you want to clear the existing records in the file member before adding new records. To add new records to the end of existing records in the file member, specify *ADD. 8. At the Submit to batch prompt, do one of the following: If you do not want to submit the job for batch processing, specify *NO and press Enter to check data group file entries.

246

Checking file entry configuration manually

To submit the job for batch processing, accept *YES. Press Enter and continue with the next step.

9. At the Job description prompts, specify the name and library of the job description used to submit the batch request. Accept MXAUDIT to submit the request using the default job description, MXAUDIT. 10. At the Job name prompt, accept *CMD to use the command name to identify the job or specify a simple name. 11. To start the data group file entry check, press Enter.

247

Data groups cannot be started

Two common reasons why a data group cannot be started are as follows: The communications link between systems defined to the data group is not active. Use the procedure Verifying a communications link for system definitions on page 244. The journaling environment for the data group has not been built. Verify that journaling environment defined in the journal definition exists. If necessary, use the appropriate procedure in the MIMIX Reference book. The journal receiver has been deleted from the system. You can use WRKJRNA to determine if the journal receiver exists on the source system.

248

Cannot start or end an RJ link

Cannot start or end an RJ link

In normal operations, unconfirmed entries are automatically handled by the RJ link monitors. In the event of a switch, the unconfirmed entries are processed, ensuring that you have the latest updates to your data. However, there is a scenario where you may end up with a backlog of unconfirmed entries that can prevent you from starting or ending an RJ link. This problem can occur when all of the following are true: The data group is not switchable or you do not want to switch it A link failure on an RJ link that is configured for synchronous delivery leaves unconfirmed entries The RJ link monitors are not active, either because you are not using them or they failed as a result of a bad link

To recover from this situation, you should run the Verify Communications Link (VFYCMNLNK) command to assist you in determining what may by wrong and why the RJ link will not start. If you are using an independent ASP, check the transfer definition to ensure the correct database name has been specified. You also need to end the remote journal link from the target system. Ending the link from the target system is a restriction of the IBM remote journal function.

Removing unconfirmed entries to free an RJ link

Note: You should never remove unconfirmed entries from a switchable data group unless you are directed to by your MIMIX administrator or a CustomerCare representative. If you need to remove a backlog of unconfirmed entries, do the following: 1. Use the WRKRJLNK command to display the status of the RJ link. The status shown on the Work with RJ Links display is the status of the link on the system where you entered the command. (This system is identified at the upper right corner of the display.) An RJ link with unconfirmed entries will have a state of *INACTPEND. Note: You may need to access this display from the other system defined by the RJ link. 2. Ending the remote journal link on the system with unconfirmed entries will cause them to be deleted. Do the following: a. Type 10 (End) next to the link and press F4 (Prompt). b. The End Remote Journal Link (ENDRJLNK) display appears. Default values on this command ends the link from the source system. If there are unconfirmed entries on the target system, press F10 (Additional parameters). Then specify *TGT at the End RJ link on system prompt. c. To process the request, press Enter.

249

RJ link active but data not transferring

Following an initial program load (IPL), the RJ link may appear to be active when data cannot actually flow from the source system to the target system journal receiver. This is an operating system restriction. MIMIX does not receive notification of a failure. To recover, end the RJ lInk and restart it following an IPL. This can be included in automation programs.

250

Errors using target journal defined by RJ link

Errors using target journal defined by RJ link

If you receive errors when using a target journal defined by an RJ link, you may need to change the journal definition and journaling environment. This situation is caused when the target journal definition is created as a result of adding an RJ link based on a source journal definition which specified QSYSOPR as the threshold message queue. If you receive errors when using the target journal, do the following: 1. On the Work with Journal Definitions display, locate the target journal definition that is identified by the errors. 2. Type a 5 (Display) next to the target journal definition and press Enter. 3. Page down to see the value of the Threshold message queue. If the value is QSYSOPR, press F12 and continue with the next step. For any other value, the cause of the problem needs further isolation beyond this procedure.

4. Type a 2 (Change) next to the target journal definition and press Enter. 5. Press F9 (All parameters), then page down to locate the Threshold message queue and Library prompts. 6. Change the Threshold message queue prompt to *JRNDFN and the Library prompt to *JRNLIB, or to other acceptable values. 7. To accept the change, press Enter.

251

Verifying data group file entries

The Verify Data Group File Entries (VFYDGFE) command allows you to verify files from a specific library by verifying the current state of the file on the system identified in the data group as the source of data. This procedure generates a report in a spooled file named MXVFYDGFE. The information in the report includes whether each member for the specified search criteria is defined to MIMIX, the journal and library to which it is journaled, whether it uses after-image journaling or before- and after-image journaling, the apply session used. This information can help you verify that you have all the files you need from a library properly defined to MIMIX DB Replicator. To verify data group file entries, do the following: 1. On a command line, type VFYDGFE (Verify Data Group File Entries). The Verify DG File Entries display appears. 2. Specify the name of the data group at the Data group definition prompt. 3. At the System 1 file and Library prompts, specify the value you want and the library in which the files are located. 4. If you want to create a spooled file that can be printed, specify *PRINT at the Output prompt. Then press Enter.

Verifying data group data area entries

The Verify Data Group Data Area Entries (VFYDGDAE) command allows you to verify the data areas in a specific library defined to a data group definition. The audit report determines the data source for the data group and retrieves the appropriate information. This procedure generates a report in a spooled file named MXVFYDAE. The information in the report includes whether each data area for the specified search criteria is defined to MIMIX and the length of each data area. This information can help you verify that you have all the data areas you need from a library defined to MIMIX DB Replicator. To verify data group data area entries, do the following: 1. On a command line, type VFYDGDAE (Verify Data Group Data Area Entries). The Verify DG Data Area Entries (VFYDGDAE) display appears. 2. Specify the name of the data group at the Data group definition prompt. 3. At the System 1 data area and Library prompts, specify the value you want and the library in which the data areas are located and press Enter.

Verifying key attributes

Before you configure for keyed replication, verify that the file or files you for which you want to use keyed replication are actually eligible.

252

Verifying key attributes

Do the following to verify that the attributes of a file are appropriate for keyed replication: 1. On a command line, type VFYKEYATR (Verify Key Attributes). The Verify Key Attributes display appears. 2. Do one of the following: To verify a file in a library, specify a file name and a library. To verify all files in a library, specify *ALL and a library. To verify files associated with the file entries for a data group, specify *MIMIXDFN for the File prompt and press Enter. Prompts for the Data group definition appear. Specify the name of the data group that you want to check.

3. Press Enter. 4. A spooled file is created that indicates whether you can use keyed replication for the files in the library or data group you specified. Display the spooled file (WRKSPLF command) or use your standard process for printing. You can use keyed replication for the file if *BOTH appears in the Replication Type Allowed column. If a value appears in the Replication Type Defined column, the file is already defined to the data group with the replication type shown.

253

Working with data group timestamps

Timestamps allow you to view the performance of the database send, receive, and apply processes for a data group to identify potential problem areas, such as a slow send process, inadequate communications capacity, or excessive overhead on the target system. Although they can assist you in identifying problem areas, timestamps are not intended as an accurate means of calculating the performance of MIMIX. A timestamp is a single record that is passed between all replication processes. The timestamp originates on the source system as a journal entry, is sent to the target system, and then processed by the associated apply session. The timestamp record is updated with the date and time at each of the following areas during the replication process: Created - Date and time the journal entry is created Sent - Date and time when the journal entry is sent to the target system Received - Date and time when the journal entry is received Applied - Date and time when the journal entry is applied

Note: For data groups that use remote journaling, the created and sent timestamps will be set to the same value. The received timestamp will be set to the time when the record was read on the target system by the database reader process. After all four timestamps have been added, the journal entry is converted and placed into a file for viewing or printing. You can view timestamps only from the management system. The system manager must be active to return the timestamps to the management system.

Automatically creating timestamps

The data group definition includes a parameter for automatically creating timestamps. MIMIX automatically creates a timestamp after the number of journal entries specified in the Timestamp interval (TSPITV) has passed. The timestamp entry created is placed at the end of all current entries in the journal receiver. You specify this value when you create or change a data group definition. You can change this value at any time. Note: Data groups configured for remote journaling will not automatically generate timestamps. To generate timestamps in this case, refer to Creating timestamps for remote journaling processing on page 255.

Creating additional timestamps

Note: By using the Create Data Group Timestamps (CRTDGTSP) command in a batch job, you can use timestamps to monitor performance at critical times in your daily processing. To create one or more timestamps, do the following: 1. From the Work with Data Groups display, type 41 (Timestamps) next to the data group you want and press Enter.

254

Working with data group timestamps

2. The Work with DG Timestamps display appears. Type a 1 (Create) next to the blank line at the top of the display and press Enter. 3. The Create Data Group Timestamps display appears. Specify the name of the data group and the number of timestamps you want to create and press Enter. Note: You should generate multiple timestamps to receive a more accurate view of replication process performance.

Creating timestamps for remote journaling processing

If you need to generate timestamps to monitor replication performance, you can set up automation to create them for remote journaling (RJ) data groups that you wish to monitor. In this procedure, you will create an interval monitor using the Create Monitor Object (CRTMONOBJ) command. This is accomplished by specifying *CMD for the interface exit program on the monitor object, and then Create Data Group Timestamps (CRTDGTSP) for the command (*CMD). You can also run CRTDGTSP manually or schedule a job to run the command in batch. For more information, see Creating an interval monitor in the MIMIX Monitor book. Do the following to create an interval monitor: 1. From the Work with Monitors display, type a 1 (Create) in the Opt column next to the blank line at the top of the list and press Enter. 2. The Create Monitor Object (CRTMONOBJ) display appears. Do the following: a. At the Monitor prompt, provide a unique name for the monitor. b. At the Event class prompt, specify *INTERVAL. c. At the Interface exit program prompt, specify *CMD. d. At the Time interval (sec.) prompt, specify how often the interval monitor should run and press Enter. By default, this monitor runs every 15 seconds. Use your data group time stamp interval (default is every 20,000 entries) to estimate how many entries you process a day. From there, determine how often you need to run the monitor in order to provide an adequate sample. 3. The Add Monitor Information (ADDMONINF) display appears. Do the following: a. At the Command prompt, type CRTDGTSP. b. At the Library prompt, type the name of your installation library and press F4 (Prompt). 4. The Create Data Group Timestamps (CRTDGTSP) display appears. Do the following: a. At the Data group definition prompts, specify the name of the RJ data group. b. At the Number of stamps to create prompt, specify the number of timestamps you want to create and press Enter. 5. From the Work with Monitors display, type a 9 (Start) next to the interval monitor you created. This allows you to start generating timestamps. For information about viewing timestamps, see Displaying or printing timestamps on page 256.

255

Repeat this procedure for each RJ data group for which you want to generate timestamps.

Deleting timestamps
You can delete all timestamps or you can select a group of one or more timestamps to delete. To delete timestamps for a data group, do the following: 1. From the Work with Data Groups display, type 41 (Timestamps) next to the data group you want and press Enter. 2. The Work with DG Timestamps display appears. Type a 4 (Delete) next to the timestamps you want to delete and press Enter. 3. A confirmation screen appears. Press Enter. To selectively delete a range of timestamps, do the following: 1. Type the command DLTDGTSP and press F4 (Prompt). 2. The Delete Data Group Timestamps display appears. Specify values you want for the Data group definition prompt. 3. Specify the values you want for the Starting date and time prompt and for the Ending date and time prompt, then press Enter.

Displaying or printing timestamps

To display or print data group timestamps, do the following: 1. From the Work with Data Groups display, type 41 (Timestamps) next to the data group you want and press Enter. 2. The Work with DG Timestamps display appears. Do one of the following: To display the timestamp information, type a 5 (Display) next to the data group you want. To print the timestamp information, type a 6 (Print) next to the data group you want.

3. Press Enter. 4. If you selected to display, the Display Data Group Timestamps display appears. If you selected to print, a spooled file is created that you can print using your standard printing procedures.

256

Removing journaled changes

Removing journaled changes

If the necessary environment is available, MIMIX can support the Remove Journaled Changes (RMVJRNCHG) journal entry by simulating the Remove Journaled Changes process on the backup system. Note: This is a long running procedure and will affect your existing journal changes. Ensure that performing this procedure is appropriate for your environment. In order to use the Remove Journaled Changes journal entry, you must meet the following criteria: You must be configured for both before and after image journaling. This can be defined as a default file entry option at the data group level or it can be defined for individual data group file entries. You must be configured with *SEND as the value of the Before images element of the DB journal entry processing (DBJRNPRC) parameter of the data group definition. This permits the database apply process to roll back certain types of journal entries. If you have large objects (LOBs), *YES must be the value for the Use remote journal link (RJLNK) parameter of the data group definition. The target system (where replicated changes are applied) must have the log spaces that contain the original transactions. To ensure that the appropriate log spaces are retained, you can do one of the following: Calculate how many log spaces need to be retained using the log space size and the size and number of the receivers containing the appropriate journal transactions. Then, set elements of the database apply processing (DBAPYPRC) parameter in the data group definition. Use the Hold Data Group Log (HLDDGLOG) command to place a hold on the delete operation of all log spaces for all apply sessions defined to the specified data group. The log spaces are held until a request to release them with Release Data Group Log (RLSDGLOG) command is received. If you are changing an existing data group to have these values, you must end and restart the data group before you are able to use the RMVJRNCHG command.

257

Performing journal analysis

When a source system fails before MIMIX has sent all journal entries to the target system, unprocessed transactions occur. Unprocessed transactions can also occur if journal entries are in the communications buffer being sent to the target system when the sending system fails. Following an unplanned switch, unprocessed transactions on the original source system must be addressed in order to prevent data loss before synchronizing data and starting data groups. The journal analysis process finds any missing transactions that were not sent to the target system when the source system went down and an unplanned switch to the backup was performed. Once unprocessed transactions are located, users must analyze the journal entries and take appropriate actions to resolve them. The time at which to perform journal analysis is when the original source system has been brought back up and before performing the synchronization phase of the switch (which synchronizes data and starts data groups). Analyze all data groups that were not disabled at the time of the unplanned switch. Note: The journal analysis tool is limited to database files replicated from a user journal. The tool does not identify unprocessed transactions for data areas, data queues, or IFS objects replicated through a user journal, or database files configured for replication from the system journal. From the original source system, do the following: 1. Ensure that the port communications jobs (PORTxxxxx) and the MIMIX system managers have been started. IMPORTANT! Do not start data groups at this time! Doing so will delete the data required to perform the journal analysis. 2. From the Work with Data Groups display on the original source system, enter 43 (Journal analysis) next to the data group to be analyzed. The Journal Analysis of Files display appears. 3. Check the list area for a pop-up window and do the following: If a pop-up window with the message Journal analysis information not collected is displayed, press Enter to collect journal analysis information, then go to Step 5. If you do not see a pop-up window, information about files from a previous run of journal analysis exists, go to Step 4.

4. If you did not see a pop-up window in Step 3 and you need to clear data from a previous run of journal analysis and collect new information, do the following: a. If you want to keep information from a previous run, make a copy of file DM6500P located in the installation library. b. Press F9 (Update display) to clear the screen and collect the new information. A pop-up confirmation window with the following message is displayed: WARNING! The journal analysis journal entries file will be cleared!

258

Performing journal analysis

c. Press Enter to submit the update request. 5. The request to collect journal analysis information is submitted by job RTVFILANZ using the job description MIMIXQGPL/MIMIXDFT. When the job completes, LVI3855 Retrieval of affected files for journal analysis completed normally appears in the message log. Press F5 (Refresh) to see the collected information. It may take a short time to collect the information. 6. Retrieve journal entries. The journal entries for the files identified on the display must be retrieved before you can use options to display or print statistics (5 and 6) or display journal entries (11). Do one of the following: Press F14 (Retrieve all entries). A pop-up window stating Confirm retrieval of ALL analysis journal entries appears. Press Enter. (The retrieved information is placed in an internal file.This does not produce a spool file.) If there are a large number of files listed on the display, you may want to retrieve entries for only a selected file at a time. Type option 9 (Retrieve journal entries) next to the file to retrieve journal entries for and press Enter. The retrieved journal entries are placed in a spool file named MXJEANZL.

Message: LVI3856 Retrieval of journal entries for journal analysis completed normally appears in the message log. 7. Review the collected information using the following: Use option 11 (Display journal entries) to view the entries for each file. Use F21 (Print list) to print all entries for a file. You can use options 5 (Display statistics) and 6 (Print statistics) to see the statistical breakdown of journal entries for a selected file member identified by journal analysis. The statistics include the number of adds, deletes, and updates, along with the related file transactions and dates of the first and last journal entries.

Figure 35 shows an example of the information displayed by option 11 for one journal entry.

259

Figure 35. Sample of one journal entry

Data group definition: Journal definition: File identification File . . . . : <FILE> Library . : <LIB> Member . . . : <MBR> Journal header information Journal code . . . . . : Journal type . . . . . : Generated date . . . . : Generated time . . . . : Job name . . . . . . . : User name . . . . . . : Job number . . . . . . : Program name . . . . . : <DGDFN> <SYS1> <SYS2> <JRNDFN> <SYSDFN>

R DL 9/08/09 10:36:31 <JOB NAME> <USER> <JOB NBR> <PROGRAM>

Record-level information Delete record

Journal header information (continued) Record length . . . . : 607 Record number . . . . : 838 Operation indicator . : 0 Commit cycle ID . . . : 0 Journal identification Journal name . . . . . : Library . . . . . . : Receiver identification Receiver name . . . . : Library . . . . . . : Sequence number . . . :

<JOURNAL> <JRNLIB>

<RCVR> <RCVRLIB> <JOURNAL SEQUENCE>

8. Determine what action you need to take for each unprocessed entry. For example: You may need to run the original job again on the current source system to reproduce the entries. If a file has already been updated on the current source system (manually or otherwise), you may need to merge data from both files. If this is the case, do not synchronize the files. If there are write changes (R-PT entries), these changes should be made on the current source system before running the synchronization phase of the switch or starting data groups in order to maintain Relative Record Number consistency within the file. If this is done after the data group has been started, the relative record numbers could become unsynchronized between the two systems.

Note: It is the customers responsibility to fix the files.

Updated for 6.0.15.00.

Removing journal analysis entries for a selected file

You can use option 4 (Remove journal entries) to remove all journal analysis journal entries for a selected file member. A confirmation display appears to confirm your

260

Performing journal analysis

choices. When you continue with the confirmation, the journal entries for the selected file member are immediately removed from the journal analysis information that is displayed. It does not delete any other information contained in other MIMIX files.
Updated for 6.0.15.00.

261

Interpreting audit results - supporting information

Interpreting audit results supporting information

APPENDIX A
Audits use commands that compare and synchronize data. The results of the audits are placed in output files associated with the commands. The following topics provide supporting information for interpreting data returned in the output files. Interpreting results for configuration data - #DGFE audit on page 263 describes the #DGFE audit which verifies the configuration data defined to your configuration using the Check Data Group File Entries (CHKDGFE) command. Interpreting results of audits for record counts and file data on page 265 describes the audits and commands that compare file data or record counts. Interpreting results of audits that compare attributes on page 268 describes the Compare Attributes commands and their results.

262

Interpreting results for configuration data - #DGFE audit

Interpreting results for configuration data - #DGFE audit

The #DGFE audit verifies the configuration data that is defined for replication in your configuration. This audit invokes the Check Data Group File Entries (CHKDGFE) command for the audits comparison phase. The CHKDGFE command collects data on the source system and generates a report in a spooled file or an outfile. The report is available on the system where the command ran. The values in the Result column of the report indicate detected problems and the result of any attempted automatic recovery actions. Table 34 shows the possible Result values and describes the action to take to resolve any reported problems.
Table 34. Result *NODGFE CHKDGFE - possible results and actions to for resolving errors Recovery Actions No file entry exists. Create the DGFE or change the DGOBJE to COOPDB(*NO)
Note: Changing the object entry affects all objects using the object entry. If you do not want all objects changed to this value, copy the existing DGOBJE to a new, specific DGOBJE with the appropriate COOPDB value.

*EXTRADGFE

An extra file entry exists. Delete the DGFE or change the DGOBJE to COOPDB(*YES)
Note: Changing the object entry affects all objects using the object entry. If you do not want all objects changed to this value, copy the existing DGOBJE to a new, specific DGOBJE with the appropriate COOPDB value.

*NOFILE *NOMBR *RCYFAILED

No file exists for the existing file entry. Delete the DGFE, re-create the missing file, or restore the missing file. No file member exists for the existing file entry. Delete the DGFE for the member or add the member to the file. Automatic audit recovery actions were attempted but failed to correct the detected error. Run the audit again. Recovered by automatic recovery actions. No action is needed. File entries are in transition and cannot be compared. Run the audit again.

*RECOVERED *UA

The Option column of the report provides supplemental information about the comparison. Possible values are: *NONE - No options were specified on the comparison request. *NOFILECHK - The comparison request included an option that prevented an error from being reported when a file specified in a data group file entry does not exist. *DGFESYNC - The data group file entry was not synchronized between the source and target systems. This may have been resolved by automatic recovery

263

actions for the audit. One possible reason why actual configuration data in your environment may not match what is defined to your configuration is that a file was deleted but the associated data group file entries were left intact. Another reason is that a data group file entry was specified with a member name, but a member is no longer defined to that file. If you use the automatic scheduling and automatic audit recovery functions of MIMIX AutoGuard, these configuration problems can be automatically detected and recovered for you. Table 35 provides examples of when various configuration errors might occur.
Table 35. Result *NODGFE *EXTRADGFE *NOFILE *NOMBR CHKDGFE - possible error conditions File exists Yes Yes No Yes Member exists Yes Yes No No DGFE exists No Yes Yes Yes DGOBJE exists COOPDB(*YES) COOPDB(*NO) Exclude No entry

264

Interpreting results of audits for record counts and file data

Interpreting results of audits for record counts and file data

The audits and commands that compare file data or record counts are as follows: #FILDTA audit or Compare File Data (CMPFILDTA) command #MBRRCDCNT audit or Compare Record Count (CMPRCDCNT) command

Each record in the output files for these audits or commands identifies a file member that has been compared and indicates whether a difference was detected for that member. MIMIX Availability Manager displays only detected differences found by each compare command using a subset of the fields from the output file. You can see the full set of fields in each output file by viewing it from a 5250 emulator. The type of data included in the output file is determined by the report type specified on the compare command. When viewed from a 5250 emulator, the data included for each report type is as follows: Difference reports (RPTTYPE(*DIF)) return information about detected differences. Difference reports are the default for these compare commands. Full reports (RPTTYPE(*ALL)) return information about all objects and attributes compared. Full reports include both differences and objects that are considered synchronized. Relative record number reports (RPTTYPE(*RRN)) return the relative record number of the first 1,000 records of a member that fail to compare. Relative record number reports apply only to the Compare File Data command.

What differences were detected by #FILDTA

The Difference Indicator (DIFIND) field identifies the result of the comparison. Table 36 identifies values for the Compare File Data command that can appear in this field
Table 36. Values *APY *CMT Possible values for Compare File Data (CMPFILDTA) output file field Difference Indicator (DIFIND) Description The database apply (DBAPY) job encountered a problem processing a U-MX journal entry for this member. Commit cycle activity on the source system prevents active processing from comparing records or record counts in the selected member. Unable to process selected member. Cannot open file. Unable to process selected member containing a large object (LOB). The file or the MIMIX-created SQL view cannot be opened. Unable to process selected member. The file uses an unsupported data type.

*CO *CO (LOB) *DT

265

Table 36. Values *EQ

Possible values for Compare File Data (CMPFILDTA) output file field Difference Indicator (DIFIND) Description Data matches. No differences were detected within the data compared. Global difference indicator. Member excluded from comparison because it was not changed or restored after the timestamp specified for the CHGDATE parameter. No difference was detected. However, fields with unsupported types were omitted. The file feature is not supported for comparison. Examples of file features include materialized query tables. Matching entry not found in database apply table. Unable to process selected member. File formats differ between source and target files. Either the record length or the null capability is different. Indicates that a member is held or an inactive state was detected. Unable to complete processing on selected member. Messages preceding LVE0101 may be helpful. Indicates a difference was detected. Member not found on system 1. Member not found on system 2. The file member is being processed for repair by another job running the Compare File Data (CMPFILDTA) command. The source file is not journaled, or is journaled to the wrong journal. Unable to process selected member. See messages preceding message LVE3D42 in job log. The file or member is being processed by the Synchronize DG File Entry (SYNCDGFE) command. Unable to process selected member. Reason unknown. Messages preceding message LVE3D42 in job log may be helpful. Indicates that the members synchronization status is unknown.

*EQ (DATE)

*EQ (OMIT) *FF *FMC *FMT

*HLD *IOERR *NE *NF1 *NF2 *REP *SJ *SP *SYNC *UE *UN

266

Interpreting results of audits for record counts and file data

What differences were detected by #MBRRCDCNT

Table 37 identifies values for the Compare Record Count command that can appear in the Difference Indicator (DIFIND) field.
Table 37. Values *APY *CMT Possible values for Compare Record Count (CMPRCDCNT) output file field Difference Indicator (DIFIND) Description The database apply (DBAPY) job encountered a problem processing a U-MX journal entry for this member. Commit cycle activity on the source system prevents active processing from comparing records or record counts in the selected member. The attribute compared is equal to configuration Record counts match. No difference was detected within the record counts compared. Global difference indicator. The file feature is not supported for comparison. Examples of file features include materialized query tables. Matching entry not found in database apply table. Indicates that a member is held or an inactive state was detected. Lock prevented access to member. Indicates a difference was detected. Member not found on system 1. Member not found on system 2. The source file is not journaled, or is journaled to the wrong journal. Unable to process selected member. Reason unknown. Messages preceding LVE3D42 in job log may be helpful. Indicates that the members synchronization status is unknown.

*EC *EQ *FF *FMC *HLD *LCK *NE *NF1 *NF2 *SJ *UE *UN

Updated for 6.0.12.00.

267

Interpreting results of audits that compare attributes

Each audit that compares attributes does so by calling a Compare Attributes1 command and places the results in an output file. Each row in an output file for a Compare Attributes command can contain either a summary record format or a detailed record format. Each summary row identifies a compared object and includes a prioritized object-level summary of whether differences were detected. Each detail row identifies a specific attribute compared for an object and the comparison results. The type of data included in the output file is determined by the report type specified on the Compare Attributes command. When viewed from a 5250 emulator, the data included for each report type is as follows: Difference reports (RPTTYPE(*DIF)) return information about detected differences. Only summary rows for objects that had detected differences are included. Detail rows for all compared attributes are included. Difference reports are the default for the Compare Attributes commands. Full reports (RPTTYPE(*ALL)) return information about all objects and attributes compared. For each object compared there is a summary row as well as a detail row for each attribute compared. Full reports include both differences and objects that are considered synchronized. Summary reports (RPTTYPE(*SUMMARY)) return only a summary row for each object compared. Specific attributes compared are not included.

For difference and full reports of compare attribute commands, several of the attribute selectors return an indicator (*INDONLY) rather than an actual value. Attributes that return indicators are usually variable in length, so an indicator is returned to conserve space. In these instances, the attributes are checked thoroughly, but the report only contains an indication of whether it is synchronized. For example, an authorization list can contain a variable number of entries. When comparing authorization lists, the CMPOBJA command will first determine if both lists have the same number of entries. If the same number of entries exist, it will then determine whether both lists contain the same entries. If differences in the number of entries are found or if the entries within the authorization list are not equal, the report will indicate that differences are detected. The report will not provide the list of entriesit will only indicate that they are not equal in terms of count or content. MIMIX Availability Manager displays only detected differences found by Compare Attributes commands using a subset of the fields from the output file. MIMIX Availability Manager displays summary rows in the Summary List window and detail rows in the Details window for the Compare command type. You can see the full set of fields in the output file by viewing it from a 5250 emulator.

1. The Compare Attribute commands are: Compare File Attributes (CMPFILA), Compare Object Attributes (CMPOBJA), Compare IFS Attributes (CMPIFSA), and Compare DLO Attributes (CMPDLOA).

268

Interpreting results of audits that compare attributes

What attribute differences were detected

The Difference Indicator (DIFIND) field identifies the result of the comparison. Table 38 identifies values that can appear in this field. Not all values may be valid for every Compare command. Within MIMIX Availability Manager, the value shown in the Summary List window is a prioritized summary of the status of all attributes checked for the object. This summary value is also presented along with other object-identifying information at the top of the Details window. For each attribute displayed on the Details window, the results of its comparison is shown. When the output file is viewed from a 5250 emulator, the summary row is the first record for each compared object and is indicated by an asterisk (*) in the Compared Attribute (CMPATR) field. The summary rows Difference Indicator value is the prioritized summary of the status of all attributes checked for the object. When included, detail rows appear below the summary row for the object compared and show the actual result for the attributes compared. The Priority2 column in Table 38 indicates the order of precedence MIMIX uses when determining the prioritized summary value for the compared object.
Table 38. Values1 *EC *EQ *NA *NC *NE *NS *RCYSBM Possible values for output file field Difference Indicator (DIFIND) Description The values are based on the MIMIX configuration settings. The actual values may or may not be equal. Record counts match. No differences were detected. Global difference indicator. The values are not compared. The actual values may or may not be equal. The values are not equal based on the MIMIX configuration settings. The actual values may or may not be equal. Indicates differences were detected. Indicates that the attribute is not supported on one of the systems. Will not cause a global not equal condition. Indicates that MIMIX AutoGuard submitted an automatic audit recovery action that must be processed through the user journal replication processes. The database apply (DBAPY) will attempt the recovery and send an *ERROR or *INFO notification to indicate the outcome of the recovery attempt. Used to indicate that automatic recovery attempts via AutoGuard failed to recover the detected difference. Indicates that recovery for this object was successful. Unable to process selected member. The source file is not journaled. 13 1 Summary Record2 Priority 5 5 5 3 2 5

*RCYFAILED *RECOVERED *SJ

269

Table 38. Values1 *SP *UA

Possible values for output file field Difference Indicator (DIFIND) Description Unable to process selected member. See messages preceding message LVE3D42 in job log. Object status is unknown due to object activity. If an object difference is found and the comparison has a value specified on the Maximum replication lag prompt, the difference is seen as unknown due to object activity. This status is only displayed in the summary record.
Note: The Maximum replication lag prompt is only valid when a data group is specified on the command.

Summary Record2 Priority 1 2

*UN
1. 2. 3.

Indicates that the objects synchronization status is unknown.

Not all values may be possible for every Compare command. Priorities are used to determine the value shown in output files for Compare Attribute commands. The value *RECOVERED can only appear in an output file modified by a recovery action. The object was initially found to be *NE or *NC but MIMIX autonomic functions recovered the object.

For most attributes, when a detailed row contains blanks in either of the System 1 Indicator or System 2 Indicator fields, MIMIX determines the value of the Difference Indicator field according to Table 39. For example, if the System 1 Indicator is *NOTFOUND and the System 2 Indicator is blank (Object found), the resultant Difference Indicator is *NE.
Table 39. Difference Indicator values that are derived from System Indicator values. Difference Indicator System 1 Indicator Object *NOTCMPD *NOTFOUND *NOTSPT *RTVFAILED *DAMAGED Found (blank value) *NA Object Found *EQ / *EQ (blank value) (LOB) / *NE / *UA / *EC / *NC *NA *NE / *UA *NS *UN *NE *NE *NS *UN *NE

System *NOTCMPD *NA 2 Indicator *NOTFOUND *NE / *UA *NOTSPT *NS

*NE *EQ *NE *NE *NE

*NS

*UN

*NE *NE *NE *NE *NE

*NE / *UA *NE / *UA *NS *UN *NE *UN *UN *NE

*RTVFAILED *UN *DAMAGED *NE

270

Interpreting results of audits that compare attributes

For a small number of specific attributes, the comparison is more complex. The results returned vary according to parameters specified on the compare request and MIMIX configuration values. For more information see the following topics: Comparison results for journal status and other journal attributes on page 290 Comparison results for auxiliary storage pool ID (*ASP) on page 294 Comparison results for user profile status (*USRPRFSTS) on page 297 Comparison results for user profile password (*PRFPWDIND) on page 300

Where was the difference detected

The System 1 Indicator (SYS1IND) and System 2 Indicator (SYS2IND) fields show the status of the attribute on each system as determined by the compare request. Table 40 identifies the possible values. While these fields are available in both summary and detail rows in the output file, MIMIX Availability Manager only displays them in the Details window.
Table 40. Value <blank> *DAMAGED *MBRNOTFND *NOTCMPD *NOTFOUND *NOTSPT Possible values for output file fields SYS1IND and SYS2IND Description No special conditions exist for this object. Object damaged condition. Member not found. Attribute not compared. Due to MIMIX configuration settings, this attribute cannot be compared. Object not found. Attribute not supported. Not all attributes are supported on all IBM i releases. This is the value that is used to indicate an unsupported attribute has been specified. Unable to retrieve the attributes of the object. Reason for failure may be a lock condition. Summary Record1 Priority 5 3 2 N/A2 1 N/A2

*RTVFAILED
1. 2.

The priority indicates the order of precedence MIMIX uses when setting the system indicators fields in the summary record. This value is not used in determining the priority of summary level records.

For comparisons which include a data group, the Data Source (DTASRC) field identifies which system is configured as the source for replication. In MIMIX Availability Manager Details windows, the direction of the arrow shown the data group field identifies the flow of replication.

271

What attributes were compared

In each detailed row, the Compared Attribute (CMPATR) field identifies a compared attribute. The following topics identify the attributes that can be compared by each command and the possible values returned: Attributes compared and expected results - #FILATR, #FILATRMBR audits on page 273 Attributes compared and expected results - #OBJATR audit on page 278 Attributes compared and expected results - #IFSATR audit on page 286 Attributes compared and expected results - #DLOATR audit on page 288

272

Attributes compared and expected results - #FILATR, #FILATRMBR audits

The Compare File Attribute (CMPFILA) command supports comparisons at the file and member level. Most of the attributes supported are for file-level comparisons. The #FILATR audit and the #FILATRMBR audit each invoke the CMPFILA command for the comparison phase of the audit. Some attributes are common file attributes such as owner, authority, and creation date. Most of the attributes, however, are file-specific attributes. Examples of filespecific attributes include triggers, constraints, database relationships, and journaling information. The difference Indicator (DIFIND) returned after comparing file attributes may depend on whether the file is defined by file entries or object entries. For instance, a attribute could be equal (*EC) to the database configuration but not equal (*NC) to the object configuration. See What attribute differences were detected on page 269. Table 41 lists the attributes that can be compared and the value shown in the Compared Attribute (CMPATR) field in the output file. The Returned Values column lists the values you can expect in the System1 Value (SYS1VAL) and System 2 Value (SYS2VAL) columns as a result of running the comparison.
Table 41. Attribute *ACCPTH1 Compare File Attributes (CMPFILA) attributes Description Access path Returned Values (SYS1VAL, SYS2VAL) AR - Arrival sequence access path EV - Encoded vector with a 1-, 2-, or 4-byte vector. KC - Keyed sequence access path with duplicate keys allowed. Duplicate keys are accessed in first-changed-first-out (FCFO) order. KF - Keyed sequence access path with duplicate keys allowed. Duplicate keys are accessed in first-in-first-out (FIFO) order. KL - Keyed sequence access path with duplicate keys allowed. Duplicate keys are accessed in last-in-first-out (LIFO) order KN - Keyed sequence access path with duplicate keys allowed. No order is guaranteed when accessing duplicate keys. KU - Keyed sequence access path with no duplicate keys allowed (UNIQUE). *YES, *NO *MAX4GB, *MAX1TB *YES, *NO Group which checks attributes *ALWDLT, *ALWRD, *ALWUPD, *ALWWRT *YES, *NO *YES, *NO

*ACCPTHVLD2 *ACCPTHSIZ1 *ALWDLT *ALWOPS *ALWRD *ALWUPD

Access path valid Access path size Allow delete operation Allow operations Allow read operation Allow update operation

273

Table 41. Attribute *ALWWRT *ASP

Compare File Attributes (CMPFILA) attributes Description Allow write operation Auxiliary storage pool ID Returned Values (SYS1VAL, SYS2VAL) *YES, *NO 1-16 (pre-V5R2) 1-255 (V5R2) 1 = System ASP See Comparison results for auxiliary storage pool ID (*ASP) on page 294 for details. *NONE, *CHANGE, *ALL Group which checks attributes *AUTL, *PGP, *PRVAUTIND, *PUBAUTIND *NONE, list name 33 character name in the format: library/file(member)

*AUDVAL *AUT *AUTL *BASEDONPF2

Object audit value File authorities Authority list name Name of based-on physical file member Pre-determined set of basic attributes

*BASIC

Group which checks a pre-determined set of attributes. When *FILE is specified for the Comparison level (CMPLVL), these attributes are compared: *CST (group), *NBRMBR, *OBJATR, *RCDFMT, *TEXT, and *TRIGGER (group). When *MBR is specified for the Comparison level (CMPLVL), these attributes are compared: *CURRCDS, *EXPDATE, *NBRDLTRCD, *OBJATR, *SHARE, and *TEXT. 1-65535 Group which checks attributes *CSTIND, *CSTNBR No value, indicator only5 When this attribute is returned in output, its Difference Indicator value indicates if the number of constraints, constraint names, constraint types, and the check pending attribute are equal. For referential and check constraints, the constraint state as well as whether the constraint status is enabled or disabled is also compared. Numeric value 0-4294967295 *YES, *NO Group which checks *DBRIND, *OBJATR

*CCSID1 *CST *CSTIND 3

Coded character set Constraint attributes Constraint equal indicator

*CSTNBR 3 *CURRCDS *DBCSCAP *DBR

Number of constraints Current number of records DBCS capable

274

Table 41. Attribute

Compare File Attributes (CMPFILA) attributes Description Database relations Returned Values (SYS1VAL, SYS2VAL) No value, indicator only5 When this attribute is returned in output, its Difference Indicator value indicates if the number of database relations and the dependent file names are equal. Blank for *NONE or date in CYYMMDD format, where C equals the century. Value 0 is 19nn and 1 is 20nn. Valid only for Comparison level of *FILE, this group compares the basic set of attributes (*BASIC) plus an extended set of attributes. The following attributes are compared: *ACCPTH, *AUT (group), *CCSID, *CST (group), *CURRCDS, *DBR (group), *MAXKEYL, *MAXMBRS, *MAXRCDL, *NBRMBR, *OBJATR, *OWNER, *PFSIZE (group), *RCDFMT, *REUSEDLT, *SELOMT, *SQLTYP, *TEXT, and *TRIGGER (group). 10 character name *NONE if the file has no members. *YES, *NO *NONE, 1-32767 0-32767 *YES, *NO Add, update, and delete authorities are not checked. Differences in these authorities do not result in an *NE condition. Group which checks *JOURNALED, *JRN, *JRNLIB, *JRNIMG, *JRNOMIT. Results are described in Comparison results for journal status and other journal attributes on page 290. *YES, *NO 10 character name, blank if never journaled *AFTER, *BOTH 10 character name, blank if never journaled *OPNCLO, *NONE 3 character ID 10 character name *NONE if the file has no members.

*DBRIND 3

*EXPDATE1 *EXTENDED

Expiration date for member Pre-determined, extended set

*FIRSTMBR1 4 *FRCKEY1 *FRCRATIO1 *INCRCDS1 *JOIN

Name of member *FIRST Force keyed access path Records to force a write Increment number of records Join Logical file

*JOURNAL

Journal attributes

*JOURNALED *JRN *JRNIMG *JRNLIB *JRNOMIT *LANGID1 *LASTMBR1 4

File is currently journaled Current or last journal Record images Current or last journal library Journal entries to be omitted Language ID Name of member *LAST

275

Table 41. Attribute *LVLCHK1 *MAINT1 *MAXINC1

Compare File Attributes (CMPFILA) attributes Description Record format level check Access path maintenance Maximum increments Maximum key length Maximum members Max % deleted records allowed Maximum record length Current number of deleted records Number of members Initial number of records Object control level File owner File size attributes Primary group Private authority indicator Returned Values (SYS1VAL, SYS2VAL) *YES, *NO *IMMED, *REBLD, *DLY 0-32767 1-2000 *NOMAX, 1-32767 *NONE, 1-100 1-32766 0-4294967295 0-32767 *NOMAX, 1-2147483646 8 character user-defined value User profile name Group which checks *CURRCDS, *INCRCDS, *MAXINC, *NBRDLTRCD, *NBRRCDS *NONE, user profile name No value, indicator only5 When this attribute is returned in output, its Difference Indicator value indicates if the number of private authorities and private authority values are equal. No value, indicator only5 When this attribute is returned in output, its Difference Indicator value indicates if public authority values are equal. 1-32 *IPL, *AFTIPL, *NO *YES, *NO

*MAXKEYL1 *MAXMBRS1 *MAXPCT1 *MAXRCDL1 *NBRDLTRCD1 *NBRMBR1 *NBRRCDS1 *OBJCTLLVL1 *OWNER *PFSIZE *PGP *PRVAUTIND

*PUBAUTIND

Public authority indicator Number of record formats Access path recovery Reuse deleted records

*RCDFMT *RECOVER1 *REUSEDLT1

276

Table 41. Attribute *SELOMT *SHARE1 *SQLTYP *TEXT1

Compare File Attributes (CMPFILA) attributes Description Select / omit file Share open data path SQL file type Text description Returned Values (SYS1VAL, SYS2VAL) *YES, *NO *YES, *NO PF Types - NONE, TABLE, LF Types - INDEX, VIEW, NONE 50 character value Group which checks *TRGIND, *TRGNBR, *TRGXSTIND Trigger equal indicator No value, indicator only5 When this attribute is returned in output, its Difference Indicator value indicates whether it is enabled or disabled, and if the number of triggers, trigger names, trigger time, trigger event, and trigger condition with an event type of update are equal. Numeric value No value, indicator only5 When this attribute is returned in output, its Difference Indicator value indicates if a trigger program exists on the system. 10 character user-defined value *IMMED, *CLS, 1-32767 *IMMED, *NOMAX, 1-32767

*TRIGGER *TRGIND 3

*TRGNBR 3 *TRGXSTIND 3

Number of triggers Trigger existence indicator User-defined attribute Maximum file wait time Maximum record wait time

*USRATR *WAITFILE1 *WAITRCD1

1.

2. 3. 4.

5.

Differences detected for this attribute are marked as *EC (equal configuration) when the compare request specified a data group and the object is configured for system journal replication with a configured object auditing value of *NONE. This attribute is only compared for logical file members by the #FILATRMBR audit. This attribute cannot be specified as input for comparing but it is included in a group attribute. When the group attribute is checked, this value may appear in the output. Differences detected for this attribute are marked as *EC (equal configuration) when the compare request specified a data group and the file is configured for system journal replication with a configured Omit content (OMTDTA) value of *FILE. If *PRINT is specified in the comparison, an indicator appears in the system 1 and system 2 columns. If *OUTFILE is specified, however, these values are blank.

277

Attributes compared and expected results - #OBJATR audit

The #OBJATR audit calls the Compare Object Attributes (CMPOBJA) command and places the results in an output file. Table 42 lists the attributes that can be compared by the CMPOBJA command and the value shown in the Compared Attribute (CMPATR) field in the output file. The command supports attributes that are common among most library-based objects as well as extended attributes which are unique to specific object types, such as subsystem descriptions, user profiles, and data areas. The Returned Values column lists the values you can expect in the System1 Value (SYS1VAL) and System 2 Value (SYS2VAL) columns as a result of running the compare.
Table 42. Attribute *ACCPTHSIZ1 2 *AJEIND Compare Object Attributes (CMPOBJA) attributes Description Access path size Valid for logical files only. Auto start job entries. Valid for subsystem descriptions only. Returned Values (SYS1VAL, SYS2VAL) *MAX4GB and *MAX1TB No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if the number of auto start job entries, job entry and associated job description, and library entry values are equal. 1-16 (pre-V5R1) 1-32 (V5R1) 1-255 (V5R2), 1 = System ASP See Comparison results for auxiliary storage pool ID (*ASP) on page 294 for details. Numeric value

*ASP

Auxiliary storage pool ID

*ASPNBR

Number of defined storage pools. Valid for subsystem descriptions only. Attention key handling program Valid for user profiles only. Object audit value Authority attributes Authority to check. Valid for job queues only. Authority list name Pre-determined set of basic attributes

*ATTNPGM2

*SYSVAL, *NONE, *ASSIST, attention program name

*AUDVAL *AUT *AUTCHK2 *AUTL *BASIC

*NONE, *USRPRF, *CHANGE, *ALL Group which checks *AUTL, *PGP, *PRVAUTIND, *PUBAUTIND *OWNER, *DTAAUT *NONE, list name Group which checks a pre-determined set of attributes. These attributes are compared: *CRTTSP, *DOMAIN, *INFSTS, *OBJATR, *TEXT, and *USRATR.

278

Table 42. Attribute *CCSID2

Compare Object Attributes (CMPOBJA) attributes Description Character identifier control. Valid for user profiles only. Country ID Valid for user profiles only. Communications entries Valid for subsystem descriptions only. Returned Values (SYS1VAL, SYS2VAL) *SYSVAL, ccsid-value

*CNTRYID2

*SYSVAL, country-id

*COMMEIND

No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if the number of communication entries, maximum number of active jobs, communication device, communication mode, associated job description and library, and the default user entry values are equal. *SYSVAL, *CHANGE, *ALL, *USE, *EXCLUDE, *SYSVAL, *CHANGE, *ALL, *USE, *EXCLUDE

*CRTAUT2

Authority given to users who do not have specific authority to the object. Valid for libraries only. Auditing value for objects created in this library Valid for libraries only. Profile that owns objects created by user Valid for user profiles only. Object creation date Current library Valid for user profiles only. Data cyclic redundancy check (CRC) Valid for data queues only. DDM conversation Valid for job descriptions only. Decimal positions Valid for data areas only. Object Domain Data area extended attributes

*CRTOBJAUD2

*SYSVAL, *NONE, *USRPRF, *CHANGE, *ALL

*CRTOBJOWN

*USRPRF, *GRPPRF, profile-name

*CRTTSP *CURLIB

YYYY-MM-DD-HH.MM.SS.mmmmmm *CRTDFT, current-library

*DATACRC2

10 character value

*DDMCNV2

*KEEP, *DROP

*DECPOS *DOMAIN *DTAARAEXT

0-9 *SYSTEM, *USER Group which checks *DECPOS, *LENGTH, *TYPE, *VALUE

279

Table 42. Attribute

Compare Object Attributes (CMPOBJA) attributes Description Pre-determined, extended set Returned Values (SYS1VAL, SYS2VAL) Group which compares the basic set of attributes (*BASIC) plus an extended set of attributes. The following attributes are compared: *AUT, *CRTTSP, *DOMAIN, *INFSTS, *OBJATR, *TEXT, and *USRATR. *NONE, 1 - 32,767 1 - 4294967294

*EXTENDED

*FRCRATIO1 2 *GID

Records to force a write Valid for logical files only. Group profile ID number Valid for user profiles only. Group authority to created objects Valid for user profiles only. Group authority type Valid for user profiles only. Group profile name Valid for user profiles only. Information status

*GRPAUT

*NONE, *ALL, *CHANGE, *USE, *EXCLUDE

*GRPAUTTYP

*PGP, *PRIVATE

*GRPPRF

*NONE, profile-name

*INFSTS

*OK (No errors occurred), *RTVFAILED (No information returned - insufficient authority or object is locked), *DAMAGED (Object is damaged or partially damaged). Menu - *SIGNOFF, menu name Library - *LIBL, library name Program - *NONE, program name Library - *LIBL, library name Group which checks *DDMCNV, *JOBQ, *JOBQLIB, *JOBQPRI, *LIBLIND, *LOGOUTPUT, *OUTQ, *OUTQLIB, *OUTQPRI, *PRTDEV 10 character name

*INLMNU

Initial menu Valid for user profiles only. Initial program Valid for user profiles only. Job description extended attributes Job queue Valid for job descriptions only. Job queue entries Valid for subsystem descriptions only.

*INLPGM

*JOBDEXT

*JOBQ2

*JOBQEIND

No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if the number of job queue entries, job queue names, job queue libraries, and order of entries are the same

280

Table 42. Attribute

Compare Object Attributes (CMPOBJA) attributes Description Job queue extended attributes Job queue library Valid for job descriptions only. Job queue priority Valid for job descriptions only. Subsystem that receives jobs from this queue Valid for job queues only. Job queue status Valid for job queues only. Journal attributes Returned Values (SYS1VAL, SYS2VAL) Group which checks *AUTCHK, *JOBQSBS, *JOBQSTS, *OPRCTL 10 character name

*JOBQEXT *JOBQLIB2

*JOBQPRI2

1 (highest) - 9 (lowest)

*JOBQSBS2

Subsystem name

*JOBQSTS2 *JOURNAL

HELD, RELEASED Group which checks *JOURNALED, *JRN, *JRNLIB, *JRNIMG, *JRNOMIT4. Results are described in Comparison results for journal status and other journal attributes on page 290. *YES, *NO 10 character name *AFTER, *BOTH 10 character name *OPNCLO, *NONE *SYSVAL, language-id

*JOURNALED *JRN *JRNIMG *JRNLIB *JRNOMIT *LANGID2

Object is currently journaled Current or last journal Record images Current or last journal library Journal entries to be omitted Language ID Valid for user profiles only. Data area length Valid for data areas only Extended library information attributes Initial library list Valid for job descriptions only.

*LENGTH *LIBEXT *LIBLIND

1-2000 (character), 1-24 (decimal), 1 (logical) Group which checks *CRTAUT, *CRTOBJAUD No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if the number of library list entries and entry list values are equal. The comparison is order dependent.

281

Table 42. Attribute *LMTCPB

Compare Object Attributes (CMPOBJA) attributes Description Limit capabilities Valid for user profiles only. Job log output Valid for job descriptions only. Record format level check Valid for logical files only. Access path maintenance Valid for logical files only. Maximum active jobs Valid for subsystem descriptions only. Maximum members Valid for logical files only. Message queue Valid for user profiles only. Number of logical file members Valid for logical files only. Object attribute Object control level Valid for object types that support this attribute5. Operator controlled Valid for job queues only. Output queue Valid for job descriptions only. Output queue library Valid for job descriptions only. Output queue priority Valid for job descriptions only. Returned Values (SYS1VAL, SYS2VAL) *PARTIAL, *YES, *NO

*LOGOUTPUT2

*SYSVAL, *JOBLOGSVR, *JOBEND, *PND

*LVLCHK1 2

*YES, *NO

*MAINT1 2

*DLY, *IMMED, *REBLD

*MAXACT 2

Numeric value, *NOMAX (32,767)

*MAXMBRS1 2 *MSGQ2

*NOMAX, 1 - 32,767 Message queue - message queue name Library - *LIBL, library name 0 - 32,767

*NBRMBR1 2

*OBJATR *OBJCTLLVL2

10 character object extended attribute 8 character user-defined value

*OPRCTL2 *OUTQ2

*YES, *NO *USRPRF, *DEV, *WRKSTN, output queue name

*OUTQLIB2

10 character name

*OUTQPRI2

1 (highest) - 9 (lowest)

282

Table 42. Attribute *OWNER *PGP

Compare Object Attributes (CMPOBJA) attributes Description Object owner Primary group Pre-start job entries Valid for subsystem descriptions only. Returned Values (SYS1VAL, SYS2VAL) 10 character name *NONE, user profile name No value, indicator only1 When this attribute is returned in output, its Difference Indicator value indicates if the number of prestart jobs, program, user profile, start job, wait for job, initial jobs, maximum jobs, additional jobs, threshold, maximum users, job name, job description, first and second class, and number of first and second class jobs values are equal. *LIBL/*WRKSTN, *DEV

*PRESTIND

*PRFOUTQ2

Output queue Valid for user profiles only. User profile password indicator Printer device Valid for job descriptions only. Private authority indicator

*PRFPWDIND *PRTDEV2

See Comparison results for user profile password (*PRFPWDIND) on page 300 for details. *USRPRF, *SYSVAL, *WRKSTN, printer device name

*PRVAUTIND

No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if the number of private authorities and private authority values are equal No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if the public authority values are equal. *SYSVAL, *NOMAX, 1-366 days

*PUBAUTIND

Public authority indicator

*PWDEXPITV

Password expiration interval Valid for user profiles only. No password indicator Valid for user profiles only. Job queue allocation indicator Valid for subsystem descriptions only.

*PWDIND

*YES (no password), *NO (password)

*QUEALCIND

No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if the job queue entries for a subsystem are in the same order and have the same queue names and queue library names. It also compares the allocation indicator values

283

Table 42. Attribute

Compare Object Attributes (CMPOBJA) attributes Description Remote location entries Valid for subsystem descriptions only. Returned Values (SYS1VAL, SYS2VAL) No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if the number of remote location entries, remote location, mode, job description and library, maximum active jabs, and default user entry values are equal. No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if the number of routing entries, sequence number, maximum active, steps, compare start, entry program, class, and compare entry values are equal Group which checks *AJEIND, *ASPNBR, *COMMEIND, *JOBQEIND, *MAXACT, *PRESTIND, *RLOCIND, *RTGEIND, *SBSDSTS *ACTIVE, *INACTIVE

*RLOCIND

*RTGEIND

Routing entries Valid for subsystem descriptions only.

*SBSDEXT

Subsystem description extended attributes Subsystem status Valid for subsystem descriptions only. Object size Special authorities Valid for user profiles only. SQL stored procedures Valid for programs and service programs only.

*SBSDSTS2

*SIZE *SPCAUTIND

Numeric value No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if special authority values are equal *NONE, or indicator only3 *NONE is returned when there are no stored procedures associated with the program or service program. When the indicator only is returned in output, the Difference Indicator value identifies whether SQL stored procedures associated with the object are equal. *NONE, or indicator only3 *NONE is returned when there are no user defined functions associated with the program or service program. When the indicator only is returned in output, the Difference Indicator value identifies whether SQL user defined functions associated with the object are equal. No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if supplemental group values are equal 50 character description

*SQLSP

*SQLUDF

SQL user defined functions Valid for programs and service programs only.

*SUPGRPIND

Supplemental Groups Valid for user profiles only. Text description

*TEXT2

284

Table 42. Attribute *TYPE

Compare Object Attributes (CMPOBJA) attributes Description Data area type - data area types of DDM resolved to actual data area types Valid for data areas only. User profile ID number Valid for user profiles only. User-defined attribute User Class Valid for user profiles only. User profile extended attributes Returned Values (SYS1VAL, SYS2VAL) *CHAR, *DEC, *LGL

*UID

1 - 4294967294

*USRATR2 *USRCLS

10 character user-defined value *SECOFR, *SECADM, *PGMR, *SYSOPR, *USER

*USRPRFEXT

Group which checks *ATTNPGM, *CCSID, *CNTRYID, *CRTOBJOWN, *CURLIB, *GID, *GRPAUT, *GRPAUTTYP, *GRPPRF, *INLMNU, *INLPGM, *LANGID, *LMTCPB, *MSGQ, *PRFOUTQ, *PWDEXPITV, *PWDIND, *SPCAUTIND, *SUPGRPIND, *USRCLS *ENABLED, *DISABLED6 For details, see Comparison results for user profile status (*USRPRFSTS) on page 297. Character value of data

*USRPRFSTS

User profile status

*VALUE2
1. 2. 3. 4. 5. 6.

Data area value Valid for data areas only.

This attribute only applies to logical files. Use the Compare File Attributes (CMPFILA) command to compare or omit physical file attributes. Differences detected for this attribute are marked as *EC (equal configuration) when the compare request specified a data group and the object is configured for system journal replication with a configured object auditing value of *NONE. If *PRINT is specified for the output format on the compare request, an indicator appears in the System 1 and System 2 columns. If *OUTFILE is specified, these values are blank. These attributes are compared for object types of *FILE, *DTAQ, and *DTAARA. These are the only objects supported by IBM's user journals. The *OBJCTLLVL attribute is only supported on the following object types: *AUTL, *CNNL, *COSD, *CTLD, *DEVD, *DTAARA, *DTAQ, *FILE, *IPXD, *LIB, *LIND, *MODD, *NTBD, *NWID, *NWSD, and *USRPRF. The profile status is only compared if no data group is specified or the USRPRFSTS has a value of *SRC for the specified data group. If a data group is specified on the CMPOBJA command and the USRPRFSTS value on the object entry has a value of *TGT, *ENABLED, or *DISABLED, the user profile status is not compared.

285

Attributes compared and expected results - #IFSATR audit

The #IFSATR audit calls the Compare IFS Attributes (CMPIFSA) command and places the results in an output file. Table 43 lists the attributes that can be compared by the CMPIFSA command and the value shown in the Compared Attribute (CMPATR) field in the output file. The Returned Values column lists the values you can expect in the System1 Value (SYS1VAL) and System 2 Value (SYS2VAL) columns as a result of running the compare.
Table 43. Attribute *ALWSAV1 *ASP Compare IFS Attributes (CMPIFSA) attributes Description Allow save Auxiliary storage pool Returned Values (SYS1VAL, SYS2VAL) *YES, *NO 1-16 (pre-V5R1) 1-255 (V5R1) 1-System ASP See Comparison results for auxiliary storage pool ID (*ASP) on page 294 for details. *ALL, *CHANGE, *NONE, *USRPRF Group which checks attributes *AUTL, *PGP, *PUBAUTIND, *PRVAUTIND *NONE, list name Group which checks a pre-determined set of attributes. The following set of attributes are compared: *CCSID, *DATASIZE, *OBJTYPE, and the group *PCATTR. 1-65535 SAA format (YY-MM-DD-HH.MM.SS.mmmmmm) 8 character value 0-4294967295 Group which checks a pre-determined set of attributes. Compares the basic set of attributes (*BASIC) plus an extended set of attributes. The following attributes are compared: *AUT (group), *CCSID, *DATASIZE, *OBJTYPE, *OWNER, and *PCATTR (group). Groups which checks attributes *JOURNALED, *JRN, *JRNLIB, *JRNIMG, *JRNOPT. Results are described in Comparison results for journal status and other journal attributes on page 290. *YES, *NO 10 character name *AFTER, *BOTH

*AUDVAL *AUT *AUTL *BASIC

Object auditing value Authority attributes Authority list name Pre-determined set of basic attributes Coded character set Create timestamp Data cyclic redundancy check (CRC) Data size Pre-determined, extended set

*CCSID1 *CRTTSP2 *DATACRC3 *DATASIZE1 *EXTENDED

*JOURNAL

Journal information

*JOURNALED *JRN *JRNIMG

File is currently journaled Current or last journal Record images

286

Table 43. Attribute *JRNLIB *JRNOPT

Compare IFS Attributes (CMPIFSA) attributes Description Current or last journal library Journal optional entries Object type File owner Archived file PC Attributes Hidden file Read only attribute System file Primary group Private authority indicator Returned Values (SYS1VAL, SYS2VAL) 10 character name *YES, *NO *STMF, *DIR, *SYMLNK 10 character name *YES, *NO Group which checks *PCARCHIVE, *PCHIDDEN, *PCREADO, *PCSYSTEM *YES, *NO *YES, *NO *YES, *NO *NONE, user profile name No value, indicator only4 When this attribute is returned in output, its Difference Indicator value indicates if the number of private authorities and private authority values are equal. No value, indicator only4 When this attribute is returned in output, its Difference Indicator value indicates if the public authority values are equal.

*OBJTYPE *OWNER *PCARCHIVE1 *PCATTR *PCHIDDEN1 *PCREADO1 *PCSYSTEM1 *PGP *PRVAUTIND

*PUBAUTIND

Public authority indicator

1.

2.

3. 4.

Differences detected for this attribute are marked as *EC (equal configuration) when the compare request specified a data group and the object is configured for system journal replication with a configured object auditing value of *NONE. The *CRTTSP attribute does not compare directories (*DIR) or symbolic links (*SYMLNK). For stream files (*STMF), the #IFSATR audit omits the *CRTTSP attribute from comparison since creation timestamps are not preserved during replication. Running the CMPIFSA command will detect differences in the creation timestamps for stream files. When a stream file has Storage Freed *YES on either the source system or target system, the status of this attribute is reflected as not supported (*NS) and the data has not been compared. If *PRINT is specified in the comparison, an indicator appears in the system 1 and system 2 columns. If *OUTFILE is specified, these values are blank.

287

Attributes compared and expected results - #DLOATR audit

The #DLOATR audit calls the Compare DLO Attributes (CMPDLOA) command and places the results in an output file. Table 44 lists the attributes that can be compared by the CMPDLOA command and the value shown in the Compared Attribute (CMPATR) field in the output file. The Returned Values column lists the values you can expect in the System1 Value (SYS1VAL) and System 2 Value (SYS2VAL) columns as a result of running the compare.
Table 44. Attribute *ASP Compare DLO Attributes (CMPDLOA) attributes Description Auxiliary storage pool Returned Values (SYS1VAL, SYS2VAL) 1-16 (pre-V5R1) 1-32 (V5R1) 1 = System ASP See Comparison results for auxiliary storage pool ID (*ASP) on page 294 for details. *NONE, *USRPRF, *CHANGE, *ALL Group which checks *AUTL, *PGP, *PUBAUTIND, *PRVAUTIND *NONE, list name Group which checks a pre-determined set of attributes. The following set of attributes are compared: *CCSID, *DATASIZE, *OBJTYPE, *PCATTR, and *TEXT. 1-65535 SAA format (YY-MM-DD-HH.MM.SS.mmmmmm) 0-42949672951 Group which checks a pre-determined set of attributes. Compares the basic set of attributes (*BASIC) plus an extended set of attributes. The following attributes are compared *AUT, *CCSID, *DATASIZE, *OBJTYPE, *OWNER, *PCATTR, and *TEXT. SAA format (YY-MM-DD-HH.MM.SS.mmmmmm) *DOC, *FLR2 10 character name *YES, *NO Group which checks *PCARCHIVE, *PCHIDDEN, *PCREADO, *PCSYSTEM *YES, *NO *YES, *NO

*AUDVAL *AUT *AUTL *BASIC

Object audit value Authority attributes Authority list name Pre-determined set of basic attributes

*CCSID *CRTTSP *DATASIZE *EXTENDED

Coded character set Create timestamp Data size Pre-determined, extended set

*MODTSP *OBJTYPE *OWNER *PCARCHIVE *PCATTR *PCHIDDEN *PCREADO

Modify timestamp Object type File owner Archived file PC Attributes Hidden file Read only attribute

288

Table 44. Attribute

Compare DLO Attributes (CMPDLOA) attributes Description System file Primary group Private authority indicator Returned Values (SYS1VAL, SYS2VAL) *YES, *NO *NONE, user profile name No value, indicator only3 When this attribute is returned in output, its Difference Indicator value if the number of private authorities and private authority values are equal No value, indicator only1 When this attribute is returned in output, its Difference Indicator value if the public authority values are equal 50 character description

*PCSYSTEM *PGP *PRVAUTIND

*PUBAUTIND

Public authority indicator

*TEXT
1. 2. 3.

Text description

This attribute is not supported for DLOs with an object type of *FLR. This attribute is always compared. If *PRINT is specified in the comparison, an indicator appears in the system 1 and system 2 columns. If *OUTFILE is specified, these values are blank.

289

Comparison results for journal status and other journal attributes

The Compare File Attributes (CMPFILA), Compare Object Attributes (CMPOBJA), and Compare IFS Attributes (CMPIFSA) commands support comparing the journaling attributes listed in Table 45 for objects replicated from the user journal. These commands function similarly when comparing journaling attributes. When a compare is requested, MIMIX determines the result displayed in the Differences Indicator field by considering whether the file is journaled, whether the request includes a data group, and the data groups configured settings for journaling. Regardless of which journaling attribute is specified on the command, MIMIX always checks the journaling status first (*JOURNALED attribute). If the file or object is journaled on both systems, MIMIX then considers whether the command specified a data group definition before comparing any other requested attribute.
Table 45. Journaling attributes

When specified on the CMPOBJA command, these values apply only to files, data areas, or data queues. When specified on the CMPFILA command, these values apply only to PF-DTA and PF38-DTA files. *JOURNAL *JOURNALED Object journal information attributes. This value acts as a group selection, causing all other journaling attributes to be selected Journal Status. Indicates whether the object is currently being journaled. This attribute is always compared when any of the other journaling attributes are selected. Journal. Indicates the name of the current or last journal. If blank, the object has never been journaled. Journal Image. Indicates the kinds of images that are written to the journal receiver for changes to objects. Journal Library. Identifies the library that contains the journal. If blank, the object has never been journaled. Journal Omit. Indicates whether file open and close journal entries are omitted.

*JRN 1 *JRNIMG 1 2 *JRNLIB 1 *JRNOMIT 1

1.

2.

When these values are specified on a Compare command, the journal status (*JOURNALED) attribute is always evaluated first. The result of the journal status comparison determines whether the command will compare the specified attribute. Although *JRNIMG can be specified on the CMPIFSA command, it is not compared even when the journal status is as expected. The journal image status is reflected as not supported (*NS) because the operating system only supports after (*AFTER) images.

Compares that do not specify a data group - When no data group is specified on the compare request, MIMIX compares the journaled status (*JOURNALED attribute). Table 46 shows the result displayed in the Differences Indicator field. If the file or

290

object is not journaled on both systems, the compare ends. If both source and target systems are journaled, MIMIX then compares any other specified journaling attribute.
Table 46. Difference indicator values for *JOURNALED attribute when no data group is specified Difference Indicator Target Journal Status 1 Yes Source No *NOTFOUND
1.

Yes *EQ *NE *NE

No *NE *EQ *NE

*NOTFOUND *NE *NE *UN

The returned values for journal status found on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field.

Compares that specify a data group - When a data group is specified on the compare request, MIMIX compares the journaled status (*JOURNALED attribute) to the configuration values. If both source and target systems are journaled according to the expected configuration settings, then MIMIX compares any other specified journaling attribute against the configuration settings. The Compare commands vary slightly in which configuration settings are checked. For CMPFILA requests, if the journaled status is as configured, any other specified journal attributes are compared. Possible results from comparing the *JOURNALED attribute are shown in Table 47. For CMPOBJA and CMPIFSA requests, if the journaled status is as configured and the configuration specifies *YES for Cooperate with database (COOPDB), then any other specified journal attributes are compared. Possible results from comparing the *JOURNALED attribute are shown in Table 47 and Table 48. If the configuration specifies COOPDB(*NO), only the journaled status is compared; possible results are shown in Table 49.

Table 47, Table 48, and Table 49 show results for the *JOURNALED attribute that can appear in the Difference Indicator field when the compare request specified a data group and considered the configuration settings.

291

Table 47 shows results when the configured settings for Journal on target and Cooperate with database are both *YES.
Table 47. Difference indicator values for *JOURNALED attribute when a data group is specified and the configuration specifies *YES for JRNTGT and COOPDB Difference Indicator Target Journal Status 1 Yes Source No *NOTFOUND
1.

Yes *EC *NC *NE

No *EC *NC *NE

*NOTFOUND *NE *NE *UN

The returned values for journal status found on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field.

Table 48 shows results when the configured settings are *NO for Journal on target and *YES for Cooperate with database. .
Table 48. Difference indicator values for *JOURNALED attribute when a data group is specified and the configuration specifies *NO for JRNTGT and *YES for COOPDB. Difference Indicator Target Journal Status 1 Yes Source No *NOTFOUND
1.

Yes *NC *NC *NE

No *EC *NC *NE

*NOTFOUND *NE *NE *UN

The returned values for journal status found on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field.

Table 49 shows results when the configured setting for Cooperate with database is *NO. In this scenario, you may want to investigate further. Even though the Difference Indicator shows values marked as configured (*EC), the object can be not journaled

292

on one or both systems. The actual journal status values are returned in the System 1 Value (SYS1VAL) and System 2 Value (SYS2VAL) fields.
Table 49. Difference indicator values for *JOURNALED attribute when a data group is specified and the configuration specifies *NO for COOPDB. Difference Indicator Target Journal Status 1 Yes Source No *NOTFOUND
1.

Yes *EC *EC *NE

No *EC *EC *NE

*NOTFOUND *NE *NE *UN

The returned values for journal status found on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field.

How configured journaling settings are determined

When a data group is specified on a compare request, MIMIX also considers configuration settings when comparing journaling attributes. For comparison purposes, MIMIX assumes that the source system is journaled and that the target system is journaled according to configuration settings. Depending on the command used, there are slight differences in what configuration settings are checked. The CMPFILA, CMPOBJA, and CMPIFSA commands retrieve the following configurable journaling attributes from the data group definition: The Journal on target (JRNTGT) parameter identifies whether activity replicated through the user journal is journaled on the target system. The default value is *YES. The System 1 journal definition (JRNDFN1) and System 2 journal definition (JRNDFN2) values are retrieved and used to determine the source journal, source journal library, target journal, and target journal library. Values for elements Journal image and Omit open/close entries specified in the File entry options (FEOPT) parameter are retrieved. The default values are *AFTER and *YES, respectively.

Because the data groups values for Journal image and Omit open/close entries can be overridden by a data group file entry or a data group object entry, the CMPFILA and CMPOBJA commands also retrieve these values from the entries. The values determined after the order of precedence is resolved, sometimes called the overall MIMIX configuration values, are used for the compare. For CMPOBJA and CMPIFSA requests, the value of the Cooperate with database (COOPDB) parameter is retrieved from the data group object entry or data group IFS entry. The default value in object entries is *YES, while the default value in IFS entries is *NO.

293

Comparison results for auxiliary storage pool ID (*ASP)

The Compare File Attributes (CMPFILA), Compare Object Attributes (CMPOBJA), Compare IFS Attributes (CMPIFSA), and Compare DLO Attributes (CMPDLOA) commands support comparing the auxiliary storage pool (*ASP) attribute for objects replicated from the user journal. These commands function similarly. When a compare is requested, MIMIX determines the result displayed in the Differences Indicator field by considering whether a data group was specified on the compare request. Compares that do not specify a data group - When no data group is specified on the compare request, MIMIX compares the *ASP attribute for all files or objects that match the selection criteria specified in the request. The result displayed in the Differences Indicator field. Table 50 shows the possible results in the Difference Indicator field.
Table 50. Difference Indicator values when no data group is specified Difference Indicator Target ASP Values 1 ASP1 Source ASP2 *NOTFOUND
1.

ASP1 *EQ *NE *NE

ASP2 *NE *EQ *NE

*NOTFOUND *NE *NE *EQ

The returned values for *ASP attribute on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field.

Compares that specify a data group - When a data group is specified on the compare request (CMPFILA, CMPDLOA, CMPIFSA commands), MIMIX does not compare the *ASP attribute. When a data group is specified on a CMPOBJA request which specifies an object type except libraries (*LIB), MIMIX does not compare the *ASP attribute. Table 51 shows the possible results in the Difference Indicator field
Table 51. Difference Indicator values for non-library objects when the request specified a data group Difference Indicator Target ASP Values 1 ASP1 Source ASP2 *NOTFOUND
1.

ASP1 *NOTCMPD *NOTCMPD *NE

ASP2 *NOTCMPD *NOTCMPD *NE

*NOTFOUND *NE *NE *EQ

The returned values for *ASP attribute on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field.

294

For CMPOBJA requests which specify a a data group and an object type of *LIB, MIMIX considers configuration settings for the library. Values for the System 1 library ASP number (LIB1ASP), System 1 library ASP device (LIB1ASPD), System 2 library ASP number (LIB2ASP), and System 2 library ASP device (LIB2ASPD) are retrieved from the data group object entry and used in the comparison. Table 52, Table 53, and Table 54 show the possible results in the Difference Indicator field. Note: For Table 52, Table 53, and Table 54, the results are the same even if the system roles are switched. Table 52 shows the expected values for the ASP attribute when the request specifies a data group and the configuration specifies *SRCLIB for the System 1 library ASP number and the data source is system 2. .
Table 52. Difference Indicator values for libraries when a data group is specified and configured values are LIB1ASP(*SRCLIB) and DTASRC(*SYS2). Difference Indicator Target ASP Values 1 ASP1 Source ASP2 *NOTFOUND
1.

ASP1 *EC *NC *NE

ASP2 *NC *EC *NE

*NOTFOUND *NE *NE *EQ

The returned values for *ASP attribute on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field.

Table 53 shows the expected values for the ASP attribute the request specifies a data group and the configuration specifies 1 for the System 1 library ASP number and the data source is system 2.
Table 53. Difference Indicator values for libraries when a data group is specified and configured values are LIB1ASP(1) and DTASRC(*SYS2) Difference Indicator Target ASP Values 1 Source 2 *NOTFOUND
1.
1

1 *EC *EC *NE

2 *NC *NC *NE

*NOTFOUND *NE *NE *EQ

The returned values for *ASP attribute on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field.

Table 54 shows the expected values for the ASP attribute when the request specifies a data group and the configuration specifies *ASPDEV for the System 1 library ASP

295

number, DEVNAME is specified for the System 1 library ASP device, and data source is system 2. .
Table 54. Difference Indicator values for libraries when a data group is specified and configured values are LIB1ASP(*ASPDEV), LIB1ASPD(DEVNAME) and DTASRC(*SYS2) Difference Indicator Target ASP Values 1 1 Source 2 *NOTFOUND
1.

DEVNAME *EC *EC *NE

2 *NC *NC *NE

*NOTFOUND *NE *NE *EQ

The returned values for *ASP attribute on the Source and Target systems are shown in the SYS1VAL and SYS2VAL fields. Which system is source and which is target is determined by the value of the DTASRC field.

296

Comparison results for user profile status (*USRPRFSTS)

When comparing the attribute *USRPRFSTS (user profile status) with the Compare Object Attributes (CMPOBJA) command, MIMIX determines the result displayed in the Differences Indicator field by considering the following: The status values of the object on both the source and target systems Configured values for replicating user profile status, at the data group and object entry levels The value of the Data group definition (DGDFN) parameter specified on the CMPOBJA command.

Compares that do not specify a data group - When the CMPOBJA command does not specify a data group, MIMIX compares the status values between source and target systems. The result is displayed in the Differences Indicator field, according to Table 38 in Interpreting results of audits that compare attributes on page 268. Compares that specify a data group - When the CMPOBJA command specifies a data group, MIMIX checks the configuration settings and the values on one or both systems. (For additional information, see How configured user profile status is determined on page 298.) When the configured value is *SRC, the CMPOBJA command compares the values on both systems. The user profile status on the target system must be the same as the status on the source system, otherwise an error condition is reported. Table 55 shows the possible values.
Table 55. Difference Indicator values when configured user profile status is *SRC Difference Indicator Target User profile status *ENABLED Source *DISABLED *NOTFOUND *ENABLED *EC *NC *NE *DISABLED *NC *EC *NE *NOTFOUND *NE *NE *UN

When the configured value is *ENABLED or *DISABLED, the CMPOBJA command checks the target system value against the configured value. If the user profile status on the target system does not match the configured value, an error condition is reported. The source system user profile status is not relevant. Table 56 and Table 57

297

show the possible values when configured values are *ENABLED or *DISABLED, respectively.
Table 56. Difference Indicator values when configured user profile status is *ENABLED Difference Indicator Target User profile status *ENABLED Source *DISABLED *NOTFOUND *ENABLED *EC *EC *NE *DISABLED *NC *NC *NE *NOTFOUND *NE *NE *UN

Table 57.

Difference Indicator values when configured user profile status is *DISABLED Difference Indicator Target

User profile status *ENABLED Source *DISABLED *NOTFOUND

*ENABLED *NC *NC *NE

*DISABLED *EC *EC *NE

*NOTFOUND *NE *NE *UN

When the configured value is *TGT, the CMPOBJA command does not compare the values because the result is indeterminate. Any differences in user profile status between systems are not reported. Table 58 shows possible values.
Table 58. Difference Indicator values when configured user profile status *TGT Difference Indicator Target User profile status *ENABLED Source *DISABLED *NOTFOUND *ENABLED *NA *NA *NE *DISABLED *NA *NA *NE *NOTFOUND *NE *NE *UN

How configured user profile status is determined

The data group definition determines the behavior for replicating user profile status unless it is explicitly overridden by a non-default value in a data group object entry. The value determined after the order of precedence is resolved is sometimes called the overall MIMIX configuration value. Unless specified otherwise in the data group or

298

in an object entry, the default is to use the value *SRC from the data group definition. Table 59 shows the possible values at both the data group and object entry levels.
Table 59. *DGDFT Configuration values for replicating user profile status Only available for data group object entries, this indicates that the specified in the data group definition is used for the user profile statue. This is the default value for object entries. The status of the user profile is set to *DISABLED when the user profile is created or changed on the target system. The status of the user profile is set to *ENABLED when the user profile is created or changed on the target system. This is the default value in the data group definition. The status of the user profile on the source system is always used when the user profile is created or changed on the target system. If a new user profile is created, the status is set to *DISABLED. If an existing user profile is changed, the status of the user profile on the target system is not altered.

*DISABLE 1 *ENABLE 1 *SRC

*TGT

1.

Data group definitions use these values. In data group object entries, the values *DISABLED and *ENABLED are used but have the same meaning.

299

Comparison results for user profile password (*PRFPWDIND)

When comparing the attribute *PRFPWDIND (user profile password indicator) with the Compare Object Attributes (CMPOBJA) command, MIMIX assumes that the user profile names are the same on both systems. User profile passwords are only compared if the user profile name is the same on both systems and the user profile of the local system is enabled and has a defined password. If the local or remote user profile has a password of *NONE, or if the local user profile is disabled or expired, the user profile password is not compared. The System Indicator fields will indicate that the attribute was not compared (*NOTCMPD). The Difference Indicator field will also return a value of not compared (*NA). The CMPOBJA command does not support name mapping while comparing the *PRFPWDIND attribute. If the user profile names are different, or if you attempt name mapping, the System Indicator fields will indicate that comparing the attribute is not supported (*NOTSPT). The Difference Indicator field will also return a value of not supported (*NS). The following tables identify the expected results when user profile password is compared. Note that the local system is the system on which the command is being run, and the remote system is defined as System 2. Table 60 shows the possible Difference Indicator values when the user profile passwords are the same on the local and remote systems and are not defined as *NONE.
Table 60. Difference Indicator values when user profile passwords are the same, but not *NONE. Difference Indicator Remote System User Profile Password *ENABLED *DISABLED Local System Expired Not Found *ENABLED *EQ *NA *NA *NE *DISABLED *EQ *NA *NA *NE Expired *EQ *NA *NA *NE Not Found *NE *NE *NE *EQ

300

Table 61 shows the possible Difference Indicator values when the user profile passwords are different on the local and remote systems and are not defined as *NONE.
Table 61. Difference Indicator values when user profile passwords are different, but not *NONE Difference Indicator Remote System User Profile Password *ENABLED *DISABLED Local System Expired Not Found *ENABLED *NE *NA *NA *NE *DISABLED *NE *NA *NA *NE Expired *NE *NA *NA *NE Not Found *NE *NE *NE *EQ

Table 62 shows the possible Difference Indicator values when the user profile passwords are defined as *NONE on the local and remote systems.
Table 62. Difference Indicator values when user profile passwords are *NONE. Difference Indicator Remote System User Profile Password *ENABLED *DISABLED Local System Expired Not Found *ENABLED *NA *NA *NA *NE *DISABLED *NA *NA *NA *NE Expired *NA *NA *NA *NE Not Found *NE *NE *NE *EQ

301

IBM Power Systems operations that affect MIMIX

IBM Power Systems operations that affect MIMIX

APPENDIX B
The following topics describe how to protect the integrity of your MIMIX environment when you perform operations such as IPLs and IBM i operating system upgrades. Only basic procedures for a standard one-to-one MIMIX installation are covered. If you are operating in a complex environmentif you have cluster, SAP R/3, IBM WebSphere MQ, or other application considerations, for examplecontact your Certified MIMIX Consultant. Ultimately, you must tailor these procedures to suit the needs of your particular environment. These topics describe MIMIX-specific steps only. Refer to the user manuals that correspond to any additional applications installed in your environment. For instructions on performing IBM PowerTM Systems operations, consult your IBM manuals or the IBM Information Center at http://publib.boulder.ibm.com/pubs/html/as400/infocenter.html. The following topics are included: MIMIX procedures when performing an initial program load (IPL) on page 302 includes the MIMIX-specific steps for performing an initial program load (IPL) to help ensure the integrity of your MIMIX environment is not compromised. MIMIX procedures when performing an operating system upgrade on page 303 describes when and how to perform recommended MIMIX-specific steps while performing a standard upgrade of IBM i. MIMIX procedures when upgrading hardware without a disk image change on page 310 describes MIMIX prerequisites and procedures for performing a hardware upgrade without a disk image change. MIMIX procedures when performing a hardware upgrade with a disk image change on page 313 describes prerequisites for saving and restoring MIMIX software when upgrading from one system to another. Handling MIMIX during a system restore on page 314 includes prerequisites for restoring MIMIX software within a MIMIX system pair, to one system from a save of the other system when an environment meets the conditions specified.

MIMIX procedures when performing an initial program load (IPL)

An initial program load (IPL) loads the operating system and prepares the system for user operations. Performing the recommended MIMIX-specific steps can help ensure that objects are not damaged during the IPL and that the integrity of your MIMIX environment is not compromised. Notes:

302

MIMIX procedures when performing an operating system upgrade

This procedure describes an IPL performed under normal circumstances. It does not address IPL considerations for system switching environments. Before beginning this procedure, review your startup procedures to determine whether subsystems will start after the IPL. This startup program is defined in the QSTRUPPGM system value.

To perform an IPL in a MIMIX environment, do the following: 1. End MIMIX from either the source or target system. The End MIMIX (ENDMMX) command attempts to end the MIMIX processes for the installation, including the MIMIX managers and the data groups. Data groups can be ended in an immediate (*IMMED) or controlled (*CNTRLD) manner. Note: For more information about the ENDMMX command, see Choices when ending replication on page 141. 2. End the MIMIX subsystems on both the source and target system. On each system, type the following on a command line and press Enter: ENDSBS SBS(MIMIXSBS) OPTION(*IMMED) 3. Perform the IPL. 4. If your subsystems do not start during the startup procedures defined in the QSTRUPPGM system value, start the MIMIX subsystems on both the source and target systems. On each system, type the following on a command line and press Enter: STRSBS SBS(MIMIXQGPL/MIMIXSBS) 5. Verify the communication links start, using the Verify Communications Link (VFYCMNLNK) command. Note: For more information about the VFYCMNLNK command, see Verifying a communications link for system definitions on page 244. 6. Start MIMIX from either the source or target system. The Start MIMIX (STRMMX) command starts the MIMIX processes for the installation, including the MIMIX managers and the data groups. Note: For more information about the STRMMX command, see Starting MIMIX on page 147.

MIMIX procedures when performing an operating system upgrade

This topic describes when and how to perform recommended MIMIX-specific steps while performing a standard upgrade of the IBM i operating system (slip-install, where the IBM i release is upgraded without a restore of the user libraries). Performing these recommended steps can help ensure that MIMIX products start properly once the operating system upgrade is complete.

303

IBM Power Systems operations that affect MIMIX

Table 63 indicates which procedures are needed for different upgrade scenarios. Use these instructions in conjunction with the instructions provided by IBM for upgrading from one IBM i release to another IBM i release.
Table 63. IBM i operating system upgrade scenarios and recommended processes for handling MIMIX during the upgrade Perform these procedures 1. Perform the preparation steps described in Prerequisites for performing an OS upgrade on either system on page 304. 2. Follow the procedure in MIMIX-specific steps for an OS upgrade on the backup system on page 305. 1. Perform the preparation steps described in Prerequisites for performing an OS upgrade on either system on page 304. 2. Perform one of the following procedures: If you need to maintain user access to production applications during the upgrade, perform a planned switch as described in MIMIX-specific steps for an OS upgrade on the production system with switching on page 307. Your production operations will be temporarily running on the backup system. If you have more flexibility with scheduling downtime, you can perform the upgrade without switching as described in MIMIX-specific steps for an OS upgrade on the production system without switching on page 308. 1. Perform the preparation steps described in Prerequisites for performing an OS upgrade on either system on page 304. 2. Upgrade the backup system first following the MIMIX-specific steps for an OS upgrade on the backup system on page 305. By doing this first, you can ensure that the backup system supports all the capabilities of the production system and you can work through problems or custom operations before affecting your production environment. 3. Once you have the verified that the backup system is upgraded and operating as desired, perform one of the following procedures to upgrade IBM i on the production system: If you need to maintain user access to production applications during the upgrade, perform a planned switch as described in MIMIX-specific steps for an OS upgrade on the production system with switching on page 307. Your production operations will be temporarily running on the backup system. If you have more flexibility with scheduling downtime, you can perform the upgrade without switching as described in MIMIX-specific steps for an OS upgrade on the production system without switching on page 308

To upgrade Backup system only

Production system only

Both backup and production systems

Prerequisites for performing an OS upgrade on either system

Before you start an upgrade of the IBM i operating system on either system, do the following: 1. Access Support information on the web as you perform the following steps to ensure that the system is ready to upgrade:

304

MIMIX procedures when performing an operating system upgrade

a. Check the compatibility of the operating systems on the production and backup systems, ensuring the systems will meet the requirements of a MIMIXsupported environment once the IBM i operating system upgrade has occurred. b. Ensure the recommended IBM IBM i PTFs have been applied according to your IBM i version. c. Ensure the recommended MIMIX service packs have been applied according to your MIMIX version. Review the Read Me document that corresponds to the MIMIX service pack, and check the website for relevant Technical Alerts and FAQs. 2. Review your startup procedures to understand how your environment is configured to start after an IPL. This startup program is defined in the QSTRUPPGM system value. An IBM i upgrade may include rebuilding access paths, converting formats, or performing other operations that must be complete before MIMIX or other applications are started. The upgrade may not complete successfully if your QSTRUPPGM procedures start MIMIX or other applications during an IPL. Ensure that these processes are disabled before continuing with the IBM i upgrade.

MIMIX-specific steps for an OS upgrade on the backup system

Use this procedure to upgrade the operating system on the backup system. Notes: If you plan to upgrade both the production and backup systems during the same scheduled maintenance period, upgrade the backup system first. In the following steps, the terms production and backup always refer to the original roles of the systems before upgrading the operating system on either system. The icons at the beginning of some steps show the state of the systems and replication as a result of the action in the step. The arrow in the icon indicates the direction and state of replication for a classic production to backup environment. MIMIX Model Switch Framework commands, such as RUNSWTFWK, are typically run from the backup system.

To perform an operating system upgrade of the backup system in a MIMIX environment, do the following: 1. Ensure that you have completed any prerequisite tasks for your upgrade scenario. See Table 63 for a list of required tasks for different upgrade scenarios. 2. End all user applications, user interfaces, and operations actively running on the backup system. Be sure to address the following: Disarm any monitors, such as MIMIX Monitor, robot jobs, or other job schedulers. Make sure all users are off the system.

Note: For more information, refer to your Runbook, Using MIMIX Monitor, and your applications user manuals.

305

IBM Power Systems operations that affect MIMIX

3. End the data groups from either system using the command: ENDDG DGDFN(*ALL) ENDOPT(*CNTRLD) Note: For more information about ending data groups see Choices when ending replication on page 141. 4. Wait until the status of each data group becomes inactive (red) by monitoring the status on the Work with Data Groups (WRKDG) display. Note: For more information about the WRKDG display, see The Work with Data Groups display - 5250 emulator on page 54. 5. If you have applications that use commitment control, ensure there are no open commit cycles. For more information, see Checking for open commit cycles on page 139. a. If an open commit cycle exists, restart the data group and repeat Step 3, Step 4, and Step 5 until there is no open commit cycle for any apply session. 6. Use the following command to end other MIMIX products in the installation library, end the MIMIX managers, and end the RJ link: ENDMMX ENDOPT(*CNTRLD) ENDRJLNK(*YES) 7. Use the following command on the production and backup system to end the MIMIX subsystems: ENDSBS SBS(MIMIXSBS) OPTION(*IMMED) 8. Complete the operating system upgrade. Allow any upgrade conversions and access path rebuilds to complete before continuing with the next step. Note: During the IBM i upgrade, make sure you perform a system save on the system being upgraded. This step will provide you with a backup of existing data. 9. Ensure the names of the journal receivers match the journal definitions: a. From the backup system, specify the command:
installation-name/WRKJRNDFN JRNDFN(QAUDJRN *LOCAL)

b. Next to the JRNDFN(QAUDJRN *LOCAL) journal definition, specify 14 (Build) and press F4. Type *JRNDFN for the Source for values parameter and press Enter. 10. Start the MIMIX subsystems on both the production and backup systems using the following command from each system: STRSBS SBS(MIMIXQGPL/MIMIXSBS) 11. Perform a normal start of the data groups from either system using the STRMMX command. This step also starts the MIMIX managers. 12. Perform your normal process for validating the IBM i release upgrade. Notes: At your convenience, schedule a switch to verify that your applications function on the new operating system on the backup system.

306

MIMIX procedures when performing an operating system upgrade

After the IBM i upgrade, you may receive object errors for program object types (*PGM) if your source IBM i version is higher than your target IBM i version. MIMIX is unable to save/restore *PGM objects in this case. To avoid these errors, compile the *PGM objects on the source system using the Create Program (CRTPGM) command. On the Target release prompt, specify the IBM i version of your target system.

MIMIX-specific steps for an OS upgrade on the production system with switching

Use this procedure if you need to maintain user access to production applications during the production system upgrade. This procedure temporarily switches production activity to the backup system before the upgrade and switches back to normal operations after the production system upgrade is complete. Notes: In the following steps, the terms production and backup always refer to the original roles of the systems before upgrading the operating system on either system. The icons at the beginning of some steps show the state of the systems and replication as a result of the action in the step. The arrow in the icon indicates the direction and state of replication for a classic production to backup environment. MIMIX Model Switch Framework commands, such as RUNSWTFWK, are typically run from the backup system. You can find more information about using the RUNSWTFWK command in the Using MIMIX Monitor book.

To perform an operating system upgrade of the production system in a MIMIX environment while maintaining availability, do the following: 1. Ensure that you have completed any prerequisite tasks for your upgrade scenario. See Table 63 for a list of required tasks for different upgrade scenarios. 2. Use the procedures in your Runbook to perform a planned switch to the backup system. Note: Do not perform the synchronize phase of your switch procedures. If you do not have a Runbook, you need to follow your processes for the following: End all user applications, user interfaces, and operations actively running on the production system. Disarm any monitors, robot jobs, or other job schedulers and make sure all users are off the system. Resolve any errors in MIMIX and perform a controlled end of the data groups. Perform a planned switch to the backup system.

3. End MIMIX products in the installation library and end the RJ link using the command: ENDMMX ENDOPT(*CNTRLD) ENDRJLNK(*YES) Note: For more information about the ENDMMX command, see Choices when ending replication on page 141. 4. From the production system, use the following command to end the MIMIX

307

IBM Power Systems operations that affect MIMIX

subsystems: ENDSBS SBS(MIMIXSBS) OPTION(*IMMED) 5. Start applications on the backup system and allow users to access their applications from the backup system. 6. On the production system, complete the operating system upgrade. Allow any upgrade conversions and access path rebuilds to complete before continuing with the next step. Note: During the IBM i upgrade, make sure you perform a system save on the system being upgraded. This step will provide you with a backup of existing data. 7. Ensure the names of the journal receivers match the journal definitions: a. From the original production system, specify the command:
installation-name/WRKJRNDFN JRNDFN(QAUDJRN *LOCAL)

b. Next to the JRNDFN(QAUDJRN *LOCAL) journal definition, specify 14 (Build) and press F4. Type *JRNDFN for the Source for values parameter and press Enter. 8. Follow your Runbook procedures to perform a synchronization. If you do not have a Runbook, you need to follow your processes for the following: Starting MIMIX subsystems Starting data groups

9. Follow your Runbook procedures to perform a planned switch back to the production system and start replication. If you do not have a Runbook, you need to follow your processes to switch replication so that you return to your normal replication environment. 10. Perform your normal process for validating the IBM i release upgrade. Note: After the IBM i upgrade, you may receive object errors for program object types (*PGM) if your source IBM i version is higher than your target IBM i version. MIMIX is unable to save/restore *PGM objects in this case. To avoid these errors, compile the *PGM objects on the source system using the Create Program (CRTPGM) command. On the Target release prompt, specify the IBM i version of your target system.

MIMIX-specific steps for an OS upgrade on the production system without switching

Use this procedure if you have more flexibility with scheduling downtime and can perform the upgrade without switching. Notes: In the following steps, the terms production and backup always refer to the original roles of the systems before upgrading the operating system on either system. The icons at the beginning of some steps show the state of the systems and replication as a result of the action in the step. The arrow in the icon indicates the

308

MIMIX procedures when performing an operating system upgrade

direction and state of replication for a classic production to backup environment. MIMIX Model Switch Framework commands, such as RUNSWTFWK, are typically run from the backup system. You can find more information about using the RUNSWTFWK command in the Using MIMIX Monitor book.

To perform an operating system upgrade of the production system in a MIMIX environment without switching, do the following: 1. Ensure that you have completed any prerequisite tasks for your upgrade scenario. See Table 63 for a list of required tasks for different upgrade scenarios. 2. End all user applications, user interfaces, and operations actively running on the production system. Be sure to address the following: Disarm any monitors, such as MIMIX Monitor, robot jobs, or other job schedulers. Make sure all users are off the system.

Note: For more information, refer to your Runbook, Using MIMIX Monitor, and your applications user manuals. 3. End the data groups from either system using the command: ENDDG DGDFN(*ALL) ENDOPT(*CNTRLD) Note: For more information about ending data groups see Choices when ending replication on page 141. 4. Wait until the status of each data group becomes inactive (red) by monitoring the status on the Work with Data Groups (WRKDG) display. Note: For more information about the WRKDG display, see The Work with Data Groups display - 5250 emulator on page 54. 5. If you have applications that use commitment control, ensure there are no open commit cycles. For more information, see Checking for open commit cycles on page 139. a. If an open commit cycle exist, restart the data group and repeat Step 3, Step 4, and Step 5 until there is no open commit cycle for any apply session. 6. Use the following command to end other MIMIX products in the installation library, end the MIMIX managers, and end the RJ link: ENDMMX ENDOPT(*CNTRLD) ENDRJLNK(*YES) 7. End the MIMIX subsystems on the production system and on the backup system. On each system, type the following on a command line and press Enter: ENDSBS SBS(MIMIXSBS) OPTION(*IMMED) 8. Complete the operating system upgrade. Allow any upgrade conversions and access path rebuilds to complete before continuing with the next step. Note: During the IBM i upgrade, make sure you perform a system save on the system being upgraded. This step will provide you with a backup of existing data. 9. Start the MIMIX subsystems on the production system and the backup system as

309

IBM Power Systems operations that affect MIMIX

you would during the synchronization phase of a switch. From each system, type the following on a command line and press Enter: STRSBS SBS(MIMIXQGPL/MIMIXSBS) 10. Ensure the names of the journal receivers match the journal definitions: a. From the production system, specify the command:
installation-name/WRKJRNDFN JRNDFN(QAUDJRN *LOCAL)

b. Next to the JRNDFN(QAUDJRN *LOCAL) journal definition, specify 14 (Build) and press F4. Type *JRNDFN for the Source for values parameter and press Enter. c. Record the newly attached journal receiver name by placing the cursor on the posted message and pressing F1 or Help. 11. Using the information you gathered in Step 10, start each data group as follows (This step also starts the MIMIX managers.): a. From the WRKDG display, type an 9 (Start DG) next to the data group and press Enter. The Start Data Group display appears. b. At the Object journal receiver prompt, specify the receiver name recorded in Step 10c. c. At the Object large sequence number prompt, specify *FIRST. d. At the Clear pending prompt, specify *YES. 12. Start any applications that you disabled prior to completing the IBM i upgrade according to your Runbook instructions. These applications are normally started in the program defined in the QSTRUPPGM system value. Allow users back on the production system. Note: After the IBM i upgrade, you may receive object errors for program object types (*PGM) if your source IBM i version is higher than your target IBM i version. MIMIX is unable to save/restore *PGM objects in this case. To avoid these errors, compile the *PGM objects on the source system using the Create Program (CRTPGM) command. On the Target release prompt, specify the IBM i version of your target system.

MIMIX procedures when upgrading hardware without a disk image change

This topic describes MIMIX prerequisites and procedures for a hardware upgrade without a disk image change that will change a model, feature, or serial number and require a new access code. Performing these steps can ensure that MIMIX products start properly once the hardware upgrade is complete.

Considerations for performing a hardware system upgrade without a disk

310

MIMIX procedures when upgrading hardware without a disk image change

image change
Before you start a hardware upgrade on either system, consider the following: Ensure the new system is compatible with and meets the requirements for a MIMIX-supported environment. For more information, see the Supported Environments Matrix in the Technical Documents section of Support Central. Apply the latest MIMIX fixes on both systems. The fixes are available by product in the Downloads section of Support Central. Obtain new MIMIX product access codes. These codes are required for products when a model, feature, or serial number changes. For more information, see Working with access codes in the License and Availability Manager book. Determine whether a planned switch is required prior to the hardware upgrade. For example, a switch would be necessary if the source system is being upgraded and users need to continue working while the upgrade takes place. To perform a switch, follow the steps in your runbook. For more information, see Switching on page 204. Determine if the transfer definitions need to be changed. For example, transfer definitions would need to be changed if the IP addresses or host names change. For more information, see Configuring transfer definitions in the MIMIX Reference book.

MIMIX-specific steps for a hardware upgrade without a disk image change

Use this procedure to restart your MIMIX installation when updating your hardware. If you have special considerations, contact your Certified MIMIX Consultant for assistance. Before you begin, ensure that Considerations for performing a hardware system upgrade without a disk image change on page 310 have been reviewed and completed where applicable.

Hardware upgrade without a disk image change - preliminary steps

To perform this portion of the upgrade process, do the following on the system prior to the upgrade: 1. Ensure MIMIX is operating normally before performing the upgrade. There should be no files or objects in error and all transactions should be caught up. See Resolving common replication problems on page 163 for more information about resolving problems. 2. Ensure users are logged off the system and perform a controlled shutdown of all MIMIX data groups. For more information, see Ending a data group in a controlled manner on page 152. 3. End all MIMIX products. For more information, see Ending MIMIX on page 147. 4. Print the status information for each data group by doing the following: a. From the Work with Data Groups display, type 8 (Display detail status) next to each data group.

311

IBM Power Systems operations that affect MIMIX

b. Press Enter. c. Press F7 for object status and print the display. Keep the information for later use. d. Press F8 for database status and print the display. Keep the information for later use. 5. Optional step: Save the MIMIX software by doing a full system save or by saving all MIMIX installation libraries: LAKEVIEW MIMIXQGPL MIMIX-installation-library MIMIX-installation-library_0 MIMIX-installation-library_1 /LakeviewTech (directory tree)

6. Optional step: If upgrading the source system and performing a switch, follow the steps in your runbook. For more information, see Switching on page 204.

Hardware upgrade without a disk image change - subsequent steps

To perform this portion of the upgrade process, do the following on the system after the upgrade has been completed: 1. Optional step: Update any transfer definitions that require changes. For more information, see Configuring transfer definitions in the MIMIX Reference book. 2. Enter the new product access code on the system. Do the following: a. From the MIMIX main menu select option 31 (Product Management Menu). The License Manager Main Menu appears. b. Select option 1 (Update access code). The Update Access Codes (UPDACCCDE) command appears. Follow the instructions displayed for obtaining access codes. For more information, see Obtaining access codes using UPDACCCDE command in the License and Availability Manager book. 3. Confirm that communications work between the new system and other systems in the MIMIX environment. For more information, see Verifying a communications link for system definitions on page 244. 4. Optional step: Perform a data group switch by following the steps in your runbook, then skip to Step 6. See Considerations for performing a hardware system upgrade without a disk image change on page 310 to determine if a switch is required. 5. Use the Start Data Group (STRDG) command to start all data groups. For more information, see Starting and ending replication on page 131. 6. Run your MIMIX audits to verify the systems are synchronized. See Running audits immediately on page 91 for more information about running audits.

312

MIMIX procedures when performing a hardware upgrade with a disk image change

MIMIX procedures when performing a hardware upgrade with a disk image change
When a hardware upgrade is being performed on a system, MIMIX software may need to be saved from the system being replaced and then restored to the system that is its replacement. The saved MIMIX information must be restored on a system that performs the same role within MIMIX operations. For example, if the network system is being replaced, MIMIX software must be saved from the network system and restored on the new network system. A network system cannot be restored to a new management system. This topic describes steps to consider prior to saving and restoring MIMIX software when upgrading from one system to another. Performing these steps can ensure that MIMIX products start properly once the hardware upgrade is complete. IMPORTANT! To ensure the integrity of your data, contact your Certified MIMIX Consultant for assistance performing a hardware upgrade.

Considerations for performing a hardware system upgrade with a disk image change
Before you start a hardware upgrade on either system, consider the following: Contact your contact your Certified MIMIX Consultant prior to performing the upgrade for instructions that may be specific to your environment. Ensure the new system is compatible with and meets the requirements for a MIMIX-supported environment. For more information, see the Supported Environments Matrix in the Technical Documents section of Support Central. Apply the latest MIMIX fixes on both systems. The fixes are available by product in the Downloads section of Support Central. Obtain new MIMIX product access codes. These codes are required for products when a model, feature, or serial number changes. For more information, see Working with access codes in the License and Availability Manager book. Determine whether a planned switch is required prior to the hardware upgrade. For example, a switch would be necessary if the source system is being upgraded and users need to continue working while the upgrade takes place. To perform a switch, follow the steps in your runbook. For more information, see Switching on page 204. Determine if the transfer definitions need to be changed. For example, transfer definitions would need to be changed if the IP addresses or host names change. For more information, see Configuring transfer definitions in the MIMIX Reference book. Copy all automation for MIMIX to the new machine, including exit programs. Transfer any modifications of programs such as QSTARTUP to the new system. Modifications may be needed to start the MIMIX subsystem after an IPL. Refer to your Runbook for an overview of the required automation changes that need to be performed on the system.

313

IBM Power Systems operations that affect MIMIX

Handling MIMIX during a system restore

Occasionally, an entire system may need to be restored because of a system failure. For example, if there is a processor or OS (operating system) failure. This topic includes prerequisites for restoring MIMIX software within a MIMIX system pair (two systems using the same MIMIX installation) to one system from a save of the other system. A system restore may need to be performed when the when the following conditions exist: The original production system, including the Licensed Internal Code and the OS, has been recovered from the backup system by tape. The IBM installed release level is the same on each system.

IMPORTANT! To ensure the integrity of your data, contact your Certified MIMIX Consultant for assistance performing a system restore. For information about MIMIX-supported environments, see the Supported Environments Matrix in the Technical Documents section of Support Central.

Prerequisites for performing a restore of MIMIX

Before you restore MIMIX on a system, consider the following steps which help ensure that MIMIX products start properly once the restore is complete: Contact your contact your Certified MIMIX Consultant prior to performing the restore for instructions that may be specific to your environment. Locate your MIMIX product access codes. These codes may be required after the restore. For more information, see Working with access codes in the License and Availability Manager book.

314

Notices
Copyright 1999, 2009, Vision Solutions, Inc. All rights reserved. The information in this document is subject to change without notice and is furnished under a license agreement. This document is proprietary to Vision Solutions, Inc., and may be used only as authorized in our license agreement. No portion of this manual may be copied or otherwise reproduced, translated, or transmitted in whole or part, without the express consent of Vision Solutions, Inc. If you are an entity of the U.S. government, you agree that this documentation and the program(s) referred to in this document are Commercial Computer Software, as defined in the Federal Acquisition Regulations (FAR), and the DoD FAR Supplement, and are delivered with only those rights set forth within the license agreement for such documentation and program(s). Use, duplication or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFAR 252.227-7013 (48 CFR) or subparagraphs (c)(1) & (2) of the Commercial Computer Software Restricted Rights clause at FAR 52.227-19. Vision Solutions, Inc. makes no warranty of any kind regarding this material and assumes no responsibility for any errors that may appear in this document. The program(s) referred to in this document are not specifically developed, or licensed, for use in any nuclear, aviation, mass transit, or medical application or in any other inherently dangerous applications, and any such use shall remove Vision Solutions, Inc. from liability. Vision Solutions, Inc. shall not be liable for any claims or damages arising from such use of the Program(s) for any such applications. Examples and Example Programs: This book contains examples of reports and data used in daily operation. To illustrate them as completely as possible the examples may include names of individuals, companies, brands, and products. All of these names are fictitious. Any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. This book contains small programs that are furnished by Vision Solutions, Inc. as simple examples to provide an illustration. These examples have not been thoroughly tested under all conditions. Vision Solutions, therefore, cannot guarantee or imply reliability, serviceability, or function of these example programs. All programs contained herein are provided to you AS IS. THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. MIMIX and Vision Solutions are registered trademarks of Vision Solutions, Inc. IntelliStart, MIMIX dr1, MIMIX AutoGuard, MIMIX AutoNotify, MIMIX Availability Manager, MIMIX ha1, MIMIX ha Lite, MIMIX DB2 Replicator, MIMIX Object Replicator, MIMIX Monitor, MIMIX Promoter, MIMIX Switch Assistant, RJ Link, Replicate1, Vision AutoValidate, and Vision Cluster1 are trademarks of Vision Solutions, Inc. AS/400, DB2, eServer, i5/OS, IBM, iSeries, OS/400, Power, System i, and WebSphere are trademarks of International Business Machines Corporation. Internet Explorer, Microsoft, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Netscape is a registered trademark of AOL LLC. Mozilla and Firefox are trademarks of the Mozilla Foundation. UNIX is a registered trademark of The Open Group in the United States and other countries. Java and all Java-based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All other trademarks are the property of their respective owners. Corporate Headquarters Vision Solutions, Inc. Irvine, California USA Tel: +1 (949) 253-6500

Index
Symbols
*FAILED activity entry 185, 188 *HLD file entry 170 tracking entry 179 *HLDERR file entry 170 tracking entry 179 *HLDRLTD file entry 170 last performed 100 last successful run 98 policies which affect 109 prevent from running 110 problems reported in installation 54 recommendations 81, 82 recovery phase 19 requirements 81 results 93, 95 rule name 104 running immediately 91 schedule 102 schedule, considerations for changing 105 schedule, shipped default 104 scheduler, alternative 108 scheduler, automatic 104 status 85 status from 5250 emulator 52 status from MIMIX Availability Manager 48 status, compliance 98 status, runtime 87 summary 87 when not to audit 23 audit level best practice 81 changing before switch 210 differences, displaying 92 audit results 93, 95 #DGFE rule 263 #DLOATR rule 288 #DLOATR rule, ASP attributes 294 #FILATR rule 273 #FILATR rule, ASP attributes 294 #FILATR rule, journal attributes 290 #FILATRMBR rule 273 #FILATRMBR rule, ASP attributes 294 #FILATRMBR rule, journal attributes 290 #FILDTA rule 265 #IFSATR rule 286 #IFSATR rule, ASP attributes 294 #IFSATR rule, journal attributes 290 #MBRRCDCNT rule 265 #OBJATR rule 278 #OBJATR rule, ASP attributes 294 #OBJATR rule, journal attributes 290 #OBJATR rule, user profile password attribute 300 #OBJATR rule, user profile status attribute 297 interpreting, attribute comparisons 268

A
accessing MIMIX Availability Status display 50 MIMIX Main Menu 42 status from MIMIX Availability Manager 48 activity entries, object confirm delay/retry cycle 189 failed, resolving 185 remove history 190 retrying 188 additional resources 11 agintro 79 applications, reducing contention with 242 attributes, supported CMPDLOA command 288 CMPFILA command 273 CMPIFSA command 286 CMPOBJA command 278 audit after a configuration change 106 authority level to run 81 automatic recovery 82 before switching 81 best practice 20, 81, 100 bi-directional environment considerations 22 changing schedule 105, 106 compare phase 19 comparison levels 19, 81 compliance 98 compliance threshold 28, 29 concepts 19 definition of 18 differences, resolving 93, 95 displaying compliance status 85, 100 displaying runtime status 85, 90 displaying schedule 102 ending 91 getting started 20 job log 96

316

interpreting, file data comparisons 265 resolving problems 95, 263 troubleshooting 96 auditing level, object set when starting a data group 140 used for replication 192 authority level for auditing, product 81 AutoGuard, MIMIX 15 automatic error recovery policies for 33 system journal replication 34 user journal replication 33 automatic recovery audit recommendations 82 audits 27 concept 18 system journal replication 27 user journal replication 27 AutoNotify feature, MIMIX 124 Availability Manager, MIMIX 15 Availability Status display, MIMIX 50

B
backlog, identifying a 76 backup system 16 best practice audit frequency 100 audit level 29, 81 audit level before switch 82, 210 audit threshold 28, 29 MIMIX AutoGuard 20 switch frequency 204, 215 switch threshold 31 switching 205 bi-directional environment policy considerations 22

C
clear error entries processing 136 when to 136 clear pending entries check for open commits 139 open commit cycle prevents 139 processing 136 resolving open commits before 140 when to 136 cold start, replacement for 136 commands, by mnemonic

CHGDG 233 CHKDGFE 106, 246, 263 CRTDGTSP 254 DLTDGTSP 256 DSPDGSTS 64 DSPDGTSP 256 DSPMMXMSGQ 167 DSPRJLNK 227 ENDDG 131, 141 ENDJRNFE 196 ENDJRNIFSE 199 ENDJRNOBJE 202 ENDJRNPF 196 ENDMMX 131, 141, 147 ENDMMXMGR 165 ENDRJLNK 237 ENDSVR 223 HLDDGLOG 257 MIMIX 42 RLSDGLOG 257 RUNRULE 80, 115 RUNRULEGRP 80, 115 STRDG 131, 133, 135 STRJRNFE 195 STRJRNIFSE 198 STRJRNOBJE 201 STRMMX 131, 133, 147 STRMMXMGR 165 STRRJLNK 237 STRSVR 222 SWTDG 217, 219 VFYCMNLNK 244, 245 VFYJRNFE 197 VFYJRNIFSE 200 VFYJRNOBJE 203 VFYKEYATR 252 WRKCPYSTS 226 WRKDG 54 WRKDGACT 185 WRKDGACTE 186 WRKDGFE 170 WRKDGIFSTE 180 WRKDGOBJTE 180 WRKDGTSP 254 WRKMMXSTS 50, 125 WRKMSGLOG 168 WRKNFY 120 WRKRJLNK 228, 230 commands, by name Change Data Group 233

317

Check Data Group File Entries 246, 263 Check Data group File Entry 106 Create Data Group Timestamps 254 Delete DG Timestamps 256 Display Data Group Status 64 Display Data Group Timestamps 256 Display MIMIX Message Queue 167 Display RJ Link 227 End Data Group 131, 141 End Journal Physical File 196 End Journaling File Entry 196 End Journaling IFS Entries 199 End Journaling Obj Entries 202 End Lakeview TCP Server 223 End MIMIX 131, 141, 147 End MIMIX Managers 165 End RJ Link 237 Hold Data Group Log 257 MIMIX 42 MIMIX Availability Status 50 Release Data Group Log 257 Run Rule 80, 115 Run Rule Group 80, 115 Start Data Group 131, 133, 135 Start Journaling File Entry 195 Start Journaling IFS Entries 198 Start Journaling Obj Entries 201 Start Lakeview TCP Server 222 Start MIMIX 131, 133, 147 Start MIMIX Managers 165 Start RJ Link 237 Switch Data Group 217, 219 Verify Communications Link 244, 245 Verify Journaling File Entry 197 Verify Journaling IFS Entries 200 Verify Journaling Obj Entries 203 Verify Key Attributes 252 Work with Copy Status 226 Work with Data Group Activity 185 Work with Data Groups 54 Work with DG Activity Entries 186 Work with DG File Entries 170 Work with DG IFS Tracking Ent. 180 Work with DG Obj Tracking Ent. 180 Work with DG Timestamps 254 Work with Message Log 168 Work with MIMIX Availability Status 125 Work with Notifications 120 Work with RJ Links 228, 230 commit cycles

effect on audit comparison 265, 267 commit cycles, open checking for 139 checking for after a controlled end 153 effect on clear pend start 137 prevent a clear pending STRDG 139 preventing problems with 144 communications ending TCP sever 223 starting TCP sever 222 compare phase 19 compliance audit 98 concept 19 switch 215 switch, policies for 208, 209 compliance status audit 85 switch 215 concepts auditing 19 MIMIX 15 MIMIX AutoGuard 18 configuration audit after changing 106 determining data areas and data queues 235 determining, IFS objects 234 results of #DGFE audit after changing 263 constraints, CMPFILA file-specific attribute 273 contacting Vision Solutions 12 contention with applications, reducing 242 controlled end confirm end 153 description 143 procedure 152 wait time 144 copying active files 226 correcting file-level errors 176 record-level errors 177 CustomerCare 12

D
data areas and data queues determining configuration of 235 holding user journal entries for 182 resolving problems 180 tracking entries 179 verifying journaling 203

318

data group 15 activity details 61, 64 backlogs 76 controlled vs. immediate end 143 definition 16 determining if RJ link used 230 disabling 233 enabling 233 ending choices 141 ending considerations 146 ending controlled 152 ending immediately 151 ending selected processes 151 indication of disabled state 232 recovery point cleared 146 starting considerations 133, 135 starting selected processes 150 state, disabled or enabled 232 status from 5250 emulator 52 status from MIMIX Availability Manager 48 status, database view 71 status, detailed 61 status, merged view 65 status, object view 69 status, summary 54 switching 205, 217 system journal activity 61 timestamps 254 user journal activity 61 when to exclude from auditing 23 data group entry description 15 database apply (DBAPY) status 71 database error recovery, automatic 34 definition data group 16 journal 16 remote journal (RJ) link 16 system 16 transfer 16 delay intervals journal manager 164 system manager 164 delay/retry cycle, confirm object in a 189 differences, resolving audit 93, 95 disabled data group 232 displaying data group spooled file information 224 data group status details 61 long IFS object names 224

RJ link 227 RJ link status 228 status 48, 50

E
ending audit 91 MIMIX managers 164 MIMIXSBS subsystem 148 system and journal managers 165 TCP server 223 ending data group clears recovery point 146 considerations when ending 146 controlled end 152 controlled end wait time 144 controlled vs. immediate 143 how to confirm end 153 immediate end 151 processes 144 processes, effect of 159 processes, specifying selected 151 when to end RJ link 144 ending journaling data areas and data queues 202 files 196 IFS objects 199 IFS tracking entry 199 object tracking entry 202 ending MIMIX 147 considerations 141 controlled vs. immediate 143 end subsystem, when to also 148 follow up after 148 included processes 142 using default values 147 using specified values 148 when to end RJ link 144 ending replication 131 choices and considerations 141 controlled vs. immediate 143 ending RJ link independently from data group 237 when to end 144 Enterprise View 45 errors file level 176 record level 177 system journal replicated objects 185

319

target journal of RJ link 251 user journal replicated objects 170, 179

I
i5/OS upgrade 303 IFS objects determining configuration 234 file IDs (FIDs) 236 hold user journal entries for 182 path names 224 resolving problems 180 tracking entries for 179 verifying journaling 200 immediate end description 143 incomplete tracking entry 143 information and additional resources 11 installation, status of from 5250 emulator 50 from MIMIX Availability Manager 48 IPL 302

F
file file-level errors 176 hold journal entries 174 new 192 not journaled 57 record-level errors 177 replicated 170 file identifiers (FIDs) 236 file in error examine held journal entries 173 resolving 170 file on hold release and apply held entries 176 release and clear entries 176 release at synchronization point 175

J G
guidelines for auditing 81 job log for audit 96 journal 17 journal at create requirements 192 requirements and restrictions 193 journal cache or state resolving problems 57 status 72 journal definition 16 defined to RJ Link 231 journal entry description 17 unconfirmed 249 journal manager 16 delay intervals 164 ending 164, 165 resolving problems 164 starting 164 journal receiver 17 journaling 17 cannot end 196 data group problem with 56 ending for data areas and data queues 202 ending for IFS objects 199 ending for physical files 196 implicitly started 192 requirements for starting 192 starting for data areas and data queues 201

H
hardware upgrade MIMIX-specific steps 311 no disk image change 310 prerequisites 311 with a disk image change 313 held error (*HLDERR) file entry 170 preferred action for entry 171, 181 tracking entry 179 help, accessing 9 history log, removing completed entries 190 hold (*HLD) preferred action for held entry 171, 181 put file entry on hold 174 put tracking entry on hold 182 release a held file entry 176 release a held tracking entry 183 hold ignore (*HLDIGN) preferred action for ignored entry 171, 181 put file entry on hold ignore 174 put tracking entry on hold ignore 182 hold related (*HLDRLTD) 171 hot backup 13

320

starting for IFS objects 198 starting for physical files 195 starting, ending, and verifying 191 verifying for data areas and data queues 203 verifying for IFS objects 200 verifying for physical files 197 journaling status data areas and data queues 201 files 195 IFS objects 198

K
keyed replication verifying file attributes 252

L
last audit performed 98 last switch performed 215 log space 17 logging in, first time 37 long IFS path names 224

policy default 31 MIMIX rules 19, 80 automatic audit recovery 82 command prompting 83 replacement variables 83 MIMIX subsystem (MIMIXSBS) starting 147 when to end 148 MIMIX Switch Assistant 16 best practice 205 getting started 21 setting default switch framework 208 setting switch compliance policies 208 using 212 MMNFYNEWE monitor 124 monitor for newly created objects 124 mxpswtichLiteLastperform 215 mxpswtichLiteSwtCmply 216

N
names, displaying long 224 navigation bar status 46 network system 17 new hardware upgrade 313 prerequisites 313 new objects IFS object journal at create requirements 192 journal at create selection criteria 193 newly created objects, notification of 124 notifications definition 19, 119 displaying 120, 125 new problems in installation 54 severity level 20, 121 status 121

M
management system 17 manager journal 16 system 16 menu MIMIX Main 42 message queue, primary and secondary 167 messages ENDMMX 149 STRMMX 149 MIMIX AutoGuard 15 automatic recovery 18 getting started 20 introduction 18 MIMIX Availability Manager 15 benefits 44 monitoring status with 48 MIMIX CDP feature exclude from audit 23 recovery point cleared 146 MIMIX installation 15 MIMIX managers ending 164 resolving problems 164 starting 164 MIMIX Model Switch Framework 16, 205

O
object auditing concept 17 setting level with STRDG 140 used for replication 192 object error recovery, automatic 35 objects configuration of non-file 234 displaying long IFS names 224 displaying objects in error 67 displaying objects with active entries 67 in error, resolving 185 new 192

321

reducing contention 242 tracking entries for data areas and data queues 179 open commit cycles audit results 265, 267 effect on clear pend start 139 prevent a clear pend start 137 prevent problems with 144 resolving before clearing entries 140 shown in status 153 operations common, where to start 44 less common 221 orphaned recoveries 128 outfiles user profile password 300 user profile status 297 output file fields Difference Indicator 265, 269 System 1 Indicator field 271 System 2 Indicator field 271

P
path names, IFS 224 planned switch 205 policies 19 changing values 24 considerations when choosing values 22 for auditing 109 for automatic recovery during replication 33 for switching 208 introduction 22 policy action for running audits 30 audit action threshold 29 audit level 29 audit notify on success 27 audit rule 27 audit schedule 32 audit warning threshold 28 automatic audit recovery 27 automatic system journal recovery 27 automatic user journal recovery 27 CMPRCDCNT commit threshold 31 data group definition 27 default model switch framework 31 independent ASP library ratio 31 journaling attribute difference action 28 maximum rule runtime 28

notification severity 27 object only on target 28 run rule on system 30 switch action threshold 31 switch warning threshold 31 synchronize threshold size 30 system journal recovery success 27 third delay retry interval 30 third delay retry interval, number of 30 user journal apply threshold 28 user journal recovery success 27 problems reporting a problem 241 troubleshoot 239 where to start 239 problems, journaling data areas and data queues 201 files 195 IFS objects 198 problems, resolving audit results 93, 95, 263 common errors 163 data group cannot end 243 data group cannot start 248 files in error 170 files not journaled 57 journal cache or state 57 objects in error 185 open commits when starting data group 140 RJ link cannot end 249 RJ link cannot start 249 switch compliance 216 tracking entries 179 production system 16 publications, IBM 11

Q
QDFTJRN data area restrictions 193 role in processing new objects 193 QSTRUPPGM system value 303, 305

R
recommendations audit automatic recovery 82 auditing 81 audits and rules 82 before planned switch 206 policies in bi-directional environment 22

322

recoveries active in installation 54 definition 19, 120 detected database errors 34 displaying details 125 occurring in installation 125 orphaned 128 orphaned, identifying 128 orphaned. removing 129 recovery phase 20 recovery point cleared by ENDDG 146 release (*RLS) held file entry 176 held tracking entry 183 release clear (*RLSCLR) file entry 176 tracking entry 184 release wait (*RLSWAIT) file entry 175 tracking entry 183 remote journal (RJ) link 16 remote journal environment processes ended by ENDDG 159 processes started by STRDG 155 unconfirmed journal entry 249 removing activity history entries 190 duplicate tracking entries 184 unconfirmed entries 249 reorganizing, active files 226 replacement variables 83 replication automatic error recovery 33 backlogs, identifying 76 choices when ending 141 choices when starting 133 direction of 17 ending 131 resolve replication errors 163 starting 131 status from 5250 emulator 52 status from MIMIX Availability Manager 48 supported paths 13 switching 204 system journal 13 user journal 13 replication path 15 replication, problems troubleshoot 239

where to start 163 requirements audits 81 journal at create 192 journaling 192 MIMIX AutoGuard 81 resolving problems common replication errors 163 troubleshooting 239 restore MIMIX prerequisites 314 restrictions journal at create 193 QDFTJRN data area 193 results user-defined rules 118 retry objects in error 188 retrying, data group activity entries 188 RJ link 16 displaying 227 ending independently 237 errors for target journal of 251 identifying data groups that use 230 journal definitions by an 231 operating without a data group 237 removing unconfirmed entries 249 status 228 when to end 145 rule #DGFE 104 #DLOATR 105 #FILATR 104 #FILATRMBR 105 #FILDTA 105 #IFSATR 105 #OBJATR 104 user-defined, results of 118 rules 80 advantages of using 18 business 18 considerations for using 82 messages from 84 MIMIX 19, 80 notifications from 84 relationship with rules 80 replacement variables 83 requirements 81 run command considerations 83 run on management system 83 types 80

323

rules, MIMIX descriptions 104 running audits immediately 91 rule groups 115 rules 115

S
schedule audit considerations 105 automatic audit 104 default audit 104 schedule, shipped audit 104 servers ending TCP 223 starting TCP 222 services status from 5250 emulator 53 status from MIMIX Availability Manager 49 severity level, notification 121 source system 17 spooled files, displaying MIMIX-created 224 starting MIMIX managers 164 RJ link independently 237 system and journal managers 164 TCP server 222 starting data group at specified journal location 135 considerations 133, 135 prevented when open commit cycles 137, 139 procedure 150 processes, effect of 155 set object auditing level 140 when to clear entries 136 starting journaling data areas and data queues 201 file entry 195 files 195 IFS objects 198 IFS tracking entry 198 object tracking entry 201 starting MIMIX considerations 133 included processes 133 procedure 147 starting replication 131 choices and considerations 133

status active file operations 226 audit compliance 100 audit runtime and compliance 85 audits 87, 90 audits (runtime) 48, 52 checking from 5250 emulator 50 checking from MIMIX Availability Manager 48 data group detail 61, 64 data group summary 48, 52 database apply (DBAPY) 71 enterprise view 45 installation summary 50 introduction 45 journal cache or state 72 journaling data areas and data queues 201 journaling files 195 journaling IFS objects 198 journaling tracking entries 198, 201 notification 121 notification new in installation 52 recoveries active in installation 125 replication 48, 52 RJ link 228 services 49, 53 switch compliance 215 switching 59, 212 Work with Data Groups display 54 subsystem, MIMIXSBS ended 177 ending 148 starting 147 Switch Assistant, MIMIX 16, 212 getting started 21 switch framework disable policy when not used 210 specify a default 208 switching 204 best practice 20, 204, 205, 215 change audit level before 82, 210 compliance 215 conditions that end 219 description, planned switch 205 description, unplanned switch 206 getting started with MIMIX Switch Assistant 21 journal analysis after unplanned switch 258 last switch field 215 phases of a 205 policies for 208

324

problems checking compliance 216 reasons for 205 setting switch compliance policies 208, 209 setting switch framework policy 208 switch framework vs. SWTDG command 205 SWTDG command details 219 unplanned, actions to complete an 207 using MIMIX Switch Assistant 212 using option on MIMIX Basic Main Menu 212 using STRDG command 217 synchronize file entry 171 objects, system journal replicated 187 tracking entries 182 system definition 16 system journal replication 13 detailed status 61, 69 errors automatically recovered 34 journaling requirements 192 system manager 16 delay intervals 164 ending 164, 165 resolving problems 164 starting 164 system roles management or network 17 production or backup 16 source or target 17

working with active file operations 226 tracking entry 15 file identifiers (FIDs) 236 IFS 179 incomplete 143 not journaled 57 object 179 removing duplicate 184 transfer definition 16

U
unconfirmed journal entries, removing 249 unplanned switch 206 performing journal analysis 258 unprocessed entries 153 upgrade hardware, no disk image change 310 hardware, with a disk image change 313 new hardware 313 OS/400 303 user journal replication 13 detailed status 61, 71 errors automatically recovered 33 journaling requirements 192 non-file objects 234 tracking entries 179 tracking entry 15 user profile password 300 status 297

T
target system 17 threshold audit action 29 audit warning 28 CMPRCDCNT open commit 31 switch action 31 switch warning 31 synchronize size 30 user journal apply 28 timestamps 254 automatically created 254 creating additional 254 deleting 256 displaying 256 printing 256 tips displaying data group spooled files 224 displaying long IFS object names 224 removing journaled changes 257

V
verifying communications link 244, 245 journaling, IFS tracking entries 200 journaling, object tracking entries 203 journaling, physical files 197 key attributes 252 viewing status, active file operations 226

W
wait time, data group controlled end 144 wait time, data group controlled end during switch 219 windows, layout for 37

325