Sunteți pe pagina 1din 325
MIMIX ha1 ™ and MIMIX ha Lite ™ for IBM ® i Using MIMIX Version

MIMIX ha1 and MIMIX ha Lite for IBM ® i

Using MIMIX

Version 6.0

Published: December 2009 level 6.0.15.00

for IBM ® i Using MIMIX Version 6.0 Published: December 2009 level 6.0.15.00 Copyrights, Trademarks, and

Copyrights, Trademarks, and Notices

 

Product conventions

9

Menus and commands

9

Accessing online help

9

Publication conventions

9

Formatting for displays and commands

10

Sources for additional information

11

How to contact us

12

Chapter 1

MIMIX overview

13

MIMIX concepts

15

MIMIX AutoGuard overview

18

Key concepts for MIMIX AutoGuard

18

Auditing overview

19

What are MIMIX AutoGuard best practices?

20

How do I get started with MIMIX AutoGuard?

20

New MIMIX installations

21

MIMIX policies

22

Considerations when choosing policy values

22

When not to use MIMIX AutoGuard

23

Setting policies - general

24

To change existing installation policies

24

To change policies for a data group

25

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

25

Disabling MIMIX AutoGuard for data groups using the MIMIX CDP feature

26

Policy descriptions

27

Policies for recovery during replication

33

Errors handled by automatic database recovery

33

Errors handled by automatic object recovery

34

Logging in to MIMIX Availability Manager

37

Your location is remembered

37

Areas of the window in MIMIX Availability Manager

37

Additional navigation and selection aids

39

Other useful tips

41

Accessing the MIMIX Main Menu from a 5250 emulator

42

Chapter 2

Working with status

44

Becoming acquainted with status

45

Status in MIMIX Availability Manager

45

The Enterprise View - your status shortcut

45

Status on the navigation bar

46

Monitoring status with MIMIX Availability Manager

48

Checking replication status with MIMIX Availability Manager

48

Checking audit status with MIMIX Availability Manager

48

Checking status of supporting services with MIMIX Availability Manager

49

Monitoring status with MIMIX Availability Status

50

Checking replication status - 5250 emulator

52

Checking audit and notification status - 5250 emulator

52

Checking for status of supporting services - 5250 emulator

53

The Work with Data Groups display - 5250 emulator

54

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

56

 

Problems reflected in the Data Group column

56

Resolving problems highlighted in the Data Group column

57

Replication problems reflected in the Source and Target columns

59

Setting the automatic refresh interval

60

Working with the detailed status of data groups

61

Displaying data group detailed status with MIMIX Availability Manager

61

Variations of the Data Group Details - Activity window

64

Displaying data group detailed status from a 5250 emulator

64

Merged view

65

Object detailed status views

69

Database detailed status views

71

Identifying replication processes with backlogs

76

Chapter 3

Working with audits and rules

79

What are rules and how they are used by auditing

80

Requirements for using audits and rules

81

Guidelines and recommendations for auditing

81

Considerations and recommendations for rules

82

Replacement variables

83

Rule-generated messages and notifications

84

Where audit status and compliance status is reported

85

Working with audits

87

Displaying audit status

90

Running audits immediately

91

Ending audits

91

Displaying audit level differences

92

Resolving audit problems - MIMIX Availability Manager

93

Resolving audit problems - 5250 emulator

95

Checking the job log of an audit

96

Working with audit compliance

98

Determining whether auditing is within compliance

100

Working with audit schedules

102

How audits are scheduled automatically

104

Shipped default audit schedules

104

Considerations for changing audit scheduling

105

When to run the #DGFE audit

106

Changing when audits are scheduled

106

Schedule parameter notes

107

Changing the system where audits are performed

108

Considerations for using a different job scheduler for audits

108

Policies for auditing

109

Preventing audits from running

110

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

110

To restrict audit activity for a specific data group based on its state

111

To disable auditing for an installation

112

To disable auditing for a data group

113

To disable automatic scheduling of an audit

113

Running rules and rule groups manually

115

Running rules or rule groups from within MIMIX Availability Manager

115

Running rules or rule groups from the Rules window

115

 

Running rules or rule groups from the Data Groups window

116

Running rules from the 5250 emulator

116

Running rule groups from the 5250 emulator

117

Checking results of a user-defined rule

118

Chapter 4

Working with notifications and recoveries

119

What are notifications and recoveries

119

Displaying notifications

120

What information is available for notifications

121

Detailed information

122

Options for working with notifications

122

Notifications for newly created objects

124

Displaying recoveries

125

What information is available for recoveries

126

Detailed information

127

Options for working with recoveries

127

Orphaned recoveries

128

Determining whether a recovery is orphaned

128

Removing an orphaned recovery

129

Chapter 5

Starting and ending replication

131

Choices when starting replication

133

What is started with the STRMMX command

133

Considerations for starting data groups

135

When to clear pending entries and entries in error

136

Clear pending and clear error processing

136

Clearing pending entries when open commit cycles exist

139

Checking for open commit cycles

139

Resolving open commit cycles to enable a clear pending start

