Using Mimix

MIMIX ha1™ and MIMIX ha Lite™ for IBM® i

Version 6.0

Using MIMIX

Published: December 2009 level 6.0.15.00

Copyrights, Trademarks, and Notices

Product conventions.................................................................................................... 9Menus and commands .......................................................................................... 9Accessing online help............................................................................................ 9

Publication conventions............................................................................................... 9Formatting for displays and commands .............................................................. 10

Sources for additional information............................................................................. 11How to contact us...................................................................................................... 12

Chapter 1 MIMIX overview 13MIMIX concepts......................................................................................................... 15MIMIX AutoGuard overview ...................................................................................... 18

Key concepts for MIMIX AutoGuard.................................................................... 18Auditing overview ................................................................................................ 19What are MIMIX AutoGuard best practices?....................................................... 20How do I get started with MIMIX AutoGuard? ..................................................... 20

New MIMIX installations ................................................................................ 21MIMIX policies ........................................................................................................... 22

Considerations when choosing policy values...................................................... 22When not to use MIMIX AutoGuard .................................................................... 23Setting policies - general ..................................................................................... 24

To change existing installation policies ......................................................... 24To change policies for a data group .............................................................. 25To reset a data group-level policy to use the installation level value............. 25

Disabling MIMIX AutoGuard for data groups using the MIMIX CDP feature ....... 26Policy descriptions............................................................................................... 27

Policies for recovery during replication...................................................................... 33Errors handled by automatic database recovery ................................................. 33Errors handled by automatic object recovery ...................................................... 34

Logging in to MIMIX Availability Manager ................................................................. 37Your location is remembered .............................................................................. 37

Areas of the window in MIMIX Availability Manager.................................................. 37Additional navigation and selection aids ............................................................. 39Other useful tips .................................................................................................. 41

Accessing the MIMIX Main Menu from a 5250 emulator........................................... 42

Chapter 2 Working with status 44Becoming acquainted with status.............................................................................. 45

Status in MIMIX Availability Manager.................................................................. 45The Enterprise View - your status shortcut.................................................... 45Status on the navigation bar.......................................................................... 46

Monitoring status with MIMIX Availability Manager ................................................... 48Checking replication status with MIMIX Availability Manager.............................. 48Checking audit status with MIMIX Availability Manager ...................................... 48Checking status of supporting services with MIMIX Availability Manager ........... 49

Monitoring status with MIMIX Availability Status ....................................................... 50Checking replication status - 5250 emulator ....................................................... 52Checking audit and notification status - 5250 emulator....................................... 52Checking for status of supporting services - 5250 emulator ............................... 53

The Work with Data Groups display - 5250 emulator................................................ 54Problems reflected in the Audits/Recov./Notif. field ............................................ 56

2

Problems reflected in the Data Group column .................................................... 56Resolving problems highlighted in the Data Group column........................... 57

Replication problems reflected in the Source and Target columns ..................... 59Setting the automatic refresh interval .................................................................. 60

Working with the detailed status of data groups........................................................ 61Displaying data group detailed status with MIMIX Availability Manager.............. 61

Variations of the Data Group Details - Activity window ................................. 64Displaying data group detailed status from a 5250 emulator .............................. 64

Merged view .................................................................................................. 65Object detailed status views .......................................................................... 69Database detailed status views ..................................................................... 71

Identifying replication processes with backlogs......................................................... 76

Chapter 3 Working with audits and rules 79What are rules and how they are used by auditing ................................................... 80Requirements for using audits and rules................................................................... 81Guidelines and recommendations for auditing .......................................................... 81

Considerations and recommendations for rules.................................................. 82Replacement variables .................................................................................. 83Rule-generated messages and notifications ................................................. 84

Where audit status and compliance status is reported.............................................. 85Working with audits ................................................................................................... 87

Displaying audit status ........................................................................................ 90Running audits immediately ................................................................................ 91Ending audits....................................................................................................... 91Displaying audit level differences ........................................................................ 92Resolving audit problems - MIMIX Availability Manager ..................................... 93Resolving audit problems - 5250 emulator .......................................................... 95Checking the job log of an audit .......................................................................... 96

Working with audit compliance.................................................................................. 98Determining whether auditing is within compliance........................................... 100

Working with audit schedules.................................................................................. 102How audits are scheduled automatically ........................................................... 104Shipped default audit schedules ....................................................................... 104Considerations for changing audit scheduling................................................... 105

When to run the #DGFE audit ..................................................................... 106Changing when audits are scheduled ............................................................... 106

Schedule parameter notes .......................................................................... 107Changing the system where audits are performed............................................ 108Considerations for using a different job scheduler for audits ............................ 108

Policies for auditing ................................................................................................. 109Preventing audits from running ......................................................................... 110

To restrict audit activity in an installation based on data group state .......... 110To restrict audit activity for a specific data group based on its state ........... 111To disable auditing for an installation .......................................................... 112To disable auditing for a data group ............................................................ 113To disable automatic scheduling of an audit ............................................... 113

Running rules and rule groups manually................................................................. 115Running rules or rule groups from within MIMIX Availability Manager .............. 115

Running rules or rule groups from the Rules window.................................. 115

3

Running rules or rule groups from the Data Groups window....................... 116Running rules from the 5250 emulator .............................................................. 116Running rule groups from the 5250 emulator .................................................... 117

Checking results of a user-defined rule................................................................... 118

Chapter 4 Working with notifications and recoveries 119What are notifications and recoveries ..................................................................... 119Displaying notifications............................................................................................ 120

What information is available for notifications ................................................... 121Detailed information..................................................................................... 122

Options for working with notifications ................................................................ 122Notifications for newly created objects .................................................................... 124Displaying recoveries .............................................................................................. 125

What information is available for recoveries...................................................... 126Detailed information..................................................................................... 127

Options for working with recoveries .................................................................. 127Orphaned recoveries......................................................................................... 128

Determining whether a recovery is orphaned.............................................. 128Removing an orphaned recovery ................................................................ 129

Chapter 5 Starting and ending replication 131Choices when starting replication............................................................................ 133

What is started with the STRMMX command.................................................... 133Considerations for starting data groups .................................................................. 135

When to clear pending entries and entries in error ........................................... 136Clear pending and clear error processing ................................................... 136

Clearing pending entries when open commit cycles exist ................................. 139Checking for open commit cycles................................................................ 139Resolving open commit cycles to enable a clear pending start................... 140

Setting the audit level when starting a data group ............................................ 140Choices when ending replication............................................................................. 141

What is ended by the ENDMMX command....................................................... 142Ending immediately or controlled ...................................................................... 143

Controlling how long to wait for a controlled end to complete ..................... 144Ending all or selected processes....................................................................... 144When to end the RJ link .................................................................................... 144

Considerations for ending data groups ................................................................... 146Starting MIMIX......................................................................................................... 147Ending MIMIX.......................................................................................................... 147

Ending with default values................................................................................. 147Ending by prompting the ENDMMX command.................................................. 148After you end MIMIX products........................................................................... 148

STRMMX and ENDMMX messages ....................................................................... 149Starting selected data group processes .................................................................. 150Ending selected data group processes ................................................................... 151Ending a data group in a controlled manner ........................................................... 152

Preparing for a controlled end of a data group.................................................. 152Performing the controlled end ........................................................................... 152Confirming the end request completed without problems ................................. 153

What replication processes are started by the STRDG command.......................... 155

4

What replication processes are ended by the ENDDG command .......................... 159

Chapter 6 Resolving common replication problems 163Working with MIMIX managers ............................................................................... 164

Resolving status problems with system and journal managers......................... 164Starting a system manager or a journal manager ............................................. 165Ending a system manager or a journal manager .............................................. 165

Working with message queues ............................................................................... 167Working with the message log ................................................................................ 168Working with user journal replicated files ................................................................ 170

Working with files in error .................................................................................. 170Working with journal transactions for files in error....................................... 173

Placing a file on hold ......................................................................................... 174Ignoring a held file ............................................................................................. 174Releasing a held file at a synchronization point ................................................ 175Releasing a held file .......................................................................................... 176Releasing a held file and clearing entries.......................................................... 176Correcting file-level errors ................................................................................. 176Correcting record-level errors............................................................................ 177

Record written in error ................................................................................. 177Working with tracking entries .................................................................................. 179

Working with tracking entries from MIMIX Availability Manager........................ 179Accessing the Data Group Details - Activity window................................... 179

Working with tracking entries from a 5250 emulator ......................................... 180Accessing the appropriate tracking entry display ........................................ 180Holding journal entries associated with a tracking entry.............................. 182Ignoring journal entries associated with a tracking entry............................. 182Waiting to synchronize and release held journal entries for a tracking entry ....183Releasing held journal entries for a tracking entry ...................................... 183Releasing and clearing held journal entries for a tracking entry.................. 184Removing a tracking entry........................................................................... 184

Working with objects in error ................................................................................... 185Using the Work with DG Activity Entries display ............................................... 186Retrying data group activity entries ................................................................... 188

Retrying a failed data group activity entry ................................................... 188Determining whether an activity entry is in a delay/retry cycle .......................... 189

Removing data group activity history entries........................................................... 190

Chapter 7 Starting, ending, and verifying journaling 191What objects need to be journaled.......................................................................... 192

Authority requirements for starting journaling.................................................... 193MIMIX commands for starting journaling................................................................. 194Journaling for physical files ..................................................................................... 195

Displaying journaling status for physical files .................................................... 195Starting journaling for physical files................................................................... 195Ending journaling for physical files .................................................................... 196Verifying journaling for physical files ................................................................. 197

Journaling for IFS objects........................................................................................ 198Displaying journaling status for IFS objects ...................................................... 198

5

Starting journaling for IFS objects ..................................................................... 198Ending journaling for IFS objects ...................................................................... 199Verifying journaling for IFS objects.................................................................... 200

Journaling for data areas and data queues............................................................. 201Displaying journaling status for data areas and data queues............................ 201Starting journaling for data areas and data queues .......................................... 201Ending journaling for data areas and data queues............................................ 202Verifying journaling for data areas and data queues......................................... 203

Chapter 8 Switching 204About switching ....................................................................................................... 204

MIMIX Model Switch Framework....................................................................... 205Planned Switch.................................................................................................. 205Unplanned switch .............................................................................................. 206Setting policies for switching ............................................................................. 208

Specifying a default switch framework in policies........................................ 208Setting polices for MIMIX Switch Assistant ................................................. 208Setting policies for switch compliance for a specific data group.................. 209Setting policies when MIMIX Switch Assistant is not used.......................... 210

Changing the audit level policy for switching..................................................... 210Switching using MIMIX Switch Assistant................................................................. 212Switching from the MIMIX Basic Main Menu........................................................... 212

Switching to the backup system ........................................................................ 213Synchronizing data and starting MIMIX on the original production system....... 214Switching to the production system................................................................... 214

Determining when the last switch was performed ................................................... 215Checking the last switch dates from MIMIX Availability Manager ..................... 215Checking the last switch date from a 5250 emulator......................................... 216

Problems checking switch compliance.................................................................... 216Performing a data group switch............................................................................... 217

Performing a data group switch from MIMIX Availability Manager .................... 217Performing a data group switch from a 5250 emulator ..................................... 217

Switch Data Group (SWTDG) command................................................................. 219

Chapter 9 Less common operations 221Starting the TCP/IP server ...................................................................................... 222Ending the TCP/IP server........................................................................................ 223Working with objects ............................................................................................... 224

Displaying long object names............................................................................ 224Considerations for working with long IFS path names ................................ 224

Displaying data group spooled file information.................................................. 224Viewing status for active file operations .................................................................. 226Displaying a remote journal link .............................................................................. 227Displaying status of a remote journal link................................................................ 228Identifying data groups that use an RJ link ............................................................. 230Identifying journal definitions used with RJ ............................................................. 231Disabling and enabling data groups ........................................................................ 232

Procedures for disabling and enabling data groups .......................................... 233Determining if non-file objects are configured for user journal replication............... 234

Determining how IFS objects are configured .................................................... 234

6

Determining how data areas or data queues are configured ............................ 235Using file identifiers (FIDs) for IFS objects .............................................................. 236Operating a remote journal link independently........................................................ 237

Starting a remote journal link independently ..................................................... 237Ending a remote journal link independently ...................................................... 237

Chapter 10 Troubleshooting - where to start 239Gathering information before reporting a problem .................................................. 241

Obtaining MIMIX and IBM i information from your system ................................ 241Reducing contention between MIMIX and user applications................................... 242Data groups cannot be ended ................................................................................. 243Verifying a communications link for system definitions ........................................... 244Verifying the communications link for a data group................................................. 245

Verifying all communications links..................................................................... 245Checking file entry configuration manually.............................................................. 246Data groups cannot be started ................................................................................ 248Cannot start or end an RJ link................................................................................. 249

Removing unconfirmed entries to free an RJ link.............................................. 249RJ link active but data not transferring .................................................................... 250Errors using target journal defined by RJ link.......................................................... 251Verifying data group file entries............................................................................... 252Verifying data group data area entries .................................................................... 252Verifying key attributes ............................................................................................ 252Working with data group timestamps ...................................................................... 254

Automatically creating timestamps.................................................................... 254Creating additional timestamps ......................................................................... 254Creating timestamps for remote journaling processing ..................................... 255Deleting timestamps.......................................................................................... 256Displaying or printing timestamps ..................................................................... 256

Removing journaled changes.................................................................................. 257Performing journal analysis ..................................................................................... 258

Removing journal analysis entries for a selected file ........................................ 260

Appendix A Interpreting audit results - supporting information 262Interpreting results for configuration data - #DGFE audit........................................ 263Interpreting results of audits for record counts and file data ................................... 265

What differences were detected by #FILDTA.................................................... 265What differences were detected by #MBRRCDCNT......................................... 267

Interpreting results of audits that compare attributes .............................................. 268What attribute differences were detected.......................................................... 269Where was the difference detected................................................................... 271What attributes were compared ........................................................................ 272Attributes compared and expected results - #FILATR, #FILATRMBR audits.... 273Attributes compared and expected results - #OBJATR audit ............................ 278Attributes compared and expected results - #IFSATR audit ............................. 286Attributes compared and expected results - #DLOATR audit ........................... 288Comparison results for journal status and other journal attributes .................... 290

How configured journaling settings are determined .................................... 293Comparison results for auxiliary storage pool ID (*ASP)................................... 294Comparison results for user profile status (*USRPRFSTS) .............................. 297

7

How configured user profile status is determined........................................ 298Comparison results for user profile password (*PRFPWDIND)......................... 300

Appendix B IBM Power™ Systems operations that affect MIMIX 302MIMIX procedures when performing an initial program load (IPL) .......................... 302MIMIX procedures when performing an operating system upgrade........................ 303

Prerequisites for performing an OS upgrade on either system ......................... 304MIMIX-specific steps for an OS upgrade on the backup system....................... 305MIMIX-specific steps for an OS upgrade on the production system with switching

307MIMIX-specific steps for an OS upgrade on the production system without switch-

ing............................................................................................................................ 308MIMIX 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..... 311Hardware upgrade without a disk image change - preliminary steps .......... 311Hardware 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..................................................................................................................... 313Handling MIMIX during a system restore ................................................................ 314

Prerequisites for performing a restore of MIMIX ............................................... 314

Index 316

8

Product conventions

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

Menus and commandsFunctionality 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 helpMIMIX 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 conventionsThis 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.

9

Formatting for displays and commandsTable 1 shows the formatting used for the information you see on displays and command interfaces:

Table 1. Formatting examples for displays and commands

Convention Description Examples

InitialCapitalization

Names of menus or displays, commands, keyboard keys, columns. (Column names are also shown in italic).

MIMIX Basic Main Menu Update Access Code command Page Up key

Italic Names of columns, prompts on displays, variables, user-defined values

The Status column The Start processes prompt The library-name value

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

CHGUPSCFG command WARNMSG parameter The value *YES

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.

Type the command MIMIX and press Enter. DGDFN(name system1 system2) CHGVAR &RETURN &CONTINUE

10

Sources for additional information

11

Sources for additional informationThis 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

http://publib.boulder.ibm.com/iseries/

http://publib.boulder.ibm.com/iseries/

12

How to contact usFor 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.

http://www.visionsolutions.com/Support/Support-Product-Index.aspx

http://www.visionsolutions.com/Support/Contact-CustomerCare.aspx

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 conceptsThe 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 overviewMIMIX® 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 AutoGuardAll 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 switch-readiness.

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 overviewMultiple 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 valuesPolicy 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 bi-directional 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 bi-directional 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 AutoGuardAt 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 - generalPolicies 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

http://portal.lakeviewtech.com/wps/myportal/suppbyprod?WCM_GLOBAL_CONTEXT=/wps/wcm/myconnect/LakeviewPortal/Support/Support%20By%20Product/MIMIX%20ha1/FAQs/

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




2. For the Data group definition, specify the full three-part name.


4. Specify a value for the policy you want defined for the data group. Use F1 (Help) to view descriptions of possible values.


To reset a data group-level policy to use the installation level valueFrom 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.






4. For the policy you want to reset, specify *INST.


25

Disabling MIMIX AutoGuard for data groups using the MIMIX CDP featureThe 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.




2. For the Data group definition, specify the full three-part name of the data group that uses the MIMIX CDP feature.


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.


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

26

Policy descriptionsThere 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 group-level 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 command’s 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 policy’s value. The shipped default for this policy of 1440 minutes (24 hours) prevents running multiple instances of the same MIMIX rule within the same day. Valid values are 60 minutes through 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 policy’s shipped default is to run audits from the management system. You can also set the policy to run audits from the network system, the source or target system, or from a list of system definitions. When both systems of a data group are in the specified list, the target system is used. While this policy is intended for audits, any rule that meets the same criteria will use this policy.

Action for running audits - Select a value for each 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 group’s 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 group’s 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 prod-uct.

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 replicationMIMIX AutoGuard™ can automatically attempt to correct problems it encounters during replication. Table 2 shows these policies and their shipped default values.

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.

Table 2. Policies associated with automatic recovery during replication, with shipped default values

Policy Shipped Values MIMIX AutoGuard

Installation Data Groups

Object Replication

Database Replication

Data group definition *INST Name1

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

Yes Yes

Automatic system journal recovery

*ENABLED *INST1 Yes2

2. When this policy is enabled, the other policies in the same column are in effect unless otherwise noted.

–

Automatic user journal recovery

*ENABLED *INST – Yes2

System journal recovery notify on success

*YES *INST Yes –

User journal recovery notify on success

*YES *INST – Yes

Synchronize threshold size 9,999,999 *INST Yes Yes

Number of third delay retry attempts

100 *INST Yes –

Third delay retry interval 15 *INST Yes –

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.

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.

Table 3. Errors detected and corrected during database replication when automatic database recovery is enabled.

Error Description

File level errors - and - Unique-key record level error

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.

Record level errors 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.

Errors on IFS objects configured for advanced journaling

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.

Errors on data area and data queue objects configured for advanced journaling

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.

Errors when DBAPY cannot open the file or apply transactions to the file

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.

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. Errors detected and recoveries attempted by object autonomics during object replication

Error Description

Missing objects on target system1

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.

Missing parent objects on target system1

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.

Missing *USRPRF objects on target system1

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.

Missing *AUTL objects on target system1

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.

35

In-use condition

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.

Table 4. Errors detected and recoveries attempted by object autonomics during object replication

Error Description

36

Logging in to MIMIX Availability Manager

Logging in to MIMIX Availability ManagerThe 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 rememberedOnce 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 high-level 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 aidsNavigation 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:

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

Status icons - overview

Status Description Action required An error occurred. Immediate user action is required.

Unknown Some or all status information is unavailable. Immediate user action is required.

Partially Active Processes are changing state or some processes are active while others are ended. User action may be required.

Ended All processes have ended normally due to a user request. User action is necessary to restart the processes.

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

Attention A warning condition exists that is either automatically correctable or is a non-critical condition. User action may be necessary.

Unknown The status is unknown because collector services is not active. User action is necessary to start collector services.

(No icon) Active Processes are active. Disabled The process has been disabled.

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 tipsActions 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 emulatorThe 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

Figure 4. MIMIX Intermediate Main Menu

MIMIX Basic Main Menu System: SYSTEM1 MIMIX Select one of the following: 1. Availability status WRKMMXSTS 2. Start MIMIX 3. End MIMIX 5. Start or complete switch 11. Configuration menu 12. Work with monitors WRKMON 13. Work with messages WRKMSGLOG 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.

MIMIX Intermediate Main Menu System: SYSTEM1 MIMIX Select one of the following: 1. Work with data groups WRKDG 2. Work with systems WRKSYS 3. Work with messages WRKMSGLOG 4. Work with monitors 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

44

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.

Becoming acquainted with status

Becoming acquainted with statusYou 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 ManagerMIMIX 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 window—all 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 ManagerMIMIX 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 ManagerThe 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 ManagerThe 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 ManagerThe 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.


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.


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


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.


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 emulatorFrom 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 high-lighting 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.

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

Work with Data Groups 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-------- -Errors- Opt 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 Bottom F3=Exit F5=Refresh F7=Audits F8=Recoveries F9=Automatic refresh F10=Legend F13=Repeat F16=DG definitions F23=More options F23=More keys

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. fieldWhen 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 columnWhen a data group name is highlighted in color, journaling problems exist that affect replication of one or more types of data.

Table 5. Conditions which highlight the data group name in color.

Color Possible Problems

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

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

56


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:

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)

Jrn State and Cache Src: v v Tgt: v v

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.


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.


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


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.

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

Table 6. Possible status values for source and target process summaries

I Inactive (highlighted red) – The process is currently not active.

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

A Active (highlighted blue) – The process is currently active. For the database source column, this value indicates that the send/receive processes are active.

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

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

U Unknown (highlighted white) – The status of the process cannot be determined possibly because of an error or communications problem.

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

T 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

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

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

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

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

59

Setting the automatic refresh intervalYou 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 groupsMIMIX 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 ManagerWhen 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


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 windowThe 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 emulatorThe 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


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

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 (left-most) are omitted. Truncated journal sequence numbers are prefixed by '>'. This is shown in Figure 14.

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 F7=Object view F8=Database F9=Automatic refresh F10=Restart statistics F12=Cancel F14=Start DG F15=End DG

Table 7. Possible values for detailed status. Not all statuses are used by each process.

Color and Status

Description

Red When displayed on the Data group, Database errors, or Objects in error fields, a problem exists that requires action.

Red - I The process is inactive.

Red - W The process is suspended at a recovery point. This status is only available for apply processes.

Yellow When displayed on the Data group field, a problem exists that may require attention.

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

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

White - U The status of the process is unknown

66


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

Blue - A The process is active.

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

Green - D The data group is disabled. This also means the data group is currently inactive.

Table 7. Possible values for detailed status. Not all statuses are used by each process.

Color and Status

Description

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


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 viewsFigure 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 view’s 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 (left-most) 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 System: CHICAGO 17:50:00 Data group . . . . : CRITICALAP Objects in error . . 4 Elapsed time . . . : 00:52:51 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 F7=Merged view F8=Database view F9=Automatic refresh F11=View 2 F12=Cancel F24=More keys

Data Group Object Status System: CHICAGO 17:57:31 Data group . . . . : CRITICALAP Objects in error . . 4 Elapsed time . . . : 00:52:51 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 F7=Merged view F8=Database view F9=Automatic refresh F11=View 3 F12=Cancel F24=More keys

70



Database detailed status viewsFigure 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 view’s 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

DG Object Journal Entry Detail System: CHICAGO 18:01:20 Data group . . . . : CRITICALAP Source system: LONDON-A Entry Sequence # Receiver Date Time Current entry TSF 10,022,314,732 AUDRCV0108 4/22/08 17:37:13 Last read entry - 10,022,175,464 AUDRCV0103 4/21/08 11:05:56 Last received - 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 F7=Merged view F8=Database view F9=Automatic refresh F11=View 1 F12=Cancel F24=More keys

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. Possible status values for Journal State fields

Field Color and Status

Description

Either system White U Unknown. MIMIX was not able to retrieve values, possibly because the journal environment has not yet been built.

No color A Journal state is active

No color X The required IBM feature, IBM i option 42 - High Availability Journal Performance, is not installed on this system

No color S Journal is in standby state as expected

Source Red S Source journal is in standby state but that state is not expected.

Red I Source journal in inactive state but that state is not expected.

Target Yellow S Target journal state or cache is not as expected and the database apply session is active

Yellow I Target journal state is inactive but that state is not expected.

blank blank The IBM feature is installed but the data group is configured to not journal on the target system.

72


Figure 18. Data group detail status—database 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

Table 9. Possible status values for Journal Cache fields

Field Color and Status

Description

White U Unknown. MIMIX was not able to retrieve values, possibly because the journal environment has not yet been built

Either System

No color X The required IBM feature, IBM i option 42 - High Availability Journal Performance, is not installed on this system

No color Y Caching is active

No color N Caching is not active.

Source Yellow Y Source journal cache value is not as expected.

Yellow N Source journal cache value is not as expected.

Target Yellow Y Target journal cache value not as expected and the database apply session is active.

Yellow N Target journal cache value not as expected and the database apply session is active.

blank blank The IBM feature is installed but the data group is configured to not journal on the target system.

73

numbers that are associated with *MAXOPT3 support.

Figure 19. Data group database status—view 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 dis-play also shows that journal standby state is active and journal caching is not active.

Data Group Database Status System: 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 F3=Exit F5=Refresh F7=Object view F8=Merged view F9=Automatic refresh F11=View 2 F12=Cancel F24=More keys

Data Group Database Status System: 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 F3=Exit F5=Refresh F7=Object view F8=Merged view F9=Automatic refresh F11=View 3 F12=Cancel F24=More keys

74


Figure 20. Data group database status, view 3.

Figure 21. Data group detail status—database view 4. In this example, the combined number of file and tracking entries shown in Figure 18 and Figure 19 are separated into separate col-umns for file entries, IFS tracking entries, and object tracking entries.

DG Database Jrn Entry Detail System: CHICAGO 18:16:04 Data group . . . . : CRITICALAP Source system: LONDON-A Entry Sequence # Receiver Date Time Current entry UMX 12,345,678,900,000,002,591 LONDN0002 4/20/08 11:02:35 RJ target entry UMX 12,345,678,900,000,002,591 LONDN0002 4/20/08 11:02:35 Last read entry UMX 12,345,678,900,000,002,591 LONDN0002 4/20/08 11:02:35 Last received - 12,345,678,900,000,002,590 - 4/20/08 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 F7=Object view F8=Merged view F9=Automatic refresh F11=View 1 F12=Cancel F24=More keys

File and Tracking Entry Status System: CHICAGO 16:07:03 Data group . . . . : CRITICALAP File IFS Trk Obj Trk Entries Entries Entries Number of entries . . . . : 7 3 2 Not journaled on source . : 1 0 0 Not journaled on target . : 0 1 0 Held due to error . . . . : 0 1 1 Held for other reasons . .: 0 0 0 F3=Exit F5=Refresh F7=Object view F8=Merged view F9=Automatic refresh F11=View 1 F12=Cancel F24=More keys

75

ying replication processes with backlogs

76

Identit has exceeded its backlog threshold will or condition with a higher priority status, roblem is resolved. Also, a backlog may y have been disabled (set to *NONE).

of data groups” on page 61.

is information and the appropriate fields

m the Details area of the navigation bar

te view.

Table 10. es

Process

Fields Highlighted when Thresh-old Exceeded

RJ Link the source system to the remote journal on acklog.

Not Sent 1

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

Identif

fying replication processes with backlogsIf replication processes are active and have no reported error conditions, a replication process thahave a status that reflects this condition. However, if a replication process is inactive or has an errthe threshold condition will not be visible in the process status until the process is started or the pexist but not be large enough to exceed the threshold setting, or the threshold warning setting ma

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

2. Locate the appropriate window or view for the process you want to check. Table 10 identifies thfor each process.

• In MIMIX Availability Manager, you may need to select User Journal or System Journal froto access the appropriate window.

• In a 5250 emulator, use F7 or F8 on the Data Group Status display to locate the appropria

Location of fields in each user interface which identify backlogs and threshold conditions for replication process

Description

User Interface

Window / View Fields to Check for Backlog

The backlog is the quantity of source journal entries that have not been transferred from the local journal on the target system. The time difference between the last entry in each journal can also be an indication of a b

MIMIX Availability Manager

Data Group Status Details -User Journal window

• Not Sent• Differences between transactions identified for

Source and Target.

5250 emulator

Merged view, Database views 1 and 2 Differences between journal entries identified by SoJrn and RJ Tgt jrn for the database link.


77

DB Readeor DB Sen

between the last entry that was read by the

arget Not Read 1

d

st

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

DB Apply as a separate entry with its own backlog.

Unprocessed Entries 2

• Apply Status • Unprocessed Entry Count

Object Send

rence between the last entry that was read

Not Processed 1

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

Table 10. es

Process


Identif

r d

The backlog is the quantity of journal entries that are waiting to be read by the process. The time difference process and the last entry in the journal on the source system can also be an indication of a backlog.



• Not Read• Differences between transactions identified for T

(or Current) and Last Read.

5250 emulator

Merged view, Database views 1 and 2 For remote journaling configurations, differences between journal entries identified by Source Jrn anLast read. For MIMIX source-send configurations, differences between journal entries identified by Current and LaRead.

The backlog is the number of entries waiting to be applied to the target system. Each apply session is listed



Unprocessed Entries

5250 emulator

Database views 1, 2, and 3 Unprocessed Entry Count

The backlog is the quantity of journal entries that have not been read from the system journal. The time diffeby the process and the last entry in the system journal can also be an indication of a backlog.


Data Group Status Details -System Journal window

• Not Processed • Differences between transactions identified for

Current and Last Read.

5250 emulator

Merged view, Object views 1, 2, and 3 Differences between transactions identified for ObjeCurrent and Last Read


Description

User Interface



78

Object Retrieve

Retrievers, Backlog column

• Retrievers, Act column• Retrieve Backlog

ContainerSend

Containers, Backlog column

• Senders, Act column• Container Send Backlog

Object Apply

Apply, Backlog column

• Applies, Act column• Apply Backlog