140

Setting the audit level when starting a data group

140

Choices when ending replication

141

What is ended by the ENDMMX command

142

Ending immediately or controlled

143

Controlling how long to wait for a controlled end to complete

144

Ending all or selected processes

144

When to end the RJ link

144

Considerations for ending data groups

146

Starting MIMIX

147

Ending MIMIX

147

Ending with default values

147

Ending by prompting the ENDMMX command

148

After you end MIMIX products

148

STRMMX and ENDMMX messages

149

Starting selected data group processes

150

Ending selected data group processes

151

Ending a data group in a controlled manner

152

Preparing for a controlled end of a data group

152

Performing the controlled end

152

Confirming the end request completed without problems

153

What replication processes are started by the STRDG command

155

What replication processes are ended by the ENDDG command

159

Chapter 6

Resolving common replication problems

163

Working with MIMIX managers

164

Resolving status problems with system and journal managers

164

Starting a system manager or a journal manager

165

Ending a system manager or a journal manager

165

Working with message queues

167

Working with the message log

168

Working with user journal replicated files

170

Working with files in error

170

Working with journal transactions for files in error

173

Placing a file on hold

174

Ignoring a held file

174

Releasing a held file at a synchronization point

175

Releasing a held file

176

Releasing a held file and clearing entries

176

Correcting file-level errors

176

Correcting record-level errors

177

Record written in error

177

Working with tracking entries

179

Working with tracking entries from MIMIX Availability Manager

179

Accessing the Data Group Details - Activity window

179

Working with tracking entries from a 5250 emulator

180

Accessing the appropriate tracking entry display

180

Holding journal entries associated with a tracking entry

182

Ignoring journal entries associated with a tracking entry

182

Waiting to synchronize and release held journal entries for a tracking entry

183

Releasing held journal entries for a tracking entry

183

Releasing and clearing held journal entries for a tracking entry

184

Removing a tracking entry

184

Working with objects in error

185

Using the Work with DG Activity Entries display

186

Retrying data group activity entries

188

Retrying a failed data group activity entry

188

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

189

Removing data group activity history entries

190

Chapter 7

Starting, ending, and verifying journaling

191

What objects need to be journaled

192

Authority requirements for starting journaling

193

MIMIX commands for starting journaling

194

Journaling for physical files

195

Displaying journaling status for physical files

195

Starting journaling for physical files

195

Ending journaling for physical files

196

Verifying journaling for physical files

197

Journaling for IFS objects

198

Displaying journaling status for IFS objects

198

 

Starting journaling for IFS objects

198

Ending journaling for IFS objects

199

Verifying journaling for IFS objects

200

Journaling for data areas and data queues

201

Displaying journaling status for data areas and data queues

201

Starting journaling for data areas and data queues

201

Ending journaling for data areas and data queues

202

Verifying journaling for data areas and data queues

203

Chapter 8

Switching

204

About switching

204

MIMIX Model Switch Framework

205

Planned Switch

205

Unplanned switch

206

Setting policies for switching

208

Specifying a default switch framework in policies

208

Setting polices for MIMIX Switch Assistant

208

Setting policies for switch compliance for a specific data group

209

Setting policies when MIMIX Switch Assistant is not used

210

Changing the audit level policy for switching

210

Switching using MIMIX Switch Assistant

212

Switching from the MIMIX Basic Main Menu

212

Switching to the backup system

213

Synchronizing data and starting MIMIX on the original production system

214

Switching to the production system

214

Determining when the last switch was performed

215

Checking the last switch dates from MIMIX Availability Manager

215

Checking the last switch date from a 5250 emulator

216

Problems checking switch compliance

216

Performing a data group switch

217

Performing a data group switch from MIMIX Availability Manager

217

Performing a data group switch from a 5250 emulator

217

Switch Data Group (SWTDG) command

219

Chapter 9

Less common operations

221

Starting the TCP/IP server

222

Ending the TCP/IP server

223

Working with objects

224

Displaying long object names

224

Considerations for working with long IFS path names

224

Displaying data group spooled file information

224

Viewing status for active file operations

226

Displaying a remote journal link

227

Displaying status of a remote journal link

228

Identifying data groups that use an RJ link

230

Identifying journal definitions used with RJ

231

Disabling and enabling data groups

232

Procedures for disabling and enabling data groups

233

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

234

Determining how IFS objects are configured

234

 

Determining how data areas or data queues are configured

235

Using file identifiers (FIDs) for IFS objects

236

Operating a remote journal link independently

237

Starting a remote journal link independently

237

Ending a remote journal link independently

237

Chapter 10

Troubleshooting - where to start

239

Gathering information before reporting a problem

241

Obtaining MIMIX and IBM i information from your system

241

Reducing contention between MIMIX and user applications

242

Data groups cannot be ended

243

Verifying a communications link for system definitions

244

Verifying the communications link for a data group

245

Verifying all communications links

245

Checking file entry configuration manually

246

Data groups cannot be started

248

Cannot start or end an RJ link

249

Removing unconfirmed entries to free an RJ link

249