Notes: 1. When t or by entries and by how much.2. When old is exceeded.3. When h4. When h

Table 10. es

Process


Identif

The backlog is the number of entries for which MIMIX is waiting to retrieve objects.



Retrievers, Backlog column

5250 emulator

Object views 1 and 2 Retrieve Backlog

The backlog is the number of packaged objects for entries that are waiting to be sent to the target system.



Containers, Backlog column

5250 emulator

Object views 1 and 2 Container Send Backlog

The backlog is the number of entries waiting to be applied to the target system.



Apply, Backlog column

5250 emulator

Object views 1 and 2 Apply Backlog

he threshold is exceeded, the field also includes text which indicates whether the backlog was exceeded by timethe threshold is exceeded, the field also includes text which indicates the number of entries by which the threshighlighted, the threshold journal entry quantity criterion is exceeded.ighlighted the threshold time criterion is exceeded.


Description

User Interface


79

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.

80

What are rules and how they are used by auditingA 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. User-defined 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. User-defined 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.

Requirements for using audits and rules

Requirements for using audits and rulesTo 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 auditingTo 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 rulesThe following considerations apply to MIMIX rules used by audits as well as to user-defined 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

http://www.visionsolutions.com/Support/Support-Product-Index.aspx

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 variablesReplacement 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 notificationsFor 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 reportedAudit 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)

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

Work with Data Groups 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-------- -Errors- Opt 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 Bottom F3=Exit F5=Refresh F7=Audits F8=Recoveries F9=Automatic refresh F10=Legend F16=DG definitions F23=More options F24=More keys

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

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

Work with Audits System: AS01 Type options, press Enter 5=Display 6=Print 7=Notification 8=Recoveries 9=Run rule 10=End 36=Change DG policies 37=Change audit schedule 46=Mark recovered Audit ---------Definition--------- Object Opt Status Rule DG Name System 1 System 2 Differences __ *CMPACT #DLOATR EMP AS01 AS02 0 __ *CMPACT #FILATR EMP AS01 AS02 0 __ *CMPACT #FILATRMBR EMP AS01 AS02 0 __ *RCYACT #FILDTA EMP AS01 AS02 0 __ *QUEUED #IFSATR EMP AS01 AS02 0 __ *QUEUED #MBRRCDCNT EMP AS01 AS02 0 __ *NOTRUN #OBJATR EMP AS01 AS02 0 __ *NODIFF #DGFE EMP AS01 AS02 0 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

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

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)

Work with Audits System: AS01 Type options, press Enter 5=Display 6=Print 7=Notification 8=Recoveries 9=Run rule 10=End 36=Change DG policies 37=Change audit schedule 46=Mark recovered Audit ------Last Run------- Object Opt Status Rule DG Name Recovery Level Differences __ *CMPACT #DLOATR EMP *ENABLED *LEVEL30 0 __ *CMPACT #FILATR EMP *ENABLED *LEVEL30 0 __ *CMPACT #FILATRMBR EMP *ENABLED *LEVEL30 0 __ *RCYACT #FILDTA EMP *ENABLED *LEVEL30 0 __ *QUEUED #IFSATR EMP *ENABLED *LEVEL30 0 __ *QUEUED #MBRRCDCNT EMP *ENABLED *LEVEL30 0 __ *NOTRUN #OBJATR EMP *ENABLED *LEVEL30 0 __ *NODIFF #DGFE EMP *ENABLED *LEVEL30 0 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

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 immediatelyYou 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 auditsOnly 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. Addressing audit problems - MIMIX Availability Manager

State Results Action

Rule Failed (blank) 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.

Rule Failed User journal replication is not active

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 .

93

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

Completed Successfully

Differences detected, recovery disabled

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.

Completed Successfully

Differences detected, some objects not 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.

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.

Table 11. Addressing audit problems - MIMIX Availability Manager

State Results Action

94

Resolving audit problems - 5250 emulatorWhen 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. Addressing audit problems - 5250 emulator

Status Action

*FAILED 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

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 auditAn audit’s 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.

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

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

Table 12. Addressing audit problems - 5250 emulator

Status Action

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 . This choice is only available when viewing audits from the sending system.

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 complianceCompliance 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: AS01 Type options, press Enter 5=Display 6=Print 7=Notification 8=Recoveries 9=Run rule 10=End 36=Change DG policies 37=Change audit schedule ---------Definition--------- ---Compare End--- Opt Compliance Rule DB Name System 1 System 2 Date Time __ *OK #DGFE EMP AS01 AS02 09/25/08 12:15:34 __ *OK #DLOATR EMP AS01 AS02 09/25/08 12:15:34 __ *OK #FILATR EMP AS01 AS02 09/25/08 12:15:34 __ *OK #FILATRMBR EMP AS01 AS02 09/25/08 12:15:35 __ *OK #FILDTA EMP AS01 AS02 09/25/08 12:15:38 __ *OK #IFSATR EMP AS01 AS02 09/25/08 12:15:36 __ *OK #MBRRCDCNT EMP AS01 AS02 09/25/08 12:15:38 __ *OK #OBJATR EMP AS01 AS02 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.

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

Work with Audits System: AS01 Type options, press Enter 5=Display 6=Print 7=Notification 8=Recoveries 9=Run rule 10=End 36=Change DG policies 37=Change audit schedule -Scheduled Time-- ---Compare End--- Opt Compliance Rule DG Name Date Time Date Time __ *OK #DGFE EMP 09/26/08 02:00:00 09/25/08 12:15:34 __ *OK #DLOATR EMP 09/26/08 02:25:00 09/25/08 12:15:34 __ *OK #FILATR EMP 09/26/08 02:10:00 09/25/08 12:15:34 __ *OK #FILATRMBR EMP 09/26/08 02:20:00 09/25/08 12:15:35 __ *OK #FILDTA EMP 09/26/08 02:35:00 09/25/08 12:15:38 __ *OK #IFSATR EMP 09/26/08 02:15:00 09/25/08 12:15:36 __ *OK #MBRRCDCNT EMP 09/26/08 02:30:00 09/25/08 12:15:38 __ *OK #OBJATR EMP 09/26/08 02:05:00 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

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

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

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

Work with Audits System: AS01 Type options, press Enter 5=Display 6=Print 7=Notification 8=Recoveries 9=Run rule 10=End 36=Change DG policies 37=Change audit schedule ---------Definition--------- -Scheduled Time-- Opt Rule DG Name System 1 System 2 Frequency Date Time __ #DGFE EMP AS01 AS02 *WEEKLY 09/25/08 02:00:00 __ #DLOATR EMP AS01 AS02 *WEEKLY 09/25/08 02:25:00 __ #FILATR EMP AS01 AS02 *WEEKLY 09/25/08 02:10:00 __ #FILATRMBR EMP AS01 AS02 *WEEKLY 09/25/08 02:20:00 __ #FILDTA EMP AS01 AS02 *WEEKLY 09/25/08 02:35:00 __ #IFSATR EMP AS01 AS02 *WEEKLY 09/25/08 02:15:00 __ #MBRRCDCNT EMP AS01 AS02 *WEEKLY 09/25/08 02:30:00 __ #OBJATR EMP AS01 AS02 *WEEKLY 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

Work with Audits System: AS01 Type options, press Enter 5=Display 6=Print 7=Notification 8=Recoveries 9=Run rule 10=End 36=Change DG policies 37=Change audit schedule Weekday Rel.Day Opt Rule DG Name Frequency Date SMTWTFS 12345L Time __ #DGFE EMP *WEEKLY *NONE SMTWTFS 02:00:00 __ #DLOATR EMP *WEEKLY *NONE SMTWTFS 02:25:00 __ #FILATR EMP *WEEKLY *NONE SMTWTFS 02:10:00 __ #FILATRMBR EMP *WEEKLY *NONE SMTWTFS 02:20:00 __ #FILDTA EMP *WEEKLY *NONE SMTWTFS 02:35:00 __ #IFSATR EMP *WEEKLY *NONE SMTWTFS 02:15:00 __ #MBRRCDCNT EMP *WEEKLY *NONE SMTWTFS 02:30:00 __ #OBJATR EMP *WEEKLY *NONE SMTWTFS 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

103

How audits are scheduled automaticallyThe 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 schedulesA 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 rule’s 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 MIMIX rules and schedule for corresponding shipped audit monitor

Shipped Schedule

Rule Name Description Job Name

2:00 a.m. daily #DGFE Checks configuration for files using cooperative processing.Uses the Check Data Group File Entries (CHKDGFE) command.

sdn_DGFE

2:05 a.m. daily #OBJATR Compares all attributes for all object types supported for replication.Uses the Compare Object Attributes (CMPOBJA) command

sdn_OBJATR

2:10 a.m. daily #FILATR Compares all file attributes.Uses the Compare File Attributes (CMPFILA) command.

sdn_FILATR

104


Considerations for changing audit schedulingAudit 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.

2:15 a.m. daily #IFSATR Compares IFS attributes.Uses the Compare IFS Attributes (CMPIFSA) command.

sdn_IFSATR

2:20 a.m. daily #FILATRMBR Compares basic file attributes at the member level.Uses the Compare File Attributes (CMPFILA) command.

sdn_MBRATR

2:25 a.m. daily #DLOATR Compares all DLO attributes.Uses the Compare DLO Attributes (CMPDLOA) command.

sdn_DLOATR

2:30 a.m daily #MBRRCDCNT 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.

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.

Table 13. Shipped MIMIX rules and schedule for corresponding shipped audit monitor

Shipped Schedule

Rule Name Description Job Name

105

When to run the #DGFE auditIn 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 scheduledA change to an audit’s 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.



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.


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


Schedule parameter notesIn 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 performedNote: 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 auditsIf 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 auditingTable 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 installation-level 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. How policies correlate to function

Policy Shipped Values Auditing


Data group definition

*INST Name Yes

Audit rule

– Varies by rule Yes

Automatic audit recovery *ENABLED *INST Yes

Audit notify on success *RULE *INST Yes

Notification severity *RULE *INST Yes

Object only on target action *DISABLED *INST Yes

Journal attribute differences action1

• MIMIX configured higher• MIMIX configured lower

*CHGOBJ*NOCHG

*INST*INST

Yes

User journal apply threshold action *END *INST Yes

Maximum rule runtime 1440 *INST Yes

Audit warning threshold 7 *INST Yes2

Audit action threshold 14 *INST Yes2

Audit level *LEVEL30 *INST Yes

Run rule on system *MGT *INST Yes

Action for running audits1 • Inactive data group• Apply in threshold

*NONE*NONE

*INST*INST

Yes

Synchronize threshold size 9,999,999 *INST Yes

109

Preventing audits from runningScenarios 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

CMPRCDCNT commit threshold3 *NOMAX *INST Yes

Audit schedule Frequency Scheduled date Scheduled day Scheduled time Relative day of month

– *WEEKLY*NONE*ALLVaries by rule

Yes

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

Table 14. How policies correlate to function

Policy Shipped Values Auditing


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


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:


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


To restrict audit activity for a specific data group based on its stateFrom 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:


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.






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.


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.



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.


5. For Automatic audit recovery, select Disable.




112




4. Specify *DISABLED for the Audit level policy.


To disable auditing for a data groupFrom 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:




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.







4. Specify *DISABLED for the Audit level policy.


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:


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.





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.


114

Running rules and rule groups manually

Running rules and rule groups manuallyUser 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 ManagerFrom 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 windowUse 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 windowUse 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 emulatorThis 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 emulatorThis 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 ruleThese 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.


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 recoveriesA 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 notificationsYou 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 notificationsWhile 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 informationWhen 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 user-generated notifications, this information is available only if it was specified when the notification was added.

Options for working with notificationsTable 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

Notifications Window Action

WRKNFY Option Description

Delete 4=Remove 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.

Display Details 5=Display Displays available additional information associated with the notification.

6=Print Prints the information associated with the notification.Print support in MIMIX Availability Manager is provided by the browser.

Output File1 8=View results 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

Job Log1 12=Display job 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

122

Displaying notifications

Acknowledge 46=Acknowledge Sets the selected notification status to *ACK (Acknowledged).

Mark as New 47=Mark as new Sets the selected notification status to *NEW (New).

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

1. This action may also be available for a notification from the Notification Details window.2. 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-installa-tion-library_0.

Table 15. Options available for notifications

Notifications Window Action

WRKNFY Option Description

123

124

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.

Displaying recoveries

Displaying recoveriesActive 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

What information is available for recoveriesWhile 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).

Work with Data Groups 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-------- -Errors- Opt 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 Bottom F3=Exit F5=Refresh F7=Audits F8=Recoveries F9=Automatic refresh F10=Legend F16=DG definitions F23=More options F24=More keys

126


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 informationWhen 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 recoveriesTable 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

Recoveries Window Action

WRKRCY Option

Description

4=Remove 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.

Display Details 5=Display Displays available additional information associated with the recovery.

6=Print Prints the information associated with the recovery.Print support in MIMIX Availability Manager is provided by the browser.

Output File1 8=View progress 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.

127

Orphaned recoveriesThere 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 orphanedFrom MIMIX Availability Manager, do the following to determine whether a recovery is orphaned:


2. Verify that the system from which you are viewing recoveries is the system

End Recovery 10=End job 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.

Job Log1 12=Display job 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.

Hold Job 13=Hold job 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.

Release Job 14=Release job 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.

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

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

Table 16. Options available for recoveries

Recoveries Window Action

WRKRCY Option

Description

128


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:


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

Clear pending and clear error processingThe 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

Table 17. When to Reset a Data Group

Reason for Resetting Data Group Specify the following values on the STRDG command:

After synchronizing database files and objects between two systems.

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.

After switching the direction of the data group, when starting replication on the system that now becomes the source system.

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

After changing the Number of DB apply sessions (NBRDBAPY) parameter on the data group definition

Specify *YES for the Clear pending prompt.

136


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 and CLRERR processing

CLRPND CLRERR Processing Description Notes

*NO *NO Data groups start with regular processing: • Data group file entry status remains unchanged.• Hold logs remain unchanged.

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

*NO *YES • 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.

See File entry states See Log spaces

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

• 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

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

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

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

*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


Clearing pending entries when open commit cycles existOpen 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 cyclesFrom MIMIX Availability Manager, do the following to check for open commit cycles:


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.

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.



139

Resolving open commit cycles to enable a clear pending startThese 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 groupWhen 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

Reason for Ending Replication Use Command Additional Information

Ending communications for any reason ENDMMX

Performing a full save and restore of data that is defined to MIMIX

ENDMMX The save request may not be able to save all the files or objects if they are opened or locked by MIMIX.

Preparing to update MIMIX software ENDMMX See controlled end information in “Ending immediately or controlled” on page 143.

Performing an IPL of either system ENDMMX Also end the RJ link

Upgrading the operating system release on either system

ENDMMX Also end the RJ link

Performing a switch in preparation for performing maintenance on either system

--- Let MIMIX Switch Assistant or your MIMIX Model Switch Framework end replication.

Ending only a selected replication process

ENDDG See “Ending selected data group processes” on page 151.

Changing configuration, such as adding or changing data group entries

ENDDG The changes are not available to active replication processes until the data group processes are ended and restarted.

141

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

Performing a backup. ENDDG 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.

Table 19. Choosing the appropriate command to end replication

Reason for Ending Replication Use Command Additional Information

142


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 controlledBoth 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 completeWhen 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 processesMIMIX 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


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

146

Considerations for ending data groupsBefore 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.

Starting MIMIX

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


• 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 MIMIXFor 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 software’s 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.


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 commandTo 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 productsSome 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 messagesOnce 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

150

Starting selected data group processesBefore 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.

Ending selected data group processes

151

Ending selected data group processesBefore 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.

Ending a data group in a controlled mannerThe 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 groupIt 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

sses are started by the STRDG command

155

What sses based on the value you specify for MIX Remote Journal support (MIMIX RJ

er and the possible values for the PRC

plication for each of the possible values a to the target system. On the target y process (DBAPY) completes

n the data groups are ended. If the RJ ified for the PRC parameter includes sult of each process when the RJ link is

k is already active.

What replication proce

replication processes are started by the STRDG commandMIMIX determines how each data group is configured and starts the appropriate replication procethe Start processes (PRC parameter). Default configuration values create data groups that use MIsupport) for database replication and source-send technology for object replication.

The following table shows the correlation between choice text values in MIMIX Availability Managparameter on the command.

Table 20 identifies the processes that are started when MIMIX RJ support is used for database reon the PRC parameter. An RJ link identifies the IBM i remote journal function, which transfers datsystem, the data is processed by the MIMIX database reader (DBRDR) before the database applreplication.

For data groups that use MIMIX RJ support, it is standard practice to leave the RJ link active whelink is not already active when starting data groups, MIMIX starts the RJ link when the value specdatabase source system processes or all processes. The RJ Link column in Table 20 shows the renot active while the Notes column identifies behavior that may not be anticipated when the RJ lin

MIMIX Availability Manager Choice Text Special Value on CommandAll *ALLAll Source *ALLSRCAll Target *ALLTGTAll Database *DBALLAll Object *OBJALLDatabase Source *DBSRCDatabase Target *DBTGTObject Source *OBJSRCObject Target *OBJTGTDatabase Reader *DBRDRDatabase Apply *DBAPY


156

Table 20. on processes are inactive when the STRDG

Value forPRC ect replication

RCV CNRRCV STSSND OBJAPY

*ALL ts Starts Starts Starts

*ALLSRC ts Starts Starts Inactive

*ALLTGT tive Inactive Inactive Starts

*DBALL tive2 Inactive2 Inactive2 Inactive2

*OBJALL ts Starts Starts Starts

*DBSRC tive2 Inactive2 Inactive2 Inactive2

*DBTGT tive2 Inactive2 Inactive2 Inactive2

*OBJSRC ts Starts Starts Inactive

*OBJTGT tive Inactive Inactive Starts

*DBRDR tive2 Inactive2 Inactive2 Inactive2

*DBAPY tive2 Inactive2 Inactive2 Inactive2

Notes:A. Data g ects and data on the target system from becomingB. When C. When D. When ere they will be processed by the DBRDR. E. If data se source processes are selected.

1. This col es when the RJ Link is already active, which is default


Processes started by data groups configured for MIMIX Remote Journal support. This assumes that all replicatirequest is made.

Notes Source Processes Target Processes

DB replication Object replication DB replication Obj

RJ Link 1 OBJSND OBJRTV CNRSND STSRCV DBRDR DBAPY OBJ

E Starts1 Starts Starts Starts Starts Starts Starts Star

A, E Starts1 Starts Starts Starts Starts Inactive Inactive Star

A, B Inactive1 Inactive Inactive Inactive Inactive Starts Starts Inac

A, E Starts1 Inactive2 Inactive2 Inactive2 Inactive2 Starts Starts Inac

A, C Inactive1 Starts Starts Starts Starts Inactive3 Inactive 3 Star

A, C, E

Starts1 Inactive2 Inactive2 Inactive2 Inactive2 Inactive Inactive Inac

A, B Inactive1 Inactive2 Inactive2 Inactive2 Inactive2 Starts Starts Inac

A, C Inactive1 Starts Starts Starts Starts Inactive3 Inactive3 Star

A, C Inactive1 Inactive Inactive Inactive Inactive Inactive3 Inactive3 Inac

A, D Inactive1 Inactive2 Inactive2 Inactive2 Inactive2 Starts Inactive Inac

A, C Inactive1 Inactive2 Inactive2 Inactive2 Inactive2 Inactive3 Starts3 Inac

roups which use cooperative processing should have both database and object processes started to prevent obj not fully synchronized.the RJ link is already active, database replication becomes operational. the RJ link is already active, database journal entries continue to transfer to the target system over the RJ linkthe RJ link is already active, database journal entries continue to transfer to the target system over the RJ link, whgroup data area entries are configured, the data area polling process also starts when values which start databa

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


157

e replication. Data groups created on

send technology is used for database s replace the IBM i remote journal

2. These o3. These d

Table 21. sses are inactive when the STRDG request

Value forPRC ject replication

JRCV CNRRCV STSSND OBJAPY

*ALL rts Starts Starts Starts

*ALLSRC rts Starts Starts Inactive

*ALLTGT ctive Inactive Inactive Starts

*DBALL ctive2 Inactive2 Inactive2 Inactive2

*OBJALL rts Starts Starts Starts

*DBSRC ctive2 Inactive2 Inactive2 Inactive2

*DBTGT ctive2 Inactive2 Inactive2 Inactive2

*OBJSRC rts Starts Starts Inactive

*OBJTGT ctive Inactive Inactive Starts

*DBRDR ctive2 Inactive2 Inactive2 Inactive2

*DBAPY ctive2 Inactive2 Inactive2 Inactive2

Notes:A. Data g ects and data on the target system from becoming


Optionally, data groups can use source-send technology instead of remote journaling for databasearlier 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-replication. The MIMIX database send (DBSND) process and database receive (DBRCV) procesfunction and the DBRDR process, respectively.

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

Processes started by data groups configured for Source Send replication This assumes that all replication proceis made.


DB replication Object replication DB replication Ob

DBSND 1 OBJSND OBJRTV CNRSND STSRCV DBRCV DBAPY OB

— Starts 1 Starts Starts Starts Starts Starts Starts Sta

A Starts 1 Starts Starts Starts Starts Starts Inactive Sta

A Inactive Inactive Inactive Inactive Inactive Inactive Starts Ina

A Starts 1 Inactive2 Inactive2 Inactive2 Inactive2 Starts Starts Ina

A Inactive 3 Starts Starts Starts Starts Inactive3 Inactive3 Sta

A Starts 1 Inactive2 Inactive2 Inactive2 Inactive2 Starts Inactive Ina

A Inactive Inactive2 Inactive2 Inactive2 Inactive2 Inactive Starts Ina

A Inactive3 Starts Starts Starts Starts Inactive3 Inactive3 Sta

A Inactive3 Inactive Inactive Inactive Inactive Inactive3 Inactive3 Ina4 — — Inactive2 Inactive2 Inactive2 Inactive2 — — Ina

A Inactive3 Inactive2 Inactive2 Inactive2 Inactive2 Inactive3 Starts 3 Ina

roups which use cooperative processing should have both database and object processes started to prevent obj not fully synchronized.


158

1. When th2. These o3. These d4. The dat


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

sses are ended by the ENDDG command

159

What sses based on the value you specify for X Remote Journal support (MIMIX RJ

er and the possible values for the PRC

upport is used for database replication. n the target system, the data is

completes replication.

d options. In most cases, leaving the RJ ournaling (ENDRJLNK parameter).


replication processes are ended by the ENDDG commandMIMIX determines how each data group is configured and ends the appropriate replication procethe End options (PRC parameter). Default configuration values create data groups that use MIMIsupport) for database replication and source-send technology for object replication.

The following table shows the correlation between choice text values in MIMIX Availability Managparameter on the command.

Table 22 identifies the processes that are ended by each value for End options when MIMIX RJ sAn RJ link identifies the IBM i remote journal function, which transfers data to the target system. Oprocessed by the MIMIX database reader (DBRDR) before the database apply process (DBAPY)

The communications defined by the RJ link remains active and is not affected by any value for Enlink active is preferable. If necessary, you can end the RJ link by changing value for End remote j“When to end the RJ link” on page 144 describes when you need to end the RJ link.

MIMIX Availability Manager Choice Text Special Value on CommandAll *ALLAll Source *ALLSRCAll Target *ALLTGTAll Database *DBALLAll Object *OBJALLDatabase Source *DBSRCDatabase Target *DBTGTObject Source *OBJSRCObject Target *OBJTGTDatabase Reader *DBRDRDatabase Apply *DBAPY


160

Table 22. on processes are active when the ENDDG

Value forPRC ect replication

RCV CNRRCV STSSND OBJAPY

*ALL s Ends Ends Ends

*ALLSRC s Ends Ends Active

*ALLTGT ve Active Active Ends

*DBALL ve 2 Active 2 Active 2 Active 2

*OBJALL s Ends Ends Ends

*DBSRC ve 2 Active 2 Active 2 Active 2

*DBTGT ve 2 Active 2 Active 2 Active 2

*OBJSRC s Ends Ends Active

*OBJTGT ve Active Active Ends

*DBRDR ve 2 Active 2 Active 2 Active 2

*DBAPY ve 2 Active 2 Active 2 Active 2

Notes:A. Has no the RJ link, where they will be processed. B. Data g hile object processes remain active may result in o active may result in files being placed on hold due C. New da space on the target system before the end request wD. New d y the DBRDR. E. The da


Processes ended by data groups configured for MIMIX Remote Journal support. This assumes that all replicatirequest is made and that the request does not specify to end the RJ link.


DB replication Object replication DB replication Obj

RJ Link 1 OBJSND OBJRTV CNRSND STSRCV DBRDR DBAPY OBJ

E Active1 Ends Ends Ends Ends Ends Ends End

A, E Active1 Ends Ends Ends Ends Active Active End

— Active1 Active Active Active Active Ends Ends Acti

B, E Active1 Active 2 Active 2 Active 2 Active 2 Ends Ends Acti

A, B Active1 Ends Ends Ends Ends Active 3 Active 3 End

A, B, E

Active1 Active 2 Active 2 Active 2 Active 2 Active Active Acti

B Active1 Active 2 Active 2 Active 2 Active 2 Ends Ends Acti

A, B Active1 Ends Ends Ends Ends Active 3 Active 3 End

A, B Active1 Active Active Active Active Active 3 Active 3 Acti

B, C Active1 Active 2 Active 2 Active 2 Active 2 Ends Active Acti

B, D Active1 Active 2 Active 2 Active 2 Active 2 Active Ends Acti

effect on database-only replication. New database journal entries continue to transfer to the target system overroups that use cooperative processing may be affected by the result of this value. Ending database processes wbject activity entries being placed on hold. Similarly, ending object processes while database processes remain to error.tabase journal entries continue to transfer to the target system over the RJ link. Existing entries stored in the log

as processed will be applied.atabase journal entries continue to transfer to the target system over the RJ link, where they will be processed bta area polling process ends when values which end database source processes are specified.


161

e replication. Data groups created on

technology is used for database s are replaced by the IBM i remote

1. The RJ over the RJ link. See the Notes column for addi-tional de

2. These o3. These d

Table 23. sses are active when the ENDDG request is



*ALL s Ends Ends Ends

*ALLSRC s Ends Ends Active

*ALLTGT ive Active Active Ends

*DBALL ive 2 Active 2 Active 2 Active 2

*OBJALL s Ends Ends Ends

*DBSRC ive 2 Active 2 Active 2 Active 2

*DBTGT ive 2 Active 2 Active 2 Active 2

*OBJSRC s Ends Ends Active

*OBJTGT ive Active Active Ends

Notes:A. Data g hile object processes remain active may result in o active may result in files being placed on hold due


Optionally, data groups can use source-send technology instead of remote journaling for databasearlier 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-sendreplication. The MIMIX database send (DBSND) process and database receive (DBRCV) procesjournal function and the DBRDR process, respectively.

link is not ended by the End options (PRC) parameter. New database journal entries continue to transfer to the target systemtails.bject replication processes are not available in data groups configured for database-only replication.atabase replication processes are not available in data groups configured for object-only replication.

Processes ended by data groups configured for Source Send replication This assumes that all replication procemade.




— Ends 1 Ends Ends Ends Ends Ends Ends End

— Ends 1 Ends Ends Ends Ends Ends Active End

— Active Active Active Active Active Active Ends Act

A Ends 1 Active 2 Active 2 Active 2 Active 2 Ends Ends Act

A Active 3 Ends Ends Ends Ends Active 3 Active 3 End

A Ends 1 Active 2 Active 2 Active 2 Active 2 Ends Active Act

A Active Active 2 Active 2 Active 2 Active 2 Active Ends Act

A Active 3 Ends Ends Ends Ends Active 3 Active 3 End

A Active 3 Active Active Active Active Active 3 Active 3 Act

roups that use cooperative processing may be affected by the result of this value. Ending database processes wbject activity entries being placed on hold. Similarly, ending object processes while database processes remain to error.


162

*DBRDR ive 2 Active 2 Active 2 Active 2

*DBAPY ive 2 Active 2 Active 2 Active 2

1. When th2. These o3. These d4. The dat

Table 23. sses are active when the ENDDG request is



Notes:A. Data g hile object processes remain active may result in o active may result in files being placed on hold due


4 — — Active 2 Active 2 Active 2 Active 2 — — Act

A Active 3 Active 2 Active 2 Active 2 Active 2 Active 3 Ends 3 Act

e database send (DBSND) process ends, the data area polling process also ends. bject replication processes are not available in data groups configured for database-only replication.atabase replication processes are not available in data groups configured for object-only replicationabase reader (*DBRDR) process is not used by data groups configured for source-send replication.

Processes ended by data groups configured for Source Send replication This assumes that all replication procemade.




roups that use cooperative processing may be affected by the result of this value. Ending database processes wbject activity entries being placed on hold. Similarly, ending object processes while database processes remain to error.

163

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.

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 managersFrom 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 managerFrom 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 managerFrom 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

167

Working with message queuesYou 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.

Working with the message logThe 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 filesWhen 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 errorData 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:


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. Possible actions based on replication status of a file entry

Status Preferred Action1

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

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

*HLDERR User action is required. Attempt to resolve the error by synchronizing the file (option 16).

171

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

*HLDRGZ*HLDRNM*HLDPRM*HLDSYNC

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.

*HLDRTY 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 in-use). 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

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

*RLSWAIT 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).

*CMPACT*CMPRLS*CMPRPR

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.

1. Evaluate the cause of the problem before taking any action.

Table 25. Options for working with file entries from the Work with DG FIle Entries display

Option Additional Information

9=Start journaling See “Starting journaling for physical files” on page 195.

10=End journaling See “Ending journaling for physical files” on page 196.

11=Verify journaling See “Verifying journaling for physical files” on page 197.

16=Sync DG file entry

See topic ‘Synchronizing database files’ in the MIMIX Reference book.

Table 24. Possible actions based on replication status of a file entry


172


Working with journal transactions for files in errorWhen 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.

20=Work with file error entries

See topic “Working with journal transactions for files in error” on page 173.