RJ link active but data not transferring

250

Errors using target journal defined by RJ link

251

Verifying data group file entries

252

Verifying data group data area entries

252

Verifying key attributes

252

Working with data group timestamps

254

Automatically creating timestamps

254

Creating additional timestamps

254

Creating timestamps for remote journaling processing

255

Deleting timestamps

256

Displaying or printing timestamps

256

Removing journaled changes

257

Performing journal analysis

258

Removing journal analysis entries for a selected file

260

Appendix A

Interpreting audit results - supporting information

262

Interpreting results for configuration data - #DGFE audit

263

Interpreting results of audits for record counts and file data

265

What differences were detected by #FILDTA

265

What differences were detected by #MBRRCDCNT

267

Interpreting results of audits that compare attributes

268

What attribute differences were detected

269

Where was the difference detected

271

What attributes were compared

272

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

273

Attributes compared and expected results - #OBJATR audit

278

Attributes compared and expected results - #IFSATR audit

286

Attributes compared and expected results - #DLOATR audit

288

Comparison results for journal status and other journal attributes

290

How configured journaling settings are determined

293

Comparison results for auxiliary storage pool ID (*ASP)

294

Comparison results for user profile status (*USRPRFSTS)

297

 

How configured user profile status is determined

298

Comparison results for user profile password (*PRFPWDIND)

300

Appendix B

IBM Power Systems operations that affect MIMIX

302

MIMIX procedures when performing an initial program load (IPL)

302

MIMIX procedures when performing an operating system upgrade

303

Prerequisites for performing an OS upgrade on either system

304

MIMIX-specific steps for an OS upgrade on the backup system

305

MIMIX-specific steps for an OS upgrade on the production system with switching

307

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

ing

308

MIMIX procedures when upgrading hardware without a disk image change

310

Considerations for performing a hardware system upgrade without a disk image

change

310

MIMIX-specific steps for a hardware upgrade without a disk image change

311

Hardware upgrade without a disk image change - preliminary steps

311

Hardware upgrade without a disk image change - subsequent steps

312

MIMIX procedures when performing a hardware upgrade with a disk image change

313

Considerations for performing a hardware system upgrade with a disk image change

313

Handling MIMIX during a system restore

314

Prerequisites for performing a restore of MIMIX

314

Index

316

Product conventions

Product conventions

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

Menus and commands

Functionality for all MIMIX products is accessible from a common MIMIX Main Menu. The options you see on a given menu may vary according to which products are installed.

When there is a corresponding command for a menu option, the command is shown at the far right of the display. You can use either the menu option or the command to access the function.

To issue a command from a command line outside of the menu interface, you can add the product library name to your library list or you can qualify the command with the name of the product library.

If you enter a command without parameters, the system will prompt you for any required parameters. If you enter the command with all of the required parameters, the function is invoked immediately. Some commands can be submitted in batch jobs.

Accessing online help

MIMIX Availability Manager includes online help that is accessible from within the product. From any window within MIMIX Availability Manager, selecting the Help icon will open the help system and access help for the current window.

From a 5250 emulator, context sensitive online help is available for all MIMIX commands and displays. Simply press F1 to view help. The position of your cursor determines what you will see.

• To view general help for a command, a display, or a menu, press F1 when the cursor is at the top of the display.

• To view help for a specific option, promp t, or column, press F1 when the cursor is located in the area for which you want help.

Publication conventions

This book uses typography and specialized formatting to help you quickly identify the type of information you are reading. For example, specialized styles and techniques distinguish information you see on a display from information you enter on a display or command line. In text, bold type identifies a new term whereas an underlined word highlights its importance. Notes and Attentions are specialized formatting techniques that are used, respectively, to highlight a fact or to warn you of the potential for damage. The following topics illustrate formatting techniques that may be used in this book.

Formatting for displays and commands

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

Table 1.

Formatting examples for displays and commands

Convention

Description

Examples

Initial

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

Capitalization

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

Sources for additional information

Sources for additional information

This book refers to other published information. The following information, plus additional technical information, can be located in the IBM System i and i5/OS Information Center.

From the Information center you can access these IBM Power TM Systems topics, books, and redbooks:

Backup and Recovery

Journal management

DB2 Universal Database for IBM Power TM 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 Power TM 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

How to contact us

For contact information, visit our Contact CustomerCare web page.

If you are current on maintenance, support for MIMIX products is also available when you log in to Support Central.

It is important to include product and version information whenever you report problems. If you use MIMIX Availability Manager, you should also include the version information provided at the bottom of each MIMIX Availability Manager window.

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

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.

MIMIX concepts

MIMIX concepts

The basic concepts associated with MIMIX ® are identified below. More detailed information is available in the MIMIX Reference book.

MIMIX installation - The network of IBM Power TM 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.

• 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

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.

MIMIX AutoGuard overview

MIMIX ® AutoGuard significantly simplifies the amount of time and effort required to maintain your MIMIX environment for availability and switch-readiness. MIMIX AutoGuard does this by automatically checking for differences in the data and object attributes that you replicate between systems and correcting detected differences. The checks and corrections are performed during replication processes and during a series of scheduled audits. MIMIX is shipped with these capabilities of MIMIX AutoGuard enabled.