23=Hold file See topic “Placing a file on hold” on page 174.

24=Ignore file See topic “Ignoring a held file” on page 174.

25=Release wait See topic “Releasing a held file at a synchronization point” on page 175.

26=Release See topic “Releasing a held file” on page 176.

27=Release clear See topic “Releasing a held file and clearing entries” on page 176.

31=Repair member data

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.

35=Work with related files

Table 25. Options for working with file entries from the Work with DG FIle Entries display


173

b. Select the option (Table 26) you want to use on the journal transaction:

Placing a file on holdUse 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:



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

Table 26. Options available from the Work with DG FE on Hold display.

2=Change 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.

4=Delete You can delete the journal entry.

5=Display You can display details for the specified journal entry associated with the data group file entry in question.

9=Immediate apply

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.

174


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:




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 pointUse 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:




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 fileUse 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:




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 entriesUse 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:




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 errorsTypically, file-level errors can be categorized as one of the following:

• A problem with the configuration of files defined for replication.

176


• 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 errorsRecord-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 errorThis 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 entriesTracking 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 ManagerFrom 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 windowThe 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 emulatorFrom 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 displayTo access IFS tracking entry or object tracking entry displays for a data group, do the following:



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.

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.

Table 27. Tracking entry options on the Work with Data Groups display

Select Option Result

50=IFS trk entries Lists all IFS tracking entries for the selected data group on the Work with DG IFS Trk. Entries display.

51=IFS trk entries not active

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.

52=Obj trk entries Lists all object tracking entries for the selected data group on the Work with DG Obj. Trk. Entries display.

53=Obj trk entries not active

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.

180


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

Table 28. Possible actions based on replication status of a tracking entry


1. Evaluate the cause of the problem before taking any action.

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

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

*HLDERR User action is required. Attempt to resolve the error by synchronizing the file (option 16).

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

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

*RLSWAIT If the status does not change to *ACTIVE, you may need to synchronize (option 16)

Table 29. Options for working with tracking entries


4=Remove See “Removing a tracking entry” on page 184

5=Display Identifies an object, its replication status, journaling status, and the database apply session used.

6=Print Creates a spooled file which can be printed

9=Start journaling See “Starting journaling for IFS objects” on page 198 and “Starting journaling for data areas and data queues” on page 201.

10=End journaling See “Ending journaling for IFS objects” on page 199 and “Ending journaling for data areas and data queues” on page 202.

11=Verify journaling See “Verifying journaling for IFS objects” on page 200 and “Verifying journaling for data areas and data queues” on page 203.

181

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

16=Synchronize 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.

23=Hold See “Holding journal entries associated with a tracking entry” on page 182.

24=Ignore See “Ignoring journal entries associated with a tracking entry” on page 182.

25=Release wait See “Waiting to synchronize and release held journal entries for a tracking entry” on page 183.

26=Release See “Releasing held journal entries for a tracking entry” on page 183.

27=Release clear See “Releasing and clearing held journal entries for a tracking entry” on page 184.

Table 29. Options for working with tracking entries


182


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:


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 entryUse 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:


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 entryUse 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:


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 entryUse 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:


2. Type 27 (Release clear) next to the tracking entry for the object you want and press Enter.

Removing a tracking entryUse 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:


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 errorUse 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:



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

Table 30. Options on the Work with Data Group Activity display for working with objects in error.

4=Remove 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).

For more information, see “Removing data group activity history entries” on page 190.

7=Display message Use this option to display any error message that is associated with the entry.

8=Retry 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

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.

12=Work with entries 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.

14=Remove related 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.

Table 30. Options on the Work with Data Group Activity display for working with objects in error.

Table 31. Options available on the Work with DG Activity Entries display.

4=Remove 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.

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

6=Print Use this option to print the entry.

7=Display message Use this option to display the error message associated with the processing failure for the entry.

8=Retry 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.

186

Working with objects in error

9=Display related 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.

12=Display job Displays the job that was processing the object when the error occurred, if the still job information exists and is on this system.

16=Synchronize 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).

Table 31. Options available on the Work with DG Activity Entries display.

187

Retrying data group activity entriesData 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 entryYou 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 cycleThis 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

190

Removing data group activity history entriesMIMIX 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.

191

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.

What objects need to be journaledA 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 journalingNormal 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 journalingBefore 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 command’s 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 filesData 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 filesUse 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 filesUse 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 filesUse 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:


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 filesUse 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:


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 objectsIFS 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 objectsUse this procedure to display journaling status for IFS objects identified by IFS tracking entries. Do the following:


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



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 objectsUse 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:


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.


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.


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.


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:


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.


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.


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 queuesObject 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 queuesTo check journaling status for data areas and data queues identified by object tracking entries. Do the following:


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:



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.




7. To start journaling on the objects specified, press Enter.

Ending journaling for data areas and data queuesUse 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:


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:



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.


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.


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:


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:



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.


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 switchingReplication 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 FrameworkMIMIX 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 SwitchYou 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 switchIn 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 switchingTable 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.

Specifying a default switch framework in policiesMIMIX 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.





4. At the Default model switch framework prompt, specify the name of the switch framework to use for switching this installation.


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

Table 32. Shipped values of policies used by MIMIX Switch Assistant.

Policy Shipped Values


Data group definition *INST Name1

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

Switch warning threshold 90 *DISABLED

Switch action threshold 180 *DISABLED

Default model switch framework MXMSFDFT *INST

208



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.







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.


Setting policies for switch compliance for a specific data groupIf 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.


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.


Setting policies when MIMIX Switch Assistant is not usedIf 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.


Changing the audit level policy for switchingRegardless 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:


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.



210



4. For Audit level, specify *LEVEL30. Then press Enter.

211

Switching using MIMIX Switch AssistantThe 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 MenuOption 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 systemThis 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 systemThis 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.


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.


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


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.


Determining when the last switch was performedReplication 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 ManagerMIMIX 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:


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 complianceThe 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 switchPerforming 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 ManagerTo 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 emulatorTo 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) commandThe 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.


220

221

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.

222

Starting the TCP/IP serverUse 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.


Ending the TCP/IP server

223

Ending the TCP/IP serverTo 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.

Working with objectsWhen working with objects, these tips may be helpful.

Displaying long object namesFrom MIMIX Availability Manager, object names are fully displayed in the assigned space.

To view the IFS tracking name, do the following:


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

http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/ifs/rzaax.pdf

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

226

Viewing status for active file operationsIf 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.

Displaying a remote journal link

227

Displaying a remote journal linkTo 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.

Displaying status of a remote journal linkFrom MIMIX Availability Manager, to determine whether a data group uses remote journaling, do the following:


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. Possible states for RJ links, shown in order starting with most severe.

State Description

The following states are considered to be inactive:

*UNKNOWN Neither journal defined to the remote journal link resides on the local system so the state of the link cannot be checked.

*NOTAVAIL The ASP where the journal is located is varied off.

*NOTBUILT The remote journal link is defined to MIMIX but one of the associated journal environments has not been built.

*SRCNOTBLT The remote journal link is defined to MIMIX but the associated source journal environment has not been built.

*TGTNOTBLT 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

*FAILED The remote journal cannot receive journal entries from the source journal due to an error condition.

*CTLINACT The remote journal link is processing a request for a controlled end.

*INACTIVE The remote journal link is not active.

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.

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

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

*SYNC An active remote journal link is connected using synchronous delivery mode.

*ASYNC An active remote journal link is connected using asynchronous delivery mode.

Table 33. Possible states for RJ links, shown in order starting with most severe.

State Description

229

230

Identifying data groups that use an RJ linkUse 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.

Identifying journal definitions used with RJ

231

Identifying journal definitions used with RJTo 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.

Disabling and enabling data groupsMIMIX 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 groupsFrom 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:


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:


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

236

Using file identifiers (FIDs) for IFS objectsCommands 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.

Operating a remote journal link independently

Operating a remote journal link independentlyYou 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 independentlyTo 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 independentlyDefault 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.


• 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

http://www.mimix.com

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

241

Gathering information before reporting a problemBefore 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 systemTo 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.

242

Reducing contention between MIMIX and user applica-tions

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.

Data groups cannot be ended

243

Data groups cannot be endedA 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.

244

Verifying a communications link for system definitionsDo 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.

Verifying the communications link for a data group

245

Verifying the communications link for a data groupBefore 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 linksThe 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.”

Checking file entry configuration manuallyThe 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 sent—to 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

248

Data groups cannot be startedTwo 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.

Cannot start or end an RJ link

249

Cannot start or end an RJ linkIn 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 linkNote: 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.

250

RJ link active but data not transferringFollowing 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.

Errors using target journal defined by RJ link

251

Errors using target journal defined by RJ linkIf 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.

Verifying data group file entriesThe 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 entriesThe 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 attributesBefore 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.


• 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 timestampsTimestamps 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 timestampsThe 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 processingIf 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 timestampsYou 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:


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 timestampsTo display or print data group timestamps, do the following:


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

257

Removing journaled changesIf 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.

Performing journal analysisWhen 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

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 customer’s responsibility to fix the files.


Removing journal analysis entries for a selected fileYou 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

Data group definition: <DGDFN> <SYS1> <SYS2> Journal definition: <JRNDFN> <SYSDFN> File identification File . . . . : <FILE> Library . : <LIB> Member . . . : <MBR> Journal header information Journal code . . . . . : R Record-level information Journal type . . . . . : DL Delete record Generated date . . . . : 9/08/09 Generated time . . . . : 10:36:31 Job name . . . . . . . : <JOB NAME> User name . . . . . . : <USER> Job number . . . . . . : <JOB NBR> Program name . . . . . : <PROGRAM> Journal header information (continued) Record length . . . . : 607 Record number . . . . : 838 Operation indicator . : 0 Commit cycle ID . . . : 0 Journal identification Journal name . . . . . : <JOURNAL> Library . . . . . . : <JRNLIB> Receiver identification Receiver name . . . . : <RCVR> Library . . . . . . : <RCVRLIB> Sequence number . . . : <JOURNAL SEQUENCE>

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.


261

Interpreting audit results - supporting information

262

APPENDIX A Interpreting audit results - supporting information

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.

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 audit’s 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.

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

Table 34. CHKDGFE - possible results and actions to for resolving errors

Result Recovery Actions

*NODGFE 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 No file exists for the existing file entry. Delete the DGFE, re-create the missing file, or restore the missing file.

*NOMBR No file member exists for the existing file entry.Delete the DGFE for the member or add the member to the file.

*RCYFAILED Automatic audit recovery actions were attempted but failed to correct the detected error.Run the audit again.

*RECOVERED Recovered by automatic recovery actions.No action is needed.

*UA File entries are in transition and cannot be compared.Run the audit again.

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. CHKDGFE - possible error conditions

Result File exists

Member exists

DGFE exists

DGOBJE exists

*NODGFE Yes Yes No COOPDB(*YES)

*EXTRADGFE Yes Yes Yes COOPDB(*NO)

*NOFILE No No Yes Exclude

*NOMBR Yes No Yes No entry

264

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 #FILDTAThe 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. Possible values for Compare File Data (CMPFILDTA) output file field Difference Indicator (DIFIND)

Values Description

*APY The database apply (DBAPY) job encountered a problem processing a U-MX journal entry for this member.

*CMT Commit cycle activity on the source system prevents active processing from comparing records or record counts in the selected member.

*CO Unable to process selected member. Cannot open file.

*CO (LOB) Unable to process selected member containing a large object (LOB). The file or the MIMIX-created SQL view cannot be opened.

*DT Unable to process selected member. The file uses an unsupported data type.

265

*EQ Data matches. No differences were detected within the data compared. Global difference indicator.

*EQ (DATE) Member excluded from comparison because it was not changed or restored after the timestamp specified for the CHGDATE parameter.

*EQ (OMIT) No difference was detected. However, fields with unsupported types were omitted.

*FF The file feature is not supported for comparison. Examples of file features include materialized query tables.

*FMC Matching entry not found in database apply table.

*FMT Unable to process selected member. File formats differ between source and target files. Either the record length or the null capability is different.

*HLD Indicates that a member is held or an inactive state was detected.

*IOERR Unable to complete processing on selected member. Messages preceding LVE0101 may be helpful.

*NE Indicates a difference was detected.

*NF1 Member not found on system 1.


*REP The file member is being processed for repair by another job running the Compare File Data (CMPFILDTA) command.

*SJ The source file is not journaled, or is journaled to the wrong journal.

*SP Unable to process selected member. See messages preceding message LVE3D42 in job log.

*SYNC The file or member is being processed by the Synchronize DG File Entry (SYNCDGFE) command.

*UE Unable to process selected member. Reason unknown. Messages preceding message LVE3D42 in job log may be helpful.

*UN Indicates that the member’s synchronization status is unknown.

Table 36. Possible values for Compare File Data (CMPFILDTA) output file field Difference Indicator (DIFIND)

Values Description

266


What differences were detected by #MBRRCDCNTTable 37 identifies values for the Compare Record Count command that can appear in the Difference Indicator (DIFIND) field.


Table 37. Possible values for Compare Record Count (CMPRCDCNT) output file field Dif-ference Indicator (DIFIND)

Values Description

*APY The database apply (DBAPY) job encountered a problem processing a U-MX journal entry for this member.

*CMT Commit cycle activity on the source system prevents active processing from comparing records or record counts in the selected member.

*EC The attribute compared is equal to configuration

*EQ Record counts match. No difference was detected within the record counts compared. Global difference indicator.

*FF The file feature is not supported for comparison. Examples of file features include materialized query tables.

*FMC Matching entry not found in database apply table.

*HLD Indicates that a member is held or an inactive state was detected.

*LCK Lock prevented access to member.

*NE Indicates a difference was detected.



*SJ The source file is not journaled, or is journaled to the wrong journal.

*UE Unable to process selected member. Reason unknown. Messages preceding LVE3D42 in job log may be helpful.

*UN Indicates that the member’s synchronization status is unknown.

267

Interpreting results of audits that compare attributesEach 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 entries—it 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 (CMP-DLOA).

268

Interpreting results of audits that compare attributes

What attribute differences were detectedThe 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 row’s 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. Possible values for output file field Difference Indicator (DIFIND)

Values1 Description Summary Record2 Priority

*EC The values are based on the MIMIX configuration settings. The actual values may or may not be equal.

5

*EQ Record counts match. No differences were detected. Global difference indicator.

5

*NA The values are not compared. The actual values may or may not be equal.

5

*NC The values are not equal based on the MIMIX configuration settings. The actual values may or may not be equal.

3

*NE Indicates differences were detected. 2

*NS Indicates that the attribute is not supported on one of the systems. Will not cause a global not equal condition.

5

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

*RCYFAILED Used to indicate that automatic recovery attempts via AutoGuard failed to recover the detected difference.

*RECOVERED Indicates that recovery for this object was successful. 1 3

*SJ Unable to process selected member. The source file is not journaled.

1

269

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.

*SP Unable to process selected member. See messages preceding message LVE3D42 in job log.

1

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

2

*UN Indicates that the object’s synchronization status is unknown. 4

1. Not all values may be possible for every Compare command.2. Priorities are used to determine the value shown in output files for Compare Attribute commands. 3. 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.

Table 38. Possible values for output file field Difference Indicator (DIFIND)

Values1 Description Summary Record2 Priority

Table 39. Difference Indicator values that are derived from System Indicator values.

Difference Indicator

System 1 Indicator

Object Found (blank value)

*NOTCMPD *NOTFOUND *NOTSPT *RTVFAILED *DAMAGED

System 2

Indicator

Object Found (blank value)

*EQ / *EQ (LOB) / *NE / *UA / *EC / *NC

*NA *NE *NS *UN *NE

*NOTCMPD *NA *NA *NE *NS *UN *NE

*NOTFOUND *NE / *UA *NE / *UA *EQ *NE / *UA *NE / *UA *NE

*NOTSPT *NS *NS *NE *NS *UN *NE

*RTVFAILED *UN *UN *NE *UN *UN *NE

*DAMAGED *NE *NE *NE *NE *NE *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.

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.

Table 40. Possible values for output file fields SYS1IND and SYS2IND

Value Description Summary Record1 Priority

<blank> No special conditions exist for this object. 5

*DAMAGED Object damaged condition. 3

*MBRNOTFND Member not found. 2

*NOTCMPD Attribute not compared. Due to MIMIX configuration settings, this attribute cannot be compared.

N/A2

*NOTFOUND Object not found. 1

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

N/A2

*RTVFAILED Unable to retrieve the attributes of the object. Reason for failure may be a lock condition.

4

1. The priority indicates the order of precedence MIMIX uses when setting the system indicators fields in the summary record.

2. This value is not used in determining the priority of summary level records.

271

What attributes were comparedIn 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 auditsThe 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 file-specific 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. Compare File Attributes (CMPFILA) attributes

Attribute Description Returned Values (SYS1VAL, SYS2VAL)

*ACCPTH1 Access path AR - Arrival sequence access pathEV - 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) orderKN - 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).

*ACCPTHVLD2 Access path valid *YES, *NO

*ACCPTHSIZ1 Access path size *MAX4GB, *MAX1TB

*ALWDLT Allow delete operation

*YES, *NO

*ALWOPS Allow operations Group which checks attributes *ALWDLT, *ALWRD, *ALWUPD, *ALWWRT

*ALWRD Allow read operation

*YES, *NO

*ALWUPD Allow update operation

*YES, *NO

273

*ALWWRT Allow write operation

*YES, *NO

*ASP Auxiliary storage pool ID

1-16 (pre-V5R2)1-255 (V5R2)1 = System ASPSee “Comparison results for auxiliary storage pool ID (*ASP)” on page 294 for details.

*AUDVAL Object audit value *NONE, *CHANGE, *ALL

*AUT File authorities Group which checks attributes *AUTL, *PGP, *PRVAUTIND, *PUBAUTIND

*AUTL Authority list name *NONE, list name

*BASEDONPF2 Name of based-on physical file member

33 character name in the format: library/file(member)

*BASIC Pre-determined set of basic attributes

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.

*CCSID1 Coded character set 1-65535

*CST Constraint attributes Group which checks attributes *CSTIND, *CSTNBR

*CSTIND 3 Constraint equal indicator

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.

*CSTNBR 3 Number of constraints

Numeric value

*CURRCDS Current number of records

0-4294967295

*DBCSCAP DBCS capable *YES, *NO

*DBR Group which checks *DBRIND, *OBJATR



274

*DBRIND 3 Database relations 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.

*EXPDATE1 Expiration date for member

Blank for *NONE or date in CYYMMDD format, where C equals the century. Value 0 is 19nn and 1 is 20nn.

*EXTENDED Pre-determined, extended set

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

*FIRSTMBR1 4 Name of member *FIRST

10 character name*NONE if the file has no members.

*FRCKEY1 Force keyed access path

*YES, *NO

*FRCRATIO1 Records to force a write

*NONE, 1-32767

*INCRCDS1 Increment number of records

0-32767

*JOIN Join Logical file *YES, *NOAdd, update, and delete authorities are not checked. Differences in these authorities do not result in an *NE condition.

*JOURNAL Journal attributes Group which checks *JOURNALED, *JRN, *JRNLIB, *JRNIMG, *JRNOMIT. Results are described in “Comparison results for journal status and other journal attributes” on page 290.

*JOURNALED File is currently journaled

*YES, *NO

*JRN Current or last journal

10 character name, blank if never journaled

*JRNIMG Record images *AFTER, *BOTH

*JRNLIB Current or last journal library

10 character name, blank if never journaled

*JRNOMIT Journal entries to be omitted

*OPNCLO, *NONE

*LANGID1 Language ID 3 character ID

*LASTMBR1 4 Name of member *LAST

10 character name*NONE if the file has no members.



275

*LVLCHK1 Record format level check

*YES, *NO

*MAINT1 Access path maintenance

*IMMED, *REBLD, *DLY

*MAXINC1 Maximum increments

0-32767

*MAXKEYL1 Maximum key length

1-2000

*MAXMBRS1 Maximum members *NOMAX, 1-32767

*MAXPCT1 Max % deleted records allowed

*NONE, 1-100

*MAXRCDL1 Maximum record length

1-32766

*NBRDLTRCD1 Current number of deleted records

0-4294967295

*NBRMBR1 Number of members

0-32767

*NBRRCDS1 Initial number of records

*NOMAX, 1-2147483646

*OBJCTLLVL1 Object control level 8 character user-defined value

*OWNER File owner User profile name

*PFSIZE File size attributes Group which checks *CURRCDS, *INCRCDS, *MAXINC, *NBRDLTRCD, *NBRRCDS

*PGP Primary group *NONE, user profile name

*PRVAUTIND Private authority indicator

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.

*PUBAUTIND Public authority indicator

No value, indicator only5 When this attribute is returned in output, its Difference Indicator value indicates if public authority values are equal.

*RCDFMT Number of record formats

1-32

*RECOVER1 Access path recovery

*IPL, *AFTIPL, *NO

*REUSEDLT1 Reuse deleted records

*YES, *NO



276

*SELOMT Select / omit file *YES, *NO

*SHARE1 Share open data path

*YES, *NO

*SQLTYP SQL file type PF Types - NONE, TABLE, LF Types - INDEX, VIEW, NONE

*TEXT1 Text description 50 character value

*TRIGGER Group which checks *TRGIND, *TRGNBR, *TRGXSTIND

*TRGIND 3 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.

*TRGNBR 3 Number of triggers Numeric value

*TRGXSTIND 3 Trigger existence indicator

No value, indicator only5 When this attribute is returned in output, its Difference Indicator value indicates if a trigger program exists on the system.

*USRATR User-defined attribute

10 character user-defined value

*WAITFILE1 Maximum file wait time

*IMMED, *CLS, 1-32767

*WAITRCD1 Maximum record wait time

*IMMED, *NOMAX, 1-32767

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

2. This attribute is only compared for logical file members by the #FILATRMBR audit.3. 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.4. 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.

5. 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. Compare Object Attributes (CMPOBJA) attributes


*ACCPTHSIZ1 2 Access path sizeValid for logical files only.

*MAX4GB and *MAX1TB

*AJEIND Auto start job entries.Valid for subsystem descriptions only.

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.

*ASP Auxiliary storage pool ID 1-16 (pre-V5R1)1-32 (V5R1)1-255 (V5R2), 1 = System ASPSee “Comparison results for auxiliary storage pool ID (*ASP)” on page 294 for details.

*ASPNBR Number of defined storage pools.Valid for subsystem descriptions only.

Numeric value

*ATTNPGM2 Attention key handling program Valid for user profiles only.

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

*AUDVAL Object audit value *NONE, *USRPRF, *CHANGE, *ALL

*AUT Authority attributes Group which checks *AUTL, *PGP, *PRVAUTIND, *PUBAUTIND

*AUTCHK2 Authority to check.Valid for job queues only.

*OWNER, *DTAAUT



Group which checks a pre-determined set of attributes. These attributes are compared: *CRTTSP, *DOMAIN, *INFSTS, *OBJATR, *TEXT, and *USRATR.

278

*CCSID2 Character identifier control.Valid for user profiles only.

*SYSVAL, ccsid-value

*CNTRYID2 Country ID Valid for user profiles only.

*SYSVAL, country-id

*COMMEIND Communications entriesValid for subsystem descriptions only.

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.

*CRTAUT2 Authority given to users who do not have specific authority to the object.Valid for libraries only.

*SYSVAL, *CHANGE, *ALL, *USE, *EXCLUDE, *SYSVAL, *CHANGE, *ALL, *USE, *EXCLUDE

*CRTOBJAUD2 Auditing value for objects created in this libraryValid for libraries only.

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

*CRTOBJOWN Profile that owns objects created by userValid for user profiles only.

*USRPRF, *GRPPRF, profile-name

*CRTTSP Object creation date YYYY-MM-DD-HH.MM.SS.mmmmmm

*CURLIB Current library Valid for user profiles only.

*CRTDFT, current-library

*DATACRC2 Data cyclic redundancy check (CRC)Valid for data queues only.

10 character value

*DDMCNV2 DDM conversationValid for job descriptions only.

*KEEP, *DROP

*DECPOS Decimal positionsValid for data areas only.

0-9

*DOMAIN Object Domain *SYSTEM, *USER

*DTAARAEXT Data area extended attributes

Group which checks *DECPOS, *LENGTH, *TYPE, *VALUE



279


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.

*FRCRATIO1 2 Records to force a writeValid for logical files only.

*NONE, 1 - 32,767

*GID Group profile ID numberValid for user profiles only.

1 - 4294967294

*GRPAUT Group authority to created objects Valid for user profiles only.

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

*GRPAUTTYP Group authority typeValid for user profiles only.

*PGP, *PRIVATE

*GRPPRF Group profile nameValid for user profiles only.

*NONE, profile-name

*INFSTS Information status *OK (No errors occurred), *RTVFAILED (No information returned - insufficient authority or object is locked), *DAMAGED (Object is damaged or partially damaged).

*INLMNU Initial menuValid for user profiles only.

Menu - *SIGNOFF, menu nameLibrary - *LIBL, library name

*INLPGM Initial programValid for user profiles only.

Program - *NONE, program name Library - *LIBL, library name

*JOBDEXT Job description extended attributes

Group which checks *DDMCNV, *JOBQ, *JOBQLIB, *JOBQPRI, *LIBLIND, *LOGOUTPUT, *OUTQ, *OUTQLIB, *OUTQPRI, *PRTDEV

*JOBQ2 Job queueValid for job descriptions only.

10 character name

*JOBQEIND Job queue entriesValid for subsystem descriptions only.

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

*JOBQEXT Job queue extended attributes

Group which checks *AUTCHK, *JOBQSBS, *JOBQSTS, *OPRCTL

*JOBQLIB2 Job queue libraryValid for job descriptions only.

10 character name

*JOBQPRI2 Job queue priorityValid for job descriptions only.

1 (highest) - 9 (lowest)

*JOBQSBS2 Subsystem that receives jobs from this queueValid for job queues only.

Subsystem name

*JOBQSTS2 Job queue statusValid for job queues only.

HELD, RELEASED

*JOURNAL Journal attributes Group which checks *JOURNALED, *JRN, *JRNLIB, *JRNIMG, *JRNOMIT4.Results are described in “Comparison results for journal status and other journal attributes” on page 290.

*JOURNALED Object is currently journaled

*YES, *NO

*JRN Current or last journal 10 character name



10 character name

*JRNOMIT Journal entries to be omitted

*OPNCLO, *NONE

*LANGID2 Language IDValid for user profiles only.

*SYSVAL, language-id

*LENGTH Data area lengthValid for data areas only

1-2000 (character), 1-24 (decimal), 1 (logical)

*LIBEXT Extended library information attributes

Group which checks *CRTAUT, *CRTOBJAUD

*LIBLIND Initial library listValid for job descriptions only.

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

*LMTCPB Limit capabilitiesValid for user profiles only.

*PARTIAL, *YES, *NO

*LOGOUTPUT2 Job log outputValid for job descriptions only.

*SYSVAL, *JOBLOGSVR, *JOBEND, *PND

*LVLCHK1 2 Record format level checkValid for logical files only.

*YES, *NO

*MAINT1 2 Access path maintenanceValid for logical files only.

*DLY, *IMMED, *REBLD

*MAXACT 2 Maximum active jobsValid for subsystem descriptions only.

Numeric value, *NOMAX (32,767)

*MAXMBRS1 2 Maximum membersValid for logical files only.

*NOMAX, 1 - 32,767

*MSGQ2 Message queueValid for user profiles only.

Message queue - message queue nameLibrary - *LIBL, library name

*NBRMBR1 2 Number of logical file membersValid for logical files only.

0 - 32,767

*OBJATR Object attribute 10 character object extended attribute

*OBJCTLLVL2 Object control levelValid for object types that support this attribute5.

8 character user-defined value

*OPRCTL2 Operator controlledValid for job queues only.

*YES, *NO

*OUTQ2 Output queueValid for job descriptions only.

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

*OUTQLIB2 Output queue libraryValid for job descriptions only.

10 character name

*OUTQPRI2 Output queue priorityValid for job descriptions only.

1 (highest) - 9 (lowest)



282

*OWNER Object owner 10 character name


*PRESTIND Pre-start job entriesValid for subsystem descriptions only.

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.

*PRFOUTQ2 Output queueValid for user profiles only.