During replication, MIMIX AutoGuard resolves any differences detected between your source and target systems to ensure up-to-the-minute accuracy. During a series of automatic, regularly scheduled audits, MIMIX AutoGuard checks for differences between the source and target systems and resolves any detected differences to ensure that you are switch-ready at all times.

MIMIX AutoGuard helps you comply with best practices for maintaining availability and switch-readiness, and therefore is key to ensuring that your MIMIX environment is in tip-top shape for protecting your data. MIMIX AutoGuard incorporates best practices with user interfaces and underlying functionality so that you can fine-tune policies, see compliance information reflected in status, and access the reports and results of actions MIMIX AutoGuard takes to keep your environment synchronized.

Key concepts for MIMIX AutoGuard

All businesses run under a set of rules or guidelines. While some rules may be informally enforced, others are strictly enforced by a company's business processes or by the applications in use. In a MIMIX environment, maintaining availability and switch-readiness at all times also requires following a set of guidelines or rules.

MIMIX provides the framework necessary to incorporate the business rules necessary to support your availability requirements. This framework provides the means by which to define, enforce, and report rules. The functions provided by MIMIX ® AutoGuard use this rule framework because it enables earlier and easier detection of problems known to adversely affect availability or your ability to switch in a MIMIX environment.

The key concepts associated with MIMIX AutoGuard are identified below.

Audits - Audits are predetermined programs that are used to check for known conditions, preferably at regularly scheduled intervals. Audits use all of the concepts described here as well as additional concepts of their own, described in “Auditing overview” on page 19.

Automatic recovery - MIMIX is shipped so that automatic recovery is enabled for database replication, object replication, and auditing. This means that, if MIMIX AutoGuard detects any of a set of scenarios during these activities which are known to interfere with maintaining your MIMIX environment, it will automatically start recovery actions to correct them. Through policies, you have the ability to disable automatic recovery in any of these areas at the installation or data group level.

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 overview

Multiple audits exist for each data group. Each audit identifies a data group to be checked and the MIMIX rule used to check it.

MIMIX rules are the mechanism by which audits are defined and invoked. Each shipped MIMIX rule pre-defines a compare command to be invoked and the possible actions that can be initiated, if needed, to correct detected problems.

MIMIX ships with default scheduling information associated with each MIMIX rule. MIMIX uses this scheduling information to automatically schedule audit requests on a regular basis. Scheduling can be adjusted for individual audits through policies.

When MIMIX submits an audit request, a job is run on both systems associated with the data group being checked. MIMIX first checks the Run rule on system policy to determine where the audit should run and immediately ends the request that is not on the appropriate system.

The process of auditing consists of a compare phase and a recovery phase.

In the compare phase of an audit, the identified MIMIX rule initiates a specific compare command against the data group. The audit level policy determines how aggressively an audit checks your environment during its compare phase.

Each MIMIX rule has the capability of providing multiple audit levels. If a MIMIX rule provides more than one audit level, each level provides increasingly more checking

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

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.

MIMIX policies

MIMIX policies control whether functions provided by MIMIX AutoGuard and MIMIX Switch Assistant are enabled and specify when and how you are notified about problems that may occur. The shipped default settings for policies apply to all systems and data groups within an installation. With the Set MIMIX Policy (SETMMXPCY) command, you can change the values in effect for the installation as well as specify policies for an individual data group. When a policy is set for a data group, it takes precedence over the installation policy.

Policies must be changed from the management system. Changing policies requires that you have management-level authority to the Set MIMIX Policy (SETMMXPCY) command.

When policies apply to an area in MIMIX Availability Manager, an option to change them is available as an action.

From a 5250 emulator, you can set policies from a command line or from the Work with Audits, the MIMIX Availability Status, and the Work with DG Definitions displays.

Considerations when choosing policy values

Policy values may affect data throughout your entire environment, not just a single installation or data group. This is of particular concern in environments that have more than two systems or which have replication occurring simultaneously in more than one direction (bi-directional). Specifically, be aware of the following:

• In these environments, the value *DISABLED for the Objects only on target policy is recommended. When the policy is disabled, audits will detect that objects exist only on the target system but will not attempt to correct them. The commands used by an audit are aware of all objects on the target system, not just those which originate from the source system of the data group associated with the audit. In these environments, the values *DELETE and *SYNC must be used with care. When the policy value is Delete, audits will delete objects which may have originated from systems not associated with the data group being audited. When the policy value is Synchronize, audits will synchronize the objects to the source system of the data group being audited, which may not be the source system from which they originated.

• Synchronization of user profiles and authorization lists associated with an object will occur unless the user profiles and authorization lists are explicitly excluded from the data group configuration. In the environments mentioned, this may result in user profiles and authorization lists being synchronized to other systems in your configuration. This behavior occurs whenever any of the automatic recovery policies are enabled (database, object, audit). To prevent this from occurring, you must explicitly exclude the user profiles and authorization lists from replication for any data group for which you do not want them synchronized.