*LIBL/*WRKSTN, *DEV

*PRFPWDIND User profile password indicator

See “Comparison results for user profile password (*PRFPWDIND)” on page 300 for details.

*PRTDEV2 Printer deviceValid for job descriptions only.

*USRPRF, *SYSVAL, *WRKSTN, printer device name

*PRVAUTIND Private authority indicator 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

*PUBAUTIND Public authority indicator No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if the public authority values are equal.

*PWDEXPITV Password expiration intervalValid for user profiles only.

*SYSVAL, *NOMAX, 1-366 days

*PWDIND No password indicatorValid for user profiles only.

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

*QUEALCIND Job queue allocation indicatorValid for subsystem descriptions only.

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

*RLOCIND Remote location entriesValid for subsystem descriptions only.

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.

*RTGEIND Routing entriesValid for subsystem descriptions only.

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

*SBSDEXT Subsystem description extended attributes

Group which checks *AJEIND, *ASPNBR, *COMMEIND, *JOBQEIND, *MAXACT, *PRESTIND, *RLOCIND, *RTGEIND, *SBSDSTS

*SBSDSTS2 Subsystem statusValid for subsystem descriptions only.

*ACTIVE, *INACTIVE

*SIZE Object size Numeric value

*SPCAUTIND Special authoritiesValid for user profiles only.

No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if special authority values are equal

*SQLSP SQL stored proceduresValid for programs and service programs only.

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

*SQLUDF SQL user defined functionsValid for programs and service programs only.

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

*SUPGRPIND Supplemental GroupsValid for user profiles only.

No value, indicator only3 When this attribute is returned in output, its Difference Indicator value indicates if supplemental group values are equal

*TEXT2 Text description 50 character description



284

*TYPE Data area type - data area types of DDM resolved to actual data area typesValid for data areas only.

*CHAR, *DEC, *LGL

*UID User profile ID numberValid for user profiles only.

1 - 4294967294

*USRATR2 User-defined attribute 10 character user-defined value

*USRCLS User ClassValid for user profiles only.

*SECOFR, *SECADM, *PGMR, *SYSOPR, *USER

*USRPRFEXT User profile extended attributes

Group which checks *ATTNPGM, *CCSID, *CNTRYID, *CRTOBJOWN, *CURLIB, *GID, *GRPAUT, *GRPAUTTYP, *GRPPRF, *INLMNU, *INLPGM, *LANGID, *LMTCPB, *MSGQ, *PRFOUTQ, *PWDEXPITV, *PWDIND, *SPCAUTIND, *SUPGRPIND, *USRCLS

*USRPRFSTS User profile status *ENABLED, *DISABLED6

For details, see “Comparison results for user profile status (*USRPRFSTS)” on page 297.

*VALUE2 Data area valueValid for data areas only.

Character value of data

1. This attribute only applies to logical files. Use the Compare File Attributes (CMPFILA) command to compare or omit physical file attributes.


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

4. These attributes are compared for object types of *FILE, *DTAQ, and *DTAARA. These are the only objects supported by IBM's user journals.

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

6. The profile status is only compared if no data group is specified or the USRPRFSTS has a value of *SRC for the spec-ified 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 auditThe #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. Compare IFS Attributes (CMPIFSA) attributes


*ALWSAV1 Allow save *YES, *NO

*ASP Auxiliary storage pool 1-16 (pre-V5R1)1-255 (V5R1) 1-System ASPSee “Comparison results for auxiliary storage pool ID (*ASP)” on page 294 for details.

*AUDVAL Object auditing value *ALL, *CHANGE, *NONE, *USRPRF

*AUT Authority attributes Group which checks attributes *AUTL, *PGP, *PUBAUTIND, *PRVAUTIND



Group which checks a pre-determined set of attributes. The following set of attributes are compared: *CCSID, *DATASIZE, *OBJTYPE, and the group *PCATTR.

*CCSID1 Coded character set 1-65535

*CRTTSP2 Create timestamp SAA format (YY-MM-DD-HH.MM.SS.mmmmmm)

*DATACRC3 Data cyclic redundancy check (CRC)

8 character value

*DATASIZE1 Data size 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).

*JOURNAL Journal information 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.

*JOURNALED File is currently journaled *YES, *NO

*JRN Current or last journal 10 character name


286


10 character name

*JRNOPT Journal optional entries *YES, *NO

*OBJTYPE Object type *STMF, *DIR, *SYMLNK

*OWNER File owner 10 character name

*PCARCHIVE1 Archived file *YES, *NO

*PCATTR PC Attributes Group which checks *PCARCHIVE, *PCHIDDEN, *PCREADO, *PCSYSTEM

*PCHIDDEN1 Hidden file *YES, *NO

*PCREADO1 Read only attribute *YES, *NO

*PCSYSTEM1 System file *YES, *NO


*PRVAUTIND Private authority indicator 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.

*PUBAUTIND Public authority indicator No value, indicator only4 When this attribute is returned in output, its Difference Indicator value indicates if the public authority values are equal.


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

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

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

Table 43. Compare IFS Attributes (CMPIFSA) attributes


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. Compare DLO Attributes (CMPDLOA) attributes


*ASP Auxiliary storage pool 1-16 (pre-V5R1)1-32 (V5R1)1 = System ASPSee “Comparison results for auxiliary storage pool ID (*ASP)” on page 294 for details.

*AUDVAL Object audit value *NONE, *USRPRF, *CHANGE, *ALL

*AUT Authority attributes Group which checks *AUTL, *PGP, *PUBAUTIND, *PRVAUTIND



Group which checks a pre-determined set of attributes. The following set of attributes are compared: *CCSID, *DATASIZE, *OBJTYPE, *PCATTR, and *TEXT.

*CCSID Coded character set 1-65535

*CRTTSP Create timestamp SAA format (YY-MM-DD-HH.MM.SS.mmmmmm)

*DATASIZE Data size 0-42949672951

*EXTENDED Pre-determined, extended set 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.

*MODTSP Modify timestamp SAA format (YY-MM-DD-HH.MM.SS.mmmmmm)

*OBJTYPE Object type *DOC, *FLR2

*OWNER File owner 10 character name

*PCARCHIVE Archived file *YES, *NO

*PCATTR PC Attributes Group which checks *PCARCHIVE, *PCHIDDEN, *PCREADO, *PCSYSTEM

*PCHIDDEN Hidden file *YES, *NO

*PCREADO Read only attribute *YES, *NO

288

*PCSYSTEM System file *YES, *NO


*PRVAUTIND Private authority indicator 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

*PUBAUTIND Public authority indicator No value, indicator only1 When this attribute is returned in output, its Difference Indicator value if the public authority values are equal

*TEXT Text description 50 character description

1. This attribute is not supported for DLOs with an object type of *FLR.2. This attribute is always compared.3. 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.

Table 44. Compare DLO Attributes (CMPDLOA) attributes


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 group’s 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.

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

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 Object journal information attributes. This value acts as a group selection, causing all other journaling attributes to be selected

*JOURNALED Journal Status. Indicates whether the object is currently being journaled. This attribute is always compared when any of the other journaling attributes are selected.

*JRN 1

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

Journal. Indicates the name of the current or last journal. If blank, the object has never been journaled.

*JRNIMG 1 2

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

Journal Image. Indicates the kinds of images that are written to the journal receiver for changes to objects.

*JRNLIB 1 Journal Library. Identifies the library that contains the journal. If blank, the object has never been journaled.

*JRNOMIT 1 Journal Omit. Indicates whether file open and close journal entries are omitted.

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.

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.

Table 46. Difference indicator values for *JOURNALED attribute when no data group is specified


Journal Status 1

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

Target

Yes No *NOTFOUND

SourceYes *EQ *NE *NE

No *NE *EQ *NE

*NOTFOUND *NE *NE *UN

291

Table 47 shows results when the configured settings for Journal on target and Cooperate with database are both *YES.

Table 48 shows results when the configured settings are *NO for Journal on target and *YES for Cooperate with database. .

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

Table 47. Difference indicator values for *JOURNALED attribute when a data group is spec-ified and the configuration specifies *YES for JRNTGT and COOPDB


Journal Status 1


Target

Yes No *NOTFOUND

SourceYes *EC *EC *NE

No *NC *NC *NE


Table 48. Difference indicator values for *JOURNALED attribute when a data group is spec-ified and the configuration specifies *NO for JRNTGT and *YES for COOPDB.


Journal Status 1


Target

Yes No *NOTFOUND

SourceYes *NC *EC *NE

No *NC *NC *NE


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.

How configured journaling settings are determinedWhen 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 group’s 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.

Table 49. Difference indicator values for *JOURNALED attribute when a data group is spec-ified and the configuration specifies *NO for COOPDB.


Journal Status 1


Target

Yes No *NOTFOUND

SourceYes *EC *EC *NE

No *EC *EC *NE


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.

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 50. Difference Indicator values when no data group is specified


ASP Values 1

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

Target

ASP1 ASP2 *NOTFOUND

SourceASP1 *EQ *NE *NE

ASP2 *NE *EQ *NE

*NOTFOUND *NE *NE *EQ

Table 51. Difference Indicator values for non-library objects when the request specified a data group


ASP Values 1


Target

ASP1 ASP2 *NOTFOUND

SourceASP1 *NOTCMPD *NOTCMPD *NE

ASP2 *NOTCMPD *NOTCMPD *NE


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

Table 52. Difference Indicator values for libraries when a data group is specified and config-ured values are LIB1ASP(*SRCLIB) and DTASRC(*SYS2).


ASP Values 1


Target

ASP1 ASP2 *NOTFOUND

SourceASP1 *EC *NC *NE

ASP2 *NC *EC *NE


Table 53. Difference Indicator values for libraries when a data group is specified and config-ured values are LIB1ASP(1) and DTASRC(*SYS2)


ASP Values 1


Target

1 2 *NOTFOUND

Source1 *EC *NC *NE

2 *EC *NC *NE


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 config-ured values are LIB1ASP(*ASPDEV), LIB1ASPD(DEVNAME) and DTASRC(*SYS2)


ASP Values 1


Target

DEVNAME 2 *NOTFOUND

Source1 *EC *NC *NE

2 *EC *NC *NE


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.

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

Table 55. Difference Indicator values when configured user profile status is *SRC


User profile status Target

*ENABLED *DISABLED *NOTFOUND

Source*ENABLED *EC *NC *NE

*DISABLED *NC *EC *NE


297

show the possible values when configured values are *ENABLED or *DISABLED, respectively.

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.

How configured user profile status is determinedThe 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

Table 56. Difference Indicator values when configured user profile status is *ENABLED




Source*ENABLED *EC *NC *NE

*DISABLED *EC *NC *NE


Table 57. Difference Indicator values when configured user profile status is *DISABLED




Source*ENABLED *NC *EC *NE

*DISABLED *NC *EC *NE


Table 58. Difference Indicator values when configured user profile status *TGT




Source*ENABLED *NA *NA *NE

*DISABLED *NA *NA *NE


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. Configuration values for replicating user profile status

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

*DISABLE 1

1. Data group definitions use these values. In data group object entries, the values *DISABLED and *ENABLED are used but have the same meaning.

The status of the user profile is set to *DISABLED when the user profile is created or changed on the target system.

*ENABLE 1 The status of the user profile is set to *ENABLED when the user profile is created or changed on the target system.

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

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

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.


User Profile Password Remote System

*ENABLED *DISABLED Expired Not Found

Local System

*ENABLED *EQ *EQ *EQ *NE

*DISABLED *NA *NA *NA *NE

Expired *NA *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 62 shows the possible Difference Indicator values when the user profile passwords are defined as *NONE on the local and remote systems.

Table 61. Difference Indicator values when user profile passwords are different, but not *NONE




Local System

*ENABLED *NE *NE *NE *NE




Table 62. Difference Indicator values when user profile passwords are *NONE.




Local System

*ENABLED *NA *NA *NA *NE




301

IBM Power™ Systems operations that affect MIMIX

APPENDIX B IBM Power™ Systems operations that affect MIMIX

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 environment—if you have cluster, SAP R/3, IBM WebSphere MQ, or other application considerations, for example—contact 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

http://publib.boulder.ibm.com/pubs/html/as400/infocenter.html

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.


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


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.

Prerequisites for performing an OS upgrade on either systemBefore 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:

Table 63. IBM i operating system upgrade scenarios and recommended processes for handling MIMIX dur-ing the upgrade

To upgrade Perform these procedures

Backup system only 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.

Production system only 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.

Both backup and production systems

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

304

http://www.mimix.com/support


a. Check the compatibility of the operating systems on the production and backup systems, ensuring the systems will meet the requirements of a MIMIX-supported 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 systemUse 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


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:


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:


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


• 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:


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:


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


subsystems:


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.



a. From the original production system, specify the command: installation-name/WRKJRNDFN JRNDFN(QAUDJRN *LOCAL)


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 with-out 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


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:


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:


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:


8. Complete the operating system upgrade. Allow any upgrade conversions and access path rebuilds to complete before continuing with the next step.


9. Start the MIMIX subsystems on the production system and the backup system as

309


you would during the synchronization phase of a switch. From each system, type the following on a command line and press Enter:



a. From the production system, specify the command: installation-name/WRKJRNDFN JRNDFN(QAUDJRN *LOCAL)


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 changeBefore 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 stepsTo 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

http://portal.lakeviewtech.com/wps/portal



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




Handling MIMIX during a system restoreOccasionally, 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 MIMIXBefore 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 HeadquartersVision Solutions, Inc.Irvine, California USATel: +1 (949) 253-6500

Index

Symbols*FAILED activity entry 185, 188*HLD

file entry 170tracking entry 179

*HLDERRfile entry 170tracking entry 179

*HLDRLTD file entry 170

Aaccessing

MIMIX Availability Status display 50MIMIX Main Menu 42status from MIMIX Availability Manager 48

activity entries, objectconfirm delay/retry cycle 189failed, resolving 185remove history 190retrying 188

additional resources 11agintro 79applications, reducing contention with 242attributes, supported

CMPDLOA command 288CMPFILA command 273CMPIFSA command 286CMPOBJA command 278

auditafter a configuration change 106authority level to run 81automatic recovery 82before switching 81best practice 20, 81, 100bi-directional environment considerations 22changing schedule 105, 106compare phase 19comparison levels 19, 81compliance 98compliance threshold 28, 29concepts 19definition of 18differences, resolving 93, 95displaying compliance status 85, 100displaying runtime status 85, 90displaying schedule 102ending 91getting started 20job log 96

last performed 100last successful run 98policies which affect 109prevent from running 110problems reported in installation 54recommendations 81, 82recovery phase 19requirements 81results 93, 95rule name 104running immediately 91schedule 102schedule, considerations for changing 105schedule, shipped default 104scheduler, alternative 108scheduler, automatic 104status 85status from 5250 emulator 52status from MIMIX Availability Manager 48status, compliance 98status, runtime 87summary 87when not to audit 23

audit levelbest practice 81changing before switch 210differences, 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 297interpreting, attribute comparisons 268

316

interpreting, file data comparisons 265resolving problems 95, 263troubleshooting 96

auditing level, objectset when starting a data group 140used for replication 192

authority level for auditing, product 81AutoGuard, MIMIX 15automatic error recovery

policies for 33system journal replication 34user journal replication 33

automatic recoveryaudit recommendations 82audits 27concept 18system journal replication 27user journal replication 27

AutoNotify feature, MIMIX 124Availability Manager, MIMIX 15Availability Status display, MIMIX 50

Bbacklog, identifying a 76backup system 16best practice

audit frequency 100audit level 29, 81audit level before switch 82, 210audit threshold 28, 29MIMIX AutoGuard 20switch frequency 204, 215switch threshold 31switching 205

bi-directional environment policy consider-ations 22

Cclear error entries

processing 136when to 136

clear pending entriescheck for open commits 139open commit cycle prevents 139processing 136resolving open commits before 140when to 136

cold start, replacement for 136commands, by mnemonic

CHGDG 233CHKDGFE 106, 246, 263CRTDGTSP 254DLTDGTSP 256DSPDGSTS 64DSPDGTSP 256DSPMMXMSGQ 167DSPRJLNK 227ENDDG 131, 141ENDJRNFE 196ENDJRNIFSE 199ENDJRNOBJE 202ENDJRNPF 196ENDMMX 131, 141, 147ENDMMXMGR 165ENDRJLNK 237ENDSVR 223HLDDGLOG 257MIMIX 42RLSDGLOG 257RUNRULE 80, 115RUNRULEGRP 80, 115STRDG 131, 133, 135STRJRNFE 195STRJRNIFSE 198STRJRNOBJE 201STRMMX 131, 133, 147STRMMXMGR 165STRRJLNK 237STRSVR 222SWTDG 217, 219VFYCMNLNK 244, 245VFYJRNFE 197VFYJRNIFSE 200VFYJRNOBJE 203VFYKEYATR 252WRKCPYSTS 226WRKDG 54WRKDGACT 185WRKDGACTE 186WRKDGFE 170WRKDGIFSTE 180WRKDGOBJTE 180WRKDGTSP 254WRKMMXSTS 50, 125WRKMSGLOG 168WRKNFY 120WRKRJLNK 228, 230

commands, by nameChange Data Group 233

317

Check Data Group File Entries 246, 263Check Data group File Entry 106Create Data Group Timestamps 254Delete DG Timestamps 256Display Data Group Status 64Display Data Group Timestamps 256Display MIMIX Message Queue 167Display RJ Link 227End Data Group 131, 141End Journal Physical File 196End Journaling File Entry 196End Journaling IFS Entries 199End Journaling Obj Entries 202End Lakeview TCP Server 223End MIMIX 131, 141, 147End MIMIX Managers 165End RJ Link 237Hold Data Group Log 257MIMIX 42MIMIX Availability Status 50Release Data Group Log 257Run Rule 80, 115Run Rule Group 80, 115Start Data Group 131, 133, 135Start Journaling File Entry 195Start Journaling IFS Entries 198Start Journaling Obj Entries 201Start Lakeview TCP Server 222Start MIMIX 131, 133, 147Start MIMIX Managers 165Start RJ Link 237Switch Data Group 217, 219Verify Communications Link 244, 245Verify Journaling File Entry 197Verify Journaling IFS Entries 200Verify Journaling Obj Entries 203Verify Key Attributes 252Work with Copy Status 226Work with Data Group Activity 185Work with Data Groups 54Work with DG Activity Entries 186Work with DG File Entries 170Work with DG IFS Tracking Ent. 180Work with DG Obj Tracking Ent. 180Work with DG Timestamps 254Work with Message Log 168Work with MIMIX Availability Status 125Work with Notifications 120Work with RJ Links 228, 230

commit cycles

effect on audit comparison 265, 267commit cycles, open

checking for 139checking for after a controlled end 153effect on clear pend start 137prevent a clear pending STRDG 139preventing problems with 144

communicationsending TCP sever 223starting TCP sever 222

compare phase 19compliance

audit 98concept 19switch 215switch, policies for 208, 209

compliance statusaudit 85switch 215

conceptsauditing 19MIMIX 15MIMIX AutoGuard 18

configurationaudit after changing 106determining data areas and data queues 235determining, IFS objects 234results of #DGFE audit after changing 263

constraints, CMPFILA file-specific attribute 273contacting Vision Solutions 12contention with applications, reducing 242controlled end

confirm end 153description 143procedure 152wait time 144

copying active files 226correcting

file-level errors 176record-level errors 177

CustomerCare 12

Ddata areas and data queues

determining configuration of 235holding user journal entries for 182resolving problems 180tracking entries 179verifying journaling 203

318

data group 15activity details 61, 64backlogs 76controlled vs. immediate end 143definition 16determining if RJ link used 230disabling 233enabling 233ending choices 141ending considerations 146ending controlled 152ending immediately 151ending selected processes 151indication of disabled state 232recovery point cleared 146starting considerations 133, 135starting selected processes 150state, disabled or enabled 232status from 5250 emulator 52status from MIMIX Availability Manager 48status, database view 71status, detailed 61status, merged view 65status, object view 69status, summary 54switching 205, 217system journal activity 61timestamps 254user journal activity 61when to exclude from auditing 23

data group entrydescription 15

database apply (DBAPY) status 71database error recovery, automatic 34definition

data group 16journal 16remote journal (RJ) link 16system 16transfer 16

delay intervalsjournal manager 164system manager 164

delay/retry cycle, confirm object in a 189differences, resolving audit 93, 95disabled data group 232displaying

data group spooled file information 224data group status details 61long IFS object names 224

RJ link 227RJ link status 228status 48, 50

Eending

audit 91MIMIX managers 164MIMIXSBS subsystem 148system and journal managers 165TCP server 223

ending data groupclears recovery point 146considerations when ending 146controlled end 152controlled end wait time 144controlled vs. immediate 143how to confirm end 153immediate end 151processes 144processes, effect of 159processes, specifying selected 151when to end RJ link 144

ending journalingdata areas and data queues 202files 196IFS objects 199IFS tracking entry 199object tracking entry 202

ending MIMIX 147considerations 141controlled vs. immediate 143end subsystem, when to also 148follow up after 148included processes 142using default values 147using specified values 148when to end RJ link 144

ending replication 131choices and considerations 141controlled vs. immediate 143

ending RJ linkindependently from data group 237when to end 144

Enterprise View 45errors

file level 176record level 177system journal replicated objects 185

319

target journal of RJ link 251user journal replicated objects 170, 179

Ffile

file-level errors 176hold journal entries 174new 192not journaled 57record-level errors 177replicated 170

file identifiers (FIDs) 236file in error

examine held journal entries 173resolving 170

file on holdrelease and apply held entries 176release and clear entries 176release at synchronization point 175

Gguidelines for auditing 81

Hhardware upgrade

MIMIX-specific steps 311no disk image change 310prerequisites 311with a disk image change 313

held error (*HLDERR)file entry 170preferred action for entry 171, 181tracking entry 179

help, accessing 9history log, removing completed entries 190hold (*HLD)

preferred action for held entry 171, 181put file entry on hold 174put tracking entry on hold 182release a held file entry 176release a held tracking entry 183

hold ignore (*HLDIGN)preferred action for ignored entry 171, 181put file entry on hold ignore 174put tracking entry on hold ignore 182

hold related (*HLDRLTD) 171hot backup 13

Ii5/OS upgrade 303IFS objects

determining configuration 234file IDs (FIDs) 236hold user journal entries for 182path names 224resolving problems 180tracking entries for 179verifying journaling 200

immediate enddescription 143incomplete tracking entry 143

information and additional resources 11installation, status of

from 5250 emulator 50from MIMIX Availability Manager 48

IPL 302

Jjob log

for audit 96journal 17journal at create

requirements 192requirements and restrictions 193

journal cache or stateresolving problems 57status 72

journal definition 16defined to RJ Link 231

journal entrydescription 17unconfirmed 249

journal manager 16delay intervals 164ending 164, 165resolving problems 164starting 164

journal receiver 17journaling 17

cannot end 196data group problem with 56ending for data areas and data queues 202ending for IFS objects 199ending for physical files 196implicitly started 192requirements for starting 192starting for data areas and data queues 201

320

starting for IFS objects 198starting for physical files 195starting, ending, and verifying 191verifying for data areas and data queues 203verifying for IFS objects 200verifying for physical files 197

journaling statusdata areas and data queues 201files 195IFS objects 198

Kkeyed replication

verifying file attributes 252

Llast audit performed 98last switch performed 215log space 17logging in, first time 37long IFS path names 224

Mmanagement system 17manager

journal 16system 16

menuMIMIX Main 42

message queue, primary and secondary 167messages

ENDMMX 149STRMMX 149

MIMIX AutoGuard 15automatic recovery 18getting started 20introduction 18

MIMIX Availability Manager 15benefits 44monitoring status with 48

MIMIX CDP featureexclude from audit 23recovery point cleared 146

MIMIX installation 15MIMIX managers

ending 164resolving problems 164starting 164

MIMIX Model Switch Framework 16, 205

policy default 31MIMIX rules 19, 80

automatic audit recovery 82command prompting 83replacement variables 83

MIMIX subsystem (MIMIXSBS)starting 147when to end 148

MIMIX Switch Assistant 16best practice 205getting started 21setting default switch framework 208setting switch compliance policies 208using 212

MMNFYNEWE monitor 124monitor for newly created objects 124mxpswtichLiteLastperform 215mxpswtichLiteSwtCmply 216

Nnames, displaying long 224navigation bar status 46network system 17new hardware upgrade 313

prerequisites 313new objects

IFS object journal at create requirements 192journal at create selection criteria 193

newly created objects, notification of 124notifications

definition 19, 119displaying 120, 125new problems in installation 54severity level 20, 121status 121

Oobject auditing

concept 17setting level with STRDG 140used for replication 192

object error recovery, automatic 35objects

configuration of non-file 234displaying long IFS names 224displaying objects in error 67displaying objects with active entries 67in error, resolving 185new 192

321

reducing contention 242tracking entries for data areas and data queues 179

open commit cyclesaudit results 265, 267effect on clear pend start 139prevent a clear pend start 137prevent problems with 144resolving before clearing entries 140shown in status 153

operationscommon, where to start 44less common 221

orphaned recoveries 128outfiles

user profile password 300user profile status 297

output file fieldsDifference Indicator 265, 269System 1 Indicator field 271System 2 Indicator field 271

Ppath names, IFS 224planned switch 205policies 19

changing values 24considerations when choosing values 22for auditing 109for automatic recovery during replication 33for switching 208introduction 22

policyaction for running audits 30audit action threshold 29audit level 29audit notify on success 27audit rule 27audit schedule 32audit warning threshold 28automatic audit recovery 27automatic system journal recovery 27automatic user journal recovery 27CMPRCDCNT commit threshold 31data group definition 27default model switch framework 31independent ASP library ratio 31journaling attribute difference action 28maximum rule runtime 28

notification severity 27object only on target 28run rule on system 30switch action threshold 31switch warning threshold 31synchronize threshold size 30system journal recovery success 27third delay retry interval 30third delay retry interval, number of 30user journal apply threshold 28user journal recovery success 27

problemsreporting a problem 241troubleshoot 239where to start 239

problems, journalingdata areas and data queues 201files 195IFS objects 198

problems, resolvingaudit results 93, 95, 263common errors 163data group cannot end 243data group cannot start 248files in error 170files not journaled 57journal cache or state 57objects in error 185open commits when starting data group 140RJ link cannot end 249RJ link cannot start 249switch compliance 216tracking entries 179

production system 16publications, IBM 11

QQDFTJRN data area

restrictions 193role in processing new objects 193

QSTRUPPGM system value 303, 305

Rrecommendations

audit automatic recovery 82auditing 81audits and rules 82before planned switch 206policies in bi-directional environment 22

322

recoveriesactive in installation 54definition 19, 120detected database errors 34displaying details 125occurring in installation 125orphaned 128orphaned, identifying 128orphaned. removing 129

recovery phase 20recovery point

cleared by ENDDG 146release (*RLS)

held file entry 176held tracking entry 183

release clear (*RLSCLR)file entry 176tracking entry 184

release wait (*RLSWAIT)file entry 175tracking entry 183

remote journal (RJ) link 16remote journal environment

processes ended by ENDDG 159processes started by STRDG 155unconfirmed journal entry 249

removingactivity history entries 190duplicate tracking entries 184unconfirmed entries 249

reorganizing, active files 226replacement variables 83replication

automatic error recovery 33backlogs, identifying 76choices when ending 141choices when starting 133direction of 17ending 131resolve replication errors 163starting 131status from 5250 emulator 52status from MIMIX Availability Manager 48supported paths 13switching 204system journal 13user journal 13

replication path 15replication, problems

troubleshoot 239

where to start 163requirements

audits 81journal at create 192journaling 192MIMIX AutoGuard 81

resolving problemscommon replication errors 163troubleshooting 239

restore MIMIXprerequisites 314

restrictionsjournal at create 193QDFTJRN data area 193

resultsuser-defined rules 118

retry objects in error 188retrying, data group activity entries 188RJ link 16

displaying 227ending independently 237errors for target journal of 251identifying data groups that use 230journal definitions by an 231operating without a data group 237removing unconfirmed entries 249status 228when to end 145

rule#DGFE 104#DLOATR 105#FILATR 104#FILATRMBR 105#FILDTA 105#IFSATR 105#OBJATR 104user-defined, results of 118

rules 80advantages of using 18business 18considerations for using 82messages from 84MIMIX 19, 80notifications from 84relationship with rules 80replacement variables 83requirements 81run command considerations 83run on management system 83types 80

323

rules, MIMIXdescriptions 104

runningaudits immediately 91rule groups 115rules 115

Sschedule

audit considerations 105automatic audit 104default audit 104

schedule, shipped audit 104servers

ending TCP 223starting TCP 222

servicesstatus from 5250 emulator 53status from MIMIX Availability Manager 49

severity level, notification 121source system 17spooled files, displaying MIMIX-created 224starting

MIMIX managers 164RJ link independently 237system and journal managers 164TCP server 222

starting data groupat specified journal location 135considerations 133, 135prevented when open commit cycles 137, 139procedure 150processes, effect of 155set object auditing level 140when to clear entries 136

starting journalingdata areas and data queues 201file entry 195files 195IFS objects 198IFS tracking entry 198object tracking entry 201

starting MIMIXconsiderations 133included processes 133procedure 147

starting replication 131choices and considerations 133

statusactive file operations 226audit compliance 100audit runtime and compliance 85audits 87, 90audits (runtime) 48, 52checking from 5250 emulator 50checking from MIMIX Availability Manager 48data group detail 61, 64data group summary 48, 52database apply (DBAPY) 71enterprise view 45installation summary 50introduction 45journal cache or state 72journaling data areas and data queues 201journaling files 195journaling IFS objects 198journaling tracking entries 198, 201notification 121notification new in installation 52recoveries active in installation 125replication 48, 52RJ link 228services 49, 53switch compliance 215switching 59, 212Work with Data Groups display 54

subsystem, MIMIXSBSended 177ending 148starting 147

Switch Assistant, MIMIX 16, 212getting started 21

switch frameworkdisable policy when not used 210specify a default 208

switching 204best practice 20, 204, 205, 215change audit level before 82, 210compliance 215conditions that end 219description, planned switch 205description, unplanned switch 206getting started with MIMIX Switch Assistant 21journal analysis after unplanned switch 258last switch field 215phases of a 205policies for 208

324

problems checking compliance 216reasons for 205setting switch compliance policies 208, 209setting switch framework policy 208switch framework vs. SWTDG command 205SWTDG command details 219unplanned, actions to complete an 207using MIMIX Switch Assistant 212using option on MIMIX Basic Main Menu 212using STRDG command 217

synchronizefile entry 171objects, system journal replicated 187tracking entries 182

system definition 16system journal replication 13

detailed status 61, 69errors automatically recovered 34journaling requirements 192

system manager 16delay intervals 164ending 164, 165resolving problems 164starting 164

system rolesmanagement or network 17production or backup 16source or target 17

Ttarget system 17threshold

audit action 29audit warning 28CMPRCDCNT open commit 31switch action 31switch warning 31synchronize size 30user journal apply 28

timestamps 254automatically created 254creating additional 254deleting 256displaying 256printing 256

tipsdisplaying data group spooled files 224displaying long IFS object names 224removing journaled changes 257

working with active file operations 226tracking entry 15

file identifiers (FIDs) 236IFS 179incomplete 143not journaled 57object 179removing duplicate 184

transfer definition 16

Uunconfirmed journal entries, removing 249unplanned switch 206

performing journal analysis 258unprocessed entries 153upgrade

hardware, no disk image change 310hardware, with a disk image change 313new hardware 313OS/400 303

user journal replication 13detailed status 61, 71errors automatically recovered 33journaling requirements 192non-file objects 234tracking entries 179tracking entry 15

user profilepassword 300status 297

Vverifying

communications link 244, 245journaling, IFS tracking entries 200journaling, object tracking entries 203journaling, physical files 197key attributes 252

viewing status, active file operations 226

Wwait time, data group controlled end 144wait time, data group controlled end during switch 219windows, layout for 37

325