• In a simultaneously bi-directional environment, determine which system ‘wins’ in the event of a data conflict, that is, which system will be considered as having the correct data. Choose one direction of replication that will be audited and allow auditing for those data groups. Disable audits for data groups that replicate in the

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 AutoGuard

At times, you may need to disable automatic auditing for certain data groups because a feature in use or an application being replicated may interact with auditing in an undesirable way.

Features - Do not use MIMIX AutoGuard with any data group that is using functions provided by the MIMIX CDP feature. This feature, which requires an additional access code, permits you to perform operations associated with maintaining continuous data protection. By configuring a recovery window for a data group, you introduce an automatic delay into when the apply processes complete replication. By setting a recovery point for a data group, you identify a point that, when reached, will cause the apply processes to be suspended.

In both cases, source system changes have been transferred to the target system but have not been applied. In such an environment, MIMIX AutoGuard comparisons will report differences and attempt recovery for items that have not completed replication. To prevent this from occurring, disable co mparisons 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.

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

To exclude a data group from audits, use the instructions in “Disabling MIMIX AutoGuard for data groups using the MIMIX CDP feature” on page 26.

Setting policies - general

Policies must be changed from the management system. Changing policies requires that you have management-level authority to the Set MIMIX Policy (SETMMXPCY) command.

When you are viewing a management system from within MIMIX Availability Manager, several windows have actions available for changing policies. Actions to change policies are available from the windows resulting from your selection of any of the following from the Details area of the navigation bar: Data Groups, Services, Switching, Summary, or Compliance. If you select Policies, the MIMIX Policies window displays current settings and the Details action can be used to change policies.

The following procedures describe the basic procedures for setting policies.

For procedures specific to setting policies for auditing and switching environments, see “Policies for auditing” on page 109 and “Setting policies for switching” on page 208.

To change existing installation policies

Note:

This procedure changes a policy value at the installation level. The installation level value can be overridden by a data group level policy value. Therefore, if a data group has value other than *INST for this policy, that value remains in effect.

From MIMIX Availability Manager, the action to change installation policies is only available when the system you are viewing is the management system

1. Select the Change Installation Policies action and click

2. You will see Installation Policy near the top of the window. The current values of policies are displayed. Specify a value for the policy you want to change.

3. To accept the changes, click OK.

From a 5250 emulator, do the following from the management system:

1. From the command line type SETMMXPCY and press F4 (Prompt).

2. Verify that the value specified for Data group definition is *INST.

.
.

MIMIX policies

3. Press Enter to see all the policies and their current values.

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

5. To accept the changes, press Enter.

To change policies for a data group

From MIMIX Availability Manager, the action to change policies for a data group is only available when the system you are viewing is the management system

1. For the data group you want, select the Change Policies action and click

2. The selected data group is listed near the top of the window and current values of its policies are displayed. Select a value for the policy you want to change.

3. To accept the changes, click OK.

From a 5250 emulator, do the following from the management system:

1. From the command line type SETMMXPCY and press F4 (Prompt).

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

3. Press Enter to see all the policies and their current values.

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

5. To accept the changes, press Enter.

.
.

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

From MIMIX Availability Manager, the action to change policies for a data group is only available when the system you are viewing is the management system

1. For the data group you want, select the Change Policies action and click

2. The selected data group is listed near the top of the window and current values of its policies are displayed. For the policy you want to change, select Use installation default.

3. To accept the changes, click OK.

From a 5250 emulator, do the following from the management system:

1. From the command line type SETMMXPCY and press F4 (Prompt).

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

3. Press Enter to see all the policies and their current values.

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

5. To accept the changes, press Enter.

.
.

Disabling MIMIX AutoGuard for data groups using the MIMIX CDP feature

The functions provided by the MIMIX CDP feature 1 create an environment in which source system changes have been transferred to the target system but have not been applied. Any data group which uses this feature must disable automatic comparisons and automatic recovery actions for the data group

From MIMIX Availability Manager, the action to change policies for a data group is only available when the system you are viewing is the management system. Do the following:

1. Ensure that you have the management system selected in the navigation bar. If you are not certain which system is the management system, you can select Services to check.

2. Select Data Groups from the navigation bar. From the list of data groups, select the data group that uses the MIMIX CDP feature.

3. From within the Summary area, select the Change Policies action and click

4. Verify that the expected data group is listed near the top of the window. If you see Installation Policy, close the window and start again.

5. For Automatic system journal recovery, select Disable.

6. For Automatic user journal recovery, select Disable.

7. For Automatic audit recovery, select Disable.

8. For Audit level, select Disable.

9. To accept the changes, click OK.

From a 5250 emulator, do the following from the management system:

1. From the command line type SETMMXPCY and press F4 (Prompt).

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

3. Press Enter to see all the policies and their current values.

4. For Automatic object recovery, specify *DISABLED.

5. For Automatic database recovery, specify *DISABLED.

6. For Automatic audit recovery, specify *DISABLED.

7. For Audit level, select *DISABLED.

8. To accept the changes, press Enter.

.
.

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

Policy descriptions

There are minor differences in the names of policies between MIMIX Availability Manager and the 5250 emulator. The names shown here are those used in MIMIX Availability Manager. For a complete description of all policy values, see online help for the command.

Data group definition - Select the scope of the policies to be set. When the value *INST is specified, the policies being set by the command apply to all systems and data groups in the installation, with the exception of any policy for which a data 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

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.

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.

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.

Note:

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.

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.

Note:

Audit level - Select the level of comparison that an audit will perform when a MIMIX rule which supports multiple levels is invoked against a data group. The policy is in effect regardless of how the rule is invoked. The amount of checking performed increases with the level number. This policy makes it easy to change the level of audit performed without changing the audit scheduling or rules. No auditing is performed if this policy is set to *DISABLED.

Note:

Best practice is to use level 30 to perform the most extensive audit. If you use a lower level, consider its effect on how often you need to be certain that data

is synchronized between source and target systems. For additional information, see “Changing the audit level policy for switching” on page 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 condition 1 . 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.

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

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.

Policies for recovery during replication

Policies for recovery during replication

MIMIX AutoGuard can automatically attempt to correct problems it encounters during replication. Table 2 shows these policies and their shipped default values.

Table 2.

Policies associated with automatic recovery during replication, with shipped default values

Policy

Shipped Values

MIMIX AutoGuard

 

Installation

Data

Object

Database

 

Groups

Replication

Replication

Data group definition

*INST

Name 1

Yes

Yes

Automatic system journal recovery

*ENABLED

*INST 1

Yes 2

Automatic user journal recovery

*ENABLED

*INST

Yes 2

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

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.

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

When automatic recovery policies are enabled, MIMIX will attempt to recover errors it detects during the replication process. The following topics identify what errors can be recovered in this way:

“Errors handled by automatic database recovery” on page 33

“Errors handled by automatic object recovery” on page 34

Errors handled by automatic database recovery

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

The recovery action also sends a report of a recovery in progress to the user interface. In MIMIX Availability Manager, these reports are located on the Recoveries page. In a 5250 emulator, the reports are on the Work with Recoveries display (WRKRCY command). When the recovery action completes, the report is removed.

The DB rcy. notify on success policy determines whether a successful recovery generates an informational notification.

Only when all recovery options are exhausted without success is a file placed in hold error (*HLDERR) status. Recovery actions that end in an error do not generate a separate error notification because the error is already reflected in MIMIX status.

Table 3.

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.

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.

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

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.

on target

system 1

• 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 system 1

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

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

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.

Table 4.

Errors detected and recoveries attempted by object autonomics during object replication

Error

Description

In-use

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:

condition

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.

Logging in to MIMIX Availability Manager

Logging in to MIMIX Availability Manager

The first time you log in to MIMIX Availability Manager, you could see one of several windows.

• If you are logged in to the available systems and there are problems, you will see the system and installation with the highest severity problem.

• If there are no problems on any of the systems in view, you will see the Enterprise view.

• If you did not log in to any systems when you logged in to the server, you will see the Login window for the first system. Log in to the system so you can continue. You may be prompted to select an installation.

For many windows, you can adjust the amount of information displayed by changing preferences. You can change preferences at any time.

Many tasks can be performed in the main window. Some tasks launch a new window while leaving the main window active. You can easily close the new window by using the Close button.

Your location is remembered

Once you visit a location, MIMIX Availability Manager remembers that you were there. For example, say you viewed notifications for installation ABC, then viewed data group status for installation XYZ. The next time you return to installation ABC, MIMIX Availability Manager will display the notifications.

When you select a system in the Enterprise view, your location is reset. You will be taken to the most severe problem. If there are no problems, you will be taken to the first data group on the Data Group Status page. If you are not logged in to the system, you will be taken to the Login window for that system.

Areas of the window in MIMIX Availability Manager

MIMIX Availability Manager uses a similar layout for every window, shown in Figure 1. The primary elements of every window are:

Title bar - The title bar includes buttons for accessing online help. It also includes navigational buttons, as needed, to close a secondary window or return to the previously viewed window.

Navigation bar - The vertical navigation bar is both a navigational tool and a 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.

Note:

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.

Some windows may not have the bar or selected areas of the navigation bar.

Figure 1.

Basic window layout

areas of the navigation bar. Figure 1. Basic window layout The content area of the Data

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

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.

Unique content area layout for the Data Group Status window. Additional navigation and selection aids Navigation

Additional navigation and selection aids

Navigation within the MIMIX Availability Manager is simple and predictable. Elements such as the navigation bar, buttons, filters, and drop-down lists, function consistently throughout the interface with few exceptions.

Flyover help - Flyover help provides the first level of information about a problem or item and often identifies a predetermined action. This type of help is available for most status icons, buttons, and actions. To see flyover help, hover over the interface element with your mouse pointer. In many cases, clicking on the element will take an action that is indicated by its flyover help. For example, flyover help for a problem action button indicates what action is available; clicking on the button takes you to a command that will resolve the problem or takes you directly to the correct window where you can see the error and take steps to resolve the problem.

Status icons - Icons always represent status. Each icon has a unique shape and color combination. Many status icons are also links which provide a shortcut to a predetermined action or additional information. Flyover help identifies both the status

and the action that will occur when clicked. The following provides an overview of common status icons:

Status icons - overview

Status

Description

Action requiredstatus icons: Status icons - overview Status Description Unknown Partially Active Ended Switching Attention Unknown

UnknownStatus icons - overview Status Description Action required Partially Active Ended Switching Attention Unknown (No icon)

Partially Activeicons - overview Status Description Action required Unknown Ended Switching Attention Unknown (No icon) Active Disabled

EndedStatus Description Action required Unknown Partially Active Switching Attention Unknown (No icon) Active Disabled An

Switching Description Action required Unknown Partially Active Ended Attention Unknown (No icon) Active Disabled An error

AttentionAction required Unknown Partially Active Ended Switching Unknown (No icon) Active Disabled An error occurred.

Unknownrequired Unknown Partially Active Ended Switching Attention (No icon) Active Disabled An error occurred. Immediate user

(No icon) Active

DisabledActive Ended Switching Attention Unknown (No icon) Active An error occurred. Immediate user action is required.

An error occurred. Immediate user action is required.

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

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

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

One or more data groups is in the process of switching which system is used as the source for replication. User action may be necessary.

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

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

Processes are active.

The process has been disabled.

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

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

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.

specify filter criteria for items within the current window. on the toolbar and not associated with

on the toolbar and not associated with a drop-down list

Other useful tips

Actions that can cause changes to your MIMIX environment always have confirmations. Other actions such as displaying more information do not have confirmations.

Buttons can appear in the toolbar or within areas of a window. They may include a graphic, text, or both. Buttons are always gray.

When selecting an action that prompts a command, MIMIX Availability Manager preselects values on the command based on the item you selected. For example, selecting the action to start system managers from the Services window will prompt the Start MIMIX Managers command and will preselect system managers (*SYSMGR) in the appropriate field.

Accessing the MIMIX Main Menu from a 5250 emulator

The MIMIX command accesses the main menu for a MIMIX installation. The MIMIX Main Menu has two assistance levels, basic and intermediate. The command defaults to the basic assistance level, shown in Figure 3, with its options designed to simplify day-to-day interaction with MIMIX. Figure 4 shows the intermediate assistance level.

The options on the menu vary with the assistance level. In either assistance level, the available options also depend on the MIMIX products installed in the installation library and their licensing. The products installed and the licensing also affect subsequent menus and displays.

Accessing the menu - If you know the name of the MIMIX installation you want, you can use the name to library-qualify the command, as follows:

Type the command library-name /MIMIX and press Enter. The default name of the installation library is MIMIX.

If you do not know the name of the library, do the following:

1. Type the command LAKEVIEW/WRKPRD and press Enter.

2. Type a 9 (Display product menu) next to the product in the library you want on the Lakeview Technology Installed Products display and press Enter.

Changing the assistance level - The F21 key (Assistance level) on the main menu toggles between basic and intermediate levels of the menu. You can also specify the the Assistance Level (ASTLVL) parameter on the MIMIX command.

Note:

Procedures are written assuming you are using the MIMIX Availability Status (WRKMMXSTS) display, which can only be selected from the MIMIX Basic

Accessing the MIMIX Main Menu from a 5250 emulator

Main Menu. We recommend you use the MIMIX Basic Main Menu unless you must access the MIMIX Intermediate Main Menu.

Figure 3.

MIMIX Basic Main Menu

MIMIX Basic Main Menu

MIMIX

Select one of the following:

System:

SYSTEM1

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.

Figure 4.

MIMIX Intermediate Main Menu

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.

Working with status

CHAPTER 2 Working with status

This chapter describes common MIMIX operations that help keep your MIMIX environment running. In order for MIMIX to provide a hot backup of your critical information, all processes associated with replication must be active at all times. Supporting service jobs must also be active. MIMIX allows you to display and monitor the statuses of these processes.

While you can perform common operations, such as monitoring status, from either MIMIX Availability Manager or a 5250 emulator, MIMIX Availability Manager is preferred. MIMIX Availability Manager provides significant benefits over a 5250 emulator, including:

• Enterprise view of all installations and systems using MIMIX

• Ability to take you directly to the highest severity problem per installation

• Suggested resolution for each unique problem

The topics included in this chapter are:

“Becoming acquainted with status” on page 45 describes how status bubbles up within MIMIX Availability Manager to include the highest severity errors.

“Monitoring status with MIMIX Availability Manager” on page 48 describes how to check status of replication processes and supporting services from MIMIX Availability Manager.

“Monitoring status with MIMIX Availability Status” on page 50 describes how to check status of replication processes and supporting services from a 5250 emulator.

“The Work with Data Groups display - 5250 emulator” on page 54 describes the errors reported on this 5250 emulator display and provides procedures for resolving them.

“Working with the detailed status of data groups” on page 61 describes how to access detailed status for a data group from either user interface.

“Identifying replication processes with backlogs” on page 76 describes what fields to check in each user interface for detailed status of a data group.

Becoming acquainted with status

Becoming acquainted with status

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

In MIMIX Availability Manager, the highest level is the Enterprise View window. In a 5250 emulator, the highest level is the MIMIX Availability Status display.

Status in MIMIX Availability Manager

MIMIX Availability Manager is designed so that problems or actions that require attention are easily detected. From any window in the interface, you can quickly see if problems exist. Status values are prioritized and those requiring immediate attention or intervention have icons to draw your attention. Additionally, these statuses are “bubbled up” to the next higher 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.

status from left to right, with the most severe problems listed first. Figure 5. Enterprise View

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.

areas are represented by icons in the navigation bar. Figure 7 shows how the severity of

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

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.

information about replication activity and problems. Figure 7. A problem reflected on the Data Group Status

Monitoring status with MIMIX Availability Manager

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

Checking replication status with MIMIX Availability Manager

The Data Group Status window provides summary information for data groups, provides access to detailed status, displays actions for starting, ending, and switching data groups, and displays actions for resolving problems. If problems with replication exist, an Action required icon appears next to the Data Groups item in the Details area of the navigation bar.

Only the data groups that you have selected through Preferences are displayed.

To view the details of the replication status, do the following:

1. Select Data Groups from the Details area of the navigation bar. All data groups with problems are listed first, in order of severity.

2. Select a data group to view the summary information for the data group. You will see the following three sections:

Summary - Provides information on audit compliance, the date and time of the last switch, and whether remote journaling is configured for this data group.

Journal - Provides a Replication Process status overview for the User and System journals. The Replication Process summarizes the Send and Apply statuses of processes used during replication. Icons in this section can be clicked to view the message log for the user or system journal.

Problem - Problem icons must be addressed before the data group can replicate successfully. Each problem has a recommended action listed. Flyover help on the

Action button describes the action. Click

Note:

For more information, see “Displaying data group detailed status with MIMIX Availability Manager” on page 61.

status with MIMIX Availability Manager” on page 61. to prompt the recommended action. If you have

to prompt the recommended action.

If you have problems, the data groups are listed in the order of severity.

Checking audit status with MIMIX Availability Manager

The Audit Summary window summarizes the status of all audit activity, problems with audit results, and recoveries.

To view the audit status, do the following:

1. Select Summary from the Details area of the navigation bar. The Audit Summary window appears and provides a summary of audit status and also lists audits for the data groups selected for viewing in an installation. All audit rules with problems are listed first, in order of severity.

2. Do the following:

Monitoring status with MIMIX Availability Manager

a.

Use the flyover to determine the recommended action for the selected audit rule.

b.

From the Actions drop-down menu, select the appropriate action and click

.
.

Note:

You can also click the audit rule to see a detailed description of the audit status. The Rule status field in the Rule Details area contains the message and appropriate action for the specified audit rule. Select the appropriate

action and click

.
.

For more information, see “Working with audits” on page 87.

Checking status of supporting services with MIMIX Availability Manager

The Services window summarizes the status and also reflects potential problems with system managers, journal managers, collector services, and all enabled monitors for the installation.

To view the services, do the following:

1. Select Services from the Details area of the navigation bar. The Installation Services window appears and provides the status of the MIMIX services for the selected system and installation. From this window, you can also start or end MIMIX and resolve problems associated with various MIMIX services.

2. Do the following:

a. Use the flyover to see information and recommended actions for the System Manager, Journal Manager, Monitor Processes, and Collector Services statuses.

Note:

b. For systems with an Action required icon, select the appropriate action from

Clicking any icon to see the message log for that process.

the Actions drop-down and click

.
.

If the text in the summary display indicates a problem with a monitor, do the following:

1. Determine the system and installation on which you have monitors with problems. If you are not on that system, select the system from the Systems area of the navigation bar and the installation with which you were working. If the system that has monitor problems is not included in your list of Systems, you will need to add it through Preferences before you can see the monitor details.

2. Select Monitors from the Details area of the navigation bar. After Master Monitor, all monitors with problems are listed first, in order of severity. Each problem has a recommended action listed.

3. Do the following:

a. Use the flyover help on the Action button to describe the recommended action.

b. Select the appropriate action from the Actions drop-down and click

.
.

Monitoring status with MIMIX Availability Status

The MIMIX Availability Status display, shown in Figure 8, provides one location for quickly assessing the overall state of an entire MIMIX installation, reflecting both source and target systems. In addition to determining status, unique features of this display enable its use as the starting point for performing routine actions and resolving problems.

To access this display, do one of the following:

• Select option 1 on the MIMIX Basic Main Menu

• Enter the command WRKMMXSTS and press Enter.

Figure 8 shows the MIMIX Availability Status display.

Figure 8.

the installation is not complying with best practices for switching (red) and audits (yellow).

MIMIX Availability Status window. This example shows that MIMIX is active but

Status window. This example shows that MIMIX is active but Additional fields - In the upper

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

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

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.