Você está na página 1de 550

IBM DataMirror iCluster Version 5.

End-User Documentation

Table of Contents

Table of Contents
iCluster Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 iCluster Enterprise Edition and iCluster SMB Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 Before You Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 Minimum Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Communication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Program Temporary Fix Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 Authorization Codes and Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 Required Information for the Installation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 Creating a Journal Receiver and Journal QAUDJRN in QSYS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 Setting the QALWUSRDMN OS/400 System Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Installing, Re-installing, and Upgrading iCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Re-installing iCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Applying iCluster Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Installing, Re-Installing, or Upgrading iCluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 Overview of the Installation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 iCluster Enterprise Edition and iCluster SMB Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 Installing the iBalance Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 Signing on to your System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Preparing for an Upgrade or Reinstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Restoring the Installation Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 To Restore Objects from CD-ROM Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 To Restore Objects from Save File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Running the Installation Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 Upgrading iCluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 After You Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Starting the XDMCLUSTER Subsystem on IPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Adding an iCluster User (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Securing the iCluster Product Library (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 Scheduling iCluster Startup and Shutdown (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 Adding Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 Uninstalling iCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 Uninstalling iCluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 Migrating HA Suite to iCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 Introduction to the Migration Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

DataMirror, an IBM Company

Printed in Canada

Table of Contents

General Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 Pre-migration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 Running the Migration Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 Post-migration Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36 Running iCluster Under TCP/IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37 Adding a New Entry 'dmcluster' to the TCP/IP Service Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37 Method 1 - Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Method 2 - Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Restricting the Port Number from Being Used by Other Applications . . . . . . . . . . . . . . . . . . . . . . . . . . .37 Method 1 - Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Method 2 - Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Verifying Domain Name Server (DNS) Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 Removing the iCluster Service Table Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 Removing the dmcluster Table Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 Signing on to your System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Removing dmcluster from the TCP/IP Service Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Removing Port Number Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 Other Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41 Additional Message Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41 Batch Processes and Job Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41 iCluster Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 Working in a Clustered Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 Nodes in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Replication Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Failover Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Failovers and Switchovers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 Scenario 1: SOS Cannot Communicate with the Primary Node . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Scenario 2: IBM CRS Detects a Distress Signal from the Primary Node. . . . . . . . . . . . . . . . . . . . 49 Scenario 3: IBM CRS Loses Communication with the Primary Node . . . . . . . . . . . . . . . . . . . . . . 50 Object Specifiers and Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 Constructing Object Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Path Object Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Generic Object Specifiers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Rules of Precedence for Object Specifiers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Native Object Specifier Changes While Replication is Active . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Path Object Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 Journaled and Non-journaled Path Object Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 iCluster Quick Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 Auto-configuration of iCluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 DMAUTOCFGAuto-configure iCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
4 Printed in Canada
iClusterVersion 5.1

Table of Contents

Quick Start for the iCluster Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57 Starting iCluster from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 To invoke iCluster from the command line: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Quick Start for iCluster Administrator for Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 Logging on to iCluster Administrator for Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60 To log on to iCluster Administrator for Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 iCluster Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 Command Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 Operating System Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Commands Available to any OS/400 User. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Commands Available to OS/400 Security Officers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Commands Available to *ALLOBJ Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 iCluster Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 iCluster User Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 iCluster Operator Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 iCluster Administrator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Adding and Configuring Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Removing Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Initial Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Application Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Staging Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69 Locked Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70 Avoiding Contention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70 Commitment Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 Suspended Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72 Choosing a Failover Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73 Key Differences in Failover Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Configuring iCluster to use SwitchOver System (SOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Configuring iCluster to use IBM Cluster Resource Services (CRS) . . . . . . . . . . . . . . . . . . . . . . . . 75 Starting Replication and Journal Positions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 To start replication after setting journal positions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Monitoring Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76 Monitoring Out-of-Sync Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 To start a Sync Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 To view Sync Check results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Monitoring Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78 Restarting iCluster after Restarting a Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 Upgrading the Cluster Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 Changing IP Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 Journaling in iCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 Remote Journaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
DataMirror, an IBM Company Printed in Canada 5

Table of Contents

Configuring Remote Journaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Role Switching with Remote Journals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Passing Arguments to Sync Point User Exit Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86 iCluster Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87 Replicating Database *FILE Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87 Replicating BSF Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89 Replicating Configuration Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90 Replicating User Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91 Replicating LOBs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92 Replicating Triggers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92 Replicating Save Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92 Replicating QDLS Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94 Replicating WebSphere MQ Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95 To enable WebSphere MQ support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 iCluster Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97 Node Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99 DMADDNODEAdd Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99 DMDSPNODEDisplay Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103 DMCHGNODEChange Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104 DMRMVNODERemove Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109 DMWRKNODEWork with Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110 Group Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 DMADDGRPAdd Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 DMDSPGRPDisplay Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124 DMCHGGRPChange Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124 DMRMVGROUPRemove Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134 DMADDBACKAdd Backup Node to Recovery Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135 DMRMVBACKRemove Backup Node from Recovery Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135 DMCHGROLEChange Group Primary Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136 DMWRKGRPWork with Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137 Native AS/400 Object Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 DMSELOBJSelect Objects to Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 DMCHGOBJSLChange Object Selection to Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147 DMDSELOBJDe-select Objects from Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151 DMWRKOBJWork with Object Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152 Byte Stream File (BSF) Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155 DMADDBSFAdd Path Object Specifier to Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155 DMRMVBSFRemove Path Object Specifier to Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158 DMCHGBSFChange Path Object Specifier to Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159 DMWRKBSFWork with Path Object Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162 Switchable Device Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
6 Printed in Canada
iClusterVersion 5.1

Table of Contents

DMADDSWDEVAdd Switchable Device Entry to Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163 DMDSPASPGPDisplay Switchable Device Entry to Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164 DMCHGSWDEVChange Switchable Device Entry for Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164 DMRMVSWDEVRemove Switchable Device Entry for Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165 Resilient Application Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 DMADDAPPAdd Resilient Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167 DMDSPAPPGPDisplay Resilient Application Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170 DMUPDAPPUpdate Resilient Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172 DMCHGAPPChange Resilient Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172 DMRMVAPPRemove Resilient Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175 DMADDBACKAdd Backup Node to Recovery Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176 DMRMVBACKRemove Backup Node from Recovery Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176 DMWRKAPPWork with Resilient Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 MQSeries Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179 RBDHAMQMRebuild iCluster MQSeries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179 Administration Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 DMSETSVALSet Cluster System Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181 DMCHGTIMEChange System Date and Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193 DMDSPLOGDisplay Cluster Event Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195 DMCLRLOGClear Cluster Event Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199 HAPNGTCPPing Using TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200 JRNHADADQJournal Data Areas and Data Queues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201 STRHATCPStart TCP/IP Listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202 WRKHAJOBWork with Active Cluster Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203 DMSTRDMStart Definition Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203 DMDLTCLSTRDelete Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203 DMSYSINFSystem Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204 DMWRKSSPLFWork with Suspended Spooled Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205 DMACTSPLFActivate Spooled File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205 Cluster Operation Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207 DMSTRNODEStart Cluster Operations at Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207 DMENDNODEEnd Cluster Operations at Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208 DMSTRGRPStart Cluster Operations at Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208 DMSTRREPLStart Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211 DMENDGRPEnd Cluster Operations for Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213 DMSTRWOSwitchover Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .215 DMREJOINiCluster Rejoin Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216 DMSTRAPPStart Cluster Operations for Resilient Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217 DMENDAPPEnd Cluster Operations for Resilient Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .218 DMSWOAPPSwitchover Resilient Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220

DataMirror, an IBM Company

Printed in Canada

Table of Contents

DMSETPRIMPrepare Primary Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220 DMCHGROLEChange Group Primary Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221 DMGENEXCGenerate Command Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222 Replication Operation Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .225 DMSETPOSSet Journal Start Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .225 DMMRKPOSMark Current Journal Positions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228 CHGHAJRNChange Journal Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229 DSPHAPOSDisplay Journal Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230 RTVHAPOSRetrieve Journal Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230 VFYHAJRNVerify Audit Journal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232 STRHABRCDStart BSF Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233 DSPHABRCDDisplay Recording for BSF Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234 ENDHABRCDEnd Recording for BSF Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234 DMSTRAPYStart Replication Apply Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235 DMENDAPYEnd Replication Apply Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .236 DMACTOBJActivate Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238 DMACTBSFActivate BSF Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240 DMSUSOBJSuspend Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241 DMSUSBSFSuspend BSF Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242 DMSNDOBJSend Object Immediately. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243 DMSETSYNCSet Sync Point. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245 CRTCFGOBJCreate Configuration Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248 INITHAOBJInitialize Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .249 RTVRCVPTRetrieve Recovery Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250 RTVRCVPTRRetrieve Recovery Checkpoint (CL Program) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251 SYNCHATRGSynchronize Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252 DMLOGENTLog Journal Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .253 Status and History Monitor Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255 DSPHASMONDisplay Source Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255 WRKHASMONWork with Status Monitor on Primary Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255 WRKHATMONWork with Status Monitor on Backup Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256 CHGHASMONChange History Monitor on Primary Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257 PRGHASMONPurge History Monitory on Primary Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259 WRKHAOBJSTWork with Object Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260 WRKHABSFSTWork with BSF Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260 DMWRKOBJSTWork with Object Status by Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .261 Sync Check Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263 DSPHASCDisplay Sync Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .263 *FILEATTR Sync Check Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 *LIST Sync Check Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

Printed in Canada

iClusterVersion 5.1

Table of Contents

*DTAARA Sync Check Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 *BSF Sync Check Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 SELSCATTRSelect Sync Check Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .265 STRHASCStart Sync Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267 STRHASCUSRStart User Sync Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .270 DMSCRPTSync Check Report for IFS Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274 DMSCRPTNTVSync Check Report for Native Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .275 PRGHASCPurge Sync Check Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .276 Registered iCluster User Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .277 DMADDUSRAdd User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .277 DMCHGUSRChange User. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .278 DMRMVUSRRemove User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280 DMWRKUSRWork with Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .281 Exit Program Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283 ADDPFEXPGMAdd Exit Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283 RMVPFEXPGMRemove Exit Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283 iCluster for Supported External Storage Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285 DMRBDNODERebuild Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285 DMREGPOSRegister Positions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .286 Other Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289 SETHAREGRestore Communications Registries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289 Using the Status Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291 Working with the Status Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291 Simplified Status Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292 Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292 Status of Apply Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292 Real Time and Historical Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292 Interactive Inquiry Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292 Real Time Statistics Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293 Starting the Status Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Cycling Through the Views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Common Information on all Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Common Options for all Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Monitoring Real Time Overall Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 Monitoring Real Time Object Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 Monitoring Real Time Object Position and Totals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 Monitoring Real Time Object Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Reading Status Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 Working with Object Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306 Working with BSF Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 Working with Object Status for Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
DataMirror, an IBM Company Printed in Canada 9

Table of Contents

Monitoring Historical Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .314 Monitoring Historical Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 Monitoring Historical Object Position and Totals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Monitoring Historical Object Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 iBalance and Master-Master Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .321 Configuration of Master-Master Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .322 To configure master-master replication:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 Master-Master ReplicationOperations and Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323 Overview of Conflict Detection and Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323 Configuration of Conflict Detection and Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325 Parameter List Descriptions for a Conflict Resolution User Exit Program. . . . . . . . . . . . . . . . . . . . . . .326 Parameters Passed to the User Exit Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 Image Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 LOB Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 Control Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 Field Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Conflict Logging File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .337 High Availability Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .340 Switchover for IBM Cluster Resource Services (CRS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .341 iSeries Clustering Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .341 iSeries Clustering Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .341 iCluster Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342 iCluster and OS/400 Cluster Resource Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342 iCluster Groups and Role Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342 ROLESWITCH Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 What iCluster Does During a Switchover and Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 Switchover Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .344 Failover Overiew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .344 Failovers and the ROLESWITCH parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .344 ROLESWITCH *NO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .344 ROLESWITCH *YES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345 Preparing the Cluster to Handle Switchovers and Failovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345 ROLESWITCH Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345 User Exits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345 Journal Entry Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345 Synchronous and Asynchronous Remote Journaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .346 Failover Message Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347 Enabling Alerts in OS/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347 Line Controller Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347 Passing Arguments to Role Switch User Exit Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347 Failed State Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348
10 Printed in Canada
iClusterVersion 5.1

Table of Contents

Node Failure Detection in iCluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348 FAILED State Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348 Detecting a FAILED State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349 Group Failover in iCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349 Failed State Recovery Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .350 Recovery Paths for a FAILED State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .351 Partition State Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .355 False and True PARTITIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .355 Partition State Recovery Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .356 Recovery Paths for a PARTITION State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .357 Restarting Active Groups with Mirroring in the Original Direction with ROLESWITCH *NO . . . . . . . . . . .359 Restarting Active Groups with Mirroring in the Original Direction with ROLESWITCH *YES . . . . . . . . . .360 Restarting Active Groups with Mirroring in the Opposite Direction with ROLESWITCH *YES . . . . . . . . .361 Restarting Active Groups with Mirroring in the Opposite Direction with ROLESWITCH *NO . . . . . . . . . .361 Rejoining a Non-Functioning Node with a Role Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .362 Rejoining a Non-Functioning Node without a Role Switch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .363 Removing a Failed Node from the Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .364 iCluster and Resilient Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .364 iCluster and Resilient Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .365 Alertable Messages for Clustering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .366 Switching Over to Another Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .367 Switchover for SwitchOver System (SOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .369 SwitchOver System Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .369 SwitchOver System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .369 User Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .369 Detecting Node Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .370 Node Failure Walkthroughs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .370 Manual Failover Walkthrough. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 Automatic Failover Walkthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 Configuring Operational Switching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .376 Operational Switching Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .376 Defining User Exit Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .376 Sample User Exits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .378 Configuring Nodes for Operational Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .379 Configuring Groups for Operational Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .380 Administering Operational Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .381 Performing a Manual Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .381 To perform a manual failover: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 Recovering from Failovers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .381 To restore a group from this state: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Performing a Switchover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .382
DataMirror, an IBM Company Printed in Canada 11

Table of Contents

To perform a switchover: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 iCluster Administrator for Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383 Minimum Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383 Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383 Installing iCluster Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383 Upgrading iCluster Administrator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383 Uninstalling iCluster Administrator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383 iCluster Administrator and Event Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .384 Monitoring Operations in the iCluster Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385 Cluster Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .385 Setting System Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .386 To set system values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 Cluster Operation Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .395 Rejoin Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .395 To restart node operations so that it rejoins the cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 Delete Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .396 To end cluster operations and delete cluster definitions on all active nodes . . . . . . . . . . . . . . . . 396 Node Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .396 Working with Nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .397 Add Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .397 To add a node to the cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 Remove Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .402 To remove a node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 Start Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .403 To start cluster operations at the specified node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 End Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .403 To end cluster operations at the specified node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 Change Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .404 To change the specified node in the cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 Send Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .410 To replicate one or more objects to a target node:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Group Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .412 Working with Replication Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .413 Add Full Replication Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .413 To add a full replication group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 Start Full Replication Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .421 To start cluster operations for a full replication group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421 End Full Replication Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423 To end cluster operations for a full replication group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 Remove Full Replication Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .424
12 Printed in Canada
iClusterVersion 5.1

Table of Contents

To remove a full replication group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 Change Full Replication Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .424 To change a full replication group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 Convert to Refresh Only Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .431 To convert a full replication group to a refresh-only group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 Switchover Full Replication Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .433 To initiate a switchover for a full replication group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 Add Refresh-Only Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .434 To add a refresh-only group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 Start Refresh-Only Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .437 To start a refresh-only group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 End Refresh-Only Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .437 To end a refresh-only group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 Remove Refresh-Only Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .438 To remove a refresh-only group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 Change Refresh-Only Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .439 To change a refresh-only group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439 Convert to a Full Replication Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .441 To convert a refresh-only group to a full replication group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 Add Master-Master Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .448 To add a master-master group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448 Start Master-Master Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .452 To start a master-master group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 End Master-Master Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .454 To end a master-master group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454 Remove Master-Master Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .455 To remove a master-master group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 Change Master-Master Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .455 To change a master-master group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 Resilient Application Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .459 Working with Resilient Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .459 Add Resilient Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .459 To add a resilient application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460 Change Resilient Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .462 To change a resilient application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 Update Resilient Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .465 To update a resilient application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 Remove Resilient Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .465 To remove a resilient application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 Start Resilient Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .466

DataMirror, an IBM Company

Printed in Canada

13

Table of Contents

To start a resilient application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 End Resilient Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .468 To end a resilient application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 Switchover Resilient Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .469 To switchover a resilient application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 MQSeries Group Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .470 Working with MQSeries Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .470 Add MQSeries Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .471 To add an MQSeries group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 Start MQSeries Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .476 To start an MQSeries Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476 End MQSeries Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .478 To end an MQSeries Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 Remove MQSeries Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .478 To remove an MQSeries Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 Change MQSeries Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .479 To change an MQSeries group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 Switchover MQSeries Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .483 To switchover an MQSeries group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 Working with Recovery Domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .484 Add Backup Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .484 To add a backup node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 Remove Backup Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .485 To remove the backup node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 Working with Object Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .486 Select/Add Object Specifier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .486 To select/add an object specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486 Deselect Object Specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .492 To deselect an object specifier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492 Change Object Specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .492 To change an object specifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 iCluster Operations Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .496 Mark Journal Positions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .496 To mark current journal positions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496 Set Journal Positions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .497 To set journal positions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 Set Synchronization Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .498 To set a synchronization point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 Set Primary Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .502 To set a primary node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502

14

Printed in Canada

iClusterVersion 5.1

Table of Contents

Change Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .502 To change the role of the primary node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 Start Apply Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .503 To start the apply process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 End Apply Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .504 To end the apply process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504 Suspended Object Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .505 Activate Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .505 To activate an object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506 Suspend Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .507 To suspend an object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508 iBalance and Master-Master Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .508 Configuring Master-Master Replication in iCluster Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . .509 To configure master-master replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509 Viewing Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .510 Starting the iCluster Event Viewer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .510 To start the iCluster Event Viewer:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511 Change Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .512 To change the event log filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512 Export Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .514 To export the event log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514 Clear Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .515 To clear the event log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515 Set Message Frame Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .516 To set the message Frame Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516 Detailed Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .516 Monitoring iCluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .516 Using the Backup Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .516 To use the Backup Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517 Using the Object Status Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .518 To activate or suspend objects from the Object Status Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . 519 Using the iCluster Performance Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .520 To launch the Performance Monitor for a group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 Performance Monitor Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .520 Source Status and Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523 Updating the Performance Monitor Display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .526 To update the performance monitor display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526 Object Types Replicated by iCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .529 iCluster Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .533 iCluster Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .535 The Apply Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .535

DataMirror, an IBM Company

Printed in Canada

15

Table of Contents

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .537 Contacting DataMirror . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .547 Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .547 Contacting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .547 Training and Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .547 Send us your Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .547 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .549

16

Printed in Canada

iClusterVersion 5.1

iCluster Enterprise Edition and iCluster SMB Edition

iCluster Overview
iCluster is a replication solution that allows you to link computers together for a continuously available system. This creates a system that can continue to operate and provide services during anticipated or unexpected interruptions. iCluster can be installed on distributed systems to maintain operations after recovering from planned (switchover) or unplanned (failover) interruptions. It is designed for organizations that have the necessary hardware and communications to offload processing to other iSeries systems defined in the cluster. A cluster administrator will use the iCluster commands to define a configuration that supports high availability in a distributed iSeries environment. iCluster users that are defined by the administrator can perform certain iCluster operations based on the level of authority assigned to each user. iCluster provides the functionality that is required to support high availability in an iSeries clustered environment. A cluster consists of a network of iSeries computers (or nodes) that work together to provide seamless iSeries operations. If one node in the cluster that provides a service can no longer perform this role, operations can be automatically switched to a designated backup node. From outside of the cluster, there is no distinction as to which node in the cluster is actually performing these operations. After a switchover or failover, resilient applications behave as though operations are being provided by the same node in the cluster. To achieve this objective, you must replicate objects and data from the primary node to the backup node so that operations can be immediately moved to this node when a switchover or failover occurs. For more information on failovers and switchovers, see Failovers and Switchovers on page 47. See Choosing a Failover Mechanism on page 73 for more information on the available failover mechanisms in iCluster. DataMirror iCluster provides a set of commands and a Java-based workstation application that allows you to define cluster components and initiate replication activities within the cluster. In addition to defining nodes within a cluster, you are also able to define replication groups, initiate cluster operations, define resilient applications, and set cluster security levels. See Working in a Clustered Environment on page 43 for more information on iCluster. This section contains the following topics:

iCluster Enterprise Edition and iCluster SMB Edition on page 17

iCluster Enterprise Edition and iCluster SMB Edition


Depending on your business requirements, you can choose between the following two versions of iCluster:

iCluster Enterprise Edition iCluster SMB (Small and Medium Business) Edition.

iCluster Enterprise Edition is appropriate for complex iSeries environments that require richer configuration options. More flexibility is provided for groups and the ability to deal with them independently. iCluster SMB Edition is appropriate for less complicated environments with fewer applications, data, groups, and journals. Configuration is simpler for ease of set up and administration. It is limited to two replication groups with two data journals per group. The iBalance feature for workload balancing is available for both versions of iCluster. For more information on iBalance, see iBalance and Master-Master Replication on page 321. For more information on installing these editions of iCluster, see Installation and Upgrade on page 19.

DataMirror, an IBM Company

Printed in Canada

17

18

Printed in Canada

iClusterVersion 5.1

Before You Install

Installation and Upgrade


This section describes how to install and configure iCluster on an iSeries node.

Before You Install


This section identifies the information and parameters that you need to know before installing, re-installing, or upgrading iCluster on an iSeries node.

Minimum Requirements
The following sections list minimum hardware and software requirements for iCluster.

Hardware Requirements
Disk Space:

200 megabytes (for each installation of iCluster) 90 megabytes (recommended for running iCluster) 512 megabytes (minimum for the staging store) It is recommended that additional disk space be allocated to accommodate large save files.

Note:

Software Requirements
Operating System:

OS/400 Version 5 Release 1 and greater At the time of this release, iCluster supports V5R1 to V5R4 of the operating system. To install iCluster on a different version of the operating system, contact DataMirror Technical Support. See Contacting Technical Support on page 547 for more information. You must make sure that TCP/IP servers are installed on the system before you install and configure iCluster.

Note:

Note:

Communication Protocol

TCP/IP

Program Temporary Fix Requirements


iCluster optionally uses IBM Cluster Resource Services. If you are using this failover mechanism, then any issues in Cluster Resource Services may affect iCluster. See Choosing a Failover Mechanism on page 73 for more information. Contact DataMirror Technical Support for the current list of PTFs that are necessary for iCluster. For more information, see Contacting Technical Support on page 547. Note: For information regarding the download and installation of any required PTFs, visit the support page at the IBM web site.

The following V5R1 PTFs are required for the QDBRPLAY API functionality that is required by the apply jobs on the backup node:

SI07279 SI06408

DataMirror, an IBM Company

Printed in Canada

19

Note:

The QDBRPLAY API functionality is built-in to OS/400 V5R2 and above, and therefore the PTFs mentioned above are not required.

Authorization Codes and Licensing


iCluster requires a valid authorization code to ensure that it runs only on licensed iSeries systems. Serial numbers are recognized by the application. DataMirror trusts our clients to respect our proprietary rights. iCluster is provided by license only. You are required to purchase licenses for every node on which iCluster will be used. Licenses are issued on a machine class basis. Note: New authorization codes are required for new product releases only. For example, from iCluster V4R0 to V5R0. Authorization codes are not required for pack ID updates such as iCluster V2R0 from pack ID 4 to pack ID 5. The existing authorization code can continue to be used for pack ID updates.

You will require a valid authorization code if you are installing a feature such as iBalance or one of the two editions of iCluster: iCluster Enterprise Edition or iCluster SMB Edition. For more information, see iCluster Enterprise Edition and iCluster SMB Edition on page 23 and Installing the iBalance Feature on page 23. You can obtain authorization codes either from DataMirror Technical support or from the DataMirror web site at http://www.datamirror.com. Note that the authorization codes obtained from the web site are temporary.

Required Information for the Installation Procedure


Before starting the installation procedure, you need the following information:

Product library name: The name you want to assign to the iCluster product library. Note that DMCLUSTER is the default library name for iCluster. Device or save file name: The CD-ROM device name or save file name that will be used to restore iCluster. Authorization code: The iCluster authorization code for each system where you will install iCluster. For more information about authorization codes, see Authorization Codes and Licensing on page 20.

Creating a Journal Receiver and Journal QAUDJRN in QSYS


You need to make sure that the audit journal exists. An error will occur if the journal QAUDJRN cannot be found in the library QSYS. Follow the procedure below to create the QAUDJRN journal in library QSYS if it does not already exist. 1 Create a journal receiver by issuing the following command: CRTJRNRCV The Create Journal Receiver (CRTJRNRCV) screen appears. 2 In the Journal receiver field, enter the name of the journal receiver that you want to create. 3 In the Library field, enter the name of the library where the new journal receiver will be located. 4 Enter values in the other fields on this screen. If necessary, use F1 help to assist you in specifying these values. 5 Press Enter. 6 Create a journal for the receiver by issuing the following command: CRTJRN The Create Journal (CRTJRN) screen appears. 7 In the Journal field, enter QAUDJRN. 8 In the Library field for the journal, enter QSYS.

20

Printed in Canada

iClusterVersion 5.1

Before You Install

9 In the next two fields, enter the journal receiver name and library that you specified on the Create Journal Receiver (CRTJRNRCV) screen. 10 Enter values in the other fields on this screen. If necessary, use F1 help to assist you in specifying these values. 11 Press Enter.

Setting the QALWUSRDMN OS/400 System Value


The allow user domain (QALWUSRDMN) system value determines which libraries can contain user-domain user objects. The default value for QALWUSRDMN is *ALL. Your system administrator can change this system value on individual machines to be one library or a list of libraries. Before proceeding with the installation, you must ensure that the QALWUSRDMN OS/400 system value is set to *ALL or specifies the DMCLUSTER or staging library. This setting is required to complete the installation successfully.

Installing, Re-installing, and Upgrading iCluster


You have the option of installing, re-installing, or upgrading iCluster. This section describes the differences between these three operations.

Installation: Installs iCluster into a new product library that previously did not exist. iCluster creates new metadata. You will need to add nodes, groups, and other cluster objects before you can start replicating using iCluster. Re-installation: Installs iCluster into an existing product library (any version) that is an iCluster production library. All existing metadata is deleted from that library. You will need to add nodes, groups, and other cluster objects before you can replicate with iCluster. Upgrade: Upgrades an existing iCluster installation. A product library must exist, and the library specified during the upgrade must be an iCluster production library. An upgrade does not delete existing metadata. You do not need to re-add nodes, groups, and other cluster objects.

The subsystem must be ended prior to performing the upgrade. You can also migrate from HA Suite Version 3.6 or greater to iCluster. For more information, see Migrating HA Suite to iCluster on page 35.

Re-installing iCluster
Before re-installing iCluster, you need to end all replication activities and close all iCluster menus. Note: You also need to make sure that the iCluster product library is not in your library list. To re-install iCluster, you need to: 1 Run the iCluster installation program. The installation program automatically runs the VFYHAJRNVerify Audit Journal command. For more information, see VFYHAJRNVerify Audit Journal on page 232. 2 Re-add nodes and groups. For more information about adding and removing nodes and groups, see Node Commands and Group Commands.

Applying iCluster Updates


You can update your current version of iCluster with service packs. Service packs contain additional fixes or enhancements for your current version of iCluster. To obtain the latest service pack, contact DataMirror Technical Support. See Contacting Technical Support on page 547 for contact information.

DataMirror, an IBM Company

Printed in Canada

21

22

Printed in Canada

iClusterVersion 5.1

Installing, Re-Installing, or Upgrading iCluster

Installing, Re-Installing, or Upgrading iCluster


This section identifies the steps required to install, re-install, or upgrade iCluster.

Overview of the Installation Procedure


The installation/upgrade procedure should take between 20 and 30 minutes to complete. Before you get started, you need to sign on to the system. The installation procedure consists of the steps listed below: 1 Sign on to the system. For more information, see Signing on to your System on page 24. 2 If you are upgrading or reinstalling iCluster, then cleanly stop the current installation. For more information, see Preparing for an Upgrade or Reinstallation on page 24. 3 Restore the installation program. For more information, see Restoring the Installation Program on page 25. 4 Run the installation program. For more information, see Running the Installation Program on page 25. 5 If you are upgrading an iCluster installation, then perform upgrade tasks. For more information, see Upgrading iCluster on page 26. 6 Configure TCP/IP for iCluster. For more information, see Running iCluster Under TCP/IP on page 37. This step does not apply if you are upgrading or re-installing iCluster. 7 Perform post-installation procedures. For more information, see After You Install on page 29. The material provided in After You Install on page 29 to Other Considerations on page 41 contains information about adding nodes to your clustered environment through iCluster and removing the software from your iSeries nodes. It also provides important information about messaging, batch processes, and job logs. Note: It is recommended that you read Before You Install on page 19 for important considerations about iCluster before you start the installation program.

iCluster Enterprise Edition and iCluster SMB Edition


Depending on your business requirements, you can choose between the following two versions of iCluster:

iCluster Enterprise Edition iCluster SMB (Small and Medium Business) Edition

iCluster Enterprise Edition is appropriate for complex iSeries environments that require richer configuration options. More flexibility is provided for groups and the ability to deal with them independently. iCluster SMB Edition is appropriate for less complicated environments with fewer applications, data, groups, and journals. Configuration is simpler for ease of set up and administration. It is limited to two replication groups with two data journals per group. The iBalance feature for workload balancing is available for both versions of iCluster. You will require a valid authorization code from your DataMirror representative if you are installing iCluster Enterprise Edition or iCluster SMB Edition. For more information, see Authorization Codes and Licensing on page 20.

Installing the iBalance Feature


iBalance is an additional feature for iCluster that allows you to perform master-master replication. With master-master replication, you can perform application updates to the same objects on both the source and target, and these updates can be replicated in both directions. Depending on the replication rules used, identical copies of your data can be maintained on both the source and

DataMirror, an IBM Company

Printed in Canada

23

target systems, or conflict detection and resolution rules can be set up to control the updates to ensure that data is not overwritten on one of the servers. For more information on iBalance and master-master replication, see the iCluster iBalance and MasterMaster Replication on page 321. You can install the iBalance feature as part of an installation/upgrade or on top of an existing iCluster installation. If you are installing or upgrading to iCluster with the iBalance feature, you can follow the steps outlined in Overview of the Installation Procedure on page 23. You can also follow these same steps if you are installing the iBalance feature into an existing iCluster library. Note: To install the iBalance feature, you must obtain an iBalance authorization code from your DataMirror representative. For more information, see Authorization Codes and Licensing on page 20.

Signing on to your System


Sign on to the system with a user profile that has all of the following authorities:

*JOBCTL *SECADM *SERVICE *ALLOBJ *AUDIT *SPLCTL *SAVSYS *IOSYSCFG If you have already signed on to the system and run any programs, other than iCluster, we recommend that you sign off and then sign on again.

Note:

Preparing for an Upgrade or Reinstallation


If you do not have an active iCluster installation on your system, then you can skip this section. Otherwise, perform the following tasks to cleanly exit your current installation. 1 End all iCluster groups by running the following command for every group: DMENDGRP GROUP(<group>) 2 Drain the staging store for every group in the cluster by running the following command: DMSTRAPY GROUP(<group>) FRCDRN(*YES) 3 Clear the staging store completely with the following command: CLRLIB <staging store library> The default staging store library is DMSTORE. This value was set when the node was added to the cluster. 4 End all iCluster nodes by running the following command for every node: DMENDNODE NODE(<node>) 5 Exit the iCluster menus on all clients and terminals accessing the current installation. 6 End the XDMCLUSTER subsystem on all nodes by running the following command: ENDSBS SBS(XDMCLUSTER) After performing these tasks you can continue with the installation process. See iCluster iCluster Commands on page 97 for more information on performing these tasks.

24

Printed in Canada

iClusterVersion 5.1

Installing, Re-Installing, or Upgrading iCluster

Restoring the Installation Program


You can restore the installation objects from a CD-ROM device or from a save file using the RSTOBJ command. There are two save files required for installation. Note: The RSTOBJ command may take a few moments to complete. It does not provide any feedback while the installation objects are being restored.

To Restore Objects from CD-ROM Device


1 Insert the iCluster CD-ROM into the CD-ROM drive. 2 Run the following command: RSTOBJ OBJ(*ALL) SAVLIB(CSSINS) DEV(<CD-ROM device>) MBROPT(*ALL) ALWOBJDIF(*ALL) RSTLIB(QTEMP) OPTFILE('/ICLUSTER/CSINITIAL/CSSINS')

To Restore Objects from Save File


1 Transfer the installation files to the machine where you will install or upgrade iCluster. 2 Run the following command: RSTOBJ OBJ(*ALL) SAVLIB(CSSINS) MBROPT(*ALL) ALWOBJDIF(*ALL) DEV(*SAVF) SAVF(<save file library>/<save file name>) RSTLIB(QTEMP) Note: You must specify the save file library and name in this command. DataMirror names the save file CSSINS, but your administrator may have renamed the file.

Running the Installation Program


The installation screens in the following procedure are for an iCluster Enterprise installation. The text on the installation screens may vary depending on the edition of iCluster that you install (iCluster Enterprise or iCluster SMB) and the features you select (iBalance). Where important, the differences are noted in this procedure. 1 To run the installation program, enter the following command: ?QTEMP/CSINSTALL The DM iCluster Installation (CSINSTALL) screen appears where you can specify the device name or save file name. 2 Specify the CD-ROM device name (blank by default) or save file that will be used to restore the iCluster components, and press Enter. DataMirror names the file CSSMAS, but your administrator may have renamed the file. Note: The Savefile name for iCluster and Library Name fields are displayed only if you enter *SAVF in the Device name field.

A screen appears that displays the start of the DataMirror software license agreement. Read this document by pressing Page Down a number of times to scroll down to the bottom of the agreement. 3 Press F2 to accept the terms expressed in the software license agreement. The screen displays the version of iCluster that you are about to install. 4 Press Enter to advance to the next screen in the installation program. The iCluster Authorization Code screen is displayed. 5 In the iCluster for the iSeries Authorization Code field, enter the iCluster authorization code that you have received from DataMirror. You cannot continue with the installation without a valid authorization code. For more information about obtaining authorization codes, see Authorization Codes and Licensing on page 20. 6 Press Enter to continue the installation/upgrade process. The Installation/Upgrade screen is displayed.

DataMirror, an IBM Company

Printed in Canada

25

7 In the selection field, enter I if you want to install iCluster and proceed to Step 8 below. Note: To upgrade iCluster, enter U and then proceed to Upgrading iCluster on page 26. 8 After you select I and press Enter on the Installation/Upgrade screen in the previous step, the Confirm Installation screen is displayed. This screen confirms that you have decided to install iCluster. 9 Press Enter to continue. The iCluster Product Library screen is displayed. 10 In the iCluster for the iSeries Product Library field, specify the library name where you want to install iCluster. Before specifying the library, you should note the following:

The library that you specify will indicate whether you are installing or re-installing iCluster. See Installing, Re-installing, and Upgrading iCluster on page 21 for information about the differences between the two procedures. The default iCluster product library is DMCLUSTER. If you are installing the iBalance feature on top of an existing iCluster installation, you must specify the existing iCluster product library and press Enter. A confirmation screen will inform you that you are about to install the iBalance feature into the iCluster product library. To complete the installation, you can proceed to Step 16 in this procedure.

11 Press Enter to continue. If you specified a new library name, the New Library Installation screen is displayed. 12 Press Enter. iCluster will be installed into the specified library. If you specified an existing iCluster installation library name, then the Existing Library Installation screen is displayed. 13 In the selection field, enter N if you do not want to over-write the contents of the specified library, or enter Y if you want to reinstall iCluster into the specified library. Note: If you decide to re-install (Y), all existing objects in the specified library will be deleted, and new programs configuration information will be installed. The selection N is the default.

14 Press Enter. If you selected N, you will return to the iCluster Product Library screen (Step 10) where you can enter the name of a new library. If you selected Y, the Confirm Existing Library screen is displayed. This screen confirms that you want to re-install iCluster into the existing product library. By default, iCluster will be installed into the existing library DMCLUSTER. Note that all objects that currently reside in the specified library will be deleted. Note: When re-installing iCluster, you may receive a message indicating that the HADRCV and HABSFRCV journal receivers are never fully saved. This is a system message that is displayed when iCluster tries to delete a journal receiver. You simply need to acknowledge the message to continue with the installation.

15 Press Enter. A set of iCluster objects will be placed on your node after you press Enter. This process may take a few moments to complete. When this is done, the Confirmation screen is displayed. 16 Press Enter to complete the installation.

Upgrading iCluster
If you selected to upgrade iCluster (by selecting U from in Step 7 above), the following screen appears. This screen confirms that you have decided to upgrade to iCluster.

26

Printed in Canada

iClusterVersion 5.1

Installing, Re-Installing, or Upgrading iCluster

Note:

Before beginning the upgrade process, you must complete the tasks described in Preparing for an Upgrade or Reinstallation on page 24.

1 Press Enter to continue the upgrade process. The iCluster Product Library screen is displayed. 2 In the iCluster for the iSeries Product Library field, specify the library name where iCluster is currently installed. The default installation library is DMCLUSTER. 3 Press Enter to continue. The following Confirm Upgrade screen is displayed. This screen confirms that you are upgrading the existing version of iCluster in the specified installation library. 4 Press Enter to continue. A set of iCluster objects will be placed on your system after you press Enter. This process will take some amount of time to complete. As part of this process, the corresponding metadata will be upgraded in the DMCLUSTER library. 5 Once the upgrade is complete, the following iCluster Installation/Upgrade Complete screen is displayed. 6 Press Enter to complete the upgrade. 7 Start the subsystem and then the node, for every node in the cluster. You can now proceed to Running iCluster Under TCP/IP on page 37.

DataMirror, an IBM Company

Printed in Canada

27

28

Printed in Canada

iClusterVersion 5.1

After You Install

After You Install


This section contains information about a number of post-installation activities that you should perform to ensure that iCluster will function correctly.

Starting the XDMCLUSTER Subsystem on IPL


In most environments, you will want to configure the XDMCLUSTER subsystem to start automatically when the iSeries computer it is installed on starts. To do this, you must run the STRSBS command as a part of the QSTRUPPGM start up value. This is an optional configuration. To configure your system to start the XDMCLUSTER subsystem automatically with the computer, add the following command to the source code for the program that is specified in the QSTRUPPGM system value to allow the program to run whenever the machine is re-booted: QSYS/STRSBS <iCluster installation library name>/XDMCLUSTER If the machine does not have a program specified in the QSTRUPPGM system value, then perform the following tasks: 1 Create a startup program by modifying the QSTRUP member in the QGPL/QCLSRC source file with the command specified above, and compile the program with the CRTCLPGM command. 2 Run the following command to display the Change System Values screen: CHGSYSVAL QSTRUPPGM 3 Enter the name and library of the program created in Step 1 and press Enter. This instructs the machine to run the program every time the machine starts. See your iSeries documentation for more information on this task.

Performance Considerations
iCluster allows you to optimize the flow of data into and out of a high-speed software cache. This enables you to move data from the primary system to the backup system's cache at a much higher rate than previously possible. This performance enhancement allows you to attain near zero latency for system backup and recovery. To obtain these benefits, you should configure iCluster to run in its own storage pool, or at least run in a storage pool other than *BASE. To perform this configuration, see your system administrator.

Adding an iCluster User (Optional)


After installing iCluster on an iSeries node, it is recommended that you create one or more iCluster users on this node through the DMADDUSRAdd User command. This step will allow you to work with iCluster without having to sign on to the system as QSECOFR or a user with QSECOFR authority. If you do not know the password for QSECOFR, adding at least one iCluster user allows you to work with iCluster through the specified user name after you have logged off from QSECOFR. Each iCluster user should have security access that is appropriate for their use of iCluster. Perform the following steps to add an iCluster user on a node where iCluster has been installed: 1 Sign on to the system as QSECOFR or a user with *SECADM authority. 2 Change the current library to the iCluster product library. 3 Issue the following iCluster command: DMADDUSR USER(<OS/400 user name>) AUTH(<iCluster authority level>) PASSWORD(<iCluster Administrator log on password>) where:

DataMirror, an IBM Company

Printed in Canada

29


Note:

<OS/400 user name> is an OS/400 user profile name that is defined on the node where the command is issued. The OS/400 user name must be defined on the node and must have *IOSYSCFG authority. <iCluster Administrator log on password> is the iCluster password that you want to associate with the user name specified through the USER parameter. The iCluster password does not refer to the password associated with the specified OS/400 user name. You need to specify a password only if you will be using the iCluster Administrator. It is suggested that the specified password be different from the password associated with the OS/400 user name. <iCluster authority level> is the authority level that you will grant to the user. For example, *ADMIN for administrative privileges.

You should grant administrative (*ADMIN) privileges to at least one iCluster user so that all product operations can be performed by this user. 4 Press Enter.

Securing the iCluster Product Library (Optional)


The iCluster product library was created during the installation process. Its default name is DMCLUSTER and it is owned by DMCLUSTER. Use the following procedure to authorize the use of iCluster to specific users. 1 Edit the authority of the iCluster library object using the following command: EDTOBJAUT OBJ(QSYS/<iCluster product library>) OBJTYPE(*LIB) where <iCluster product library> is the library where iCluster was installed. Note: If you revoke authority for the user *PUBLIC, you should make sure that you add the user DMCLUSTER and any other authorized user(s) with object authority *CHANGE.

2 Press Enter to complete the operation.

Scheduling iCluster Startup and Shutdown (Optional)


Note: This section assumes that the subsystem XDMCLUSTER is active. To schedule iCluster to start up or shut down automatically at scheduled times using the IBM supplied command ADDJOBSCDE (Add Job Schedule Entry), follow these steps: 1 Create a Control Language (CL) program to set the current library to the iCluster product library name, and to execute the desired iCluster command. The sample CL program below sets the current library to DMCLUSTER and starts cluster operations to the backup node in the cluster group GRP1 an initial refresh is performed before cluster operations are started. For a detailed description of all available commands, see iCluster iCluster Commands on page 97.
CL Program: OBJ Start ***********************Beginning of data ***************** 0001.00 PGM 0002.00 CHGCURLIB CURLIB (DMCLUSTER) 0003.00 DMSTRGRP GROUP (GRP1) REFRESH(*YES) STRAPY(*YES) 0004.00ENDPGM ***********************End of data************************

2 Add an entry to the OS/400 job scheduler by issuing the ADDJOBSCDE command. An example is the following: ADDJOBSCDE JOB(OBJ_START) CMD(Call <library name 1>/OBJ_START) FRQ(*WEEKLY) SCDDATE(*NONE) SCDDAY(*ALL) SCDTIME(080000) JOBD(<iCluster product library>/CSJOBD)

30

Printed in Canada

iClusterVersion 5.1

After You Install

where:

<library name 1> is the library where you created the CL program OBJ_START. <iCluster product library> is the library where you installed the iCluster product.

Cluster operations are scheduled to start daily at 8 a.m.

Adding Nodes
Before you can start performing cluster operations with iCluster, you must add at least one node to your cluster. For more information on performing this task, see Node Commands. Note: If you are using OS/400 Cluster Resource Services to manage your cluster, you must install the QGY system library on every node in the cluster.

DataMirror, an IBM Company

Printed in Canada

31

32

Printed in Canada

iClusterVersion 5.1

Uninstalling iCluster

Uninstalling iCluster
This chapter identifies the procedure that you can use to uninstall iCluster from your nodes.

Uninstalling iCluster
Before you run the uninstall program, you must do the following:

End all replication activity and close all open iCluster menus. End all queue managers for MQSeries groups that are replicating in the cluster. This will ensure that journaling ends for objects that are selected to MQSeries groups. iCluster will end journaling before the uninstall program begins.

Note:

Perform the following steps to remove iCluster from your node. 1 Sign on to the system as QSECOFR. 2 Enter the following command to change the current library, and then press the Enter key: CHGCURLIB CURLIB(<iCluster product library>) where <iCluster product library> is the library where iCluster was installed. 3 Enter the following command to start the uninstall program, and then press Enter: ?CSUNINST The iCluster Uninstall screen is displayed. After issuing the CSUNINST command, a screen appears that displays the product library name. 4 Verify that you have specified the iCluster product library name (this is the library where iCluster is installed). 5 Press Enter to start the uninstall program. Note: You will have to acknowledge system messages during the uninstall process. The uninstall program starts. The screen will be blank for several minutes. As iCluster is being removed from your node, messages will appear briefly on the screen. You do not need to perform any actions while this is taking place. You may receive a message indicating that the HADRCV and HABSFRCV journal receivers are never fully saved. This is a system message that is displayed when iCluster attempts to delete a journal receiver. Acknowledge the message to continue with the uninstall. When the uninstall is complete, you will return to the screen where you entered the uninstall command. Messages will be displayed to confirm whether or not iCluster was successfully removed. Proceed to Removing the iCluster Service Table Entries on page 39 to complete the uninstall process.

DataMirror, an IBM Company

Printed in Canada

33

34

Printed in Canada

iClusterVersion 5.1

Migrating HA Suite to iCluster

Migrating HA Suite to iCluster


This section identifies the steps required to migrate HA Suite to iCluster.

Introduction to the Migration Procedures


To migrate HA Suite Version 3.7 or greater to iCluster, you must run a command line migration utility (DMCVTHATGT) that will define iCluster replication groups based on metadata in your version of the HA Suite installation library. System parameters and SwitchOver System information defined in HA Suite will be migrated where possible. Note: You must install iCluster on your system before you can migrate from HA Suite.

General Constraints
Certain aspects of the HA Suite configuration cannot be ported to iCluster during the migration process. These include the following:

SNA communications: This type of communication protocol is not supported in iCluster. SwitchOver System (SOS) user exits: The argument list passed to the switchover user exits (before/after) differs between HA Suite and iCluster. You must change the user exit programs in order to conform to the argument list expected by iCluster.

Pre-migration Tasks
Before running the migration utility, ensure the following tasks are completed: 1 iCluster is installed on all machines involved in replication. For more information, see Installing, Re-Installing, or Upgrading iCluster on page 23. 2 The user running the migration utility has iCluster administrative rights for the current machine. Issue the DMADDUSRAdd User command for the user who will run the utility. 3 Cluster nodes are defined. For more information, see iCluster iCluster Commands.

Running the Migration Utility


To begin the migration process from HA Suite to iCluster, complete the following tasks: 1 To run the HA Suite to iCluster migration utility, enter the following command on the iCluster command line: Note: When executing this command, the iCluster product library should be the current library and the HA Suite product library should not be in the library list.

DMCLUSTER/DMCVTHATGT HALIB(<HA Suite library>) TARGET(<target name>) BACKUP(<backup node name>) where:

<HA Suite library> is the name of the library containing the HA Suite installation. <target name> is the name of a single HA Suite target. <backup node name> is the name of the backup node with which the target is associated.

You can issue this command only on an HA Suite source machine. It will perform metadata migration from HA Suite to iCluster. Upon successful completion of this command, iCluster replication groups, object specifiers, and system values (group/object) based on HA Suite metadata will be configured. Note: The DMCVTHATGT command will only operate on a single target and must be run separately for each target on every source machine. The HA Suite target's role must be set to *PRIMARY if it is HA-enabled.

DataMirror, an IBM Company

Printed in Canada

35

2 Check the job log for errors. If there are no errors in the job log, the migration is complete. You can now proceed to the next section to complete the migration process. If there are errors in the job log, you may have to run the migration utility again.

Post-migration Tasks
After completing the migration, perform the following tasks: 1 The source system must have minimal or no activity. An idle state is recommended. 2 Ensure there are no suspended objects. If the objects were purposefully suspended in HA Suite, these objects will have to be manually suspended in iCluster. For more information, see the DMSUSOBJSuspend Object command. 3 If HA Suite is running, make sure the apply has caught up and end replication. The Transactions to process value in the HA Suite Status Monitor should be zero. For more information, see the iCluster iCluster Commands on page 97. 4 Clear the HA Suite staging store library if it is to be re-used in iCluster. 5 Issue the DMREGPOSRegister Positions command. This command will set the positions of the journals scraped by iCluster. 6 Issue the DMSTRGRPStart Cluster Operations at Group command to start replication in iCluster for each group converted by the migration. Note: After migrating to iCluster, it is recommended that you do not remove the HA Suite default journal (HASUITE/HADJRN) from your system. It is likely that you will still have a number of files journaled to this journal. When you begin using iCluster, these files will continue to be journaled to the HASUITE/HADJRN journal.

36

Printed in Canada

iClusterVersion 5.1

Running iCluster Under TCP/IP

Running iCluster Under TCP/IP


This section provides instructions to help you configure iCluster so that it can communicate with an iSeries node under TCP/IP.

Adding a New Entry 'dmcluster' to the TCP/IP Service Table


You need to add a new entry (dmcluster) to the TCP/IP service table, and specify an unused port number. You can perform this task using Method 1 - Menu or Method 2 - Command.

Method 1 - Menu
1 On the command line of the Command Entry screen, enter CFGTCP. The Configure TCP/IP screen is displayed. 2 Select option 21 - Configure related tables. The Configure Related Tables screen is displayed. 3 Select option 1 - Work with service table entries. The Work with Service Table Entries screen appears. 4 Enter 1 in the Opt column and press Enter. The Add Service Table Entry screen is displayed. 5 In the Service field, you must enter 'dmcluster' (in single quotes). 6 In the Port field, enter an unused port number in the range of 1 to 65535. 7 In the Protocol field, enter 'tcp' (in single quotes). 8 In the Text 'description' field, enter a description to indicate that this port will be used by an iCluster TCP/IP node. 9 After entering the values, press Enter. You will receive a confirmation message if you successfully added a service table entry.

Method 2 - Command
1 On the command line, enter: ADDSRVTBLE SERVICE('dmcluster') PORT(<port number>) PROTOCOL('tcp') TEXT('<user description>') 2 Press Enter. You will receive a confirmation message if you successfully added a service table entry.

Restricting the Port Number from Being Used by Other Applications


To ensure that the port number that you specified in the installation program will not be used by other applications, you can add a restriction on this port using Method 1 - Menu or Method 2 - Command as follows:

Method 1 - Menu
1 On the command line of the Command Entry screen, enter CFGTCP. The Configure TCP/IP screen is displayed. 2 Select Work with TCP/IP port restrictions (option 4). The Work with TCP/IP Port Restrictions screen is displayed.

DataMirror, an IBM Company

Printed in Canada

37

3 Enter 1 on the first row under Opt and press Enter. 4 On the first line, enter the same port number you used when adding the service table entry. 5 In the Protocol field, enter *TCP. 6 In the User Profile field, enter DMCLUSTER. This ensures that the iCluster subsystem (XDMCLUSTER) can also access this port number. 7 Press Enter to issue the command. 8 Repeat this method for all other user profiles that can issue the STRHATCPStart TCP/IP Listener command.

Method 2 - Command
1 On the command line, enter: ADDTCPPORT PORT(<port number>) PROTOCOL (*TCP) USRPRF(DMCLUSTER) This ensures that the iCluster subsystem (XDMCLUSTER) can also access this port number. 2 Press Enter to issue the command. 3 Repeat this method, but replace "DMCLUSTER" with each user profile that can issue the STRHATCP command. See the STRHATCPStart TCP/IP Listener command for more information. There are also commands and command menus to remove the entry and restriction you have just added. For more information, see Removing the iCluster Service Table Entries on page 39 and Removing Port Number Restrictions on page 39.

Verifying Domain Name Server (DNS) Configuration


If you are using the local host table for host name resolution, then you must verify the domain name server (DNS) configuration to ensure that the local host table is initially searched for the host name. 1 On the command line of the Command Entry screen, enter CFGTCP. The Configure TCP/IP screen is displayed. 2 Select option 12 - Change TCP/IP domain information. The Change TCP/IP Domain (CHGTCPDMN) screen is displayed. 3 Verify that the Host name search priority field is set to *LOCAL. *LOCAL indicates that you want to use the local host table. If you want to search a domain name server before searching the local host table, set this field to *REMOTE (this is the default setting), and specify the IP address of the domain name server in the configuration. 4 Exit the screen.

38

Printed in Canada

iClusterVersion 5.1

Removing the iCluster Service Table Entries

Removing the iCluster Service Table Entries


This section explains how to remove the iCluster service table entries that were created after the installation.

Removing the dmcluster Table Entry


Perform the following steps to remove the dmcluster entry from the TCP/IP service table. You can use Method 1 - Menu or Method 2 - Command.

Signing on to your System


Sign on to the system as QSECOFR.

Removing dmcluster from the TCP/IP Service Table


Method 1 - Menu 1 On the command line of the Command Entry screen, enter CFGTCP. The Configure TCP/IP screen is displayed. 2 Select option 21 - Configure related tables. The Configure Related Tables screen is displayed. 3 Select option 1 - Work with service table entries. The Work with Service Table Entries screen is displayed. Note: You need to remember the port number associated with this entry because it is required when removing port restrictions. For more information, see Removing Port Number Restrictions on page 39.

4 Enter 4 in the Opt field beside the dmcluster service and press the Enter key to remove the entry from the service table. Method 2 - Command 1 On the command line, enter: RMVSRVTBLE SERVICE(dmcluster) PORT(<port number>) PROTOCOL (*TCP) 2 Press Enter.

Removing Port Number Restrictions


1 On the command line of the Command Entry screen, enter CFGTCP. The Configure TCP/IP screen is displayed. 2 Select option 4 - Work with TCP/IP Port Restrictions. The Work with TCP/IP Port Restrictions screen is displayed. 3 Enter 4 beside all entries for the port number used by iCluster. 4 Press Enter on the Confirm Delete screen.

DataMirror, an IBM Company

Printed in Canada

39

40

Printed in Canada

iClusterVersion 5.1

Other Considerations

Other Considerations
This section contains important considerations for upgrading the operating system, and provides information about messaging and system logs.

Additional Message Information


Except for cases of communication or machine failures, a message is displayed on the screen when a problem occurs. If a screen operator needs more information about a message in the message area, the operator can display the Additional Message Information by moving the cursor to the message area and pressing the F1 (HELP) key. The Additional Message Information display lists extended message text, the probable cause of the message, and a list of resolutions. If the problem cannot be solved, press F6 (PRINT) to log the error. Contact DataMirror Technical Support to obtain additional assistance. For more information, see Contacting Technical Support on page 547.

Batch Processes and Job Logs


For communications and other batch processes in iCluster, system job logs are produced for both primary and backup jobs that provide messages about the operation of each particular function. 1 To access the job logs, use the following command on either the primary or backup node: WRKSPLF USER(DMCLUSTER) Note that DMCLUSTER should be specified if the default iCluster job description is used. Otherwise, specify the user profile associated with the job description that you are using.

DataMirror, an IBM Company

Printed in Canada

41

42

Printed in Canada

iClusterVersion 5.1

iCluster Basics
This section contains the following topics:

Working in a Clustered Environment on page 43 Failovers and Switchovers on page 47 Object Specifiers and Types on page 50 Path Object Specifiers on page 53

Working in a Clustered Environment


This section provides a high-level view of iSeries clusters by examining the basic elements of a clustered environment. It describes the following components:

Nodes Replication Objects Groups Failover Mechanisms

Nodes in a Cluster
A node is a single iSeries computer. To use iCluster, you must add one or more nodes to the same cluster. This cluster becomes your replication environment. The replication environment identifies each node by a name entered by the iCluster Administrator. To successfully cluster a set of nodes, each node must have a unique name and be able to communicate with every other node in the cluster. You can add up to 128 nodes to a cluster. Figure 1shows a cluster with four nodes. The lines indicate network connections between nodes. Figure 1 A Four Node Cluster

DataMirror, an IBM Company

Printed in Canada

43

Master Node The first node you add to a cluster becomes the master node. In addition to the features available to all of the other nodes in the cluster, this node also maintains a repository of configuration information for the cluster. The following table illustrates how cluster membership affects the master node.
Table 1 Cluster Membership

Action 1. TORONTO joins cluster 2. NEW YORK joins cluster 3. DALLAS joins cluster 4. TORONTO leaves cluster 5. TORONTO rejoins cluster 6. NEW YORK fails

Nodes in Cluster TORONTO TORONTO NEW YORK TORONTO NEW YORK DALLAS NEW YORK DALLAS NEW YORK DALLAS TORONTO DALLAS TORONTO

Master Node TORONTO TORONTO TORONTO NEW YORK NEW YORK DALLAS

Replication Objects
Replication objects are the data, applications, and other objects on a node that you want to replicate. You can replicate data stored in native iSeries objects or Integrated File System (IFS) files. See Object Specifiers and Types on page 50 for a complete list of the objects you can replicate.

Groups
A group is a replication relationship between nodes in a cluster. When you create a group, you typically define the primary node and backup node in the relationship. iCluster provides the following types of groups for your replication environment:

Replication groups, which support the replication of objects and data for high availability. If you are using iCluster Administrator, see Working with Replication Groups on page 413. MQSeries groups, which provide a high availability solution for WebSphere MQ. If you are using iCluster Administrator, see MQSeries Group Commands on page 470. Application groups, which support application resiliency on clusters using IBM Cluster Resources. See Application Resiliency on page 68 for more information. Switchable device groups, which use IBM Cluster Resources to support switchable disks. Refresh-only groups, which perform a refresh of the objects selected to the group and then shut down. These groups are not eligible for role switch. If you are using iCluster Administrator, see Working with Replication Groups on page 413. Master-master groups, which support the mirroring of changes from the source to the target and vice-versa. For more information, see iBalance and Master-Master Replication on page 321.

44

Printed in Canada

iClusterVersion 5.1

The replication process copies data and applications from the primary node to the backup node. For example, in the cluster in Figure 1 on page 43, we can create a group that replicates data between the TORONTO and NEWYORK nodes. In this group, TORONTO is the primary node and NEWYORK is the backup node.

The primary node keeps a record of the data it has sent to the backup node. If the backup node goes offline, then the primary node will queue the replication requests and send them to the backup node when it becomes available again. In a cluster using the SwitchOver System (SOS) (see Failover Mechanisms on page 47, below), the backup node in a group regularly polls its connection with the primary node. By configuring node and group properties, you can control what the backup node does when it cannot verify its connection with the primary node. You can also define how many attempts the backup node makes to establish communication before taking action. To use your SOS cluster as a high availability solution, you can configure the backup node to become the primary node when it cannot communicate with the previous primary node. For example, consider the group that replicates data from TORONTO to NEWYORK. NEWYORK is configured to test the link to TORONTO every minute and wait for thirty seconds for Toronto to respond. If NEWYORK does not get a response within thirty seconds for five consecutive attempts, then it considers TORONTO to be unavailable and runs a user exit application that notifies the system administrator. The system administrator performs a switchover, which causes all applications to use NEWYORK instead of TORONTO without requiring application changes. These properties were configured when NEWYORK was added to the cluster. Nodes in a cluster can belong to multiple groups and can replicate the same or different objects in these groups. Figure 2 shows the sample cluster with its groups. The arrows indicate the groups and the group names appear in italics. Figure 2 All Groups in the Cluster

Figure 2 shows the following groups:

TNGRP: Replicates from the TORONTO (primary) node to the NEWYORK (backup) node. DTGRP: Replicates from the DALLAS node to the TORONTO node.
Printed in Canada 45

DataMirror, an IBM Company

TSGRP: Replicates from the TORONTO node to the SANJOSE node. NSGRP: Replicates from the NEWYORK node to the SANJOSE node. DALLAS is a primary node (for the DTGRP group). TORONTO is both a primary node (for the TNGRP and TSGRP groups) and a backup node (for the DTGRP). NEWYORK is both a primary node (for the NSGRP group) and a backup node (for the TNGRP). SANJOSE is exclusively a backup node (for the TSGRP and NSGRP groups).

This example also illustrates that the same node can serve multiple roles in the same cluster. In the example:

After creating a group, you can specify the objects that the group replicates from the primary to the backup node. You can specify multiple objects for replication in the same group. You can also specify the same object in multiple groups from the same primary node. For example, we can replicate INVENTORY/BOOKS from TORONTO to both NEWYORK and SANJOSE by specifying it in each of the TNGRP and TSGRP groups. We can also replicate an object to only one node, even though that node is the primary node to multiple nodes. For example, we can replicate HR/PAYROLL from TORONTO to only SANJOSE by only specifying it in TSGRP. Figure 3 shows these objects and the groups they are specified for. Figure 3 Specifying Replication Objects

Chaining Groups You can create replication sequences that make your cluster more resilient by chaining a group across multiple nodes. In our basic group scenario, when the TORONTO node fails, the NEWYORK node replaces it. You can then replicate from NEWYORK to SANJOSE. This provides another layer of resiliency to your cluster. Group Independence Replication groups operate independently of each other. You can start, stop, and configure one group without affecting the other groups in the cluster. For example, if the TORONTO node loses power, the NSGRP group is unaffected. Local Loopback Replication iCluster can replicate objects across separate physical systems or between environments on the same physical system. The latter approach is known as local loopback. Since replication is within the same physical system, iCluster cannot replicate an object on top of itself and does not allow you to perform recursive updates. You must specify a different target library for local loopback replication. Local loopback replication is available for native library-based objects. You cannot use local loopback replication with BSF objects, resilient applications, MQ Series groups, and switchable device groups.

46

Printed in Canada

iClusterVersion 5.1

Failover Mechanisms
iCluster uses your failover mechanism to detect and respond to outages in a cluster. iCluster supports the following failover mechanisms:

SwitchOver System (SOS) has the backup node in each group test its connection with the primary node regularly. If the primary node is unavailable, then the backup node declares the primary node as failed. When the backup node does this, you can also have it notify an administrator and run a user exit. The Switchover for SwitchOver System (SOS) on page 369 contains more information about this failover mechanism. IBM Cluster Resource Services (IBM CRS) uses the iSeries Cluster Resource Group to maintain the status of each node in the cluster. IBM CRS handles outages by either partitioning the cluster or failing the primary node, depending on how the outage occurred. The partition and failed states require administrators to develop multiple recovery strategies. The Switchover for IBM Cluster Resource Services (CRS) on page 341 contains more information about this failover mechanism.

See Failovers and Switchovers on page 47 for more information about how each failover mechanism handles planned and unplanned outages. See Choosing a Failover Mechanism on page 73 for more information on using these failover mechanisms in iCluster.

Failovers and Switchovers


A failover occurs when the primary (or production) node in a group unexpectedly becomes unavailable. When this happens, the system can either automatically move client applications and users to the backup node as a high availability solution or the system can wait for an administrator to take action. Power failures or network failures are examples of unexpected issues that can cause a node to become unavailable. A switchover occurs when an administrator decides to swap the roles of the nodes in a group. This causes the original backup node to replicate data to the original primary node. After a switchover, client applications and users use the new primary node (formerly the backup node). Failover and switchover handling is not supported for the following types of groups:

Groups that are refresh-only. Master-master replication groups Groups that are local loopback. Groups that have a target library other than *PRIMARY. Groups that have an object specifier selected whose target library is not *GRPSEL.

DataMirror, an IBM Company

Printed in Canada

47

The following sections describe the different types of failover and switchover and how each failover mechanism handles them. They use the following figures to illustrate the concepts using the group from Working in a Clustered Environment that replicates data from TORONTO to NEWYORK. Figure 4 Initial Group Replicates from TORONTO to NEW YORK

Figure 5

NEWYORK Becomes the Primary Node after TORONTO Fails

Figure 6

After Repairing TORONTO, it Becomes NEWYORK's Backup Node

48

Printed in Canada

iClusterVersion 5.1

Automatic Failover With both failover mechanisms, administrators can configure the backup node to automatically take over the role of the primary node during a failure. This is known as an automatic failover. In an automatic failover, the backup node assumes the role of the primary node to clients. If the primary node later becomes active, then objects are replicated from the former backup node to the former primary node. For example, consider the group that replicates from TORONTO to NEWYORK (Figure 4 on page 48). If TORONTO fails, then NEWYORK becomes the primary node in the group. Clients now connect to NEWYORK (Figure 5 on page 48). After correcting the problem, TORONTO is available again and, by default, will be the group's backup node for replication (Figure 6 on page 48). Manual Failover A manual failover situation occurs when the primary node of a group becomes unavailable and you, as an administrator, configures the group to wait for a response instead of performing an automatic failover. This allows administrators to try to fix the problem instead of changing the characteristics of their group and cluster. Each failover mechanism handles manual failover situations differently, depending on how the primary node became unavailable. The following scenarios illustrate the differences between how failover mechanisms handle manual failovers. Each scenario uses the group that replicates from TORONTO to NEWYORK (Figure 4 on page 48).

Scenario 1: SOS Cannot Communicate with the Primary Node


SwitchOver System (SOS) handles all primary node outages in the same manner. SOS does not distinguish between node or communication failures. Once the backup node cannot communicate with the primary node (determined by a set of configurable timeouts and thresholds), it changes the status of the primary node to *FAILED and suspends replication. To recover from this scenario, the administrator can either failover control to the backup node (the end result is the same as an automatic failover, see Figure 5 on page 48) or can repair the primary node and restart the group.

Scenario 2: IBM CRS Detects a Distress Signal from the Primary Node
IBM CRS has the ability to detect distress signals from nodes in a cluster. These signals warn the cluster of imminent outages. For example, if TORONTO loses power and switches to a backup power supply, it can notify the cluster that it is about to go offline as the power drains from the backup power supply.

DataMirror, an IBM Company

Printed in Canada

49

After receiving the distress signal, IBM CRS sets the status of the primary node to *FAILED and suspends replication. The administrator can either failover control to the backup node (the end result is the same as an automatic failover, see Figure 5 on page 48) or can fix the problem on the primary node and restart the group. See Switchover for IBM Cluster Resource Services (CRS) on page 341 for more information recovery options for this scenario.

Scenario 3: IBM CRS Loses Communication with the Primary Node


If IBM CRS loses communications with the primary node and did not receive a distress signal, then it partitions the cluster so that the nodes in each partition are aware of the communication problems to the other partition. If the administrator repairs the problem, then the cluster will automatically merge the partition and replication will continue as it did before the failure (Figure 4 on page 48). Otherwise, the administrator must either failover control to the backup node (the end result is the same as an automatic failover, see Figure 5 on page 48) or can fix the problem on the primary node and rejoin the group. See Switchover for IBM Cluster Resource Services (CRS) on page 341 for more information recovery options for this scenario. Switchover A switchover allows administrators to reverse the nodes in a group intentionally and under controlled conditions. A common switchover scenario is upgrading a computer that is part of a replication group. The switchover allows administrators to move clients off the computer before removing it from the network. When you perform a switchover on a group, the backup node takes over for the primary node. In our example (Figure 7), NEWYORK would become the primary node and TORONTO would be the backup. NEWYORK would replicate data to TORONTO. At this point, the group appears as it did after an automatic failover (Figure 9). Depending on your failover mechanism, the failover and switchover options available to you will differ. See Choosing a Failover Mechanism on page 73 for more information.

Object Specifiers and Types


In Working in a Clustered Environment on page 43, the concept of a group was introduced to illustrate how different replication paths can be defined in a cluster. A method of addressing objects that reside on a node is needed to identify the objects that are selected to groups for replication to backup nodes. iCluster uses object specifiers to achieve this objective. Object specifiers selected to groups are shown in Table 4. An object specifier consists of the following elements:

Object name Library name Object type Object attribute This element of the object specifier only applies to *FILE objects.

Generic and special values for the object name can be specified to reference multiple objects. The name of the library where this object is stored. A special value for the object type can be specified to reference all object types that can be replicated by iCluster. Note:

Object attributes allow you to specify the type of *FILE object. A special value for the object attribute can be specified to reference all types of *FILE objects that can be replicated by iCluster.

50

Printed in Canada

iClusterVersion 5.1

Constructing Object Specifiers


For example, assume that the following set of objects exist on an iSeries node:
Table 2 Sample Objects on iSeries Node

# 1 2 3 4 5 6 7 8 9 10 11 12 13

Object EMG HLPATS HLPAG HLPRTS M3024 M3909 HASETUP HAFSYS S1 S1 SRCJD SRCLG UKK

Library LIB1 HP1 HP1 HP2 TEST TEST TEST SLIB COM COM LIB1 OLG YLIB

Object Type *MSGF *PNLGRP *PNLGRP *PNLGRP *FILE *FILE *PGM *PGM *ALRTBL *STMF *JOBD *FILE *USRIDX

Physical File Not applicable Not applicable Not applicable Not applicable Source physical file Data physical file Not applicable Not applicable Not applicable Not applicable Not applicable Data physical file Not applicable

Table 6 contains a number of object specifiers and identifies the objects that are addressed by each specifier (the number assigned to each object in Table 1 is used in Table 3 to identify the addressed objects).
Table 3 List of Objects Addressed by Example Specifiers

Object Specifier Object SRCLG M* M3909 HLPA* HLPAT* HLPAT *ALL Library OLG TEST TEST HP1 HP1 HP1 LIB1 Object Type *FILE *FILE *PNLGRP *PNLGRP *PNLGRP *PNLGRP *JOBD Object Attribute PFDTA PF Not applicable Not applicable Not applicable Not applicable Not applicable

Addressed Objects (See # in Table 2)

12 5, 6 No objects are addressed 2, 3 2 No objects are addressed 11

DataMirror, an IBM Company

Printed in Canada

51

Table 3

List of Objects Addressed by Example Specifiers

Object Specifier Object *ALL M3 *ALL S1 H Library LIB1 *TEST TEST COM *SLIB Object Type *ALL *ALL *ALL *ALL *PGM Object Attribute Not applicable Not applicable Not applicable Not applicable Not applicable

Addressed Objects (See # in Table 2)

1, 11 5, 6 5, 6, 7 9, 10 8

Note the use of generic (for instance, M* and HLPA*) and special values (for instance, *ALL) in some of the specifiers. iCluster can replicate different types of objects within a group. It is important for you to recognize the object types that are supported by this product and to be aware of certain issues that address specific types. For more information about object types, see Object Types Replicated by iCluster on page 529.

Path Object Specifiers


A path object specifier identifies a set of Byte Stream File (BSF) objects, stored in the Integrated File System (IFS), for replication. See Replicating BSF Objects on page 89 for more information. You identify a path object specifier in iCluster by supplying the full path where the BSF objects are located. It is important to identify the correct path so that you address the correct set of objects. Like object specifiers, you can select path object specifiers to groups for replication. You can select both object specifiers and path object specifiers to the same group, although DataMirror recommends that you set up two groups. For more information about path object specifiers, see Path Object Specifiers on page 53.

Generic Object Specifiers


A generic object specifier has one or more of the following properties:

A generic name component. For example, AB*. Name component of *ALL. Type component of *ALL or *FILE. Type component of *FILE and attribute component of *ALL. Note that the attribute component is ignored for object types other than *FILE.

Note:

Rules of Precedence for Object Specifiers


The following numbered list outlines the rules of precedence that iCluster applies when an object matches several object specifiers (1 = highest precedence, 3 = lowest precedence): 1 Exact specifiers (non-generic) have the highest precedence. INCLUDE and EXCLUDE specifiers have the same precedence when they are exact specifiers. 2 Generic EXCLUDE specifiers have the next highest precedence. 3 Generic INCLUDE specifiers have the lowest precedence.

52

Printed in Canada

iClusterVersion 5.1

There is no precedence among generic specifiers based on the length of the non-generic part. For example, A* as an EXCLUDE specifier has higher precedence than AB* as an INCLUDE specifier. An object named ABBA will therefore be excluded from replication. Note that there are parameters that you can specify on the object specifier that will determine, depending on the object type, how the objects matching the object specifier are replicated. These include the following:

Object polling interval - POLLINT parameter File update method - PFUPDMTD parameter

See DMDSELOBJDe-select Objects from Group (Deselect Object Specifier for iCluster Administrator) for more information on these parameters and how to select an object specifier for a replication group.

Native Object Specifier Changes While Replication is Active


iCluster supports the following with respect to native object specifier changes while replication is active:

Addition of new *INCLUDE object specifiers while replication is active for native object specifiers. Activation (with or without refresh) of objects coming into replication scope due to the addition of new *INCLUDE object specifiers. Metadata maintenance for objects due to the addition of new *INCLUDE object specifiers. As a result, there is no need for a user-specified starting journal position.

Path Object Specifiers


Path object specifiers are used to refer to objects within the Integrated File System (IFS) that you want to replicate. IFS is a OS/400 feature that supports a hierarchical directory structure similar to that found on personal computers and UNIX systems. The IFS integrates support for a number of file systems, such as QDLS, the "root" file system, and the QOpenSys file system. You can use IFS to port PC or UNIX-based applications to an iSeries system. IFS is the name used to refer to the file system, but references to the actual BSF objects that reside in this system will be through path object specifiers. See Replicating BSF Objects on page 89 for more information. Naming Conventions When creating a path object specifier, you indicate the full path name where the BSF objects that you want to replicate reside on the primary node. For example, '/Dir1/Dir2/Dir3/Dir4/file' and '/Dir1/Dir2/Dir5/Dir6/*. The path name must be contained in single quotes. Note the following regarding the definition of path object specifiers:

The path must start with a '/' (forward slash) character ('/Dir1'). The path cannot end with a '/' (forward slash) character ('/Dir3/Dir4/file'). The path can have a maximum of 5000 characters. You must enter at least two characters for the path. Generic path names of the form '/mydir*' are supported, where the generic indicator '*' is the final character of the path name. DataMirror strongly recommends that you do not specify '/*' because this specifier matches the entire IFS system, including objects that should not be replicated from one system to another.

Note:

If you are creating a path object specifier that references multiple directories, you can create an exclude object specifier by using the following methods:

Exclude a particular directory and its contents, including its sub-directories, from replication by adding an asterisk (*) to the last character of the file that you want to replicate. Create an exclude object specifier that matches the object that you do not want replicated.

DataMirror, an IBM Company

Printed in Canada

53

To exclude from replication a directory named '/Dir3/Dir4', then you should specify the following path object specifier EXC '/Dir3/Dir4*' (where EXC indicates an exclusion). In contrast, specifying EXC '/Dir3/Dir4/*' will exclude the contents of the '/Dir3/Dir4' directory, but not the directory itself.

The longer the non-generic portion of the path name, the higher the precedence it has.

Journaled and Non-journaled Path Object Specifiers


Non-journaled BSF support is appropriate for applications that create large numbers of files that are not changed after they are created or, if the file is changed, it is actually replaced with a new version of the file. For example, an application that includes photographs of objects is unlikely to ever edit the photographs. The photograph is added and may be deleted later, but will not be changed. Journaling of the files that contain the photographs is not required for replication and the overhead of journaling can be avoided by mirroring the files using the non-journaled BSF support. Journaled BSF support is appropriate for applications that store modifiable data in BSF objects. These applications change the contents of the data contained in the BSF objects and, therefore, journaling is required to mirror those changes in real time. See DMADDBSFAdd Path Object Specifier to Group (Add Full Replication Group for iCluster Administrator) for more information on non-journaled BSF support or Replicating BSF Objects on page 89 for more information on BSF objects.

54

Printed in Canada

iClusterVersion 5.1

Auto-configuration of iCluster

iCluster Quick Start


This section contains the following topics:

Auto-configuration of iCluster on page 55 Quick Start for the iCluster Command Line on page 57 Starting iCluster from the Command Line on page 58 Quick Start for iCluster Administrator for Windows on page 59 Logging on to iCluster Administrator for Windows on page 60

Auto-configuration of iCluster
The DMAUTOCFGAuto-configure iCluster command enables you to configure iCluster automatically. This command is not available from the iCluster menus but runs immediately and interactively from the command line. For an example of how to configure your cluster by manually running the commands, see Quick Start for the iCluster Command Line.

DMAUTOCFGAuto-configure iCluster
DMAUTOCFG PRMNODE( ) PRMIPADR( ) BCKNODE( ) BCKIPADR( ) PRMGRP( ) SECGRP( ) SELOBJO( ) This command automatically configures iCluster based on a typical installation. It also displays a list of all libraries on your system. By using this command, you do not have to issue seperate commands to create nodes, groups, object specifiers for each library, default journals, or set the iCluster system values. Once the DMAUTOCFG command is run, you can modify the configuration to fit the business requirements for High Availability. For this command to work, the iCluster product subsystem (XDMCLUSTER) and the DMCHATL job must be active on both nodes. The command will prompt for primary and secondary node names and IP addresses. Optionally, you can specify primary and secondary group names or use PRIMARY and SECONDARY as the default group names. To use this command, the TCP port for the dmcluster service must be 4545. This is the default port setting. For more information, see Running iCluster Under TCP/IP on page 37. This command does the following:

Creates the iCluster primary and secondary nodes using the names and IP addresses specified. Creates the default journals HADJRN and HABSFJRN and journal receivers HAD0000001 and BSF0000001 in a library called AAAJRNLIB. Sets the iCluster product system values to use the journals in AAAJRNLIB as the default journals. Creates two replication (type *REPL) groups with the names defined in the PRMGRP and SECGRP parameters. Both groups use the default journals that are created in the AAAJRNLIB library. A third group called SYSTEM will be created if the current installation is an iCluster Enterprise installation. Creates object specifiers for all user profiles, authorization lists (excluding those whose name begins with the letter 'Q'), output queues (excluding those whose name begins with the letter 'Q'), and the QGPL library (excluding all objects whose name begins with the letter 'Q') and these specifiers will be added to either the SYSTEM group for iCluster Enterprise or into the Secondary group for iCluster SMB.

The command displays all user libraries (excluding objects whose name begins with the letter 'Q' and DataMirror libraries) and allow you to choose object specifiers for the Primary and Secondary groups by library name, or just use F13 to place everything into the Primary group.

DataMirror, an IBM Company

Printed in Canada

55

Once iCluster has been configured, you can also run this command by specifying the additional parameter for select object specifiers only (SELOBJO). This option will bypass the steps mentioned above (adding nodes, configuring groups, etc.) and just display the list of libraries for selecting object specifiers. Adding object specifiers to the iCluster groups will turn on object auditing for the libraries, thus modifying the last updated date and time, so the next SAVCHGOBJ may save more objects then expected. It is recommended that a full save be done before the next SAVCHGOBJ. Input Parameters

PRMNODE Specify the name of the primary node for iCluster. If you have multiple OS levels within the cluster, this should be the node with the lowest (earliest) i5/OS release. This is a required parameter.

PRMIPADR Specify the IP address or the fully qualified host name of the primary node specified for the PRMNODE parameter specified above. The IP address of the node can be specified in dotted quad notation (142.4.15.133) or in domain name form (prod400.mycorp.com). This is a required parameter.

BCKNODE Specify the name of the secondary node for iCluster. This is a required parameter. BCKIPADR Specify the IP address or the fully qualified host name of the secondary node specified for the BCKNODE parameter above. The IP address of the node can be specified in dotted quad notation (142.4.15.133) or in domain name form (prod400.mycorp.com). This is a required parameter.

PRMGRP Specify the name of the primary iCluster group. The command will display a list of all user libraries (*ALLUSR) on the system. You can use F13 to select all of these libraries by default to this group, or you will have the option of choosing which libraries should be selected to this group by placing a P (for primary) next to the library name. Enter a group name or use the following default value:

PRIMARYThe default name of the primary group.

SECGRP Specify the name of the secondary iCluster group. If iCluster SMB is installed, all system objects will be added to this group. You will be presented with a display of all user libraries (*ALLUSR) on the system and you will have the option of using F13 to add all libraries to the previously specified Primary group or choose which libraries should be selected to this group by placing an S (for Secondary) next to the library name. Enter a group name or use the following default value:

SECONDARYThe default name of the secondary group.

SELOBJO Specify whether you want to select object specifiers when running this command. Specify one of the following values:

56

Printed in Canada

iClusterVersion 5.1

Quick Start for the iCluster Command Line


Examples

*YESIndicates that you want to run this command but only select object specifiers. The groups, nodes, and other objects must have already been created by a prior run of this command. The command assumes all nodes, groups and journals have been created and will go directly to the display of all user libraries and will allow the user to select which libraries should be selected to which group. *NOIndicates that the command will run in its entirety and will create nodes, groups, journals, and set iCluster system values.

The default setting for this parameter is N.

DMAUTOCFG PRMNODE(400P) PRMIPADR(400P) BCKNODE(400Q) BCKIPADR(400Q) PRMGRP(PRIMARY) SECGRP(SECONDARY) SELOBJO(N) Creates a primary node named 400P. Creates a backup node named 400Q. Creates a primary group using the default value of PRIMARY. Creates a secondary group using the default value of SECONDARY. The command will run in its entirety and will create nodes, groups, journals, and set iCluster system values. Minimum Security Level Administrator (*ADMIN) Menu Access This is an interactive command and it is not available from the menus.

Quick Start for the iCluster Command Line


This topic describes some sample steps to help you create a cluster with a replication group. After completing the procedure, you will have a working cluster with data that has been replicated from one node to another. Many of the commands in this topic have parameters that are not included in this tutorial. See iCluster Commands on page 97 for a complete list of parameters. Before starting, you must be logged onto a node as a user with iCluster *ADMIN authority. This node will be the master node in the cluster and the primary node for the replication group. You will also need to have values for the following placeholders.
Table 4 Placeholders for Quick Start Description

Placeholder

<lib> <port> <primary> <backup>

The iCluster product library. This value was defined during the iCluster installation process. The default library name is DMCLUSTER. The iCluster TCP/IP listener port. This value was defined during the iCluster installation process. The default port is 4545. The name of the primary node. You will use this name in both the node name and IP address fields. The name of the backup node. You will use this name in both the node name and IP address fields.

DataMirror, an IBM Company

Printed in Canada

57

Perform the following tasks on the primary node to complete this tutorial: 1 Change to the iCluster library by entering the following commands: > CHGCURLIB <lib> > GO DMCLUSTER 2 Create a library and data area object to replicate by entering the following commands: > CRTLIB LIB(MYLIB) TYPE(*TEST) TEXT('TEST LIBRARY') > CRTDTAARA DTAARA(MYLIB/MYDATA) TYPE(*CHAR) > CHGDTAARA DTAARA(MYLIB/MYDATA) VALUE(HELLO) 3 Add a primary node to the cluster. This node must be the node you are currently logged into. Enter the following command to do this: > DMADDNODE NODE(<primary>) IPADDR(<primary>) PORT(<port>) PRODLIB(<lib>) 4 Add another node to the cluster. This node will be the backup node for the replication group. > DMADDNODE NODE(<backup>) IPADDR(<backup>) PORT(<port>) PRODLIB(<lib>) 5 Add a replication group between the primary and backup nodes. > DMADDGRP GROUP(MYGROUP) GRPTYPE(*REPL) PRIMNODE(<primary>) BACKUPS(<backup>) 6 Select the object you want to replicate with the group. For this tutorial, the object is the data area you created in Step 2. > DMSELOBJ GROUP(MYGROUP) OBJ(MYLIB/MYDATA) OBJTYPE(*DTAARA) 7 Start the replication group. This mirrors the data area to the backup node. > DMSTRGRP GROUP(MYGROUP) REFRESH(*YES) USEMARKED(*NO) 8 Verify the replication by viewing the data area on the backup node. You can do this by running the following command on the backup node: > DSPDTAARA DTAARA(MYLIB/MYDATA) This displays the data area you replicated from the primary node. Related Topics For more information on the steps in this topic, see the following topics:

Working in a Clustered Environment on page 43 Starting iCluster from the Command Line on page 58 DMADDNODEAdd Node on page 99 DMADDGRPAdd Group on page 113 DMSELOBJSelect Objects to Group on page 141 DMSTRGRPStart Cluster Operations at Group on page 208

Refer to your IBM documentation for more information on the other commands in this tutorial.

Starting iCluster from the Command Line


To invoke iCluster commands, you must change your current library to the iCluster product library that you specified during installation. For more information, see Step 10 in the installation procedure.

58

Printed in Canada

iClusterVersion 5.1

Quick Start for iCluster Administrator for Windows

To invoke iCluster from the command line:


1 Issue the following command on an OS/400 command line: > CHGCURLIB <iCluster product libcrary> where <iCluster product library> is the name of the library where iCluster was installed. iCluster also provides menus from where you can issue commands. 2 To display the DataMirror iCluster Main Menu, issue the following command: > GO DMCLUSTER In addition to the main menu, which lists the commands that you are most likely to use on a regular basis, another menu (DataMirror iCluster Commands) is provided that lists all supported iCluster commands. From most iCluster screens, you can access this menu by pressing F22 (SHIFT+F10). For each command described in this document, the menu option number(s) that you can use to invoke the command are identified.

Quick Start for iCluster Administrator for Windows


The iCluster Administrator provides functions for refining a cluster configuration. Below is a set of basic steps that you should follow to start cluster operations quickly in your working environment. Perform the following steps after you have installed iCluster on each node, and installed the iCluster Administrator and iCluster Event Viewer on a Windows workstation: 1 Register your existing OS/400 user name in iCluster. The OS/400 user name must be defined on a node in the cluster, and registered in iCluster through the DMADDUSRAdd User command. You must have system administrator or *SECOFR authority to issue this command. The iCluster password that you specify will be used in Step 2. Note: It is recommended that OS/400 user names be registered in iCluster immediately after installing the product on each node in the cluster. See the Installation and Upgrade for more information.

2 Start and log on to the iCluster Administrator. The iSeries system that you must specify during the log on process must be the one where the DMADDUSRAdd User command was issued (see Step 1). For more information, see Logging on to iCluster Administrator for Windows on page 60. 3 Add the master node to the cluster. The first node added to the cluster is considered as the master node. This node must be the iSeries system that you specified during the login process (see Step 2). See the Add Node command. See Working in a Clustered Environment on page 43 for more information about the master node. 4 Add other nodes to the cluster. When adding other nodes to the cluster, ensure the iCluster Administrator is connected to an active node in the cluster. To add other nodes to the cluster, use the Add Node command again. 5 Add replication groups, MQSeries groups, and resilient applications. When adding replication groups, MQSeries groups, and resilient applications, you will identify the nodes in the recovery domain for new replication groups, resilient applications, and MQSeries groups.

DataMirror, an IBM Company

Printed in Canada

59

To add replication groups, use the Add Full Replication Group command. To add resilient applications, use the Add Resilient Application command. To add MQSeries groups, use the Add MQSeries Group command. 6 Select object specifiers to replication groups. This step is required only if you added replication groups in Step 5. To select object specifiers to replication groups, see Select/Add Object Specifier. 7 Synchronize objects on primary and backup nodes. Objects on the primary node must be synchronized with the same objects on the backup node before mirroring is started. You can perform this step in one of the following ways: On the primary node, save the objects to a save file or tape, and restore them on the backup node. Issue the Mark Journal Positions command for the replication groups and resilient applications defined earlier. When you start cluster operations for the groups and applications (see Step 8), set Use Marked Journal Positions to *YES. When you start cluster operations for the replication groups and resilient applications (see Step 8), set Refresh Selected Objects to *YES, and set Use Marked Journal Positions to *NO. 8 Start cluster operations. This step starts mirroring objects. The command you need to issue depends on the objects that you want to mirror. To start mirroring within replication groups, use the Start Full Replication Group command. To start mirroring for resilient applications, use the Start Resilient Application command. To start mirroring for MQSeries groups, see Start MQSeries Group.

Logging on to iCluster Administrator for Windows


This section explains how to log on to the iCluster Administrator.

To log on to iCluster Administrator for Windows


1 From the Windows Start button, select the program group you specified for iCluster during installation. 2 Select iCluster, then iCluster Administrator from the submenu. The iCluster Administrator Login dialog box opens.

60

Printed in Canada

iClusterVersion 5.1

Logging on to iCluster Administrator for Windows

This dialog box allows you to log on to a specific iSeries node from the workstation where you have installed iCluster. A successful log in is required to work with the different elements in your cluster configuration. The version of iCluster Administrator is displayed under Version Information. 3 In the User Name box (under User Information), specify the OS/400 user name that you want to use to log in to the system. The specified user name must be defined as a user profile on the iSeries system that is identified in the Node List box (see below), and the same name must also have been defined in iCluster through the DMADDUSRAdd User command. You can issue this iCluster command only locally on the iSeries system, and not through the iCluster Administrator. 4 In the Password box (under User Information), specify the iCluster password that is associated with the user name specified in the User Name box (see above). The password that you enter in this box is the one that was specified through the DMADDUSRAdd User (see above) or DMCHGUSRChange User command when the user name was defined in iCluster on the iSeries system identified in the Node List box (see below). It is not the password that is used to log on to the iSeries system under that name. To change an iCluster password, the DMCHGUSRChange User command has to be issued on the iSeries system with the PASSWORD parameter set to the new password. Note: The password is case-sensitive. 5 In the Node List box (under Connection Information), specify the name of the iSeries system where the login procedure will be performed. You can select system names specified in previous login attempts. Note: If you are logging in for the first time, you will have to enter the system name in the IP Address box (see below).

6 In the Host Name box (under Connection Information), specify the Host Name or the IP address of the iSeries system where the login procedure will be performed. You can also enter an iSeries system name (for example, NODE1) in this box. The IP address of the node can be specified in dotted quad notation (for example, 125.4.3.55) or in domain name form (for example, as400sys1a.abccorp.com).

DataMirror, an IBM Company

Printed in Canada

61

7 In the Port box (under Connection Information), specify the port number on the iSeries node that will be used for communications with the workstation where iCluster Administrator is running. This port number was specified during iCluster installation on the iSeries node. See Running iCluster Under TCP/IP in the iCluster Installation and Upgrade for information about the port number specification. The default port number is 4545, but consult your iSeries system administrator to obtain the port number you should specify. 8 Ensure that the iCluster Administrator box (under Windows) is checked. By default, this box is checked. 9 Check the iCluster Event Viewer box if you want to display the iCluster Event Viewer. See Starting the iCluster Event Viewer for more information. 10 Click Execute. If the attempt to log on is successful, the iCluster Administrator window opens.

This window allows you to configure your clustered environment by defining the nodes, replication groups, objects, resilient applications, and other elements that interact to support high availability. An explorer-style interface is provided so that you can view the relationship between different elements, and work with specific items that have been defined in iCluster Administrator. The iCluster Administrator consists of two main panes:

iCluster tree view: Displays the relationship of nodes, groups, and object specifiers. The tree view represents the iCluster hierarchy and status in real time. Each entity may display different icons depending on status. iCluster table view: Displays detailed information concerning the currently selected item on the left-hand side of the window.

62

Printed in Canada

iClusterVersion 5.1

iCluster Operations
This section discusses the following topics:

Command Security on page 63 Adding and Configuring Nodes on page 67 Initial Synchronization on page 68 Application Resiliency on page 68 Staging Objects on page 69 Locked Objects on page 70 Avoiding Contention on page 70 Commitment Control on page 71 Suspended Objects on page 72 Choosing a Failover Mechanism on page 73 Starting Replication and Journal Positions on page 75 Monitoring Out-of-Sync Objects on page 77 Monitoring Latency on page 78 Restarting iCluster after Restarting a Node on page 79 Upgrading the Cluster Version on page 80 Changing IP Addresses on page 80 Journaling in iCluster on page 81 Passing Arguments to Sync Point User Exit Programs on page 86

Command Security
iCluster ensures operational security by restricting the ability to run commands to users based on user access levels. This topic lists the commands that are available to users with each access level.

Operating System Authority


This section lists commands that require OS/400 authority to run.

Commands Available to any OS/400 User


Any OS/400 user with access to the iCluster library can run the following commands:

ADDPFEXPGM DMDSPAPPGP DMSNDOBJ DMSYSINF DSPHASC INITHAOBJ RBDHAMQM RTVRCVPTR

DataMirror, an IBM Company

Printed in Canada

63

STRHASC VFYHAJRN WRKHASMON CHGHAJRN DMDSPASPGP DMWRKOBJST DSPHASMON JRNHADADQ RMVPFEXPGM SELSCATTR STRHASCUSR WRKHABSFST WRKHATMON CHGHASMON DMSCRPT DSPHABRCD ENDHABRCD PRGHASC RTVHAPOS SETHAREG STRHATCP WRKHAJOB CRTCFGOBJ DMSCRPTNTV DSPHAPOS HAPNGTCP PRGHASMON RTVRCVPT STRHABRCD SYNCHATRG WRKHAOBJST

Commands Available to OS/400 Security Officers


The following iCluster commands can only be run by users who have *SECADM authority are signed in as QSECOFR:

DMADDUSR DMCHGUSR DMRMVUSR DMWRKUSR

64

Printed in Canada

iClusterVersion 5.1

Commands Available to *ALLOBJ Users


Only users who have *ALLOBJ authority or are signed in as QPGMR, QSYSOPR, or QSRV can run the DMCHGTIME command.

iCluster Authority
When adding iCluster users with the DMADDUSR command, the system administrator assigns an authority level to the user. The possible authority levels are *USER, *OPERATOR, and *ADMINISTRATOR.

iCluster User Commands


iCluster users with *USER authority can monitor and inspect objects in the cluster. They have access to the following commands:

DMCLRLOG DMWRKAPP DMWRKOBJ DMDSPGRP DMWRKBSF DMDSPLOG DMWRKGRP DMDSPNODE DMWRKNODE

iCluster Operator Commands


iCluster operators, users with *OPERATOR authority, can initiate cluster operations, view journal positions, and see cluster system values. Operators can run all *USER authority commands as well as the following commands:

DMACTBSF DMENDGRP DMLOGENT DMSETPOS DMSTRGRP DMSUSOBJ DMACTOBJ DMENDNODE DMSETSYNC DMSTRNODE DMGENEXC DMENDAPP DMMRKPOS DMSTRAPP DMSTRREPL DMENDAPY DMREGPOS DMSTRAPY

DataMirror, an IBM Company

Printed in Canada

65

DMSUSBSF

iCluster Administrator Commands


iCluster administrators, users with *ADMINISTRATOR authority, can configure all cluster aspects except for user operations. Administrators can run all * OPERATOR and *USER authority commands as well as the following commands:

DMADDAPP DMADDNODE DMAUTOCFG DMCHGGRP DMCHGSWDEV DMREJOIN DMRMVBSF DMSELOBJ DMSTRSWO DMADDBACK DMADDSWDEV DMCHGNODE DMDLTCLSTR DMRMSWDEV DMRMVGRP DMSETPRIM DMSWOAPP DMADDBSF DMCHGAPP DMCHGOBJSL DMDSELOBJ DMRMVAPP DMRMVNODE DMSETSVAL DMUPDAPP DMADDGRP DMCHGBSF DMCHGROLE DMRBDNODE DMRMVBACK DMRMVSWDEV DMSTRDM

66

Printed in Canada

iClusterVersion 5.1

Adding and Configuring Nodes


The following information pertains to the configuration and addition of nodes to your clustered environment through iCluster. Prerequisites Nodes must meet the following requirements before you add them to a cluster:

The first node you add to a cluster must be able to communicate with every other node in the cluster. The node's Internet Daemon (INETD) must be running. You can start this by running the following command:

STRTCPSVR SERVER(*INETD) DataMirror also recommends adding this command to the autostart job that runs when then the machine loads. The XDMCLUSTER subsystem must be running on all of the other nodes currently in the cluster. The DMCHATL listener job must also be running in this subsystem. See STRHATCPStart TCP/IP Listener on page 202 for more information on the listener job. Never stop the XDMCLUSTER subsystem on a node that is currently in a cluster. DataMirror recommends setting the event log's message generation level to *ALL. This ensures that all cluster information is recorded in the node operations fail. After configuring your cluster, you can lower this level to meet your business needs. See DMSETSVALSet Cluster System Values on page 181 for more information. Nodes must have the ALWADDCLU network attribute set to either *ANY or *RQSAUT. If *RQSAUT is the network attribute, then you must also have the Digital Certificate Manager and a Cryptographic Access Provider installed on the node. See your IBM documentation for more information.

Note:

If you are using the IBM CRS failover mechanism, then nodes must also meet the following requirement:

See Choosing a Failover Mechanism on page 73 for more information. Adding Nodes To add a node to a cluster, call the DMADDNODEAdd Node command. After the command completes, the node will be automatically started in the cluster. See the DMADDNODEAdd Node command for more information. Changing Nodes To change a node that is currently in a cluster, call the DMCHGNODEChange Node command. You cannot change a node if it has any active replication groups. See the DMCHGNODEChange Node command for more information.

Removing Nodes
Node information is shared between the nodes in a cluster when they are active. This requires that at least one node in the cluster must be active before you remove any nodes from the cluster. If all of the nodes in a cluster have stopped, then the nodes will be unaware of the change. This can corrupt your cluster configuration. The following procedure illustrates a possible way to safely remove nodes. 1 Open the Work with Nodes screen by running DMWRKNODEWork with Nodes from the command line. Alternatively, you can select 1 on the commands menu. 2 Verify that at least one node has a status of *ACTIVE. This does not include the status of the node you are removing. There is no restriction on the status of the node you are removing. 3 Enter option 6 next to the node you want to remove from the cluster. See DMRMVNODERemove Node for additional considerations before you remove the node. 4 Press the Enter key to confirm the operation. After performing these steps, the node will be removed from the cluster.

DataMirror, an IBM Company

Printed in Canada

67

Initial Synchronization
There are several issues that you should consider before starting replication with iCluster. System Values iCluster supports system values that can be used to control different behaviors of your cluster. System values should be reviewed and initialized prior to starting replication for the first time. See DMSETSVALSet Cluster System Values (Setting System Values for iCluster Administrator) for more information on setting and viewing system values. Refresh (Before Mirroring) Initiating a refresh operation replicates the selected objects in a group from the primary node to the backup node before mirroring begins. Since mirroring only replicates changes made to objects on the primary node, refreshing the data ensures the object on the backup node has changes made before mirroring began. Use the REFRESH parameter of DMSTRGRPStart Cluster Operations at Group (Start Full Replication Group for iCluster Administrator) to initiate this operation. When refreshing physical files in iCluster, you can choose whether these files on the primary node are locked or can be modified during refresh operations when all data is sent across the network. Mirroring After synchronizing objects on primary and backup nodes through a refresh, mirroring ensures that updates applied to group objects on the primary node are replicated immediately to the backup node. Mirroring occurs automatically in any group that is started and has a status of *ACTIVE. You can start a group with DMSTRGRPStart Cluster Operations at Group (Start Full Replication Group for iCluster Administrator). Mirroring maintains an up-to-date image of objects on the backup node. This ensures that a switchover or failover to the backup node can be performed without disrupting business operations. See Failovers and Switchovers on page 47 for more information. Mirroring is a conceptually continuous operation that is only stopped as a result of anticipated or unplanned interruptions.

Application Resiliency
In addition to moving objects in your clustered environment, you will also want to have the same applications running on a new primary node after a switchover or a failover occurs. Applications that can be re-started automatically after a switchover or failover are called resilient. Resilient applications are designed by their software vendors to operate in a clustered environment. This means that if a primary node stops, the same resilient application installed on the backup node can be started with minimal or no disruptions to service. Application vendors provide the necessary data areas and files that allow their applications to operate in a clustered environment. You should check with the application vendor whether the application has been designed to operate in a clustered environment. In iCluster, you do not have to be aware of the configuration information of the resilient application. Instead, commands are provided in iCluster to add and change a resilient application. Other commands allow you to start and end cluster operations for resilient applications. You can also update a resilient application in iCluster when the data areas and files provided by the application vendor change on the primary node. Note: The resilient application and configuration information must reside on all nodes in the recovery domain in order to support a resilient application switchover or failover.

See the following topics for more information:


68

DMADDAPPAdd Resilient Application on page 167, Add Resilient Application for iCluster Administrator DMCHGAPPChange Resilient Application on page 172, Change Resilient Application for iCluster Administrator DMSTRAPPStart Cluster Operations for Resilient Application on page 217, Start Resilient Application for iCluster Administrator DMENDAPPEnd Cluster Operations for Resilient Application on page 218, End Resilient Application for iCluster Administrator DMUPDAPPUpdate Resilient Application on page 172, Update Resilient Application for iCluster Administrator
Printed in Canada
iClusterVersion 5.1

Staging Objects
Staging is a storage mechanism of iCluster that holds journal entries on a backup node before they are applied to the target objects. This allows the apply jobs to be ended and backup and other maintenance operations to be performed that require exclusive access to files and objects. Cluster operations for the group are allowed to continue, but changes will not be applied on the backup node until the apply jobs are started again. Ending the apply process for a backup node does not affect processing on the node that is replicating objects until all available staging storage has been filled. The amount of space available for the staging store is set for each node with the staging store size parameter on the DMADDNODEAdd Node (Add Node in iCluster Administrator) and DMCHGNODEChange Node (Change Node in iCluster Administrator) commands. If cluster operations for the group are active when the apply process is stopped, the backup node will continue to receive journal information which will be placed into the staging store. If the staging store becomes full, then journal scraping will stall. The apply process on a backup node can be stopped or started independently of any cluster operation. If the group is not currently active, the apply process will end once the staging store has been drained. Staging Store and Allocation The staging store is a non-volatile storage area that is managed on a node basis. The size of the staging store must be set for each physical node in the cluster. The staging store is a non-volatile storage mechanism for backup nodes that is managed on a node-by-node basis. The size of the staging store must be set for each backup node in the cluster. All information transferred to backup nodes will travel through the staging store and assuming the apply process is active, will be applied. If the apply process is not active, the staging store will store all journal entries until the apply process is started. You can increase the size of the staging store at any time, and you can change the maximum size of the staging store. iCluster will use extra space allocated if needed while active. A decrease in the size of the store will only be made if the total size of transactions in the store is less than the maximum size of the store and all iCluster replication is ended on the node. If necessary, you can also choose to force drain the staging store when the apply process is started. Normally, the apply process merges entries from the audit and database channels and applies them in sequence. When one channel becomes empty, the apply process will stop regardless of any entries remaining in the other channel. When the staging store is force drained, then the merge will stop once the last entry of the channel with fewer entries is reached, and the apply process will then drain the other channel until it is empty. Clearing the Staging Store iCluster will clear the portion of the staging store reserved for a group, regardless of whether those entries have been applied on the backup node, in the following instances:

When you start replication with the Use marked journal positions parameter set to *YES. When you start replication after issuing the DMSETPOSSet Journal Start Position (Set Journal Positions in iCluster Administrator) command. When you start replication with a refresh before mirroring (Refresh before mirror parameter is set to *YES).

If you want the entries in the staging store to be applied on the backup node, then you need to apply them before starting replication in any of the three cases listed above. See the DMSTRAPYStart Replication Apply Process (Start Apply Process in iCluster Administrator) command for more information. LOB Staging Store LOB data is stored in a directory in IFS which is separate from the regular staging store. See Replicating LOBs on page 92 for more information about the LOB staging store.

DataMirror, an IBM Company

Printed in Canada

69

Considerations Staging increases system resources because journal data will be placed into and extracted from the staging store. Also, the system storage requirements may need to be increased to hold the staged journal entries. There will be no effect on performance or resource requirements on primary nodes. The scrape latency will not be affected while the apply process is suspended as long as the staging store is large enough to hold all the journal information. Stalling may occur if the staging store is not large enough to hold the journal entries. For example, transferring large objects can cause current products to stall as communication buffers back up due to a slow apply process.

Locked Objects
Cluster operations will sometimes lock objects to ensure that only one process can affect the object at a time. This topic provides information about locked objects in iCluster. For more general information on locked objects, see the IBM documentation. Setting the Retry Limit You can specify the number of attempts the system makes to save a locked object by creating a data area on the primary node. The data area must have a decimal 10.0 format and its value will be the maximum number of times you want the system to try to save locked objects. For example, the following command sets the retry limit in the current product library to 30 attempts: CRTDTAARA DTAARA(HASAVRETRY) TYPE(*DEC) LEN(10 0) VALUE(30) iCluster waits for about one to two seconds between each attempt to save the locked object. Setting the retry limit to 30 allows iCluster to retry the operation 30 times, which will last approximately 60 seconds. Locked Object Contention If the apply processes on the backup node cannot apply a journal entry to a file, since it is exclusively locked either by another application or by the operating system, you can configure the apply processes on the backup node to wait a certain amount of time and retry the apply process a specified number of times. This is achieved by creating a data area object in the iCluster library on the backup node. The data area should be named HA_OBJLCK, be of type *CHAR, and it must be long enough to contain the wait/retry specification string. Specify the following parameters: WAIT <n1> RETRY <n2> where: WAIT and RETRY cannot be in mixed case (only all uppercase or all lowercase). <n1> can be any positive integer except zero (0). It represents the number of seconds to wait. <n2> can be any positive integer or *NOMAX. It represents the number of times to retry the apply process. The target apply job will retry the record update every <n1> seconds until the uniquely keyed access path has been rebuilt or <n2> attempts have been made. If the last attempt fails, the file will be suspended. If the HA_OBJLCK data area is not created, the default is to wait one second and retry five more times.

Avoiding Contention
If an application upgrade procedure is running at the same time that replication is active, changes to files during the upgrade may interfere with replication or vice-versa. Sometimes it is necessary to delay the refresh of a file by iCluster to allow the upgrade process to complete before proceeding with the refresh. You can create the HA_DELAY data area in the product library to modify the default behaviour of iCluster so that if a refresh of a file is required, iCluster will delay processing of the refresh by the amount of time you specify.

70

Printed in Canada

iClusterVersion 5.1

The HA_DELAY data area affects any refresh of a file. iCluster will refresh a file when it processes a journal entry that indicates the file was created, restored, activated, or moved/renamed so that it now matches the object specifiers of the group. You can set up the HA_DELAY data area in the following way: 1 Stop mirroring. 2 Create a character data area called HA_DELAY in product library. 3 Put delay info into this DTAARA in a following format:
<*ALL++++++><GROUP NAME1><DELAY1 IN SECONDS> *CHAR(10) *CHAR(10) <*ALL++++++><GROUP NAME2><DELAY2 IN SECONDS> <*ALL++++++><GROUP NAME3><DELAY3 IN SECONDS> *CHAR(5)

Group name may be specific or *ALL. Example 1


'MYTARGET1+MYGROUP7++100++MYTARGET2+*ALL++++++90+++'

Here + is a <Space> padding and for the group MYGROUP7 delay is set to 100 seconds, whereas for all groups selected to the backup node delay is 90 sec. Example 2
'*ALL++++++MYGROUP+++120++'

Commitment Control
Commitment control stages database transactions so that they are assembled before being applied, or additionally, opened in a commitment control environment to ensure that only complete transactions are applied. It also makes sure that the changes are applied in the correct sequence. Commitment control staging is performed on backup nodes. You can specify commitment control at the replication group and system levels. iCluster supports *LEVEL1, and *LEVEL2 commitment control, or no commitment control at all. *NONE If there is no commitment control, the update processes on the backup node will not perform commitment control staging, will not open the files under commitment control and will not apply updates under commitment control. *LEVEL1 Commitment Control iCluster assembles all updates that comprise a transaction before applying them on the backup node. *LEVEL1 does not require that the backup files are journaled, it will not open the files under commitment control and will not apply the updates under commitment control. If the backup node ends abnormally in the middle of applying a transaction, the transaction will become partially applied and iCluster will complete the transaction at next startup. This option may be useful to those who do not want to journal the backup node files for performance reasons but do want transaction consistency. *LEVEL2 Commitment Control iCluster makes sure that all updates in a transaction are opened in a commitment control environment to ensure that only complete transactions are applied. *LEVEL2 requires that backup files are journaled with both images. It will then open the files under commitment control and apply the updates under commitment control. If the backup or replicate node ends abnormally in the middle of applying a transaction, the system will automatically rollback the transaction, ensuring that the database is still consistent. This option provides true commitment control. Commitment Control Considerations A suspended file cannot be involved in transactions under commitment control. Updates to suspended files will not be applied as part of a committed transaction. For more information about suspended files, see Suspended Objects on page 72.

DataMirror, an IBM Company

Printed in Canada

71

Suspended Objects
During normal replication, all changes to replicated objects are applied on the backup node. However, there are circumstances where objects may become suspended, meaning that one or more changes could not be processed. Potentially, the primary and backup nodes could become unsynchronized. If a suspended object is a part of the transaction under Commitment Control, the transaction will not be applied on the backup system in its entirety. Suspending Objects An object can become suspended in several ways. The following list describes some possible causes:

If it cannot be refreshed or if an iCluster file or member level operation fails. If you set a cluster system value to indicate the maximum size of a file that can be refreshed through the network. Any file that is larger than this parameter will not be refreshed if required, and instead, will be marked as suspended. See DMSETSVAL Set Cluster System Values on page 181 (Setting System Values for the iCluster Administrator) for more information. If a manual refresh is specified when selecting an object specifier to a replication group. You may want to perform a manual refresh to control the size of objects being transferred through the network or to have some control over the number of "stalled" journal entries (an entry that has been delayed in being sent to the backup node). Note that you are responsible for a manual refresh from the primary node to the backup node. If you select a certain object to be suspended. The reason why an object was suspended by the user will be displayed through the Status Monitor. If it cannot be restored to the backup node because it is locked by an application.

In most cases, suspended objects can be automatically reactivated by iCluster. You can reactivate any object that is not automatically reactivated using the DMACTOBJActivate Object (Activate Object in the iCluster Administrator) command for native objects and DMACTBSFActivate BSF Object (Activate Object in the iCluster Administrator)command for IFS objects. See Activating Objects and Automatic Reactivation for more information. Activating Objects Mirroring of suspended objects begins when you activate the objects. You can activate one or more suspended objects through the DMACTOBJActivate Object (Activate Object in the iCluster Administrator) command for native objects, DMACTBSF Activate BSF Object (Activate Object in the iCluster Administrator) command for BSF objects, or from the Status Monitor. Objects can be refreshed as a part of the activation or mirror can begin on activation. You do not have the option to specify a particular time or journal entry at which to start mirroring for the file being activated. Note: If you do not refresh the objects when activating them, then you must ensure any logical files associated with a suspended physical file are created on the backup node before activating the physical file, which starts mirroring. The system will only mirror dependent files that exist on the target. You must also ensure that no changes are made to an object between the time of the save and the time the file is activated. Changes made since the time of the save will not be applied to the object on the backup node. Also, you will be responsible for replicating any suspended objects.

Note:

Automatic Reactivation Automatic reactivation allows iCluster to refresh automatically those objects that become unsynchronized on either the primary or backup system. If an error occurs while replicating an object, it will become unsynchronized and iCluster will suspend it. Once an object is suspended, subsequent updates to that object will not be applied until it is automatically reactivated or you manually activate it. See the DMACTOBJActivate Object (Activate Object in the iCluster Administrator) command for more information about activating objects manually.

72

Printed in Canada

iClusterVersion 5.1

Automatic reactivation attempts to resynchronize suspended objects without user intervention. This feature decreases the amount of user effort required to keep your primary and backup nodes synchronized, and decreases the time that your nodes could be unsynchronized if an object is suspended. It also reduces the time you need to monitor the replication status of their system and to activate suspended objects. iCluster automatically reactivates the following objects that are suspended on both the primary and backup nodes:

Non-journaled native objects Physical files (data) Logical files

IFS files are also automatically reactivated on the primary node. You have the option of indicating whether you want to enable automatic reactivation. Also, you can specify the number of reactivation attempts for an object and the size of an object that will be tried for reactivation. See the DMSETSVALSet Cluster System Values command for more information about the parameters that you can set for automatic reactivation. For the automatic reactivation of database files, refresh of objects, and the activation of objects (see the DMACTOBJActivate Object command), use the Maximum Refresh Size parameter in the DMSETSVALSet Cluster System Values (Setting System Values for the iCluster Administrator) command. For all other objects, use the Maximum Reactivation Size parameter in the DMSETSVALSet Cluster System Values command. Objects suspended with the following reason codes cannot be automatically reactivated. All of the other reason codes are eligible for automatic reactivation.

Native objects: EJF, JPF, MRR, NGP, RBC, SBU, SIZ, SPF IFS objects: EJF, INE, INS, LNK, SBU, SIZ

See Working with Object Status on page 306 for a complete list of reason codes and their meanings.

Choosing a Failover Mechanism


This topic offers criteria for choosing a failover mechanism and provides instructions for changing to a different system. iCluster uses its failover mechanism to detect connectivity problems and manage node status. The following failover mechanisms are available in iCluster: SwitchOver System SwitchOver System (SOS) integrates the existing failover mechanism from DataMirror HA Suite into iCluster. Its purpose is to simplify node and replication group management and support while removing some of the limitations of IBM Cluster Resource Services (IBM CRS). SOS provides a comparable set of functionality to IBM CRS, with the exception of support for resilient applications and switched disks. For new installations, SOS is the default failover mechanism. If you are upgrading from iCluster 2.0 or earlier, then your installation will continue to use IBM Cluster Resource Services. You can change your installation to use SOS after upgrading iCluster. See Configuring iCluster to use SwitchOver System (SOS) on page 74, below, for more information. IBM Cluster Resource Services IBM Cluster Resource Services (IBM CRS) is the native iSeries cluster management framework. These services provide a standard platform for managing resilient resources, including resilient applications. See Switchover for IBM Cluster Resource Services (CRS) on page 341 and your IBM documentation for more information on Cluster Resource Services.

DataMirror, an IBM Company

Printed in Canada

73

Key Differences in Failover Mechanisms


The following table lists key differences between the failover mechanisms. You can use it to determine which system meets the needs of your environment.
Table 1 Key Differences in Failover Mechanisms

Switchover System (SOS)

IBM Cluster Resource Services (IBM CRS

Supports consecutive and nonadjacent OS/400 versions in the same cluster. For example, you can have nodes running on OS/400 V5R1 and V5R3 in the same cluster. Allows control over automatic switching of nodes after detecting a failure (optional failover). Uses TCP/IP to test connectivity between nodes.

Only supports consecutive OS/400 versions in the same cluster. For example, you can have nodes running on OS/400 V5R2 and V5R3 in the same cluster, but not V5R1 and V5R3.

Performs automatic switching of nodes on failover (mandatory failover) in the cluster resource group.

Uses ICMP (ping) to test connectivity between nodes.

Handles communication failures through a single *FAILED state. This simplifies recovery from failures.

Uses *FAILED and *PARTITION states to handle communication failures.

Does not support resilient applications nor takeover IP addresses.

Supports resilient applications, including the ability to takeover IP addresses.

Does not support switchable disk storage devices on the primary and backup nodes.

Supports switchable disk storage devices.

Both SOS and IBM CRS support calling user exit programs before and after switchover operations.

DataMirror recommends that you use SOS unless your environment requires support for resilient applications or switchable disk storage devices. If it does, then you must use IBM CRS.

Configuring iCluster to use SwitchOver System (SOS)


New iCluster installations use SOS by default. To change an existing cluster to use SOS, you must perform the following tasks: 1 On the Work with Cluster Nodes (DMWRKNODEWork with Nodes on page 110) screen, ensure all nodes have a status of *ACTIVE.

74

Printed in Canada

iClusterVersion 5.1

2 On the Work with iCluster Groups (DMWRKGRPWork with Groups on page 137) screen, ensure all groups have a replication status of *INACTIVE. 3 On the iCluster System Values (DMSETSVALSet Cluster System Values on page 181) screen, change the Use OS/400 Cluster Services parameter to *NO and press Enter to save the change. 4 Change the default switchover settings for each node using the DMCHGNODEChange Node command to ensure they meet your recovery needs. 5 On the Work with Cluster Nodes (DMWRKNODEWork with Nodes on page 110) screen, restart all of the nodes in the cluster. 6 On the Work with iCluster Groups (DMWRKGRPWork with Groups on page 137) screen, restart all of the groups. Your replication environment will now run with its previous configuration and SOS. Note: After performing these tasks, you will no longer be able to use DMSETPRIMPrepare Primary Node to perform a switchover. Instead, use the DMCHGROLEChange Group Primary Node command.

Configuring iCluster to use IBM Cluster Resource Services (CRS)


After installing iCluster for the first time on a computer, run DMSETSVALSet Cluster System Values and set the CLUSTER parameter to *YES. Alternatively, perform the following tasks to change an existing cluster to use IBM CRS. Note that you must recreate the cluster as a part of this process. 1 Record the configuration of your current clustering environment including nodes, groups, and object specifiers. You will need this information when you recreate the cluster. 2 Delete the current cluster by running DMDLTCLSTRDelete Cluster on every node in the cluster. 3 On the iCluster System Values (DMSETSVALSet Cluster System Values on page 181) screen, change the Use OS/400 Cluster Services parameter to *YES and press Enter to save the change. 4 Delete residual cluster information by running DMDLTCLSTRDelete Cluster on every node in the cluster, again. 5 Repeat Step 2 and Step 3 on every node in the cluster. 6 Add each node back to the cluster using the DMADDNODEAdd Node command. The first node you add will become the master node. Note: If you have nodes with different operating system versions, then you must add the node with the lowest version first. For example, if your clusters will have nodes running on OS/400 V5R2 and V5R3, then the first node you add must be running V5R2.

7 Create the groups that will replicate objects using the DMADDGRPAdd Group command. Use the information you recorded in Step 1 to help with this step. 8 Specify the objects you want to be in each group using the DMSELOBJSelect Objects to Group and DMADDBSFAdd Path Object Specifier to Group commands. Use the information you recorded in Step 1 to help with this step. 9 On the Work with iCluster Groups (DMWRKGRPWork with Groups on page 137) screen, restart all of the groups. Your replication environment will now run using IBM CRS.

Starting Replication and Journal Positions


This topic outlines some of the differences between DMSETPOSSet Journal Start Position and DMMRKPOSMark Current Journal Positions, and how to start replication after setting or marking journal positions with these commands. How are DMSETPOS and DMMRKPOS Different? It is important to understand the differences between the DMSETPOSSet Journal Start Position and DMMRKPOSMark Current Journal Positions commands:

DataMirror, an IBM Company

Printed in Canada

75

The DMSETPOSSet Journal Start Position command requires you to specify a journal position for all journals in the specified group. The specific journal entry can be entered directly or determined by the command if a date and time is entered. DMSETPOS also allows you to use the last applied journal position. DMSETPOS is typically used for recovery purposes when you would like to resume mirroring from a journal position back in time.

In contrast, the DMMRKPOSMark Current Journal Positions command does not require you to specify a journal position for all journals in the specified group. DMMRKPOSMark Current Journal Positions automatically determines the journal position by using the current sequence number(s) in all relevant journals for the group. DMMRKPOSMark Current Journal Positions is typically used for initial synchronization. For example, after a full tape save/restore to the backup when mirroring is started from the current point in time.

Both of these commands help to prevent unsynchronized start-ups when starting replication for a group.

To start replication after setting journal positions


If you want to start replication with DMSTRGRP or DMSTRREPL after having set or marked journal positions with DMSETPOS or DMMRKPOS, note the following:

If you issue the DMMRKPOS command for a group and then start replication, you must specify *YES for the USEMARKED parameter in DMSTRGRP and DMSTRREPL. This starts replication at the journal positions you marked with the DMMRKPOS command. If you issue the DMSETPOS command for a group and then start replication, you must specify *NO for the USEMARKED parameter in DMSTRGRP and DMSTRREPL. This starts replication at the journal positions you set with the DMSETPOS command.

See DMSTRGRPStart Cluster Operations at Group and DMSTRREPLStart Replication for more detailed information on these commands.

Monitoring Replication
This topic describes the tools in iCluster you can use to monitor replication. Monitoring the replication status of your objects is very important and should be performed regularly. Using the Status Monitor You can use the iCluster Status Monitor to monitor the current status of replication. The Status Monitor allows you to determine if replication is active, if any latency exists for the journal scrape or backup apply processes, and the through put and runtime totals for replication processes. The Status Monitor also allows you to view and activate suspended objects. See Working with the Status Monitor on page 291 for more information. Using Sync Check A sync check will allow you to check whether the objects within a replication group, are equivalent on the primary and backup nodes. All objects for the specified backup node/replication group combination are checked. You can perform a sync check through the Status Monitor and the STRHASCStart Sync Check and STRHASCUSRStart User Sync Check commands. You should perform regular sync checks and review the sync check reports to ensure that the replicated objects on the primary and backup systems are equivalent. Using Event Logs In iCluster, an event log is used to maintain messages generated during replication, communication, and cluster activities. The event log is maintained on each node and contains messages about events involving that node.

76

Printed in Canada

iClusterVersion 5.1

To view all events in iCluster, display the event log on the backup node. All communication and replication events are sent to the backup node. iCluster provides the DMDSPLOGDisplay Cluster Event Log command that displays the messages that have been placed in the event log. You can use the DMCLRLOGClear Cluster Event Log command to remove specific categories of messages from the event log.

Monitoring Out-of-Sync Objects


During normal replication, all changes to replicated objects are applied on the backup node. Sync check lets you check whether the primary and backup nodes have become unsynchronized. You can perform a sync check through the Status Monitor and by issuing STRHASCStart Sync Check on page 267 and STRHASCUSRStart User Sync Check on page 270. STRHASC checks all objects for the specified replication group, while STRHASCUSR allows you to perform a sync check on specific objects that are replicated in the replication group. The following are just some of the sync check options provided by these commands:

Type of output for the sync check. You can output the sync check to a spool file or database file. Type of sync check. Object specifiers and path object specifiers that allow you to filter the objects you want to sync check. Date and time when the sync check will start.

See To view Sync Check results on page 78 for more information. The Out-of-Sync (OOS) Count Column in the Status Monitor also lets you determine if objects on the backup node are the same as the objects on the primary node within a replication group. See Out-of-Sync (OOS) Count Column for more information.

To start a Sync Check


To use sync check, perform the following tasks: 1 Use the SELSCATTRSelect Sync Check Attributes command to select the file attributes that you want to include in your sync check. Note: You can also choose to use the default attributes supplied by this command. 2 Start the sync check program with the STRHASC or STRHASCUSR command. See the STRHASCStart Sync Check and STRHASCUSRStart User Sync Check commands for more detailed information on the parameters in these commands. You can also issue these commands from the Status Monitor. See Common Options for all Views on page 295 for more information. 3 Use one of the following commands on the backup node to view the sync check:

DSPHASC DMSCRPT DMSCRPTNTV

See To view Sync Check results on page 78 for more information on viewing sync checks. Out-of-Sync (OOS) Count Column The OOS Count Column (Figure 5) displays the sum of the OS/400 native objects and IFS objects that are out-of-sync for each group. This information is current as of the last sync check. Note: The OOS field is only available on backup monitor screens in a 132-column terminal session. See Reading Status Information on page 303 for more information on the OOS column in the Status Monitor.

DataMirror, an IBM Company

Printed in Canada

77

To view Sync Check results


The command that you use to view the sync check is determined by the OUTPUT parameter in STRHASCStart Sync Check on page 267 and STRHASCUSRStart User Sync Check on page 270. This parameter determines whether output is sent to a spooled file or a database file. Use the following to determine which command you should use:

If you ran the STRHASC or STRHASCUSR commands with the OUTPUT (*MISMATCH) or OUTPUT (*ALL) options, iCluster places the results of the sync check in a spool file on the primary node. Use the DSPHASCDisplay Sync Check command to view the spool file. If you ran the STRHASC or STRHASCUSR commands with the OUTPUT (*NONE) option, the output of the sync check is sent to a database file. Use the DMSCRPTSync Check Report for IFS Objects command (*BSF sync check type) or DMSCRPTNTVSync Check Report for Native Objects command ( *FILEATTR, *DTAARA, and *LIST sync check types) to view the sync check report in the database file.

Note:

If your sync check displays out-of-sync objects that are suspended, you can use DMACTOBJActivate Object and DMACTBSFActivate BSF Object to activate and refresh the object(s) to the backup node. See Suspended Objects on page 72 for general information about suspended objects. Use the PRGHASCPurge Sync Check Results on page 276 command to clear the sync check database files of obsolete records.

Note:

Monitoring Latency
This topic describes the tools that are available in iCluster that let you monitor latency. Latency is the time interval between a journal entry being written on the primary node and it being applied on the backup node. iCluster provides statistics about real time latency so that you can examine the speed of replication from the primary node to the backup node and take any necessary action. You can adjust the LATENCY system values to the level of latency that you are willing to tolerate in your cluster. LATENCY System Values The LATENCY system values affect the latency threshold settings within iCluster. You can use these system values to determine the threshold or upper limit of latency that iCluster will tolerate before issuing a warning message. You can set the LATENCY system values with the DMSETSVALSet Cluster System Values command:

The Source Receive Threshold system value indicates the amount of source receive latency that can be tolerated before the latency warning message, OMI0308, is issued. Source receive latency indicates the difference between the timestamp of the journal entry last processed by the backup receiver for the journal, and the timestamp of the last journal entry deposited in the journal on the primary (source) node. The Target Apply Threshold system value indicates the amount of backup apply latency that can be tolerated before the latency warning message, OMI0308, is issued. The backup apply latency is the difference in the timestamps of the last entry received by the journal's receive process and the last entry applied by the journal's apply process. The Latency Check Interval system value lets you specify how often iCluster checks for latencies (source receive and target apply) and compares them with their corresponding thresholds.

See the DMDSPLOGDisplay Cluster Event Log command for more information on how to display the OMI0308 latency message in the event log.

78

Printed in Canada

iClusterVersion 5.1

Monitoring Latency with the Real Time Overall Latency Screen After setting the latency threshold system values (above), you can monitor latency in your cluster with the Real Time Overall Latency view in the Status Monitor. Figure 1 Real Time Overall Latency View in the Status Monitor

Source latency, apply latency, and total latency are displayed in real time in HH:MM:SS format for all primary/backup/group/journal combinations. Visual indicators let you know when you have exceeded latency thresholds or total latency for your cluster. Figure 1 displays three latency scenarios that you can monitor in iCluster:

The first group, denoted by [1], contains very little or no latency. None of the latency thresholds set in the DMSETSVALSet Cluster System Values command have been exceeded since only one '.' character appears under Total Latency Status. If latency thresholds have not been exceeded, the bar graph displays the '.' character. If either or both latency thresholds have been exceeded, the bar graph displays asterisks '*'.

Note:

The second group, denoted by [2], contains more latency than [1] since the bar graph under Total Latency Status now has three '.' characters. Latency thresholds have not been exceeded. The third group, denoted by [3], has exceeded one of the latency threshold values set in the DMSETSVALSet Cluster System Values command. Brackets '< >' are displayed around the Source Latency value that has exceeded the threshold. The bar graph under Total Latency Status now displays asterisks '*' since one of the latency thresholds has been exceeded.

See Monitoring Real Time Overall Latency on page 297 for more information about using the Real Time Overall Latency screen in the Status Monitor.

Restarting iCluster after Restarting a Node


Note: See your IBM documentation for more information on managing clusters, including the steps in this topic. After restarting a node in a cluster, you must perform the following tasks on the node you want to add: 1 Initialize TCP/IP processing by running the STRTCP command. 2 Start the TCP/IP server by running the STRTCPSVR command. You must minimally start the *INETD server. For example:

DataMirror, an IBM Company

Printed in Canada

79

> STRTCPSVR SERVER(*INETD) 3 Start the XDMCLUSTER subsystem by running the STRSBS command. For example: > STRSBS SBSD(XDMCLUSTER) 4 Start the TCP/IP listener job on the local node by running the STRHATCPStart TCP/IP Listener command. 5 Rejoin the node by running the DMREJOINiCluster Rejoin Cluster command. If you want to automatically restart iCluster for a node, then you must include the commands in the autostart job files for each node in the cluster.

Upgrading the Cluster Version


This topic describes the tasks you must perform when upgrading the operating system on one or more nodes in a cluster. This information only applies to iCluster installations that use IBM Cluster Resource Services as their failover mechanism. The concept of cluster versions does not apply to installations using SwitchOver System. Note: See your IBM documentation for more information on managing clusters, including the steps in this topic. Every node in a cluster has a potential node version, which is determined by the operating system version installed on the node. A cluster's version has a limit of the minimum potential node version of the nodes in the cluster. For example, consider the following cluster:
Table 2 iCluster Version

Node ALPHA BRAVO CHARLIE

OS/400 Version V5R2 V5R2 V5R3

Potential Node Version 2 2 3

The highest possible version of this cluster is 2, because 2 is the lowest common potential node version that it can support. It is technically possible for this cluster to be at version 1. Note: DataMirror recommends upgrading your cluster to its highest possible version. This reduces the likelihood of versioning problems after future node upgrades.

To see the current version of a cluster and its nodes, run the DSPCLUINF command. To upgrade the version of a cluster, perform the following tasks: 1 Upgrade the operating system for nodes in the cluster. The potential node version for each node must be greater than or equal to the version you want the cluster to have. 2 Change the cluster version by running the CHGCLUVER command.

Changing IP Addresses
This topic describes the tasks you must perform to change the IP address of a node in a cluster. The steps you must follow depend on if your iCluster installation uses SwitchOver System or IBM Cluster Resource Services as its failover mechanism. You must perform the complete set of steps for every IP address that you are changing. Do not try to change more than one node's IP addresses at a time.

80

Printed in Canada

iClusterVersion 5.1

SwitchOver System Procedure To change the IP address of a node when the cluster is using the SwitchOver System failover mechanism, perform the following steps: 1 Stop all groups that use the node by running the DMENDGRPEnd Cluster Operations for Group command. 2 Change the node's IP address using the DMCHGGRPChange Group command. The node you are changing must be active when you run this command. 3 End the node by running the DMENDNODEEnd Cluster Operations at Node command. 4 Refresh the XDMCLUSTER subsystem by ending and then starting it using the following commands: > ENDSBS SBS(XDMCLUSTER) OPTION(*IMMED) > STRSBS SBSD(XDMCLUSTER) You must end the subsystem with the *IMMED option. 5 Start the node using the DMSTRNODEStart Cluster Operations at Node command. 6 Start all groups that use the node using the DMSTRGRPStart Cluster Operations at Group command. The cluster will now use the new IP address to connect to the node. IBM Cluster Resource Services Procedure To change the IP address of a node when the cluster is using IBM Cluster Resource Services, perform the following steps: 1 Ensure at least one other node in the cluster is active. The active node cannot be the node whose IP address you are changing. 2 End all groups that use the node whose IP address you are changing by running the DMENDGRPEnd Cluster Operations for Group command. 3 End the node by running the DMENDNODEEnd Cluster Operations at Node command. 4 Change the node's IP address by configuring your network. See your operating system documentation for more information on this step. 5 Change the node's IP address in iCluster using the DMCHGNODEChange Node command on an active node. 6 Start the node whose IP address you changed by running the DMSTRNODEStart Cluster Operations at Node command. 7 Start all groups that use the node using the DMSTRGRPStart Cluster Operations at Group command. The cluster will now use the new IP address to connect to the node.

Journaling in iCluster
This topic explores some of the differences between traditional local journaling and remote journaling in iCluster.

DataMirror, an IBM Company

Printed in Canada

81

Local Journaling With local journaling, applications on the primary system generate database changes, and these changes generate journal entries that are written to a local journal receiver. iCluster then transmits these changes asynchronously to the backup system where the same changes are made. Local journaling is used by default. Figure 2 gives you a more detailed view of the local journaling process in iCluster. Figure 2 Local Journaling in iCluster

Consider the following when using local journaling:

With local journaling, iCluster lets you be more selective in what you journal. For example, you can choose to avoid journaling BSF's with non-journaled BSF support. See Path Object Specifiers on page 52 for more information. Asynchronous data updates result in very little impact to applications on the primary system. Local journaling is only available in asynchronous mode. This can result in a small amount of data latency since control returns to the applications as the journal entries are prepared for transmission to the backup system.

Remote Journaling With remote journaling, journal entries are transmitted directly from the primary system to journals and their associated receivers on the backup system. This can improve system performance on the primary system because the remote node is used to do more of the replication processing.

82

Printed in Canada

iClusterVersion 5.1

Note: Figure 3

The default data update method for remote journaling is asynchronous mode. See Configuring Remote Journaling on page 84 for more information on how to set the delivery modes for remote journaling. Remote Journaling in iCluster

Figure 3 gives you a more detailed view of the remote journaling process in iCluster. Consider the following when using remote journaling:

Remote journaling does not let you be selective about what journal entries are transmitted to the backup system. All entries in the primary system journal are sent to the remote journal. Synchronous update of data can have an impact on applications and journaling throughput on your primary system. In synchronous mode, there is no data latency with remote journaling since journal entries are applied to the backup system before updating the primary system. In asynchronous mode there is a small amount of data latency since control returns to the applications as the journal entries are prepared for transmission to the backup system. Remote journaling is configured at the journal level. See Configuring Remote Journaling on page 84 for more information.

Remote Journaling
Remote journaling is an OS/400 feature that replicates journal entries for an object on the primary node (local journal) to be placed on a journal on the backup node (remote journal). In this case, the local and remote journals are identical. This occurs independently from any iCluster operations and provides an alternative method for transporting data from the primary node to a backup node. iCluster can apply transactions from a remote journal on the backup node to the replicated objects on the backup node. Using a remote journal in a replication group can improve system performance on the primary node because remote journaling uses the backup node to do more of the replication processing. In addition, you can configure your local journal to update the remote journal either synchronously or asynchronously. Traditional iCluster journaling using only a local journal only supports asynchronous updates.

DataMirror, an IBM Company

Printed in Canada

83

See Journaling in iCluster on page 81 for a comparison of local journaling and remote journaling. See your IBM documentation for more information on remote journaling concepts, including synchronous and asynchronous journal updates

Configuring Remote Journaling


This topic describes the tasks that you must perform to configure a group or resilient application to apply journal entries from a remote journal. The examples show the required parameters you must set to perform each step. See the documentation for each command for a complete list of parameters. To configure remote journaling, perform the following tasks: 1 On the backup node, add a relational database directory entry by running the ADDRDBDIRE command. The IBM documentation describes this procedure. iCluster requires that you give this database entry the same name as the node. For example, the following command creates the relational database directory entry on a node named NEWYORK: > ADDRDBDIRE RDB(NEWYORK) RMTLOCNAME(*LOCAL) 2 On the primary node, add a relational database entry for the database on the backup node by running the ADDRDBDIRE command. For example, > ADDRDBDIRE RDB(NEWYORK) RMTLOCNAME(192.168.0.240) 3 On the primary node, create a journal receiver by running the CRTJRNRCV command. For example, the following command creates a receiver with a threshold of 5000 KB: > CRTJRNRCV JRNRCV(TORLIB/MYJRNRCV) THRESHOLD(5000) 4 On the primary node, create a journal that uses the journal receiver by running the CRTJRN command. You must configure the journal to have the system manage journal receiver changing. For example, the following command creates a journal: > CRTJRN JRN(TORLIB/MYJRN) JRNRCV(TORLIB/MYJRNRCV) MNGRCV(*SYSTEM) 5 On the primary node, add a remote journal by running the ADDRMTJRN command. iCluster requires that you do the following for this command:

Set the relational database to the database directory entry you created in Step 1. Set the names of the source journal and target journal to the journal you created in Step 4. The target journal name must be the same value as the source journal. Set the source journal library to the library of the journal you created in Step 4. Set the target journal library to a library that is different from the source journal library. The source and target libraries must be different. Create both the source journal library and the target journal library on the backup node. Set the remote journal type to *TYPE1. iCluster does not support any other remote journal types. For example, the following command creates the remote journal NYLIB/MYJRN on the backup node: > ADDRMTJRN RDB(NEWYORK) SRCJRN(TORLIB/MYJRN) TGTJRN(NYLIB/MYJRN) RMTJRNTYPE(*TYPE1)

6 On the primary node, activate the remote journal by running the CHGRMTJRN command with the JRNSTATE(*ACTIVE) parameter. For example, the following command activates the remote journal: > CHGRMTJRN RDB(NEWYORK) SRCJRN(TORLIB/MYJRN) TGTJRN(NYLIB/MYJRN) JRNSTATE(*ACTIVE) If you want to configure your journal to perform synchronous updates, then use the DELIVERY(*SYNC) parameter with this command.

84

Printed in Canada

iClusterVersion 5.1

Note:

When a remote journal group starts, iCluster automatically activates the remote journal (if it is not activated) using the default value for the DELIVERY parameter in the CHGRMTJRN command.

See the IBM CHGRMTJRN documentation for more information about this command and setting. 7 On any node, add your group or application by running the DMADDGRPAdd Group or DMADDAPPAdd Resilient Application command, respectively. Alternatively, you can use the DMCHGGRPChange Group or DMCHGAPPChange Resilient Application commands to modify existing groups or applications. When running this command, you must do the following to use the remote journal:

Set the default databse journal to use the journal you created in Step 4. Set the journal location to *REMOTE.

For example, the following command creates a group that replicates from TORONTO to NEWYORK using the MYJRN journal. > DMADDGRP GROUP(MYGRP) GRPTYPE(*REPL) PRIMNODE(TORONTO) BACKUPS(NEWYORK) DFTDBJRN(TORLIB/MYJRN) JRNLOC(*REMOTE) 8 Perform the normal configuration and administration tasks for your replication group. This includes selecting objects to be replicated, setting or marking journal positions, and starting the applications and groups. These tasks are the same for both local and remote journaling. Your group or application will now use the remote journal.

Role Switching with Remote Journals


If you intend to perform failover or switchover operations on a group using remote journaling, then you must perform additional configuration tasks. For example, consider a group that replicates data from a node named TORONTO to a node named NEWYORK. In this group, TORONTO is the primary node and NEWYORK is the backup node. Since the group uses remote journaling, TORONTO has a remote journal on NEWYORK. Since a switchover or failover reverses the roles of the nodes in a group, NEWYORK must be able to become the primary node in the group. This requires that NEWYORK also has a remote journal on TORONTO. During the switchover or failover, the nodes must perform the following tasks: 1 TORONTO must deactivate its remote journal on NEWYORK. 2 NEWYORK must activate its remote journal on TORONTO. You can create a user exit that performs these tasks. See the RMTJRNSWO file member in <lib>/QACLSRC, where <lib> is the iCluster product library, for a sample user exit. Switchovers and Failovers with Synchronous Remote Journaling Remote journals that use the synchronous delivery mode can have suspended journaled objects after a failover or switchover, if they are in a replication group that only includes after images. To prevent this suspension, you must configure your group to include both before and after images. To do this, perform one of the following tasks:

To change this property for one group, set the JRNBA property to *BOTH by running the DMCHGGRPChange Group command. All new objects that are added to this group will use this setting, but any existing objects in the group must be manually changed to include both before and after images. Perform the following tasks to change this setting for individual objects:

If you are using OS/400 V5R3, then run the CHGJRNOBJ command with the IMAGES(*BOTH) parameter. If you are using OS/400 V5R2 or earlier release, then you must stop journaling on the object by running the ENDJRN command and then restart journaling with before and after images by running the STRJRN command with the IMAGES(*BOTH) parameter. To ensure data integrity, we recommend that you do this when no users are accessing the node.

DataMirror, an IBM Company

Printed in Canada

85

To change this property globally for all groups, set the journal images attribute of the PF property to *BOTH by running the DMSETSVALSet Cluster System Values command. All new groups will use this setting by default, but any groups that were explicitly configured to include only after images will need to have their JRNBA property set to either *BOTH or *CLUSTER by running the DMCHGGRPChange Group command.

Passing Arguments to Sync Point User Exit Programs


If you define a user exit program that will be called at a sync point set with the DMSETSYNCSet Sync Point command, the following arguments will be passed to the program: User Exit Point Type: Character Length: 1 The point where the user exit program was called. One of the following values will be passed through this argument to indicate the exit point:

S: At journal entry scrape on the primary node R: At journal entry receive on the backup node A: At journal entry apply on the backup node

If you want to stop mirroring after completion of the user exit program, return the value '9' through this argument. Backup Node Name Type: Character Length: 10 The name of the backup node in the replication group. Replication Group Name Type: Character Length: 10 The replication group that had its jobs synchronized at the checkpoint journal entry. User Data Type: Character Length: 400 The user-defined data that is specified through the DMSETSYNCSet Sync Point command.

86

Printed in Canada

iClusterVersion 5.1

iCluster Replication
This section contains the following topics:

Replicating Database *FILE Objects on page 87 Replicating BSF Objects on page 89 Replicating Configuration Objects on page 90 Replicating User Profiles on page 91 Replicating LOBs on page 92 Replicating Triggers on page 92 Replicating Save Files on page 92 Replicating QDLS Objects on page 94 Replicating WebSphere MQ Objects on page 95

Replicating Database *FILE Objects


This section describes important considerations that should be noted when replicating physical files. Object Specifiers for Database Files When defining object specifiers for *FILE objects, an attribute of *ALL matches all types of files, including database files and device files. To include only database files, you need to create two object specifiers, one with an attribute of PFDTA (to include physical files) and the other with an attribute of LF (to include logical files). Note that the attribute PF (physical files) includes both source physical files and database files. When creating an object specifier for a physical file, specifying an object attribute of PFDTA allows access to certain iCluster parameters, such as the update method (by relative record number or by unique key), that cannot be accessed if PF or PFSRC (source physical file) is specified. Refreshing Physical Files iCluster uses a refresh while active method of refresh of physical files to the backup node. In other words, *FILE objects can be refreshed while they are still being updated. This is the only refresh option available for physical files in iCluster. While iCluster is refreshing a database file, changes to the content of the file may continue. Changes at the member level and file level (a rename of move operations, for example) may be delayed or they may fail while iCluster is refreshing the file. The length of time required to refresh a file depends upon the number of members in the file, the amount of data in the file, and the communications bandwidth available to the iCluster job performing the refresh. Refreshing Logical Files The refresh of logical files does not include saving and restoring the access paths associated with the logical files. The access paths are rebuilt on the secondary system when the logical file is restored. Dependent logical files are automatically refreshed when the based on physical file is refreshed. In this case, the logical files on the secondary system are deleted prior the restore of the based on physical file, and restored after the data is refreshed to the physical file. Note that there may be a relatively long period of time between deleting the logical file and restoring the new version of the logical file. During this period, the logical file will appear in the monitor as in a pending state. If a logical file has a unique key, updates to the based on physical file will be delayed until the access path is completely built after the logical file is restored. Updates to all files are applied in time order relative to the primary system, so the rebuild of a uniquely keyed access path may delay the updates to other files associated with the same journal.

DataMirror, an IBM Company

Printed in Canada

87

Unique Key Update Method The use of a unique key update method allows you to reorganize physical files without affecting the backup files. If a physical file is a multi-member file, the members of the unique index used for its replication must have the same names as the members in the physical file. You can change the backup node update method for a physical file from *UKEY to *RRN only while the replication group it belongs to is inactive. The file also must be resynchronized on source and target (by refresh or save/restore operation) before mirroring is restarted to ensure the relative record numbers on the source correspond to those on the target. Note that you can change the backup node update method of an object specifier only when the object specifier has been selected to a replication group. Member Support If a file is selected for replication, all members of the file will be replicated. You cannot exclude individual members of a file from an object specifier. Journaled Objects In this manual, the term "journaled objects" refers to database files, data areas, and data queues. BSF files can also be journaled, but they are handled differently than other journaled objects. See Replicating BSF Objects on page 89 for more information about journaled BSF objects. Referential Integrity (RI) Constraints When replicating RI constraints in iCluster, you should note the following:

Create and delete operations are replicated. RI constraints are disabled on the backup node. When performing a switchover, RI constraints are enabled on the new primary node. When starting replication after a switchover, RI constraints are disabled on the new backup node.

Check Constraints iCluster replicates all operations for check constraints. If you add, remove, enable, or disable constraints on the primary system, iCluster will replicate these changes to the backup system. Other Considerations

iCluster creates a journal on the backup node for physical files if one has not been created already. The backup node journal will have the same name and reside in the library with the same name as the corresponding primary node journal. iCluster creates a work library on the backup node for each apply job. These libraries are used to temporarily hold some replicated objects prior to restoring them. These libraries follow a naming convention of HAxxxxxxxx, where xxxxxxxx are digits. The text associated with these libraries includes the logical backup node, group name, journal name, journal library, and the journal entry. These libraries should not be deleted and are considered part of the staging store. Work libraries are also created on the primary node for each journal scrape job which follow the same naming convention, however, these libraries are temporary. iCluster will delete these libraries when they are no longer needed. iCluster only replicates authority holders for *FILE objects only. The CHGPF command is not supported when a source file is specified. The following attributes are mirrored for the CHGPF and CHGLF commands: MAXMBRS, MAINT, RECOVER, FRCRATIO, and TEXT. When mirroring files that have user defined SQL data types (SQL DISTINCT TYPEs), you must ensure that the *SQLUDT object is also in mirroring scope. The file will become suspended unless the corresponding *SQLUDT object exists on the backup system.

88

Printed in Canada

iClusterVersion 5.1

Replicating BSF Objects


Byte Stream File (BSF) objects reside in the Integrated File System (IFS) and can be replicated by iCluster through the use of path object specifiers. See Path Object Specifiers on page 53 for more information. Note the following important issues and considerations concerning BSF objects. Mirroring BSF Objects iCluster supports two types of replication for BSF objects: object-level mirroring, and content-level mirroring. The type of mirroring used for BSF objects matching a particular object specifier is determined by the JOURNAL parameter of the object specifier. See DMADDBSFAdd Path Object Specifier to Group (Add Full Replication Group for iCluster Administrator) or DMCHGBSF Change Path Object Specifier to Group (Change Full Replication Group for iCluster Administrator) for more information. The following points are worth considering when deciding on the type of replication that is most appropriate for your needs:

iCluster supports content-level and object-level mirroring in the "root" ("/") and QopenSys file systems. Content-level mirroring and object-level mirroring is also supported in the QDLS (DLO objects) file system. Content-level mirroring includes object-level mirroring support and also mirrors changes to the contents of BSF objects. Content-level mirroring requires that the BSF objects are journaled and is, therefore, more resource intensive than object-level mirroring. BSF polling allows content-level mirroring of objects in the QDLS file system. No journaling is required. See DMADDBSF Add Path Object Specifier to Group (Add Full Replication Group for iCluster Administrator) for more information. Object-level mirroring will replicate changes to the object at the object-level only including: creates, deletes, moves, renames, restores, authority changes, ownership changes, and primary group changes. In object-level mirroring, changes to the contents of the object are not mirrored. Object-level mirroring is suitable for applications that create BSF objects but do not change the contents of those objects, or change the contents by creating a completely new version of the object. The overlap of journaled (*GROUP) and non-journaled (*NONE) path object specifiers is restricted in iCluster. For example, using both '/home/user/*' (non-journaled) and '/home/user/employees/*' (journaled) is not permitted. See Path Object Specifiers on page 53 for more information. The number of objects (BSF and/or native) that may be journaled to a particular journal is limited. See the IBM documentation for more information. Consider using object-level mirroring if you have a large number (100,000 or more) of BSF objects to be replicated.

Initial Synchronization of Path Objects Initial synchronization of path objects between the primary and backup nodes involves the same considerations required for the initial synchronization of database files. Mirroring path objects involves sending to the backup node only the portion of the object that was changed, therefore the changed object must exist on the backup node prior to applying the change. If you are starting mirroring for existing path objects, you can use one of two methods to synchronize the primary and backup nodes:

Refresh the objects through iCluster. The easiest way to synchronize the primary and backup nodes is to initially refresh all objects before mirroring is started. Thereafter, when replication is started, only the mirroring of changes is required. The disadvantage of this approach is that the amount of data to refresh across the communications line may be large. Manually synchronize all objects. The second method to synchronize the primary and backup nodes is to manually save the objects on the primary node and restore them on the backup node. The starting journal position is established using DMMRKPOSMark Current Journal Positions (Mark Journal Positions for iCluster Administrator) after saving the primary node objects and before changes are made to these objects. BSF objects that are created on the primary node after the initial synchronization will be automatically refreshed to the backup node by iCluster if they are referenced by path object specifiers selected to groups.

DataMirror, an IBM Company

Printed in Canada

89

Journaling Path Objects iCluster will start journaling an object referenced by a path object specifier to the default BSF journal if the object is refreshed and it is not already journaled. iCluster will also start journaling an object referenced by a path object specifier to the default BSF journal when you invoke DMMRKPOSMark Current Journal Positions (Mark Journal Positions for iCluster Administrator). After journaling has been started, most changes to that object can be mirrored without accessing the object on the primary node. Note: Journaling changes to path objects requires resources on the primary node both to record (CPU) and store (disk) the changes. Journaling changes to path object specifiers will have an impact on the performance of applications that use those path object specifiers just as journaling database files has a performance impact on applications that use those database files.

For more information about journaling BSF objects, see DSPHABRCDDisplay Recording for BSF Object and ENDHABRCD End Recording for BSF Object. Refresh (Before Mirroring) of BSF Objects The following points should be considered when doing a refresh (before mirror) of BSF objects:

Prior to the refresh, iCluster will attempt to delete all objects on the secondary system that match the object specifiers. Refresh before mirroring will create base directories if they do not exist. For an object specifier of '/home/objects/journaled/*', iCluster will create the following base directories: '/home', '/home/objects', and '/home/objects/journaled'.

Status Monitor Support for BSF Objects Suspended BSF objects will be shown in the Status Monitor and may be activated from the object status screen or activated automatically by iCluster. For more information, see Working with the Status Monitor (Using the Object Status Monitor for iCluster Administrator). iCluster Limitations for BSF Objects iCluster currently does not provide support in the following areas:

Hard links are not supported. BSF include/exclude specifiers cannot have symbolic links to directories as part of their paths. This is only permitted when the symbolic link is at the end of a non-generic specifier that points directly to the symbolic link. iCluster does not support using symbolic links to directories to make BSF specifiers shorter. Replication must be to the same directory on the backup node. iCluster does not support directory redirection of BSF objects. DataMirror recommends that you replicate all BSF objects within a group to the same journal if they are journaled. When using separate journals there is no guarantee that replication of files will occur in the same order in which they were created/renamed on the primary node. The maximum length of path names is 5000 bytes long (OS/400 supports 16 megabyte path names). Two cluster system values, Lock File on Backup Node and Maximum Refresh Size, are not supported for path object specifiers. See DMSETSVALSet Cluster System Values (Setting System Values for iCluster Administrator) for more information about these system values. DLO extended object attributes are not replicated by iCluster. iCluster does not currently support suspension of non-journaled library objects on the backup system. The event log must be monitored to track replication errors with BSF objects on the backup system. Journaled BSF objects are suspended on the primary and backup nodes, while non-journaled BSF objects are suspended on the primary node only.

Replicating Configuration Objects


Configuration objects collectively refer to the following object types:

90

Connection lists (*CNNL)

Printed in Canada

iClusterVersion 5.1

Class-of-service descriptions (*COSD) Controller descriptions (*CTLD) Device descriptions (*DEVD) Internet package exchange descriptions (*IPXD) Line descriptions (*LIND) Mode descriptions (*MODD) NetBIOS descriptions (*NTBD) Network interface descriptions (*NWID) Network server descriptions (*NWSD)

Creating Configuration Objects When configuration objects are replicated to a node, you can request iCluster to automatically create these objects immediately after they are received or create them at a later time. If a configuration object already exists on a node, the DMSETSVALSet Cluster System Values (Setting System Values for iCluster Administrator) and DMADDNODEAdd Node (Add Node for iCluster Administrator) have options that allow you to avoid creating a configuration object if it is currently in use. As a result, DataMirror provides a set of source physical files (named CNNL, COSD, CTLD, DEVD, IPXD, LIND, MODD, NTBD, NWID, and NWSD) that are used to hold the source code for generating configuration objects on each node in the cluster. These source physical files are all located in the product library. If, at a later time, you want to create these objects, issue the CRTCFGOBJ command. See CRTCFGOBJCreate Configuration Objects on page 248 for more information. Identifying Configuration Objects When defining object specifiers, no special treatment is required to identify configuration objects. The configuration object type (see list above) can be specified in exactly the same way as all other supported types. However, you cannot use the generic type *ALL to identify configuration objects. Replicating Configuration Objects For configuration objects to be successfully replicated by iCluster, any dependent lines, devices, modes, and so on, must already exist on the backup system. You can also refer to DMSETSVALSet Cluster System Values (Setting System Values for iCluster Administrator), DMADDNODEAdd Node (Add Node for iCluster Administrator), and DMCHGNODEChange Node (Change Node for iCluster Administrator) for more information.

Replicating User Profiles


When replicating user profiles with iCluster, you should note the following:

When user profiles (*USRPRF) are replicated to backup nodes, iCluster does not replicate associated document passwords. The user must explicitly arrange for document passwords to be defined and updated on the backup node. DataMirror recommends that all user profiles (*USRPRF) in library QSYS are replicated to backup nodes. This will ensure that the owners of replicated objects are the same on both primary and backup nodes. When mirroring changes to user profiles (*USRPRF) that belong to a replication group, you need to set the parameter JOBMSGQFL to *WRAP for job description CSJOBD on the backup node. Setting this option prevents the job message queue from filling up. Since one or more group profiles can be associated with a single user profile object (*USRPRF), it is important to note that all related group profiles are also sent to the backup node when a user profile is replicated by iCluster.

DataMirror, an IBM Company

Printed in Canada

91

Replicating LOBs
A LOB (Large Object) provides the ability to store a large amount of data in a database. Previously, you may have excluded the files that contained LOBs because they potentially could have been suspended. You can include these files with LOB fields and they will be replicated just as any other data file. To replicate LOBs, you perform the same steps as for replicating other data in iCluster. Considerations You should be aware of the following considerations for LOBs in iCluster:

The staged LOB data is stored on the backup node in IFS in BSF objects. iCluster stores LOB data in the following location:

/home/DataMirror/iCluster/LOB/<00000000 >/<node name>/<group name>/<journal library>/<journal name> Currently, the maximum store size on the target system is not respected when it is creating the BSF objects for LOB staging. LOB data can be replicated as long as there is sufficient disk space on the target system to contain the LOB data. iCluster does not impose limitations in addition to those imposed by OS/400 for LOB fields in a record format. There can be a total of 1023 LOB fields in a record format. The total size of the LOB fields cannot exceed two gigabytes. We recommend setting all journals to use the highest receiver size possible to ensure successful journaling of files containing LOB data. To do this, set the receiver size to *MAXOPT2.

Replicating Triggers
When replicating triggers in iCluster, you should note the following:

iCluster supports the replication of system triggers and SQL triggers. System triggers are handled by the ADDPFTRG and RMVPFTRG operating system commands. SQL triggers are created and dropped through SQL statements on tables. All triggers in a file are disabled when the file is replicated to the backup node. When a switchover occurs, all triggers are once again enabled on the new primary node regardless of their original status. Up to 300 triggers is supported per file. You can add trigger names of up to 128 characters.

Note that for OS/400 V5R1, there are a number of PTFs that are required for QDBRPLAY API functionality and replicating triggers: SI07279 SI06408 The QDBRPLAY API functionality is built-in to OS/400 V5R2 or later and is not required for replicating triggers.

Note:

Replicating Save Files


iCluster supports the replication of save file (SAVF) objects and allows you to automatically perform actions on the backup node when the save file is replicated to the backup node. Other types of objects, such as document library objects (DLO), and folders, and Integrated File System (IFS) objects (that cannot be replicated through path object specifiers), can be saved in a save file and then replicated by transferring the save file to the backup node. When a save file is received on a backup node, iCluster automatically invokes a predefined program called SAVFEXIT. You can write this program to perform specific actions on the save file. The name and library of the replicated save file are passed as parameters to SAVFEXIT. The program can then use these parameters to determine what kind of actions should be performed on the save file. For example, if the replicated save file contains a document library object, SAVFEXIT can be modified to detect the save file and then restore the DLO by issuing the RSTDLO command.

92

Printed in Canada

iClusterVersion 5.1

Note that SAVFEXIT program has to be created after the product is installed. Issue the following command to create this program. CRTCLPGM PGM(<iCluster product library>/SAVFEXIT) SRCFILE<iCluster product library>/QACLSRC) The <iCluster product library> is the library where iCluster was installed. If you want iCluster to invoke the SAVFEXIT program automatically, it must be placed in the product library on the backup node before replication is started. If you do not want to perform any actions on the save file, remove or delete the SAVFEXIT program after stopping all replication. To replace the current SAVFEXIT program with a new program, you must first stop replication to ensure that the new program is invoked when replication is re-started. DataMirror provides sample source code that can be used to replicate document library objects, folders, and IFS objects. These code segments are located in the file QACLSRC in your product library. Table 12 identifies and briefly describes each code segment.
Table 1 Sample CL Programs

Name SAVE_DLO

Description Saves document library objects (DLO) into a named save file. This program resides on the primary node. When SAVE_DLO is called, the specified DLOs are saved into the save file. These DLOs are then saved at specified intervals. If the save file is being mirrored to a backup node, all specified DLOs will be replicated after they are saved in the save file. Saves Integrated File System objects (IFS) into a named save file. This program resides on the primary node. When SAVE_IFS is called, the specified directory is saved into the save file (this includes all directories and objects contained within the directory). Subsequent updates applied to these directories and objects are saved at specified intervals. If the save file is being mirrored to a backup node, any subsequent updates will be replicated through the save file. Restores document library objects from save files received on backup nodes. To invoke this routine when a save file is received on a backup node, rename this program to SAVFEXIT and compile it in the product library on the backup node. Restores document library objects and Integrated File System objects from save files received on backup nodes. To invoke this routine when a save file is received on a backup node, rename this program to SAVFEXIT and compile it in the product library on the backup node. Restores generic Integrated File System objects from save files received on backup nodes. To invoke this routine when a save file is received in a backup node, rename this program to SAVFEXIT and compile it into the product library on the backup node.

SAVE_IFS

SAVFEXIT01

SAVFEXIT02

SAVFEXIT03

The following describes the process of replicating these types of objects through save files: 1 Determine which objects on the primary node will be refreshed or mirrored. These objects can be of any type that can be saved in a save file. 2 Create a save file that the objects will be saved to (use the OS/400iSeries command CRTSAVF).

DataMirror, an IBM Company

Printed in Canada

93

3 Create a CL program that will save these objects into the created save file. Note that a CL program can be written to use the autostart job or delay job capabilities to schedule when objects should be saved. DataMirror provides two sample CL programs (SAVE_DLO and SAVE_IFS - see Table 1) that can be used to save document library objects and Integrated File System objects into the save file. 4 Write the SAVFEXIT program to apply user actions to replicated save files on backup nodes. This program must reside in the iCluster product library on the backup node. Use the CRTCLPGM command (see above) to create the SAVFEXIT program. Note that DataMirror provides three sample programs (SAVFEXIT01, SAVFEXIT02, and SAVFEXIT03) that can be renamed to SAVFEXIT. These sample programs restore document library objects and Integrated File System objects on backup nodes. 5 Define the backup node that will be destination of the save files. 6 Create a replication group that includes the backup node defined in the previous step. 7 Create an object specifier that references the save files and select the specifier to the replication group created in the previous step. 8 Write the SAVFEXIT program to apply user actions to replicated save files on backup nodes to make sure that the program is created on both nodes of your replication group. 9 Call the CL program (for example, SAVE_DLO or SAVE_IFS - see Table 1) that saves the objects into the save file you previously created. 10 Start node and replication group operations. When a save file is received on a backup node, SAVFEXIT is called. Typically, this program will restore the objects in the save file.

Replicating QDLS Objects


This topic describes the commands you must run to add QDLS objects to an existing replication group. See the DMADDGRP Add Group on page 113 for more information on creating replication groups. Replicating the QDLS Folder and its Subfolders To replicate the QDLS folder or any combination of its subfolders, you must add each folder to the objects replicated by a group using the DMADDBSFAdd Path Object Specifier to Group command. For example, the following commands add the PUBLIC and GLOBAL subfolders to the MYGROUP replication group: > DMADDBSF GROUP(MYGROUP) PATH('/QDLS/PUBLIC/*') > DMADDBSF GROUP(MYGROUP) PATH('/QDLS/GLOBAL/*') Excluding QDLS Folders iCluster allows you to exclude QDLS folders from replication. However, to exclude any QDLS folders, you must replicate the entire QDLS folder and then specify which folders you want to exclude. You can only exclude folders from replication and not the individual objects in the folders. To exclude QDLS folders from your replication group, perform the following tasks: 1 Add the entire QDLS folder to the replication group using the DMADDBSF command. You must include the entire QDLS folder and cannot specify a subfolder in this step. For example, > DMADDBSF GROUP(MYGROUP) PATH('/QDLS/*') 2 Specify which QDLS folders you do not want to replicate using the DMADDBSF command and setting the INCFLG parameter to *EXCLUDE. You must end each path entry with /*. For example, > DMADDBSF GROUP(MYGROUP) PATH('/QDLS/PRIVATE/*') INCFLG(*EXCLUDE) 3 Repeat step 2 for any other folders you do not want to replicate from the QDLS file system.

94

Printed in Canada

iClusterVersion 5.1

When you start the replication group, it will mirror all of the QDLS file system folders, except the ones you specified in Step 2 and Step 3. The replication process will create the folders you excluded on the backup node, but these folders will be empty.

Replicating WebSphere MQ Objects


WebSphere MQ is an application-to-application program that exchanges data contained in messages via queues. WebSphere MQ facilitates the exchange of information between applications that would not otherwise communicate with each other, such as to multiple and potentially remote systems in different geographical regions, and dissimilar systems. It provides assured, onceonly delivery of messages. iCluster and WebSphere MQ iCluster has the ability to mirror WebSphere MQ objects, enabling WebSphere MQ to continue operating on a secondary system should a failover occur. This support allows interdependent applications to continuously communicate within enterprises and between enterprises. If you use WebSphere MQ to integrate your applications, you can use iCluster to protect your applications from primary system outages since WebSphere MQ integration jobs are preserved. Note: iCluster mirrors BSF objects that represent queues, processes, name lists, and so on. Remote journaling is used to guarantee that all WebSphere MQ transactions are replicated to the backup system and applied to the backup system queues.

iCluster supports WebSphere MQ V5R2, V5R3, and V6R0. Earlier versions of WebSphere MQ are not supported. The following commands in iCluster are important for a switchover with MQSeries groups:

RBDHAMQMRebuild iCluster MQSeries rebuilds the WebSphere MQ messages for the queue manager. This command brings the WebSphere MQ objects on the backup node up-to-date based on the information recorded in the primary node's WebSphere MQ journal. DMSTRGRPStart Cluster Operations at Group starts the mirroring for the queue manager.

Multiple queue managers are supported in iCluster. Use the DMADDGRPAdd Group command to add a group for each of the queue managers to be mirrored. iCluster Limitations Authority changes made through the GRTMQMAUT and RVKMQMAUT commands are not journaled by WebSphere MQ. Therefore, iCluster does not mirror these changes. IBM recommends that the operator use a CL program of their own to apply the two commands to any WebSphere MQ objects on the original primary machine instead of issuing them on the command line. This means the operator may have to update and run the CL program periodically in order to handle newly created WebSphere MQ objects. iCluster can mirror this particular program to the target. The program can be run after a switchover. All authority changes on the primary system are properly applied on the backup. WebSphere MQ Support: Pre-requisites Before you can mirror WebSphere MQ objects with iCluster, you must perform the following steps:

Verify that you have applied the pre-requisite PTFs for the supported versions of WebSphere MQ. See PTFs for WebSphere MQ on page 96 for more information. Create a local relational database directory entry for each node in the cluster. See Creating a Local Relational Database Directory Entry on page 96 for more information. Add the QMQMADM administrative group to the DMCLUSTER user profile as either the group profile or as a supplemental group. This must be done on both the primary and backup nodes. Make sure that you have completed the miscellaneous steps outlined in Additional Pre-requisites for WebSphere MQ Support (V5R2M0 and V5R3M0) on page 96. Complete the steps in To enable WebSphere MQ support on page 96 below.

DataMirror, an IBM Company

Printed in Canada

95

PTFs for WebSphere MQ Your system administrator should install the appropriate system PTFs before you can mirror WebSphere MQ objects with iCluster. See Replicating WebSphere MQ Objects on page 95 for a service summary for OS/400 in IBM's online documentation for an upto-date listing of the necessary system PTFs. Before installing the necessary system PTFs, make sure of the following:

WebSphere MQ must be installed on both the primary and the backup machines. WebSphere MQ queue managers on both machines can start and stop properly.

Creating a Local Relational Database Directory Entry Each node in the cluster must contain a valid local relational database directory entry. These entries must be unique across the cluster. To determine if a node has a local database directory entry, issue the following OS/400 command for each node in the cluster:
WRKRDBDIRE

The local relational database directory entries are displayed as "*LOCAL" under the "Remote Location" field. If a "*LOCAL" value is not present, use the following command to create a local relational database directory entry for each node in the cluster:
ADDRDBDIRE RDB(<chosen_name>) RMTLOCNAME(*LOCAL)

Where <chosen name> can be the system name usually used for identifying the machine. Note: If two machines have the same local relational database directory value, remove one of them and recreate it with a value that closely reflects the system name.

Additional Pre-requisites for WebSphere MQ Support (V5R2M0 and V5R3M0)

The WebSphere MQ queue manager is active on the primary node, and the WebSphere MQ queue manager on the backup node exists, but is inactive before starting mirroring. You can use the WRKMQM command to check whether a certain WebSphere MQ queue manager is active or not. An error message will tell you that the manager is not active.

Check the journal AMQAJRN on both the primary and backup machines (with the command WRKJRNA). Make sure the currently attached journal receiver has the highest number on the journal receiver chain.

To enable WebSphere MQ support


1 Use the DMADDGRPAdd Group command to set up a group for WebSphere MQ replication. The appropriate object specifiers are added automatically and selected to this group by this command. See the DMADDGRPAdd Group command for more information. 2 Use the DMSTRGRPStart Cluster Operations at Group command to start replicating WebSphere MQ objects. See the DMSTRGRPStart Cluster Operations at Group command for more information. 3 After a switchover, you need to rebuild the MQSeries environment by issuing the RBDHAMQM command. You should only use RBDHAMQM on the new primary node after a switchover or failover, and the WebSphere MQ queue manager has not been activated. See RBDHAMQMRebuild iCluster MQSeries on page 179 for more information. 4 If you are mirroring the MQSeries group(s) back to the original primary system as part of a switchover, mirroring must be started with the RFSH parameter set to *YES. For more information, see DMSTRGRPStart Cluster Operations at Group on page 208. After a switchover, you should also stop the MQSeries queue manager on the original primary system. Note: MQSeries groups do not support checkpoint user exits.

96

Printed in Canada

iClusterVersion 5.1

iCluster Commands
This section contains information on the commands available in iCluster and how to use them. This guide also introduces iCluster concepts and provides general configuration information. This section provides full descriptions of each command that is supported by iCluster. For each command that is described, the following items of information are provided:

Input Parameters: Describes each parameter in the command and identifies the values that can be specified. Examples: Provides one or more examples of invoking the command. Use: Identifies limitations that determine where and when you can invoke the command. Minimum Security Level: Where applicable, identifies the minimum security level (administrator, operator, or user) that is required to invoke the command. Menu Access: Identifies the option number(s) that you can use to invoke the command through supported iCluster menus. Several historical HA Suite commands still exist within iCluster. If a command does not appear in the documentation or the menus (F22 - Shift+F10), then its use is not supported by DataMirror.

Note:

This section contains the following topics:

Node Commands on page 99 Group Commands on page 113 Native AS/400 Object Commands on page 141 Byte Stream File (BSF) Commands on page 155 Switchable Device Commands on page 163 Resilient Application Commands on page 167 MQSeries Commands on page 179 Administration Commands on page 181 Cluster Operation Commands on page 207 Replication Operation Commands on page 225 Status and History Monitor Commands on page 255 Sync Check Commands on page 263 Registered iCluster User Commands on page 277 Exit Program Commands on page 283 iCluster for Supported External Storage Systems on page 285 Other Commands on page 289

DataMirror, an IBM Company

Printed in Canada

97

98

Printed in Canada

iClusterVersion 5.1

Node Commands

Node Commands
This section contains the following commands:

DMADDNODEAdd Node on page 99 DMDSPNODEDisplay Node on page 103 DMCHGNODEChange Node on page 104 DMRMVNODERemove Node on page 109 DMWRKNODEWork with Nodes on page 110

DMADDNODEAdd Node
DMADDNODE NODE( ) IPADDR( ) IPADDR2( ) PORT( ) PRODLIB( ) DESC( ) REPLJOBD( ) USRPRFSTS( ) CFGSRCHLD( ) STGSTORSZ( ) STGSTORLIB( ) SWITCHRES( ) CHKPRIMLNK( ) CHKALTLNK( ) LNKCHKFRQ( ) LNKCHKRTO( ) LNKCHKTRY( ) MSGUSREXIT( ) MSGQUEUE( ) MSGACTWAIT( ) NUMMSGACT( ) Use this command to add a node to the cluster. When a node is added through this command, it is automatically activated in the cluster. You can de-activate cluster operations on the node by issuing the DMENDNODEEnd Cluster Operations at Node command. If no node has been added to the cluster, then you must issue this command on the system that you want to define in the cluster (see Use on page 103 if the node you are adding is not the first node in the cluster). The first node added to the cluster is considered as the master node. For more information about the master node, see Working in a Clustered Environment on page 43. If you are using IBM Cluster Resources as your failover mechanism and have nodes with different operating system versions, then the first node you add to a cluster must use the lower operating system version. See Adding Nodes on page 31 for important pre-requisite information concerning nodes in your clustered environment. Input Parameters

NODE The name that identifies the node in the cluster. IPADDR The primary IP address of the node being added to the cluster. You can specify the IP address of the node in dotted quad notation (for example, 125.4.3.55) or in domain name form (for example, as400sys1a.abccorp.com).

IPADDR2 The secondary IP address of the node being added to the cluster. You can specify the IP address of the node in dotted quad notation (for example, 125.4.3.56) or in domain name form (for example, as400sys1b.abccorp.com). The secondary IP address is used by the failover mechanism to determine if a node in the cluster is not operational or the communication link connecting the node has failed. The secondary IP address is not used by iCluster for replication operations.

PORT The TCP/IP port number on the node that has been reserved for iCluster communications. This port number was specified when defining the dmcluster service to the TCP/IP service table. For more information about adding this service to the table, see Adding a New Entry 'dmcluster' to the TCP/IP Service Table on page 37.

DataMirror, an IBM Company

Printed in Canada

99

The default port number is 4545.

PRODLIB The library on the node where iCluster has been installed. The default product library is DMCLUSTER. DESC A short description that allows you to identify this node among all others that have been defined in the cluster. The description can be a maximum of 50 characters long. REPLJOBD The name of the job description that you want to associate with jobs that handle replication activity on the specified node. Specify the name of the job description or the following value:

*CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVALSet Cluster System Values command.

The library where the job description resides must be identified if you do not specify *CLUSTER. Prefix the job description with the name of the library where the job description is located (for example, LIB1/RJD). The default setting for this parameter is *CLUSTER.

USRPRFSTS The status that you want to assign to user profiles that are replicated to the node you are adding to the cluster. Specify one of the following values:

*CLUSTERRefers to the cluster system value for this parameter you specify through the DMSETSVALSet Cluster System Values command. *PRIMARYSets the user profile status to the same status that is currently assigned to the corresponding user profile on the primary node. *DISABLEDSets all user profiles to a status of *DISABLED. *NOCHGIndicates that the current status of each user profile will not be changed by iCluster and the user profile status on the backup node is set to *DISABLED by default.

The default setting for this parameter is *CLUSTER. CFGSRCHLD Indicates whether you want iCluster to automatically create configuration objects immediately after they are received on the specified node or hold the commands for creating them in specific physical files so that they can be created at a later time. Specify one of the following values:

*CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVALSet Cluster System Values command. *YESHolds commands to create configuration objects in specific physical files so that they can be created at a later time with the CRTCFGOBJ command. *NOAutomatically creates configuration objects as soon as they are received on the node you are adding to the cluster.

If a configuration object that is being replicated already exists on the node you are adding to the cluster, you should set this value to *YES in order to prevent iCluster from trying to create the object when it is in use. The default setting for this parameter is *CLUSTER. For more information about configuration objects, see Replicating Configuration Objects on page 90.

100

Printed in Canada

iClusterVersion 5.1

Node Commands

STGSTORSZ Indicates the size (in megabytes) that you want to allocate for the staging store. Note that the size of the store changes dynamically but it cannot exceed the size specified through this parameter. The size of the staging store can range from a minimum of 512 megabytes to a maximum of 1,048,576 megabytes. All objects and data replicated between nodes will travel through the staging stores on the backup nodes. Assuming the backup node update process is active, the journal entries will be ready to be applied. If the node update process is not active, the staging store will hold all journal entries until the node apply process is re-started. The default setting for this parameter is 512 megabytes. For more information about staging stores, see Staging Objects on page 69.

STGSTORLIB The library where the staging store is located. SWITCHRES Indicates whether you will be using switchable resources on the current node. Enter one of the following values:

*YESEnables the node to use switchable resources. If you specify this value, then you must have installed OS/400 option 41 HA Switchable Resources on the node and there must be a valid license key for the option. *NODoes not enable the node for switchable resources.

CHKPRIMLNK This parameter indicates if you want to test the primary IP address for communication failures between the primary and backup nodes. The possible values are:

*YESTest the primary IP address for communication failures. *NODo not test the primary IP address for communication failures.

The default value for this parameter is *YES. This parameter has no effect in clusters that use IBM Cluster Resource Services. CHKALTLNK This parameter indicates if you want to test the alternate IP address for communication failures between the primary and backup nodes. The possible values are:

*YESTest the alternate IP address for communication failures. *NODo not test the alternate IP address for communication failures.

The default value for this parameter is *NO. This parameter has no effect in clusters that use IBM Cluster Resource Services. LNKCHKFRQ Set this parameter to how often, in seconds, you want to poll the primary and alternate links for communication failures. The default value is 60 seconds. This parameter has no effect in clusters that use IBM Cluster Resource Services.

LNKCHKRTO Set this parameter to the number of seconds you want to wait for a response when polling links for failures. The default value is 30 seconds. This parameter has no effect in clusters that use IBM Cluster Resource Services.

LNKCHKTRY

DataMirror, an IBM Company

Printed in Canada

101

Set this parameter to the number of consecutive failures you want to allow before iCluster considers the primary node to have failed. For example, if you set this parameter to 3, then after the fourth consecutive failure, iCluster will change the status of the primary node to *FAILED. The default value is 5. This parameter has no effect in clusters that use IBM Cluster Resource Services.

MSGUSREXIT Set this parameter to the name and library of the user exit program to run after the number of consecutive communication failures, specified with the LNKCHKTRY parameter, is exceeded. You can either specify a name and library or *NONE. The default value is *NONE. This user exit is run once per message sent to the message queue. This parameter has no effect in clusters that use IBM Cluster Resource Services.

MSGQUEUE Set this parameter to the name and library of the message queue that will receive messages after the number of consecutive communication failures, specified with the LNKCHKTRY parameter, is exceeded. You can either specify a name and library or *NONE. The default value is *NONE. This parameter has no effect in clusters that use IBM Cluster Resource Services.

MSGACTWAIT Set this parameter to the number of minutes to wait before sending messages to the message queue, specified with the MSGQUEUE parameter, after detecting a failure. The default value is 0 minutes.

Note:

Both MSGACTWAIT and NUMMSGACT must be set to non-zero values for messages to be sent after a failure. This parameter has no effect in clusters that use IBM Cluster Resource Services. NUMMSGACT Set this parameter to the maximum number of messages to send through the message queue, specified with the MSGQUEUE parameter, after detecting a failure. The system will wait for the time specified in the MSGACTWAIT parameter between sending each message. The default value is 0.

Note:

Both MSGACTWAIT and NUMMSGACT must be set to non-zero values for messages to be sent after a failure. This parameter has no effect in clusters that use IBM Cluster Resource Services.

Examples DMADDNODE NODE(NODE1) IPADDR(155.4.5.20) IPADDR2(155.4.5.21) PORT(4141) PRODLIB(DMICLUS) DESC('New York') REPLJOBD(LIB1/RJD) USRPRFSTS(*DISABLED) CFGSRCHLD(*YES) STGSTORSZ(1024) SWITCHRES(*NO) CHKALTLNK(*YES) MSGQUEUE(QUEUES/NYQ) MSGACTWAIT(10) NUMMSACT(6) Adds the node named NODE1 to a cluster. NODE1 has a primary IP address (expressed in dotted quad notation) of 155.4.5.20, a secondary IP address (also expressed in dotted quad notation) of 155.4.5.21, and will use port number 4141 for iCluster replication within the cluster. iCluster was installed in the library DMICLUS. Description indicates that the node is located in New York.

102

Printed in Canada

iClusterVersion 5.1

Node Commands

The job description associated with replication jobs on NODE1 will be RJD in library LIB1. User profiles replicated to NODE1 will all be set to a status of *DISABLED. Commands to create configuration objects will be held in specific source physical files so that they can be created at a later time. The maximum size of the staging store on NODE1 will be 1,024 megabytes. Switchable resources will not be enabled on the node. This node will test the alternate IP address to detect primary node failures. This node will send messages regarding primary node failures to the NYQ queue in the QUEUES library. This node will send messages to QUEUES/NYQ every ten minutes if it detects a failure. This node will send up to 6 messages to QUEUES/NYQ. DMADDNODE NODE(NODE2) IPADDR(sys1a.abc123corp.com) IPADDR2(sys1b.abc123corp.com) PORT(3333) PRODLIB(DMICLUS) DESC('Los Angeles') REPLJOBD(LIB1/RJD) USRPRFSTS(*PRIMARY) CFGSRCHLD(*NO) STGSTORSZ(2048) SWITCHRES(*NO) Adds the node named NODE2 to the cluster. NODE2 has a primary IP address (expressed in domain name form) of sys1a.abc123corp.com, a secondary IP address (also expressed in domain name form) of sys1b.abc123corp.com, and will use port number 3333 for iCluster replication within the cluster. iCluster was installed in the library DMICLUS. Description indicates that the node is located in Los Angeles. The job description associated with replication jobs on NODE2 will be RJD in library LIB1. User profiles replicated to NODE2 will be set to the same status that is currently assigned to the corresponding user profile on the primary node. Configuration objects replicated to NODE2 will be automatically created as soon as they are received. The maximum size of the staging store on NODE2 will be 2,048 megabytes. Switchable resources will not be enabled on the node. Use If at least one node has been defined in the cluster, this command must be invoked from an active node that can communicate with the master node. You can define a maximum of 128 nodes in the cluster. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 1 Work With Nodes screen - Option F6

DMDSPNODEDisplay Node
DMDSPNODE NODE( ) Use this command to display the current settings for the specified node. Input Parameter

NODE

DataMirror, an IBM Company

Printed in Canada

103

The name of the node that you want to examine. Example DMDSPNODE NODE(NODE1) Displays the current settings for the node NODE1. Use You can issue this command on an active node in the cluster. Minimum Security Level User (*USER) Menu Access F22 (Shift+F10) - Option 4 Work With Nodes screen - Option 5

DMCHGNODEChange Node
DMCHGNODE NODE( ) IPADDR( ) IPADDR2( ) DESC( ) REPLJOBD( ) USRPRFSTS( ) CFGSRCHLD( ) STGSTORSZ( ) SWITCHRES( ) CHGSTATUS( ) CHKPRIMLNK( ) CHKALTLNK( ) LNKCHKFRQ( ) LNKCHKRTO( ) LNKCHKTRY( ) MSGUSREXIT( ) MSGQUEUE( ) MSGACTWAIT( ) NUMMSGACT( ) AUTHCODE( ) Use this command to change one or more attributes of the specified node in the cluster. The node that you change must be active in the cluster, with the following exception: If you are using OS/400 Cluster Resource Services, the node must be *INACTIVE when changing its IP address(es) for iCluster. If replication is active and you are using Cluster Resource Services, the node's IP addresses and job description will not be changed. You can change all other node parameters when replication is active on the node. However, some parameters used by replication jobs will only come into effect when new replication jobs are started. Existing replication jobs will continue to use the previous parameters, with the exception of the staging store size. The staging store size comes into use by all backup replication jobs as soon as it is changed. If you are not using OS/400 Cluster Resource Services, the node must be *ACTIVE when changing its IP address(es) or any other parameter of the node. Input Parameters

NODE The node in the cluster that will have one or more attributes changed by this command. Note that the node you specify must be in the cluster. If you specify a node that does not exist in the cluster, this command will fail. Therefore, this parameter is simply used to reference an existing node in the cluster so that other attributes of the node can be changed.

IPADDR The primary IP address of the node that you want to change. See Changing IP Addresses on page 80 before changing a node's IP address. The IP address of the node can be specified in dotted quad notation (for example, 125.4.3.55) or in domain name form (for example, as400sys1a.abccorp.com). Specify the primary IP address of the node or the following value:


104

*SAMEUses the current setting for this parameter.

The default setting for this parameter is *SAME. IPADDR2

Printed in Canada

iClusterVersion 5.1

Node Commands

The secondary IP address of the node that you want to change. The IP address of the node can be specified in dotted quad notation (for example, 125.4.3.56) or in domain name form (for example, as400sys1b.abccorp.com). The secondary IP address is used by the failover mechanism to determine if a node in the cluster is not operational or the communication link connecting the node has failed. The secondary IP address is not used by iCluster for replication operations. Specify the secondary IP address of the node or the following value:

*SAMEUses the current setting for this parameter.

The default setting for this parameter is *SAME. DESC A short description that allows you to identify this node amongst all others that have been defined in the cluster. The description can be a maximum of 50 characters long. Specify a short description or the following value:

*SAMEUses the current setting for this parameter.

The default setting for this parameter is *SAME. REPLJOBD The name of the job description that you want to associate with jobs that handle replication activity on the specified node. Specify the name of the job description or one of the following values:

*SAMEUses the current setting for this parameter. *CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVAL command.

The default setting for this parameter is *SAME. The library where the job description resides must be identified if you do not specify *CLUSTER or *SAME. Prefix the job description with the name of the library where the job description is located (for example, LIB1/RJD).

USRPRFSTS The status that you want to assign to user profiles that are replicated to the node you are changing in the cluster. Specify one of the following values:

*SAMEUses the current setting for this parameter. *PRIMARYSets the user profile status to the same status that is currently assigned to the corresponding user profile on the primary node. *DISABLEDSets all user profiles to a status of *DISABLED. *NOCHGIndicates that the current status of each user profile will not be changed by iCluster and the user profile status on the backup node is set to *DISABLED by default. *CLUSTERRefers to the cluster system value for this parameter that you specify through the DMSETSVAL command.

The default setting for this parameter is *SAME. CFGSRCHLD Indicates whether you want iCluster to automatically create configuration objects immediately after they are received on the specified node or hold the commands for creating them in specific physical files so that they can be created at a later time. Specify one of the following values:

DataMirror, an IBM Company

Printed in Canada

105

*SAMEUses the current setting for this parameter. *YESHolds commands to create configuration objects in specific physical files so that they can be created at a later time with the CRTCFGOBJ command. *NOAutomatically creates configuration objects as soon as they are received on the node you are changing in the cluster. *CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVAL command.

The default setting for this parameter is *SAME. If a configuration object that is being replicated already exists on the node you are changing in the cluster, you can set this value to *YES to prevent iCluster from trying to create the object when it is in use. For more information about configuration objects, see Replicating Configuration Objects on page 90.

STGSTORSZ Indicates the size (in megabytes) that you want to allocate for the staging store. Note that the size of the store changes dynamically but it cannot exceed the size specified through this parameter. The size of the staging store can range from a minimum of 512 megabytes to a maximum of 1,048,576 megabytes. The staging store is a non-volatile storage mechanism for backup nodes that is managed on a node-by-node basis. The size of the staging store must be set for each backup node in the cluster. All objects and data replicated between nodes will travel through the staging stores on the backup nodes. Assuming the node update process is active, the journal entries will be ready to be applied. If the node update process is not active, the staging store will hold all journal entries until the node apply process is re-started. Specify the size of the staging store or the following value:

*SAMEUses the current setting for this parameter.

The default setting for this parameter is *SAME. For more information about staging stores, see Staging Objects on page 69. Note: Unlike the DMADDNODEAdd Node command, you cannot modify the staging store library through this command. To change the existing staging store library for the specified node, the node must be removed and then re-added to the cluster. See DMRMVNODERemove Node on page 109 and DMADDNODEAdd Node on page 99 for more information. SWITCHRES Indicates whether you will be using switchable resources on the node. Enter one of the following values:

*SAMEKeeps the present setting for this parameter. This is the default value. *YESEnables the node to use switchable resources. If you specify this value, then the OS/400 option 41, HA Switchable Resources, must be installed on the node and there must be a valid license key for the option. *NODoes not enable the use of switchable resources.

CHGSTATUS Indicates whether the status of the specified node should be changed. Enter one of the following values:

*SAMEKeeps the present setting for this parameter. This is the default value. *FAILEDUse this value when a node has failed but its status in the cluster is *PARTITION. After the status of the node has been changed to *FAILED, it can either be removed from the cluster or re-started if it is capable of rejoining the cluster. For more information on failovers and switchovers, see Failovers and Switchovers on page 47. To identify your failover mechanism, see Failover Mechanisms on page 47.

106

Printed in Canada

iClusterVersion 5.1

Node Commands

CHKPRIMLNK This parameter indicates if you want to test the primary IP address for communication failures between the primary and backup nodes. The possible values are:

*SAMEUse the current setting for this parameter. *YESTest the primary IP address for communication failures. *NODo not test the primary IP address for communication failures.

The default setting for this parameter is *SAME. This parameter has no effect in clusters that use IBM Cluster Resource Services. CHKALTLNK This parameter indicates if you want to test the alternate IP address for communication failures between the primary and backup nodes. The possible values are:

*SAMEUse the current setting for this parameter. *YESTest the alternate IP address for communication failures. *NODo not test the alternate IP address for communication failures.

The default setting for this parameter is *SAME. This parameter has no effect in clusters that use IBM Cluster Resource Services. LNKCHKFRQ Set this parameter to how often, in seconds, you want to poll the primary and alternate links for communication failures. The default setting for this parameter is *SAME. This parameter has no effect in clusters that use IBM Cluster Resource Services.

LNKCHKRTO Set this parameter to the number of seconds you want to wait for a response when polling links for failures. The default setting for this parameter is *SAME. This parameter has no effect in clusters that use IBM Cluster Resource Services.

LNKCHKTRY Set this parameter to the number of consecutive failures you want to allow before iCluster considers the primary node to have failed. For example, if you set this parameter to 3, then after the fourth consecutive failure, iCluster will change the status of the primary node to *FAILED. The default setting for this parameter is *SAME. This parameter has no effect in clusters that use IBM Cluster Resource Services.

MSGUSREXIT Set this parameter to the name and library of the user exit program to run after the IBM Cluster Resource Services number of consecutive communication failures, specified with the LNKCHKTRY parameter, is exceeded. This user exit is run once per message. The possible values are:

*SAMEUse the current settings for this parameter. LIBRARY/NAMEThe name and library of the message queue. *NONEDo not queue messages.

The default setting for this parameter is *SAME. This parameter has no effect in clusters that use IBM Cluster Resource Services. MSGQUEUE

DataMirror, an IBM Company

Printed in Canada

107

Set this parameter to the name and library of the message queue that will receive messages after the IBM Cluster Resource Services number of consecutive communication failures, specified with the LNKCHKTRY parameter, is exceeded. The possible values are:


Note:

*SAMEUse the current settings for this parameter. LIBRARY/NAMEThe name and library of the message queue. *NONEDo not queue messages.

The default setting for this parameter is *SAME. This parameter has no effect in clusters that use IBM Cluster Resource Services. MSGACTWAIT Set this parameter to the number of minutes to wait before sending messages to the message queue, specified with the MSGQUEUE parameter, after detecting a failure. The default setting for this parameter is *SAME. Both MSGACTWAIT and NUMMSGACT must be set to non-zero values for messages to be sent after a failure. This parameter has no effect in clusters that use IBM Cluster Resource Services. NUMMSGACT Set this parameter to the maximum number of messages to send through the message queue, specified with the MSGQUEUE parameter, after detecting a failure. The system will wait for the time specified in the MSGACTWAIT parameter between sending each message. The default setting for this parameter is *SAME. Note: Both MSGACTWAIT and NUMMSGACT must be set to non-zero values for messages to be sent after a failure. This parameter has no effect in clusters that use IBM Cluster Resource Services. AUTHCODE The new authorization code for the node that was provided by DataMirror Technical Support. See Contacting Technical Support on page 547 for more information. The authorization code was specified during iCluster installation, and is required to run iCluster on the node. Therefore, use this parameter to change the existing authorization code for the node if it no longer allows you to run iCluster. Specify the authorization code or the following value:

Examples

*SAMEUses the current setting for this parameter.

The default setting for this parameter is *SAME.

DMCHGNODE NODE(NODE1) IPADDR(155.4.5.44) IPADDR2(155.4.5.45) DESC(Chicago) REPLJOBD(LIB1/RJD) USRPRFSTS(*DISABLED) CFGSRCHLD(*YES) STGSTORSZ(4096) SWITCHRES(*NO) CHGSTATUS(*SAME) AUTHCODE(XCEFAASQLPJUIHE) Changes the attributes of NODE1 in the cluster. Changes the primary IP address of NODE1 to 155.4.5.44 (expressed in dotted quad notation), and the secondary IP address to 155.4.5.45 (also expressed in dotted quad notation). Changes the description associated with the node to indicate that the system is located in Chicago. Changes the job description associated with replication jobs on NODE1 to RJD in library LIB1. User profiles replicated to NODE1 will all be set to a status of *DISABLED. Commands to create configuration objects will be held in specific physical files so that they can be created at a later time. Changes the maximum size of the staging store on NODE1 to 4,096 megabytes.

108

Printed in Canada

iClusterVersion 5.1

Node Commands

Switchable resources will not be enabled on the node, and the status of the node will remain the same. Changes the iCluster authorization code for NODE1. DMCHGNODE NODE(NODE2) IPADDR(sys2a.abc123corp.com) IPADDR2(sys2b.abc123corp.com) DESC(London) REPLJOBD(LIB1/RJD) USRPRFSTS(*PRIMARY) CFGSRCHLD(*NO) STGSTORSZ(8192) SWITCHRES(*NO) CHGSTATUS(*SAME) AUTHCODE(*SAME) Changes the attributes of NODE2 in the cluster. Changes the primary IP address of NODE2 to sys2a.abc123corp.com (expressed in domain name form), and the secondary IP address to sys2b.abc123corp.com (also expressed in domain name form). Changes the description associated with the node to indicate that the system is located in London. Changes the job description associated with replication jobs on NODE2 to RJD in library LIB1. User profiles replicated to NODE2 will be set to the same status that is currently assigned to the corresponding user profile on the primary node. Configuration objects replicated to NODE2 will be automatically created as soon as they are received. Changes the maximum size of the staging store on NODE2 to 8,192 megabytes. Switchable resources will not be enabled on the node, and the status of the node will remain the same. The iCluster authorization code remains the same. DMCHGNODE NODE(NODE3) LNKCHKTRY(3) Changes the attributes of NODE3 in the cluster. Sets the SwitchOver System to allow three failures before changing the status of the primary node to *FAILED. Use You must issue this command from an active node that can communicate with the master node. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 2 Work With Nodes screen - Option 2

DMRMVNODERemove Node
DMRMVNODE NODE( ) Use this command to remove a node that was previously defined in the cluster. Cluster operations at the node are also stopped. A reference cannot be made to the node after it has been removed from the cluster. If you are removing the only node in the cluster, the entire cluster is deleted. In this case, the removal of the node is equivalent to the operations performed when the DMDLTCLSTRDelete Cluster command is invoked. You can use this command to remove the backup node for replication groups and applications. Note that you cannot remove the primary node of a replication group or resilient application. If you wish to remove such a node from the cluster, you can take one of two actions:

Remove all replication groups and resilient applications having this node as their primary node. See DMRMVGROUP Remove Group and DMRMVAPPRemove Resilient Application for more information. End cluster operations at the node before removing it. See DMENDNODEEnd Cluster Operations at Node for more information. After ending cluster operations, ensure that you remove the cluster definitions from the inactive node by issuing the DMDLTCLSTRDelete Cluster command at that node.

DataMirror, an IBM Company

Printed in Canada

109

Input Parameter

NODE The name of the existing node that you want to remove from the cluster.

Example DMRMVNODE NODE(NODE1) Removes the node NODE1 from the cluster. Use You must issue this command from an active node. If you issue this command on a node other than the specified node, the specified node must be active. If the specified node is inactive, the node will only be removed from the active part of the cluster. Therefore, an attempt to add the same node to the cluster at a later time will fail unless you issue the DMDLTCLSTRDelete Cluster command on the specified node only before attempting to re-add it to the cluster. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 3 Work With Nodes screen - Option 6

DMWRKNODEWork with Nodes


DMWRKNODE BY( ) GROUP( ) APPL( ) Use this command to list the nodes that have been defined in the cluster. The BY, GROUP, and APPL parameters allow you to filter the list by displaying the nodes that are included in the recovery domain for a specific replication group or resilient application. The status of each node is indicated on the displayed screen, and can be one of the following:

*ACTIVEIndicates that cluster operations are running on the node. *ACT_PENDIndicates that cluster operations are in the process of being started on the node. *INACTIVEIndicates that cluster operations are not running on the node. *INACT_PNDIndicates that cluster operations are in the process of being stopped on the node. *NEWIndicates that the node has been defined in the cluster, but cluster operations have not been started on the node. *RMV_PENDIndicates that the node is in the process of being removed from the cluster. *FAILEDIndicates that a system failure has occurred on the node. *PARTITIONIndicates that a system failure has occurred on the node or communications with the node have been lost. If a primary node in an active group is in this state, the group will assume an *INACTIVE status and no role change will occur. If a backup node in an active group is in this state, the group will remain in an *ACTIVE state and no role change will occur. See DMWRKGRPWork with Groups on page 137 for more information about group states. For general information about system failures on nodes within your cluster configuration, see Failovers and Switchovers on page 47. See Failover Mechanisms on page 47 for information on identifying your failover mechanism.


110

*IN_ERRORIndicates that an internal iCluster error may have occurred. If this status persists, contact DataMirror Technical Support. See Contacting Technical Support on page 547 for more information. *UNKNOWNIndicates that the node is not recognized in iCluster or the cluster is not recognized on the system or the current node is inactive in the cluster.
Printed in Canada
iClusterVersion 5.1

Node Commands

You should consult Adding Nodes on page 31 for important pre-requisite information concerning nodes in your clustered environment. Input Parameters

BY The set of nodes that are listed by this command. Specify one of the following values:

*NONELists all nodes defined in iCluster. *GROUPLists the nodes that are included in the recovery domain for the group specified through the GROUP parameter (see below). *APPLLists the nodes that are included in the recovery domain for the resilient application identified through the APPL parameter (see below).

The default setting for this parameter is *NONE. GROUP The name of an existing group. Nodes included in the recovery domain for the named group are listed. This parameter is only applicable when the BY parameter (see above) is set to *GROUP. APPL The name of an existing resilient application. Nodes included in the recovery domain for the named application are listed. This parameter is only applicable when the BY parameter (see above) is set to *APPL. Examples DMWRKNODE BY(*NONE) Lists all nodes defined in iCluster. DMWRKNODE BY(*GROUP) GROUP(GRP1) Lists all nodes in the recovery domain for replication group GRP1. DMWRKNODE BY(*APPL) APPL(OEPACK) Lists all nodes included in the recovery domain for the resilient application OEPACK. Use You must issue this command on an active node in the cluster. Minimum Security Level User (*USER) Menu Access Main Menu - Option 1 F22 (Shift+F10) - Option 5

DataMirror, an IBM Company

Printed in Canada

111

112

Printed in Canada

iClusterVersion 5.1

Group Commands

Group Commands
This section contains the following commands:

DMADDGRPAdd Group on page 113 DMDSPGRPDisplay Group on page 124 DMCHGGRPChange Group on page 124 DMRMVGROUPRemove Group on page 134 DMADDBACKAdd Backup Node to Recovery Domain on page 135 DMRMVBACKRemove Backup Node from Recovery Domain on page 135 DMCHGROLEChange Group Primary Node on page 136 DMWRKGRPWork with Groups on page 137

DMADDGRPAdd Group
DMADDGRP GROUP( ) GRPTYPE( ) DMNSRC( ) PRIMNODE( ) PRIMIASP( ) BACKUPS( ) BACKIASP( ) TGTLIB( ) MQVERSION( ) QMNAME( ) MSGQUEUE( ) ROLESWITCH( ) CHKJRN( ) BSWUSREXIT( ) ASWUSREXIT( ) EXITDATA( ) POLLINT( ) SAVACT( ) MAXSPLWAIT( ) SPLACTWAIT( ) DFTDBJRN( ) JRNLOC( ) JRNBACKUP( ) CMTLVL( ) JRNBA( ) OPTIMZAPY( ) DFTBSFJRN( ) RCVRYEXP( ) JRNKEY( ) LCKBACKUP( ) CFGSRCHLD( ) SWDEV( ) ONLINE( ) CRWNR( ) CRUSREXIT( ) DESC( ) Use this command to add a group consisting of one primary node and possibly one backup node. After creating a group, use the DMSELOBJSelect Objects to Group and/or DMADDBSFAdd Path Object Specifier to Group commands to specify the objects it will replicate. Using this command you can create object specifiers and indicate the target library where the objects that match the object specifier are replicated. Input Parameters

GROUP The name of the group that you want to define in iCluster. The specified group name must be unique in the cluster. GRPTYPE Specifies the type of group that you want to define. Specify one of the following values:

*REPLIndicates that you want to create a group for continuous object replication between the primary and backup nodes. *RFSHIndicates that you want to create a refresh-only group. *SWDEVIndicates that you want to create a group for the switchable disk storage devices on the primary and backup nodes. *MQSERIESIndicates that you want to create a WebSphere MQ group for object replication between the primary and backup nodes. *MSTRMSTRIndicates that you want to create a master-master replication group that replicates application updates on the primary into active tables on the backup node.

DataMirror, an IBM Company

Printed in Canada

113

For bi-directional replication, two master-master groups can be set up to mirror updates to the same objects in both directions. For more information on this type of replication, see iBalance and Master-Master Replication on page 321.

DMNSRC The name of an existing group or resilient application that you want to use to define the recovery domain of the group you are adding. This parameter allows you to add a group with the same set of primary and backup nodes as the recovery domain for an existing group or resilient application. Defining two or more replication groups with the same set of nodes is useful when you want to replicate objects between the same nodes, but you want to define different replication group behaviors for different sets of objects. Specify the name of an existing group, resilient application, or the following value:

*LISTIndicates that you want to explicitly identify the primary and backup nodes in the replication group instead of selecting an existing replication group or resilient application.

The default setting for this parameter is *LIST. PRIMNODE The name of a node that will be the primary node in the group you are adding. The node that you specify must have been added to the cluster using the DMADDNODEAdd Node command. This parameter applies only if the DMNSRC parameter (see above) is set to *LIST. For *SWDEV groups, the primary and backup nodes must have the switchable disk storage devices enabled (SWITCHRES parameter). For more information, see the DMADDNODEAdd Node command.

PRIMIASP The name of an independent auxiliary storage pool (IASP) on the primary node from which you want to replicate. Specify the name of an existing IASP or the following value:

*SYSBASIndicates that you are using a system ASP rather than an independent ASP for storing the objects that you want to replicate.

The default setting for this parameter is *SYSBAS. BACKUPS The name of a node that will be the backup node in the group you are adding. At this time, only one backup node can be specified for a group. The node that you specify must have been added to the cluster using the DMADDNODEAdd Node command. This parameter applies only to the DMNSRC parameter (see above) is set to *LIST.

BACKIASP The name of an independent auxiliary storage pool (IASP) on the backup node to which you want to replicate. Specify the name of an existing IASP or the following value:

*SYSBASIndicates that you are using a system ASP rather than an independent ASP for storing the objects to be replicated.

The default setting for this parameter is *SYSBAS. TGTLIB The name of the library on the backup system that receives the replicated objects. Specify the name of a target library or the following value:

*PRIMARYSets the target library so that it is the same as the primary node library where the object resides.

114

Printed in Canada

iClusterVersion 5.1

Group Commands

If the primary and backup environments reside on the same physical system (local loopback replication), the target library that you specify cannot be the same library where a selected object in the group currently resides. This restriction means that iCluster does not permit the special value *PRIMARY in this situation. *PRIMARY is the default setting for this parameter. Note: Switchovers and role changes are not supported for groups that use a target library other than *PRIMARY. Consequently, because a non-primary target library is required for local loopback replication, switchovers and role changes are not supported for local loopback replication. MQVERSION Indicates the product version of WebSphere MQ that you are using. WebSphere MQ Versions V5R2M0, V5R3M0, and V6R0M0 are supported. The default setting for this parameter is V5R3M0. Note: This parameter only applies to groups of type *MQSERIES. QMNAME Indicates the name of the WebSphere MQ queue manager that must be mirrored. Multiple queue managers are not supported. If you want to mirror multiple queue managers, use the DMADDGRPAdd Group command to define a group for each of them. Enter specific names. Do not use *DFT or generic names. Note: This parameter only applies to groups of type *MQSERIES. MSGQUEUE The name of the message queue on the new primary node that will receive messages generated when a failover occurs. Note that this parameter is only valid for replication groups. Specify the name of a message queue or the following value:

*NONEIndicates that you do not want to specify a message queue.

The default setting for this parameter is *NONE. The library where the message queue resides must be identified if you do not specify *NONE. Prefix the message queue with the name of the library where the queue is located. For example, LIB1/MSGQ1.

ROLESWITCH Indicates if you want the role of the backup node to change automatically so that it becomes the primary node in the replication group when a failover occurs. This parameter is valid only for replication groups which have *PRIMARY as the target library, and to MQSeries groups. The functions of the primary node will be moved to the backup node if this parameter is set to *YES when a failover occurs. Specify one of the following values:

*YESAutomatically changes the role of the backup node in the replication group to the primary node when a failover occurs. In this case, user exit programs specified through the BSWUSREXIT and ASWUSREXIT parameters (see below) are called. *NODoes not automatically change the role of the backup node in the replication group to the primary node when a failover occurs. Setting the ROLESWITCH parameter to *NO allows you to decide if you want to continue with a role switch, or continue with your current configuration.

With this setting, a failure of the group's primary node is declared by the failover mechanism, although iCluster does not prepare the backup node to take over as the primary node. Replication does not start automatically once the failed primary node is again active in the cluster.

DataMirror, an IBM Company

Printed in Canada

115

When using IBM Cluster Resource Services, only groups which have a cluster status of *ACTIVE are switched over if the primary node fails. When IBM Cluster Resource Services are not being used for iCluster operations, all groups that have the ROLESWITCH parameter set to *YES are switched over when the primary node fails, regardless of whether they are active or not. The default setting for this parameter is *NO. For more information about the ROLESWITCH parameter, see Switchover for IBM Cluster Resource Services (CRS) on page 341.

CHKJRN Specifies whether or not when switching to the new primary node, iCluster checks that the objects for the specified group are being properly journaled on that node, and starts journaling them. Certain types of objects must be journaled before replication starts. However, because journaling objects can be time-consuming, this option allows you to specify whether or not journaling is started for objects during a switchover, depending on your business requirements. Depending on the value of the group's CHKJRN parameter, iCluster may perform processing that is equivalent to the DMMRKPOSMark Current Journal Positions command when a role switch occurs. If the value of the group's CHKJRN parameter is *NO, iCluster does not perform DMMRKPOSMark Current Journal Positions processing and the replication metadata for the new primary node is generated based on the existing replication metadata on the current backup node. In case of an error in processing the backup replication metadata, or non-existent backup replication metadata, iCluster performs DMMRKPOSMark Current Journal Positions processing regardless of the CHKJRN parameter's value.

Note:

The DMMRKPOSMark Current Journal Positions command establishes the set of mirrored objects based on the actual objects that match specifiers on the backup system, regardless if they were previously mirrored or not, and starts journaling for the mirrored objects that should be journaled. If the value of the group's CHKJRN parameter is *YES, iCluster will always perform DMMRKPOSMark Current Journal Positions processing during a role switch, and the backup replication metadata is not used for setting up the replication metadata for the new primary node. You can specify one of the following values:

*YESSpecifies that iCluster checks if all mirrored objects that should be journaled are being journaled on the new primary node. If not, the objects will be journaled. *NOSpecifies that iCluster does not check if all mirrored objects that should be journaled are journaled on the new primary node. You must make sure that all objects that need to be journaled are being journaled to the correct journals, and that the objects have been journaled before replication starts.

The default setting for this parameter is *YES.

BSWUSREXIT The name of the user exit program that you want to call immediately before the role change is performed. The user exit program is called on both nodes of the group for a switchover, but only on the new primary node for a failover. This parameter is valid only for replication groups that have their target library set to *PRIMARY. If you specify a user exit program, the ROLESWITCH parameter (see above) must be set to *YES if you want to call the program when a failover occurs. The specified user exit program will always be called (regardless of the ROLESWITCH parameter setting) when a switchover is initiated. Specify the name of a user exit program or the following value:

*NONEIndicates that you do not want to specify a user exit program.

The default setting for this parameter is *NONE. The library where the user exit program resides must be identified if you do not specify *NONE. Prefix the name of the user exit program name with the name of the library where the program is located (for example, LIB1/USREXIT1).
116 Printed in Canada
iClusterVersion 5.1

Group Commands

For more information about the arguments that can be passed to the user exit program, see Passing Arguments to Role Switch User Exit Programs on page 347.

ASWUSREXIT The name of the user exit program that you want to call immediately after the role change is performed. After a role change occurs, the user exit program will be called on both nodes of the group. This parameter applies only to replication groups that have their target library set to *PRIMARY. If you specify a user exit program, the ROLESWITCH parameter (see above) must be set to *YES if you want to call the program when a failover occurs. The specified user exit program will always be invoked (regardless of the ROLESWITCH parameter setting) when a switchover is initiated. Specify the name of a user exit program or the following value:

*NONEIndicates that you do not want to specify a user exit program.

The default setting for this parameter is *NONE. The library where the user exit program resides must be identified if you do not specify *NONE. Prefix the name of the user exit program name with the name of the library where the program is located (for example, LIB1/USREXIT1). See Passing Arguments to Role Switch User Exit Programs on page 347 for more information about the arguments that can be passed to the user exit program.

EXITDATA Identifies the user-defined data that you want to pass to the user exit programs specified through the BSWUSREXIT and ASWUSREXIT parameters (see above). This parameter applies only to replication groups that have their target library set to *PRIMARY. If you specify two different user exit programs (one program before the role switch, and a different program after the role switch), the same user-defined data is passed to both programs. A maximum of 256 bytes of data can be passed to the user exit programs. If your data contains spaces or non-alphanumeric characters (commas, periods, and so on), you must enclose your data in single quotes.

POLLINT The time interval (expressed in HHMMSS format) that determines how often iCluster should check for content changes to user spaces. This parameter applies only to replication groups. You set the interval by specifying the number of hours (first two digits), minutes (middle two digits) and the seconds (last two digits) between consecutive polls. The polling interval applies only when user spaces (*USRSPC) are selected to the replication group through the DMSELOBJSelect Objects to Group command. Specify a time interval or one of the following values:


Note:

*CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVALSet Cluster System Values command. *NONESpecifies that user spaces should not be polled at the group level.

Not polling user spaces can ease the polling resources on a system that has many user spaces that have not been changed. If *NONE is selected as the polling interval for a *USRSPC object specifier but the group's polling interval is not *NONE, polling occurs for all user spaces selected to the group that do not match the *USRSPC object specifier that has a polling interval of *NONE. The default setting for this parameter is *CLUSTER. SAVACT

DataMirror, an IBM Company

Printed in Canada

117

Indicates if an object can be updated and saved at the same time it is being transferred to the backup node. This parameter does not apply to physical files because they cannot be modified while they are being saved. This parameter applies only to replication groups. Specify one of the following values:

*YESAllows objects that are in use by another job to be saved and updated. Objects may reach checkpoints at different times and may not be in a consistent state in relationship to each other. *NODoes not allow objects that are in use to be saved and updated at the same time. Objects cannot be updated while being saved. *SYNCAllows objects that are in use by another job to be saved and updated. All of the objects reach a checkpoint together and are saved in a consistent state in relationship to each other. *CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVALSet Cluster System Values command.

The default setting for this parameter is *CLUSTER. MAXSPLWAIT The time period (expressed in HHMMSS format) you want iCluster to wait before abandoning the replication of a spool file. This parameter applies only to replication groups. A spool file cannot be replicated unless it has a status of *READY. Therefore, if iCluster is up-to-date with the audit journal, it may start processing a spool file before it is ready. iCluster will only wait the amount of time set in this parameter for the spool file to have a status of *READY. If the spool file is not ready after waiting the amount of time specified in this parameter, iCluster abandons the replication of this spool file and issues a message in the event log. Specify a waiting period from 000001 to 235959, or the following value:

*CLUSTERRefers to the cluster system value for this parameter that is specified using the DMSETSVALSet Cluster System Values command.

The default setting for this parameter is *CLUSTER. SPLACTWAIT The time period (expressed in HHMMSS format) you want iCluster to wait before abandoning the replication of a spool file if no data is being written to it. This parameter applies only to replication groups. In some cases, a job may be writing to a spool file. However, the data is first placed in a temporary buffer and only written to the spool file upon the completion of the job. In such a case, the spool file will be open and have zero pages until the job ends. This parameter allows you to specify the time to wait for changes to occur to an open spool file. If no additional data is written to an open spool file (that is, it is open and has zero pages) within the time specified by this parameter, iCluster abandons the replication of this spool file and issue a message. This parameter provides added flexibility as you can specify a shorter interval over which only spool file activity is monitored. As a result, an open spool file that has no data being written to it will be abandoned quickly, as opposed to waiting the amount of time specified in the MAXSPLWAIT parameter (see above). Specify a waiting period from 000001 to 235959, or the following value:

*CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVALSet Cluster System Values command.

The default setting for this parameter is *CLUSTER. DFTDBJRN

118

Printed in Canada

iClusterVersion 5.1

Group Commands

The name of the database journal that you want to use as your default. This parameter is valid only for replication groups. The journal that you specify is used for files that are to be mirrored but are not yet journaled. iCluster starts journaling automatically in this journal. Specify the name of the database journal or the following value:

*CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVALSet Cluster System Values command.

The default setting for this parameter is *CLUSTER. The library where the journal resides must be identified if you do not specify *CLUSTER. Prefix the journal with the name of the library where the journal is located (for example, LIB1/JRN1). Note: If this group replicates data from an IASP device, then the journal must exist on the IASP device before the group can start replicating objects. JRNLOC The location of the database journal where scraping occurs. Specify one of the following values:


Note:

*LOCALIndicates that the database journal(s) on the primary node are scraped during mirroring. *REMOTEIndicates that the remote database journal(s) are scraped on the backup node during mirroring.

When a remote journal group starts, iCluster activates the remote journal automatically (if it is not already active) using the default value for the DELIVERY parameter in the CHGRMTJRN command. The default setting for this parameter is *LOCAL. After changing the journal location with this parameter, you must set the position of the local journal to the position of the last applied entry by using the DMSETPOS command with the JRNPOS(*LASTAPY) parameter.

JRNBACKUP Indicates whether replicated physical files, data areas, and data queues will be journaled on backup nodes. Specify one of the following values:

*CLUSTERIndicates that this parameter uses the system value that is specified through the DMSETSVALSet Cluster System Values command. *YESIndicates that the replicated physical files, data areas, and data queues will be journaled on backup nodes. *NOIndicates that the replicated physical files, data areas, and data queues will not be journaled on backup nodes.

The default setting for this parameter is *CLUSTER. CMTLVL The level of commitment control you want to use when replicating *FILE objects. This parameter applies only to replication groups. Commitment control stages database transactions so that they are assembled before being applied, or additionally, opened in a commitment control environment to ensure that all updates are received. It also makes sure that the changes are applied in the correct sequence. For more information, see Commitment Control on page 71. Specify one of the following values:

*NONEIndicates that the update process on the backup node will not perform commitment control staging. *LEVEL1Indicates that all updates that comprise a transaction are assembled before being applied on the backup node.

DataMirror, an IBM Company

Printed in Canada

119

*LEVEL2Indicates that all updates in a transaction are opened in a commitment control environment to ensure that all updates are received. This option provides true commitment control. *CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVALSet Cluster System Values command.

The default setting for this parameter is *CLUSTER. If you select *LEVEL2, but a file on the backup node cannot be opened under commitment control, *LEVEL1 commitment control is used for that file.

JRNBA Indicates if default journaling includes both before and after images. This parameter applies only to replication groups. Before images are necessary to remove applied or keyed replication updates. Also, if you specified unique index refresh method for a file, then it must be journaled with both before and after images. If a file is replicated using relative record number, it may be journaled with after images only. For unique key updates, both before and after images must be journaled if the CMTLVL parameter (see above) is set to *LEVEL2. Specify one of the following values:

*BOTHIndicates that you want to journal both the before and after images. *AFTERIndicates that you want to journal the after image only. *CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVALSet Cluster System Values command.

The default setting for this parameter is *CLUSTER. OPTIMZAPY Indicates whether or not you want to optimize database apply entries. Optimization can increase the apply performance for large files that are significantly larger than the shared memory pool, and have a large number of random updates applied to them. Specify one of the following values:


Note:

*NOIndicates that you do not want optimization for database apply updates. *YESIndicates that you want optimization for database apply updates.

The default setting for this parameter is *NO. DFTBSFJRN The name of the journal that you want to use as your default for journaling BSF files that will be replicated by this group. This parameter only applies to replication groups. If this group replicates data from an IASP device, then the journal must exist on the IASP device before the group can start replicating objects. The journal that you specify will be used for BSF files that are to be mirrored and journaled. See the DFTBSFJRN parameter on the DMADDBSFAdd Path Object Specifier to Group command for more information. Specify the name of the BSF journal or one of the following values:

*NONEIndicates that you do not require journaling for BSF replication. *CLUSTERBSF objects selected to this group use the journal specified at the product level. See the DMSETSVALSet Cluster System Values command for more information.

The default setting for this parameter is *CLUSTER.

120

Printed in Canada

iClusterVersion 5.1

Group Commands

The library where the journal resides must be identified if you do not specify *NONE or *CLUSTER. Prefix the journal with the name of the library where the journal is located (for example, LIB2/JRN2).

RCVRYEXP Specifies the number of journal entries applied between writing recovery checkpoints. Specifying a lower number decreases the performance of the apply, but provides a greater safeguard in recovery situations. Specifying a higher number lessens the impact of recovery checkpoints on the apply. This parameter applies only to replication groups. Enter a recovery exposure value (number of journal entries) or the following value:

*DISABLEDIndicates that recovery checkpoints will not be generated. This is the default setting for this parameter.

JRNKEY Specifies the key, or the identifier, that will be assigned to a recovery checkpoint for the group combination. You must also specify this value in the RTVRCVPTRetrieve Recovery Checkpoint or RTVRCVPTRRetrieve Recovery Checkpoint (CL Program) command. This parameter only applies to replication groups.

LCKBACKUP Indicates whether journaled files should be locked on the backup node. When locked, no other users can modify these files on the backup node. Specify one of the following values:

*CLUSTERIndicates that this parameter uses the system value that is specified through the DMSETSVALSet Cluster System Values command. *YESIndicates that files cannot be modified on the backup node when the group is active. *NOIndicates that files will not be locked when the group is active, meaning that users can modify these files on the backup node.

The default setting for this parameter is *CLUSTER. CFGSRCHLD Indicates whether you want iCluster to automatically create configuration objects immediately after they are received on a backup node or hold the commands for creating them in specific physical files so that they can be created at a later time with the CRTCFGOBJ command. If configuration objects that are being replicated already exist on backup nodes, this parameter should be set to *YES in order to prevent iCluster from trying to create objects when they are in use. Specify one of the following values:

*BACKUPIndicates that this parameter uses the Hold configuration object source setting on the backup node of the group that is specified through the DMADDNODEAdd Node command. *CLUSTERIndicates that this parameter uses the system value that is specified through the DMSETSVALSet Cluster System Values command. *YESHolds commands to create configuration objects in specific physical files so that they can be created at a later time with the CRTCFGOBJ command. *NOAutomatically creates configuration objects as soon as they are received on the node.

The default setting for this parameter is *BACKUP. SWDEV The name of a switchable disk storage device that is associated with this group.

DataMirror, an IBM Company

Printed in Canada

121

Note:

This parameter applies only when the GRPTYPE parameter is set to *SWDEV. ONLINE Indicates whether the device associated with the switchable resource group is varied on or varied off when the group is switched over from one node to another or when it is failed over to another node. This parameter applies only to groups of type *SWDEV. Specify one of the following values:

*YESThe device that is associated with the group is varied on when the group is switched over from one node to another or when it is failed over to another node. This is the default value for this parameter. *NOThe device that is associated with the group is not varied on when the group is switched over from one node to another or when it is failed over to another node.

CRWNR Indicates the group-level rules by which iCluster will resolve conflicts for the objects selected to a *MSTRMSTR replication group. Specify one of the following values:

*SRCIndicates that the source wins if there is a conflict. Source data is applied to the target, which ensures that target data matches source data and mirroring continues. *TGTIndicates that the target wins if there is a conflict. iCluster does not apply data to the target. This rule preserves data on the target and mirroring continues. *EXITIndicates that you would like to resolve data conflicts through a user exit program. With this option, you must specify a user exit program and library in the CRUSREXIT parameter below. *NONEIndicates that you do not want to enable conflict detection and resolution rules. If there is a conflict, iCluster suspends the file from replication and sends a message to the event log. This is the default behavior for iCluster.

The default setting for this parameter is *NONE. Note: This parameter only applies to iBalance and *MSTRMSTR replication groups. See iBalance and MasterMaster Replication on page 321 for more information on this feature. CRUSREXIT The name of the user exit program that you want to call to resolve data conflicts. A user exit program allows you to define a conflict resolution strategy that is not covered by one of the standard resolution methods in the CRWNR parameter. Specify the name of a user exit program or the following value:

*NONE - Indicates that you do not want to specify a user exit program.

The library where the user exit program resides must be identified if you do not specify *NONE. Prefix the name of the user exit program name with the name of the library where the program is located (for example, LIB1/USREXIT1). See Parameter List Descriptions for a Conflict Resolution User Exit Program on page 326 for more information about the values you can pass to the user exit program. The default setting for this parameter is *NONE. You cannot specify *NONE for this parameter if you specify *EXIT for the CRWNR parameter. Note: This parameter only applies to iBalance and *MSTRMSTR replication groups. See iBalance and MasterMaster Replication on page 321 for more information on this feature. DESC A short description that allows you to identify this group amongst all others that have been defined in iCluster. The description cannot exceed 50 characters in length.

122

Printed in Canada

iClusterVersion 5.1

Group Commands

Example DMADDGRP GROUP(GRP1) GRPTYPE(*REPL) DMNSRC(*LIST) PRIMNODE(NODE1) PRIMIASP(DMC_IASP1) BACKUPS(NODE2) BACKIASP(*SYSBAS) TGTLIB(*PRIMARY) MSGQUEUE(LIB1/MSGQ1) ROLESWITCH(*YES) CHKJRN(*YES) BSWUSREXIT(LIB1/BFEXIT) ASWUSREXIT(LIB1/AFEXIT) EXITDATA(ARJ123908KPJ230982) POLLINT(003000) SAVACT(*NO) MAXSPLWAIT(000200) SPLACTWAIT(000030) DFTDBJRN(LIB1/JRN1) JRNLOC(*LOCAL) CMTLVL(*LEVEL2) JRNBA(*BOTH) OPTIMZAPY(*YES) DFTBSFJRN(LIB2/JRN2) DESC('NY/LA') Adds the replication group GRP1. The primary and backup nodes in the replication group are explicitly identified through the PRIMNODE and BACKUP parameters. The primary node in the replication group is NODE1, and the backup node is NODE2. The switchable disk storage device on NODE1 is DMC_IASP1. The target library (TGTLIB) is set so that it is the same as the primary node library where the object resides. Messages generated when a failover occurs will be added to the message queue MSGQ1 in library LIB1. The backup node in the replication group will become the primary node if a failover occurs. iCluster will check if all mirrored objects that should be journaled are being journaled on the new primary node in the event of a failover or switchover. User exit programs specified through the BSWUSREXIT and ASWUSREXIT parameters will be called when failover or switchover occurs. The user exit program BFEXIT in library LIB1 will be called immediately before a role change is performed. The user exit program AFEXIT in library LIB1 will be called immediately after a role change is performed. User-defined data consisting of a sequence of characters will be passed to the user exit programs. The polling interval for user spaces selected for replication within the group is 30 minutes. Objects that are in use cannot be saved and updated at the same time. Objects cannot be updated while being saved. iCluster waits a maximum of two minutes for a spool file to have a status of *READY before abandoning the replication of a spool file. iCluster waits 30 seconds for changes to occur to an open spool file before abandoning the replication of a spool file. The default database journal is JRN1 in library LIB1. Changes are applied with *LEVEL2 commitment control. The journal location is set to *LOCAL. Database journal scraping occurs on the group's primary node. Both before and after images are journaled for changes to database files. iCluster will optimize database apply entries. The default BSF journal is JRN2 in library LIB2. Description indicates that the nodes in the replication group are located in New York and Los Angeles. DMADDGRP GROUP(GRP1) GRPTYPE(*MQSERIES) DMNSRC(*LIST) PRIMNODE(NODE1) BACKUPS(NODE2) MQVERSION (V5R2M0 ) QMNAME(QMANAGER) MSGQUEUE(LIB1/MSGQ1) BSWUSREXIT(LIB1/BFEXIT) ASWUSREXIT(LIB1/AFEXIT) EXITDATA(ARJ123908KPJ230982) DESC('NY/LA') Adds the group GRP1 for WebSphere MQ objects. The primary and backup nodes in the group are explicitly identified through the PRIMNODE and BACKUP parameters. The primary node in the group is NODE1, and the backup node is NODE2. iCluster supports WebSphere MQ Versions V5R2M0 and V5R3M0. The queue manager name for WebSphere MQ is QMANAGER. Messages generated when a failover occurs will be added to the message queue MSGQ1 in library LIB1. The backup node in the group will become the primary node if a failover occurs. User exit programs specified through the BSWUSREXIT and ASWUSREXIT parameters will be called if a failover or switchover occurs. Description indicates that the nodes in the group are located in New York and Los Angeles. Use You must issue this command from an active node, and all specified nodes in the added group must be active.

DataMirror, an IBM Company

Printed in Canada

123

Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 6

DMDSPGRPDisplay Group
DMDSPGRP GROUP( ) Use this command to display the current settings for the specified replication group. Input Parameter

GROUP

The name of the replication group that you want to examine. Example DMDSPGRP GROUP(GRP1) Displays the current settings for the replication group GRP1. Use You must issue this command on an active node in the cluster. Minimum Security Level User (*USER) Menu Access F22 (Shift+F10) - Option 11 Work With Groups screen - Option 5

DMCHGGRPChange Group
DMCHGGRP GROUP( ) GRPTYPE( ) TGTLIB( ) MSGQUEUE( ) ROLESWITCH( ) CHKJRN( ) BSWUSREXIT( ) ASWUSREXIT( ) EXITDATA( ) POLLINT( ) SAVACT( ) MAXSPLWAIT( ) SPLACTWAIT( ) DFTDBJRN( ) JRNLOC( ) JRNBACKUP( ) CMTLVL( ) JRNBA( ) OPTIMZAPY( ) DFTBSFJRN( ) RCVRYEXP( ) JRNKEY( ) LCKBACKUP( ) CFGSRCHLD( ) CRWNR( ) CRUSREXIT( ) DESC( ) Use this command to change one or more attributes of an existing replication group. It does not allow you to change the primary and backup nodes in the replication group. You can add and remove the backup nodes using the DMADDBACKAdd Backup Node to Recovery Domain and DMRMVBACKRemove Backup Node from Recovery Domain commands. Input Parameters


Note:

GROUP The name of the replication group that you want to change in iCluster. GRPTYPE Specifies the type of group that you want to define. This parameter does not apply to switchable device groups and MQSeries groups. Specify one of the following values:

124

Printed in Canada

iClusterVersion 5.1

Group Commands

*SAMEUses the current setting for this parameter. *REPLIndicates that you want to change a refresh-only group to a replication group. *RFSHIndicates that you want to change a replication group to a refresh-only group. *MSTRMSTRIndicates that you want to define a master-master replication group that replicates application updates on the primary into active tables on the backup node.

For bi-directional replication, two master-master groups can be set up to mirror updates to the same objects in both directions. For more information on this type of replication, see iBalance and Master-Master Replication on page 321. Note: You cannot change a *MSTRMSTR group to another group type or vice versa. This value is only available with iBalance. See iBalance and Master-Master Replication on page 321 for more information on this feature. The default setting for this parameter is *SAME.

TGTLIB The name of the library on the backup system that will receive the replicated objects. Specify the name of a target library or one of the following values:

*SAMEUses the current setting for this parameter. *PRIMARYSets the target library so that it is the same as the primary node library where the object resides.

The default setting for this parameter is *SAME. If the primary and backup environments reside on the same physical system (local loopback implementation), the target library that you specify cannot be the same library where a selected object in the group currently resides. This restriction means that iCluster does not permit the special value *PRIMARY in this situation. Note: Switchovers and role changes are not supported for groups that use a target library other than *PRIMARY. Also, because a non-primary target library is required for local loopback replication, switchovers and role changes are not supported for local loopback replication either. MSGQUEUE The name of the message queue that will receive messages generated when a failover occurs. Note that this parameter is valid only for replication groups. Specify the name of a message queue or one of the following values:

*SAMEUses the current setting for this parameter. *NONEIndicates that you do not want to specify a message queue.

The default setting for this parameter is *SAME. The library where the message queue resides must be identified if you do not specify *SAME or *NONE. Prefix the message queue with the name of the library where the queue is located (for example, LIB1/MSGQ1).

ROLESWITCH Indicates whether you want the role of the backup node to automatically change so that it becomes the primary node in the replication group when a failover occurs. This parameter is valid only for replication groups whose target library is *PRIMARY, and to MQSeries groups. The functions of the primary node will be moved to the backup node if this parameter is set to *YES when a failover occurs. Specify one of the following values:

*SAMEUses the current setting for this parameter.

DataMirror, an IBM Company

Printed in Canada

125

*YESAutomatically changes the role of the backup node in the replication group to the primary node when a failover occurs. In this case, user exit programs specified through the BSWUSREXIT and ASWUSREXIT parameters (see below) will be called. *NODoes not automatically change the role of the backup node in the replication group to the primary node when a failover occurs. Setting the ROLESWITCH parameter to *NO gives you the opportunity to decide if you would like to continue with a role switch, or continue with your current configuration.

With this setting, a failure of the group's primary node is declared by the failover mechanism, although iCluster will not prepare the backup node to take over as the primary node. Replication will not start up automatically once the failed primary node is again active in the cluster. When using IBM Cluster Resource Services, only groups whose cluster status is *ACTIVE are switched over if the primary node fails. When IBM Cluster Resource Services are not being used for iCluster operations, all groups that have the ROLESWITCH parameter set to *YES are switched over when the primary node fails, regardless of whether they are active or not. The default setting for this parameter is *SAME. See Switchover for IBM Cluster Resource Services (CRS) on page 341 for more information about the ROLESWITCH parameter.

CHKJRN Specifies whether (when switching to the new primary node) iCluster will check whether the objects for the specified group are being properly journaled on that node, and start journaling them. Certain types of objects must be journaled before replication starts. However, because journaling objects can be time-consuming, this option allows you to specify whether or not journaling should be started for objects during a switchover, depending on your business requirements. Depending on the value of the group's CHKJRN parameter, iCluster may perform processing that is equivalent to the DMMRKPOSMark Current Journal Positions command when a role switch occurs. If the value of the group's CHKJRN parameter is *NO, iCluster will not perform DMMRKPOSMark Current Journal Positions processing and the replication metadata for the new primary node is generated based upon the existing replication metadata on the current backup node. In the case of an error in processing the backup replication metadata, or non-existent backup replication metadata, iCluster performs DMMRKPOSMark Current Journal Positions processing regardless of the CHKJRN parameter's value. The DMMRKPOSMark Current Journal Positions command establishes the set of mirrored objects based on the actual objects that match specifiers on the backup system, regardless if they were previously mirrored or not, and starts journaling for the mirrored objects that should be journaled. If the value of the group's CHKJRN parameter is *YES, iCluster will always perform DMMRKPOSMark Current Journal Positions processing during a role switch, and the backup replication metadata is not used for setting up the replication metadata for the new primary node. You can specify one of the following values:

*SAMEKeeps the present setting for this parameter. *YESSpecifies that iCluster will check if all mirrored objects that should be journaled are being journaled on the new primary node. If not, the objects will be journaled. *NOSpecifies that iCluster will not check if all mirrored objects that should be journaled are journaled on the new primary node. You will need to make sure that all objects that need to be journaled are being journaled to the correct journals, and that the objects have been journaled before replication starts.

The default setting for this parameter is *SAME.

BSWUSREXIT The name of the user exit program that you want to call immediately before the role change is performed. This parameter is valid only for replication groups whose target library is *PRIMARY.

126

Printed in Canada

iClusterVersion 5.1

Group Commands

If you specify a user exit program, the ROLESWITCH parameter (see above) must be set to *YES if you want to call the program when a failover occurs. The specified user exit program will always be invoked (regardless of the ROLESWITCH parameter setting) when a switchover is initiated. Specify the name of a user exit program or one of the following values:

*SAMEUses the current setting for this parameter. *NONEIndicates that you do not want to specify a user exit program.

The default setting for this parameter is *SAME. The library where the user exit program resides must be identified if you do not specify *SAME or *NONE. Prefix the name of the user exit program name with the name of the library where the program is located (for example, LIB1/USREXIT1). See Passing Arguments to Role Switch User Exit Programs on page 347 for more information about the arguments that can be passed to the user exit program.

ASWUSREXIT The name of the user exit program that you want to call immediately after the role change is performed. This parameter is valid only for replication groups whose target library is *PRIMARY. If you specify a user exit program, the ROLESWITCH parameter (see above) must be set to *YES if you want to call the program when a failover occurs. The specified user exit program will always be invoked (regardless of the ROLESWITCH parameter setting) when a switchover is initiated. Specify the name of a user exit program or one of the following values:

*SAMEUses the current setting for this parameter. *NONEIndicates that you do not want to specify a user exit program.

The default setting for this parameter is *SAME. The library where the user exit program resides must be identified if you do not specify *SAME or *NONE. Prefix the name of the user exit program name with the name of the library where the program is located (for example, LIB1/USREXIT1). See Passing Arguments to Role Switch User Exit Programs on page 347 for more information about the arguments that can be passed to the user exit program.

EXITDATA Identifies the user-defined data that you want to pass to the user exit programs specified through the BSWUSREXIT and ASWUSREXIT parameters (see above). This parameter is valid only for replication groups whose target library is *PRIMARY. If you specify two different user exit programs (one program before the role switch, and another program after the role switch), the same user-defined data is passed to both programs. A maximum of 256 bytes of data can be passed to the user exit programs. If your data contains spaces or non-alphanumeric characters (commas, periods, and so on), you must enclose your data in single quotes. Specify user-defined data or the following value:

*SAMEUses the current setting for this parameter.

The default setting for this parameter is *SAME. POLLINT The time interval (expressed in HHMMSS format) that determines how often iCluster should check for content changes to user spaces. Note that this parameter is valid only for replication groups.

DataMirror, an IBM Company

Printed in Canada

127

You set the interval by specifying the number of hours (first two digits), minutes (middle two digits) and the seconds (last two digits) between consecutive polls. The polling interval is only applicable when user spaces (*USRSPC) are selected to the replication group through the DMSELOBJSelect Objects to Group command. Specify a time interval or one of the following values:


Note:

*SAMEUses the current time interval setting. *CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVALSet Cluster System Values command. *NONESpecifies that user spaces should not be polled at the group level.

Not polling user spaces can ease the polling resources on a system that has many user spaces that have not been changed. If *NONE is selected as the polling interval for a *USRSPC object specifier but the group's polling interval is not *NONE, polling will occur for all user spaces selected to the group that do not match the *USRSPC object specifier whose polling interval is *NONE. The default setting for this parameter is *SAME. SAVACT Indicates whether an object can be updated and saved at the same time it is being transferred to the backup node. Note that this parameter does not apply to physical files because they cannot be modified while they are being saved. Note that this parameter is valid only for replication groups. Specify one of the following values:

*SAMEUses the current setting for this parameter. *YESAllows objects that are in use by another job to be saved and updated. Objects may reach checkpoints at different times and may not be in a consistent state in relationship to each other. *NODoes not allow objects that are in use to be saved and updated. Objects cannot be updated while being saved. *SYNCAllows objects that are in use by another job to be saved and updated. All of the objects reach a checkpoint together and are saved in a consistent state in relationship to each other. *CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVALSet Cluster System Values command.

The default setting for this parameter is *SAME. MAXSPLWAIT The time period (expressed in HHMMSS format) you want iCluster to wait before abandoning the replication of a spool file. Note that this parameter is valid only for replication groups. A spool file cannot be replicated unless it has a status of *READY. Therefore, if iCluster is up-to-date with the audit journal, it may start processing a spool file before it is ready. iCluster will only wait the amount of time set in this parameter for the spool file to have a status of *READY. If the spool file is not ready after waiting the time specified in this parameter, iCluster will abandon the replication of this spool file and issue a message in the event log. Specify a waiting period from 000001 to 235959, or one of the following values:


128

*SAMEUses the current setting for this parameter. *CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVALSet Cluster System Values command.

The default setting for this parameter is *SAME. SPLACTWAIT

Printed in Canada

iClusterVersion 5.1

Group Commands

The time period (expressed in HHMMSS format) you want iCluster to wait before abandoning the replication of a spool file if no data is being written to it. Note that this parameter is valid only for replication groups. In some cases, a job may be writing to a spool file. However, the data is first placed in a temporary buffer and only written to the spool file upon the completion of the job. In such a case, the spool file will be open and have zero pages until the job ends. This parameter allows you to specify the time to wait for changes to occur to an open spool file. If no additional data is written to an open spool file (that is, it is open and has zero pages) within the time specified by this parameter, iCluster will abandon the replication of this spool file and issue a message. This parameter provides added flexibility as you can specify a shorter interval over which only spool file activity is monitored. As a result, an open spool file that has no data being written to it will be abandoned quickly, as opposed to waiting the full time specified in the MAXSPLWAIT parameter (see above). Specify a waiting period from 000001 to 235959, or one of the following values:

*SAMEUses the current setting for this parameter. *CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVAL command.

The default setting for this parameter is *SAME. DFTDBJRN The name of the database journal that you want to use as your default. This parameter is valid only for replication groups. The journal that you specify will be used for objects that are to be mirrored but are not yet journaled. Specify the name of the database journal or one of the following values:

*SAMEUses the current setting for this parameter. *CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVALSet Cluster System Values command.

The default setting for this parameter is *SAME. The library where the journal resides must be identified if you do not specify *CLUSTER or *SAME. Prefix the journal with the name of the library where the journal is located (for example, LIB1/JRN1). Note: Note that if this group replicates data from an IASP device, then the journal must exist on the IASP device before the group can start replicating objects. JRNLOC The location of the database journal where scraping will occur. You can specify the following value:

*LOCALIndicates that the database journal(s) on the primary node are scraped during mirroring. *REMOTEIndicates that the remote database journal(s) are scraped on the backup node during mirroring. *SAMEKeeps the present setting for this parameter.

The default setting for this parameter is *SAME. After changing the journal location with this parameter, you must set the position of the local journal to the position of the last applied entry by running the DMSETPOSSet Journal Start Position command with the JRNPOS(*LASTAPY) parameter.

JRNBACKUP Indicates whether replicated physical files, data areas, and data queues will be journaled on backup nodes.

DataMirror, an IBM Company

Printed in Canada

129

Specify one of the following values:

*SAMEKeeps the present setting for this parameter. *CLUSTERIndicates that this parameter uses the system value that is specified through the DMSETSVALSet Cluster System Values command. *YESIndicates that the replicated physical files, data areas, and data queues will be journaled on backup nodes. *NOIndicates that the replicated physical files, data areas, and data queues will not be journaled on backup nodes.

The default setting for this parameter is *SAME. CMTLVL The level of commitment control you want to use when replicating *FILE objects. This parameter is valid only for replication groups. Commitment control stages database transactions so that they are assembled before being applied, or additionally, opened in a commitment control environment to ensure that all updates are received. It also makes sure that the changes are applied in the correct sequence. For more information, see Commitment Control on page 71. Specify one of the following values:

*SAMEUses the current setting for this parameter. *NONEIndicates that the update process on the backup node will not perform commitment control staging. *LEVEL1Indicates that all updates that comprise a transaction are assembled before being applied on the backup node. *LEVEL2Indicates that all updates in a transaction are opened in a commitment control environment to ensure that all updates are received. This option provides true commitment control. *CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVALSet Cluster System Values command.

The default setting for this parameter is *SAME. Note that if you select *LEVEL2 but a file on the backup node cannot be opened under commitment control, *LEVEL1 commitment control will be used for that file.

JRNBA Indicates whether default journaling should include both before and after images. Note that this parameter is valid only for replication groups. Before images are necessary to remove applied or keyed replication updates. Also, if you specified unique index refresh method for a file, then it must be journaled with both before and after images. If a file is replicated using relative record number, it may be journaled with after images only. For unique key updates, both before and after images must be journaled if the CMTLVL parameter (see above) is set to *LEVEL2. Specify one of the following values:


130

*SAMEUses the current setting for this parameter. *BOTHIndicates that you want to journal both the before and after images. *AFTERIndicates that you want to journal the after image only. *CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVALSet Cluster System Values command.

The default setting for this parameter is *SAME. OPTIMZAPY


Printed in Canada

iClusterVersion 5.1

Group Commands

Indicates whether you want to optimize database apply entries. Optimization can increase the apply performance for large files that are significantly larger than the shared memory pool, and have a large number of random updates applied to them. Specify one of the following values:


Note:

*SAMEUses the current setting for this parameter. *NOIndicates that you do not want optimization for database apply updates. *YESIndicates that you want optimization for database apply updates.

The default setting for this parameter is *SAME. DFTBSFJRN The name of the journal that you want to use as your default for journaling BSF files that will be replicated by this group. This parameter only applies to replication groups. If this group replicates data from an IASP device, then the journal must exist on the IASP device before the group can start replicating objects. The journal that you specify will be used for BSF files that are to be mirrored and journaled. See the DFTBSFJRN parameter on the DMADDBSFAdd Path Object Specifier to Group command for more information. Specify the name of the BSF journal or one of the following special values:

*SAMEUses the current setting for this parameter. *NONEIndicates that you do not require journaling for BSF replication. *CLUSTERBSF objects selected to this group will use the journal specified at the product level. See the DMSETSVALSet Cluster System Values command for more information.

The default setting for this parameter is *CLUSTER. The library where the journal resides must be identified if you do not specify *NONE or *CLUSTER. Prefix the journal with the name of the library where the journal is located (for example, LIB2/JRN2). Note: Note that If this group replicates data from an IASP device, then the journal must exist on the IASP device before the group can start replicating objects. RCVRYEXP Specifies the number of journal entries applied between writing recovery checkpoints. Specifying a lower number decreases the performance of the apply but provides a greater safeguard in recovery situations. Specifying a higher number lessens the impact of recovery checkpoints on the apply. Note: This parameter only applies to replication groups. Enter a recovery exposure value (number of journal entries) or one of the following values:

*SAMEUses the current setting for this parameter. *DISABLEDIndicates that recovery checkpoints will not be generated.

The default setting for this parameter is *SAME. JRNKEY Specifies the key, or the identifier, that will be assigned to a recovery checkpoint for the group combination. This value must be specified for the RTVRCVPTRetrieve Recovery Checkpoint or RTVRCVPTRRetrieve Recovery Checkpoint (CL Program) command. Note: This parameter only applies to replication groups. Specify the key or the following value:

*SAMEUses the current setting for this parameter.

DataMirror, an IBM Company

Printed in Canada

131

The default setting for this parameter is *SAME.

LCKBACKUP Indicates whether journaled files should be locked on the backup node. When locked, no other users can modify these files on the backup node. Specify one of the following values:

*SAMEKeeps the present setting for this parameter. *CLUSTERIndicates that this parameter uses the system value that is specified through the DMSETSVALSet Cluster System Values command. *YESIndicates that files cannot be modified on the backup node when the group is active. *NOIndicates that files will not be locked when the group is active, meaning that users can modify these files on the backup node.

The default setting for this parameter is *SAME. CFGSRCHLD Indicates whether you want iCluster to automatically create configuration objects immediately after they are received on a backup node or hold the commands for creating them in specific physical files so that they can be created at a later time with the CRTCFGOBJ command. If configuration objects that are being replicated already exist on backup nodes, this parameter should be set to *YES in order to prevent iCluster from trying to create objects when they are in use. Specify one of the following values:

*SAMEKeeps the present setting for this parameter. *BACKUPIndicates that this parameter uses the Hold configuration object source setting on the backup node of the group that is specified through the DMADDNODEAdd Node command. *CLUSTERRefers to the system value for this parameter that is specified through the DMSETSVALSet Cluster System Values command. *YESHolds commands to create configuration objects in specific physical files so that they can be created at a later time with the CRTCFGOBJ command. *NOAutomatically creates configuration objects as soon as they are received on the node.

The default setting for this parameter is *SAME. CRWNR Indicates the group-level rules by which iCluster will resolve conflicts for the objects selected to a *MSTRMSTR replication group. Specify one of the following values:

*SAMEUses the current setting for this parameter. *SRCIndicates that the source wins if there is a conflict. Source data is applied to the target, which ensures that target data matches source data and mirroring continues. *TGTIndicates that the target wins if there is a conflict. iCluster does not apply data to the target. This rule preserves data on the target and mirroring continues. *EXITIndicates that you would like to resolve data conflicts through a user exit program. With this option, you must specify a user exit program and library in the CRUSREXIT parameter below. *NONEIndicates that you do not want to enable conflict detection and resolution rules. If there is a conflict, iCluster suspends the file from replication and sends a message to the event log. This is the default behavior for iCluster.

132

Printed in Canada

iClusterVersion 5.1

Group Commands

The default setting for this parameter is *SAME. Note: This parameter only applies to iBalance and *MSTRMSTR replication groups. See iBalance and MasterMaster Replication on page 321 for more information on this feature. CRUSREXIT The name of the user exit program that you want to call to resolve data conflicts. A user exit program allows you to define a conflict resolution strategy that is not covered by one of the standard resolution methods in the CRWNR parameter. Specify the name of a user exit program or one of the following values:

*SAMEUses the current setting for this parameter. *NONEIndicates that you do not want to specify a user exit program.

The library where the user exit program resides must be identified if you do not specify *NONE. Prefix the name of the user exit program name with the name of the library where the program is located (for example, LIB1/USREXIT1). See Parameter List Descriptions for a Conflict Resolution User Exit Program on page 326 for more information about the values you can pass to the user exit program. The default setting for this parameter is *SAME. You cannot specify *NONE for this parameter if you specify *EXIT for the CRWNR parameter. Note: This parameter only applies to iBalance and *MSTRMSTR replication groups. See iBalance and MasterMaster Replication on page 321 for more information on this feature. DESC A short description that allows you to identify this group among all others that have been defined in iCluster. The description can be a maximum of 50 characters long. Specify a description or the following value:

Example

*SAMEUses the current setting for this parameter.

The default setting for this parameter is *SAME.

DMCHGGRP GROUP(GRP1) TGTLIB(TGT1) MSGQUEUE(LIB1/MSGQ1) ROLESWITCH(*YES) BSWUSREXIT(*NONE) ASWUSREXIT(LIB1/AFEXIT) EXITDATA('ARJ 123908 KPJ 230982') POLLINT(*SAME) SAVACT(*SYNC) MAXSPLWAIT(000500) SPLACTWAIT(*CLUSTER) DFTDBJRN(LIB1/JRN1) JRNLOC(*LOCAL) CMTLVL(*NONE) JRNBA(*AFTER) OPTIMZAPY(*YES) RCVRYEXP(5000) JRNKEY(MYGROUP) DESC('LON/PAR') Changes will be made to one or more attributes of the replication group GRP1. TGT1 is the name of the library on the backup system that will receive the replicated objects. Messages generated when a failover occurs will be added to the message queue MSGQ1 in library LIB1. The backup node in the replication group will become the primary node if a failover occurs. The user exit program specified through the ASWUSREXIT parameter will be called. No user exit program will be called immediately before a role change is performed. The user exit program AFEXIT in library LIB1 will be called immediately after a role change is performed. User-defined data consisting of a sequence of characters will be passed to the user exit program. Note that single quotes are required to enclose data that includes spaces and other non-alphanumeric characters. The polling interval for user spaces selected for replication within the group is the current setting. Objects can be updated and saved when they are being replicated within the group. All of the objects will reach a checkpoint together and will be saved in a consistent state in relationship to each other. iCluster will wait a maximum of five minutes for a spool file to have a status of *READY before abandoning the replication of a spool file.

DataMirror, an IBM Company

Printed in Canada

133

iCluster will reference the corresponding cluster system value to determine how long to wait for changes to occur to an open spool file before abandoning the replication of a spool file. The default database journal will be JRN1 in library LIB1. The journal location is set to *LOCAL. Journal scraping will occur on the group's primary node. Changes will be applied with no commitment control. Only after images will be journaled. iCluster will optimize database apply entries. There will be 5000 journal entries applied between recovery checkpoints. MYGROUP is assigned to a recovery checkpoint for the group combination. The description associated with the replication group indicates that the nodes are located in London and Paris. DMCHGGRP GROUP(GRP2) GRPTYPE(*RFSH) Changes the replication group GRP2 to a refresh-only group. Use You must issue this command from an active node, and the specified replication group must be inactive. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 7 Work With Groups screen - Option 2

DMRMVGROUPRemove Group
DMRMVGRP GROUP( ) Use this command to remove a replication group that was previously defined. A reference cannot be made to the group after it has been removed. If the group is active, group operations are automatically stopped before the group is removed. Input Parameter

GROUP The name of the existing group that you want to remove.

Example DMRMVGRP GROUP(GRP1) Removes the replication group GRP1. Use You must issue this command on an active node in the cluster. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 8

134

Printed in Canada

iClusterVersion 5.1

Group Commands

Work With Groups screen - Option 6

DMADDBACKAdd Backup Node to Recovery Domain


DMADDBACK NAME( ) NODE( ) BACKIASP( ) Use this command to add a backup node to the recovery domain for an existing group or resilient application. You can add only a single backup node through this command. The recovery domain for the group or resilient application must already have a defined primary node. You can only add a backup node to the recovery domain for inactive groups or resilient applications that are not currently running. You must add a backup node to the recovery domain before replication can be started for a group or resilient application. Input Parameters

NAME The name of the group or resilient application that will have a backup node added to its recovery domain. NODE The name of the node in the cluster that will be added to the recovery domain for the specified group or resilient application. You must specify a node that has been added to the cluster. For an *SWDEV group, the node must have switchable disk storage devices enabled (SWITCHRES parameter). See the DMADDNODEAdd Node command for more information.

BACKIASP The name of the independent auxiliary storage pool (IASP) on the backup node to which you want to replicate. Specify the name of an existing IASP or the following value:

Example

*SYSBASIndicates that you are using a system ASP rather than an independent ASP for storing the objects that will be replicated.

The default setting for this parameter is *SYSBAS.

DMADDBACK NAME(GRP1) NODE(NODE1) BACKIASP(DMC_3) Adds the backup node NODE1 to group GRP1. The name of the IASP on the backup node is DMC_3. Use You must issue this command on an active node in the cluster. The specified node must also be active. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 9 or Option 27 Accessible from the Work With Groups screen (Option 22) and the Work With Resilient Applications screen (Option 22).

DMRMVBACKRemove Backup Node from Recovery Domain


DMRMVBACK NAME( ) NODE( ) Use this command to remove the backup node from the recovery domain for an existing group or resilient application.

DataMirror, an IBM Company

Printed in Canada

135

Note that you can remove a backup node only using this command. The recovery domain for the group or resilient application must already have defined primary and backup nodes. You can remove backup nodes only from recovery domains for inactive groups or resilient applications that are not currently running. Input Parameters

NAME The name of the group or resilient application that will have a backup node removed from the recovery domain. NODE The name of the backup node in the cluster that will be removed from the recovery domain for the specified group or resilient application.

Example DMRMVBACK NAME(GRP1) NODE(NODE1) Removes the backup node NODE1 from group GRP1. Use You must issue this command on an active node in the cluster. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 10 or Option 28 Accessible from the Work With Groups screen (Option 23) and the Work With Resilient Applications screen (Option 23).

DMCHGROLEChange Group Primary Node


DMCHGROLE GROUP( ) PRIMNODE( ) This command changes the specified groups' or resilient applications' primary node to the current first backup node. The groups or resilient applications will remain *INACTIVE until they are started with the DMSTRGRP or DMSTRAPP commands. The current backup is prepared to become the primary node in the same way as occurs if a failover happens when the group is active. Note: Note: A message (CSI1314) stating whether or not the role switch completed successfully is placed into the event log on all nodes of the cluster. For more information about event logs, see Monitoring Replication on page 76. This command supports spooled file replication on the primary and backup node(s) as of i5/OS V5R4.

Input Parameter

GROUP The name of the group or resilient application. If you specify a group or resilient application, the group (or groups of the resilient application) has to be in *INACTIVE status. Specify the name of the group or resilent application or one of the following values:


136

*ALLPerforms a role switch for all groups and resilient applications in the cluster. Changes the primary node of all groups and resilient applications in the cluster to the current first backup node. *PRIMNODEPerforms a role switch for all groups and resilient applications whose primary node is specified on the PRIMNODE parameter. If you specify this option, you must specify the name of the primary node in the PRIMNODE parameter (see below).

PRIMNODE

Printed in Canada

iClusterVersion 5.1

Group Commands

Indicates the name of the primary node of the groups and resilient applications for which you are performing a role switch. This parameter is only applicable when the GROUP parameter (see above) is set to *PRIMNODE. Examples DMCHGROLE GROUP(GROUP1) Changes the primary node to the backup node and the backup node to the primary node. The group or resilient application must have a status of *INACTIVE. DMCHGROLE GROUP(*ALL) Changes the primary node to the backup node and the backup node to the primary node for all groups and resilient applications in the cluster. The groups or resilient applications must have a status of *INACTIVE. Use You can invoke the DMCHGROLE command on an active node in the cluster for groups or applications in *INACTIVE status. Minimum Security Leve Admin (*ADMIN) Menu Access F22 (Shift+F10) - Option 51 Work With Groups screen - Option 20 Work With Resilient Applications screen - Option 20

DMWRKGRPWork with Groups


DMWRKGRP BY( ) NODE( ) APPL( ) Use this command to list the groups that have been defined. The BY, NODE, and APPL parameters allow you to filter the list by displaying the groups that contain a specific node or are associated with a specific resilient application. The cluster status of each group is indicated on the displayed screen, and can be one of the following:

*ACTIVEIndicates that low-level cluster support within the group is running. *INACTIVEIndicates that low-level cluster support within the group is not running. *INIT_PENDIndicates that the group is in the process of being defined in iCluster. *ADDN_PENDIndicates that a node is in the process of being added to the group. *RMVN_PENDIndicates that a node is in the process of being removed from the group. *DLT_PENDIndicates that the group is in the process of being removed from iCluster. *STRT_PENDIndicates that low-level cluster operations are in the process of being started. *END_PENDIndicates that low-level cluster operations are in the process of being stopped. *SWO_PENDIndicates that a role switch is being performed within the group. *RESTOREDIndicates that the replication group object (*CRG) has been restored to a system (a *CRG object identifies all of the nodes contained in the group). *CHG_PENDIndicates that the replication group object (*CRG) for the group is in the process of being changed. *DLTCMD_PNIndicates that the replication group object (*CRG) for the group is in the process of being deleted by the OS/400 command DLTCRG. *INDOUBTIndicates that the status of the group cannot be determined.

DataMirror, an IBM Company

Printed in Canada

137

*IN_ERRORIndicates that an internal iCluster error may have occurred. If this state persists, contact DataMirror Technical Support. See Contacting Technical Support on page 547 for more information. *UNKNOWNIndicates that the group is not recognized in iCluster. In addition, the replication status that is currently assigned to the replication group is displayed, and can be one of the following: *ACTIVEIndicates that iCluster replication is currently being performed within the replication group. *INACTIVEIndicates that iCluster replication is not currently being performed within the replication group. *INDOUBTIndicates that some, but not all of the replication groups are running. *IN_ERRORIndicates that an internal iCluster error may have occurred. If this state persists, contact DataMirror Technical Support. See Contacting Technical Support on page 547 for more information. *UNKNOWNIndicates that the replication status of the replication group cannot be determined. This status may arise if the primary node in the group is currently inactive or if there is no backup node in the group. *SWOSTARTIndicates that iCluster is starting switchover processing. *BEFUEXITIndicates that iCluster is executing the before roleswitch user exit. *STSDRAINIndicates that iCluster is draining the staging store. *STRJRNIndicates that iCluster is starting journaling on the journaled objects in replication scope. *TRIGGERSIndicates that triggers are being enabled on the new primary machine. *CONSTRIndicates that iCluster is enabling the referential integrity constrains on the new primary machine. *CHGROLESIndicates that iCluster is changing the roles of the primary and backup nodes. *MRKPOSIndicates that iCluster is marking the starting position for mirroring on the new primary node. *AFTUEXITIndicates that iCluster is executing the after roleswitch user exit.

Input Parameters BY The set of groups that are listed by this command. Specify one of the following values:

*NONELists all groups defined in iCluster. *NODELists the groups that contain the node specified through the NODE parameter (see below). *APPLLists the groups that are associated with the resilient application identified through the APPL parameter (see below).

The default setting for this parameter is *NONE. NODE The name of an existing node in the cluster. Groups that contain the specified node are listed. This parameter is only applicable when the BY parameter (see above) is set to *NODE. APPL The name of an existing resilient application. Groups associated with the identified application are listed. This parameter is only applicable when the BY parameter (see above) is set to *APPL. Examples DMWRKGRP BY(*NONE) Lists all groups. DMWRKGRP BY(*NODE) NODE(NODE1)

138

Printed in Canada

iClusterVersion 5.1

Group Commands

Lists all groups that contain the node NODE1. DMWRKGRP BY(*APPL) APPL(OEPACK) Lists all groups that are associated with the resilient application OEPACK. Use You must issue this command on an active node in the cluster. Minimum Security Level User (*USER) Menu Access Main Menu - Option 2 F22 (Shift+F10) - Option 12

DataMirror, an IBM Company

Printed in Canada

139

140

Printed in Canada

iClusterVersion 5.1

Native AS/400 Object Commands

Native AS/400 Object Commands


This section contains the following commands:

DMSELOBJSelect Objects to Group on page 141 DMCHGOBJSLChange Object Selection to Group on page 147 DMDSELOBJDe-select Objects from Group on page 151 DMWRKOBJWork with Object Specifiers on page 152

DMSELOBJSelect Objects to Group


DMSELOBJ GROUP( ) OBJ( ) OBJTYPE( ) OBJATTR( ) TGTLIB( ) DESC( ) INCFLG( ) POLLINT( ) NEWOBJACT( ) TRUNCATE( ) REPLACELFS( ) MIRRCNTS( ) PFUPDMTD( ) PFKEY( ) CRWNR( ) CRUSREXIT( ) Use this command to select an object specifier to the replication group identified through the first parameter. The objects referenced by selected specifiers are replicated from the primary node to the backup node in the replication group. Through the use of generic names, you can select any number of object specifiers to a replication group. You must define the replication group in iCluster before selecting object specifiers to the replication group. Note: Note: This command can be issued when adding new object specifiers for active replication groups. See the NEWOBJACT parameter in this command for more information. If you decide to synchronize objects on the primary and backup nodes through a save file or tape transfer, it is important that you select the object specifiers referencing these objects before saving the objects. This ensures that changes to the objects will be audited between the time of the save and the time when replication is started.

Using this command you can create object specifiers and indicate the specific target library where the objects that match the object specifier should be replicated. Target library support at the group level is a requirement for local loopback replication. Input Parameters

GROUP The name of the defined replication group that will have objects selected to it. OBJ The object name component of the specifier that you want to select. Enter a specific or generic name (to identify multiple objects in a library), or the following value:

*ALLSpecifies all objects in a library.

The library where the objects reside must be identified. Prefix the object specification with the name of the library where the objects are located (for example, LIB1/OBJ1). OBJTYPE The object type component of the specifier that you want to select. Specify an object type or the following value:

*ALLSpecifies all object types.

For a complete list of all object types that iCluster can replicate, see Object Types Replicated by iCluster on page 529. OBJATTR The attribute component of the specifier you want to select. This parameter is only applicable when the OBJTYPE parameter (see above) is set to *FILE.

DataMirror, an IBM Company

Printed in Canada

141

This field is free-form. Consequently, you can enter any value you want to describe the object, as long as the value conforms to OS/400 naming conventions. However, there are values that have special meaning to iCluster. They are PFSRC (source physical file), PFDTA (data physical file), and PF (any physical file). Other values listed are standard OS/400 file sub-types. If PF is used, the object specifier will match either PFSRC or PFDTA files. Press F4 for a list of values or enter the following value:

*ALLSpecifies all object attributes. *ALL is not a valid OS/400 object attribute but allows iCluster to gather all objects regardless of their attribute.

The default setting for this parameter is *ALL. TGTLIB The name of the library on the backup system that will receive the replicated objects. Specify the name of a target library or one of the following values:

*GROUPSpecifies the same target library as specified in the DMADDGRPAdd Group or DMCHGGRP Change Group commands. This is the default setting for this parameter. *PRIMARYSets the target library so that it is the same as the library where the object resides on the primary node.

If the primary and backup environments reside on the same physical system (local loopback implementation), the target library that you specify cannot be the same library where a selected object in the group currently resides. This restriction means that iCluster does not permit the special value *PRIMARY in this situation. Note: Switchovers and role changes are not supported for groups that have objects selected to them that have a target library other than *GROUP or *PRIMARY. Also, because a non-primary target library is required for local loopback replication, switchovers and role changes are not supported for local loopback replication either. DESC A short description that allows you to identify this object specifier selection amongst all others that have been defined in iCluster. The description can be a maximum of 50 characters long.

INCFLG Indicates whether the objects referenced by the specifier will be replicated within the replication group. Specifying *INCLUDE means that the referenced objects will be replicated to a backup environment when object replication is started. Specifying *EXCLUDE prevents the referenced objects from being replicated to a backup environment.

Note:

If the specifier is being added to an active group, only *INCLUDE may be specified. For the rules of precedence for object specifiers, see Object Specifiers and Types on page 50 for more information. Specify one of the following values:

*INCLUDESpecifies that the referenced objects will be replicated within the replication group when cluster operations are started. *EXCLUDESpecifies that the referenced objects will not be replicated within the replication group when cluster operations are started.

The default setting for this parameter is *INCLUDE. POLLINT The time interval (expressed in HHMMSS format) that determines how often iCluster should check for content changes to user spaces.

142

Printed in Canada

iClusterVersion 5.1

Native AS/400 Object Commands

You set the interval by specifying the number of hours (first two digits), minutes (middle two digits) and the seconds (last two digits) between consecutive polls. The polling interval is only applicable when the object type is set to *USRSPC (user space). Specify a time interval or one of the following values:


Note:

*GROUPRefers to the replication group value for this parameter that is specified when adding or changing a replication group. See DMADDGRPAdd Group and DMCHGGRPChange Group for more information about these two commands. *CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVALSet Cluster System Values command. *NONESpecifies that user spaces should not be polled at the object specifier level.

Not polling user spaces can ease the polling resources on a system that has many user spaces that have not been changed. If *NONE is selected as the polling interval for a *USRSPC object specifier but the group's polling interval is not *NONE, polling will occur for all user spaces selected to the group that do not match the *USRSPC object specifier whose polling interval is *NONE. The default setting for this parameter is *GROUP. NEWOBJACT Indicates the method by which replication is to begin for the objects that come into replication scope when an object specifier is added. Specify one of the following values:

*NONEThis value does not change the replication status of new, in-scope objects, and is intended to support initial group configuration. If this value is selected, mirroring must be started with a refresh of the entire group, or with the DMMRKPOSMark Current Journal Positions or DMREGPOSRegister Positions commands. The group's replication status cannot be *ACTIVE if you use this value. *CURRENTReplication of journal entries for new, in-scope objects will begin at the time the object specifier is added. Journal entries related to newly in-scope objects created after that time will be replicated. Journal entries related to new, in-scope objects created before that time will not be replicated. The group's replication status must be *ACTIVE for this option to take effect. If this value is selected, no changes should occur on the new, in-scope objects until the OMI0320 event for the object specifier appears in the event log.

*REFRESHNewly in-scope objects will be refreshed one at a time. Replication of journal entries for new, in-scope objects begins for each object as it is refreshed. The group's replication status must be *ACTIVE for this option to take effect.

The default setting for this parameter is *NONE.

TRUNCATE Indicates whether you want to remove existing data before performing a refresh. Specify one of the following values:

*YESIndicates that you want to remove and recreate existing data files as part of a refresh. This is the default behavior for iCluster and is appropriate for standard iCluster replication. You can use this option for a mastermaster group if the data on the source system is known to be complete in order to ensure a synchronized starting point. With this value, logical files are replaced automatically because the deletion of a physical file requires the deletion of all logical files upon which it is based.

*NOIndicates that you do not want to remove existing data before performing a refresh. This option is appropriate for master-master replication.

DataMirror, an IBM Company

Printed in Canada

143

The default setting for this parameter is *NO. See Master-Master ReplicationOperations and Monitoring on page 323 for more information on the refresh options that are specific to master-master replication groups. Note: This parameter is only available with iBalance. See iBalance and Master-Master Replication on page 321 for more information on this feature. REPLACELFS Indicates whether you want to replace logical files during a refresh. Specify one of the following values:


Note:

*YESIndicates that you want to replace logical files during a refresh. This is the default behavior for iCluster and is appropriate for standard replication. You can use this option for a master-master group if the logical files on the source system are the complete set required for your applications in order to ensure a synchronized starting point. *NOIndicates that you want to use existing logical files during a refresh. This option is appropriate for mastermaster replication.

iCluster does not require logical files based on the replicated physical file to be the same on source and target systems if they are not in replication scope. The default setting for this parameter is *NO. See Master-Master ReplicationOperations and Monitoring on page 323 for more information on the refresh options that are specific to master-master replication groups.

Note:

This parameter is only available with iBalance. See iBalance and Master-Master Replication on page 321 for more information on this feature. MIRRCNTS Indicates whether or not the contents of the object are mirrored. This parameter allows you to mirror object-level operations such as CREATE, DELETE, RENAME, and MOVE, but not the contents of the object. You can only use this parameter with the following type and attribute combinations:


Note:

OBJTYPE parameter is *DTAQ OBJTYPE parameter is *DTAARA OBJTYPE parameter is *FILE and OBJATTR parameter is PFDTA *YESIndicates the contents of the object are refreshed and mirrored. *NOIndicates the contents of objects are not refreshed or mirrored. Refresh creates an empty object at target, and only the object-level operations such as CREATE, DELETE, RENAME, and MOVE are mirrored.

Specify one of the following values:

The default setting for this parameter is *YES. *FILEATTR and *DTAARA sync checks will not report object contents mismatches if you decide not to refresh or mirror the object contents with MIRRCNTS(*NO). See STRHASCStart Sync Check on page 267 for more information on starting a sync check. PFUPDMTD The method to update physical data files. This parameter is applicable when *FILE object types with an attribute of PFDTA are selected, and when the INCFLG parameter (see above) is set to *INCLUDE. You must specify the update method, either by relative record number or by unique key. Relative record number specifies the location of a record in relation to the beginning of a file.

144

Printed in Canada

iClusterVersion 5.1

Native AS/400 Object Commands

Unique key specifies a unique index used to update a file. It allows you to perform reorganizations of physical files at different times on the primary node and the backup node. This option requires that both before and after images are journaled on the backup node because before images are required to remove applied or keyed replication updates. Also, if updating multi-member files, the members of the unique index must have the same name as the members of the physical file. Specify one of the following values:

*RRNIndicates an update by relative record number. *UKEYIndicates an update by unique index. If you are updating by unique index, you then need to specify the name of the unique index (logical file) in the PFKEY parameter (see below). If a unique index cannot be specified, then you must choose update by relative record number.

The default setting for this parameter is *RRN. Note: You cannot change the replication method in an object specifier for a *FILE object from *RRN to *UKEY or vice-versa. PFKEY Indicates a physical file's unique key. An object name and library defines which file to use as the physical file's unique key. This parameter is available only if the PFUPDMTD parameter (see above) is set to *UKEY and the INCFLG parameter (see above) is set to *INCLUDE. It must be specified when the update method is by unique key. The object specifier must identify a unique index for the file. You can specify the unique key and its library or the following value:

Note:

*AUTOIndicates that you want iCluster to automatically determine a unique key for every physical file being replicated by the object specifier.

If the unique key cannot be found on the target, iCluster suspends the physical file on the target with the UKM suspension code. You must identify the unique key and its library if you do not specify *AUTO. Prefix the physical file key with the name of the library where the key is located (for example, LIB1/OBJ1).

CRWNR Indicates the object-level rules by which iCluster will resolve conflicts for the objects selected to a *MSTRMSTR replication group. Specify one of the following values:

*GROUPIndicates that the object specifier inherits conflict resolution rules and the user exit program configured at the group-level. *SRCIndicates that the source wins if there is a conflict. Source data is applied to the target, which ensures that target data matches source data and mirroring continues. *TGTIndicates that the target wins if there is a conflict. iCluster does not apply data to the target. This rule preserves data on the target and mirroring continues. *EXITIndicates that you would like to resolve data conflicts through a user exit program. With this option, you must specify a user exit program and library in the CRUSREXIT parameter below. *NONEIndicates that you do not want to enable conflict detection and resolution rules. If there is a conflict, iCluster suspends the file from replication and sends a message to the event log. This is the default behavior for iCluster.

The default setting for this parameter is *NONE. Note: This parameter only applies to iBalance and *MSTRMSTR replication groups. See iBalance and MasterMaster Replication on page 321 for more information on this feature.

DataMirror, an IBM Company

Printed in Canada

145

CRUSREXIT The name of the user exit program that you want to call to resolve data conflicts. A user exit program allows you to define a conflict resolution strategy that is not covered by one of the standard resolution methods in the CRWNR parameter. Specify the name of a user exit program or the following value:

*NONEIndicates that you do not want to specify a user exit program.

The library where the user exit program resides must be identified if you do not specify *NONE. Prefix the name of the user exit program name with the name of the library where the program is located (for example, LIB1/USREXIT1). See Parameter List Descriptions for a Conflict Resolution User Exit Program on page 326 for more information about the values you can pass to the user exit program. The default setting for this parameter is *NONE. You cannot specify *NONE for this parameter if you specify *EXIT for the CRWNR parameter. Note: This parameter only applies to iBalance and *MSTRMSTR replication groups. See iBalance and MasterMaster Replication on page 321 for more information on this feature.

Examples DMSELOBJ GROUP(GRP1) OBJ(LIB1/OBJ1) OBJTYPE(*JOBD) DESC('Job Description OBJ1 in LIB1') INCFLG(*INCLUDE) NEWOBJACT (*CURRENT) Selects the object OBJ1 in library LIB1 that has an object type of *JOBD (job description). Provides a description to be associated with the object selection. The object specifier will be replicated in the replication group GRP1 when cluster operations are started. Replication of journal entries for new, in-scope objects will begin at the time the object specifier is added, provided that the group is currently active. DMSELOBJ GROUP(GRP2) OBJ(LIB2/OBJ*) OBJTYPE(*USRSPC) TGTLIB(*GROUP) INCFLG(*EXCLUDE) Selects the individual objects in library LIB2 that have names which start with OBJ (for example, OBJ2, OBJTEST, and so on) and an object type of *USRSPC (user spaces). The objects referenced by the specifier will be selected to the replication group GRP2. The target library is the same as specified in the DMADDGRPAdd Group or DMCHGGRPChange Group commands. The referenced objects will not be replicated within the replication group when cluster operations are started. DMSELOBJ GROUP(GRP3) OBJ(LIB3/OBJ3) OBJTYPE(*FILE) OBJATTR(PFDTA) TGTLIB(*PRIMARY) INCFLG(*INCLUDE) PFUPDMTD(*UKEY) PFKEY(LIB3/KEY3) Selects the object OBJ3 in the library LIB3 that has an object type of *FILE and attribute of PFDTA. The object referenced by the specifier will be replicated in the replication group GRP3 when cluster operations are started. The target library is set to *PRIMARY so that it is the same as the primary node library where the object resides. The physical file will be updated by unique key using KEY3 in library LIB3. UseYou must issue this command on an active node in the cluster. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 13 Work With Object Specifier screen - F6

146

Printed in Canada

iClusterVersion 5.1

Native AS/400 Object Commands

DMCHGOBJSLChange Object Selection to Group


DMCHGOBJSL GROUP( ) OBJ( ) OBJTYPE( ) OBJATTR( ) TGTLIB( ) DESC( ) POLLINT( ) MIRRCNTS( ) PFUPDMTD( ) PFKEY( ) CRWNR( ) CRUSREXIT( ) Use this command to change specific attributes of an object specifier selected to a replication group. Through this command, you can change the description currently associated with the object specifier (DESC) and modify the flag that determines whether the referenced objects are replicated within the group (INCFLG). In addition, the polling interval for user spaces can be changed (POLLINT), and the target library (TGTLIB) can be changed. Input Parameters

GROUP The name of the defined replication group that will be affected by the change to the object specifier. OBJ The object name component of the specifier that you want to change. Note that you cannot change the object name component through this command. It must be identified in order to change the other parameters that can be modified by this command. Enter a specific or generic name (to identify multiple objects in a library), or the following value:

*ALLSpecifies all objects in a library.

The library where the objects reside must be identified. Prefix the object specifier with the name of the library where the objects are located (for example, LIB1/OBJ1). OBJTYPE The object type component of the object specifier that you want to change. Note that you cannot change the object type component through this command. It must be identified in order to change the other parameters that can be modified by this command. Specify an object type or the following value:

*ALLSpecifies all object types.

For a complete list of all object types that iCluster can replicate, see Object Types Replicated by iCluster on page 529. OBJATTR The attribute component of the specifier you want to select. This parameter is only applicable when the OBJTYPE parameter (see above) is set to *FILE. Note that you cannot change the object attribute component through this command. It must be identified in order to change the other parameters that can be modified by this command. Press F4 for a list of values or enter the following value:

*ALLSpecifies all object attributes. *ALL is not a valid system attribute but allows iCluster to gather all objects regardless of their attribute.

The default setting for this parameter is *ALL. TGTLIB The name of the library on the backup system that will receive the replicated objects. Specify the name of a target library or one of the following values:

*SAMEKeeps the present setting for this parameter. This is the default value. *PRIMARYSets the target library so that it is the same as the library where the object resides on the primary node.

DataMirror, an IBM Company

Printed in Canada

147

If the primary and backup environments reside on the same physical system (local loopback implementation), the target library that you specify cannot be the same library where a selected object in the group currently resides. This restriction means that iCluster does not permit the special value *PRIMARY in this situation.

Note:

*GROUPSpecifies the same target library as specified in the DMADDGRPAdd Group or DMCHGGRP Change Group commands.

Switchovers and role changes are not supported for groups that have objects selected to them that have a target library other than *GROUP or *PRIMARY. Also, because a non-primary target library is required for local loopback replication, switchovers and role changes are not supported for local loopback replication either. DESC The short description that you want to use to identify this object specifier selection amongst all others that have been defined in iCluster. The description can be a maximum of 50 characters long. Specify a short description or the following value:

*SAMEUses the description that is currently associated with the object specifier selection to the replication group. INCFLG

The default setting for this parameter is *SAME. Indicates whether the objects referenced by the specifier will be replicated within the group. Specifying *INCLUDE means that the referenced objects will be replicated to a backup environment when object replication is started. Specifying *EXCLUDE prevents the referenced objects from being replicated to a backup environment. For the rules of precedence for object specifiers, see Object Specifiers and Types on page 50 for more information. Specify one of the following values:


Note:

*SAMEUses the current setting for this parameter. *INCLUDEIndicates that the referenced objects will be replicated within the replication group when cluster operations are started. *EXCLUDEIndicates that the referenced objects will not be replicated within the replication group when cluster operations are started.

The default setting for this parameter is *SAME. If you change this parameter from *EXCLUDE to *INCLUDE for an existing object specifier, you must issue the INITHAOBJInitialize Objects command. POLLINT The time interval (expressed in HHMMSS format) that determines how often iCluster should check for content changes to user spaces. You set the interval by specifying the number of hours (first two digits), minutes (middle two digits), and the seconds (last two digits) between consecutive polls. The polling interval is only applicable when the object type is set to *USRSPC (user space). Specify a time interval or one of the following values:

*SAMEUses the current polling interval setting. *GROUPRefers to the replication group value for this parameter that is specified when adding or changing a replication group. See DMADDGRPAdd Group and DMCHGGRPChange Group respectively for more information.

148

Printed in Canada

iClusterVersion 5.1

Native AS/400 Object Commands


Note:

*CLUSTERRefers to the cluster system value for this parameter that is specified through the DMSETSVALSet Cluster System Values command. *NONESpecifies that user spaces should not be polled at the object specifier level.

Not polling user spaces can ease the polling resources on a system that has many user spaces that have not been changed. If *NONE is selected as the polling interval for a *USRSPC object specifier but the group's polling interval is not *NONE, polling will occur for all user spaces selected to the group that do not match the *USRSPC object specifier whose polling interval is *NONE. The default setting for this parameter is *SAME. MIRRCNTS Indicates whether or not the contents of the object are mirrored. This parameter allows you to mirror object-level operations such as CREATE, DELETE, RENAME, and MOVE, but not the contents of the object. You can only use this parameter with the following type and attribute combinations:

OBJTYPE parameter is *DTAQ OBJTYPE parameter is *DTAARA OBJTYPE parameter is *FILE and OBJATTR parameter is PFDTA *SAMEUses the current setting for this parameter. *YESIndicates the contents of the object are refreshed and mirrored. *NOIndicates the contents of objects are not refreshed or mirrored. Refresh creates an empty object at target, and only the object-level operations such as CREATE, DELETE, RENAME, and MOVE are mirrored.

Specify one of the following values:

The default setting for this parameter is *YES. *FILEATTR and *DTAARA sync checks will not report object contents mismatches if you decide not to refresh or mirror the object contents with MIRRCNTS(*NO). See STRHASCStart Sync Check on page 267 for more information on starting a sync check.

PFUPDMTD The method to update physical data files. This parameter is applicable when *FILE object types with an attribute of PFDTA are selected, and when the INCFLG parameter (see above) is set to *INCLUDE. You must specify the update method, either by relative record number or by unique key. Relative record number specifies the location of a record in relation to the beginning of a file. Unique key specifies a unique index used to update a file. It allows you to perform reorganizations of physical files at different times on the primary node and the backup node. This option requires that both before and after images are journaled on the backup node because before images are required to remove applied or keyed replication updates. Also, if updating multi-member files, the members of the unique index must have the same name as the members of the physical file. Specify one of the following values:

*SAMEUses the current setting for this parameter. *RRNIndicates an update by relative record number. *UKEYIndicates an update by unique index. If you are updating by unique index, you then need to specify the name of the unique index (logical file) in the PFKEY parameter (see below). If a unique index cannot be specified, then you must choose update by relative record number.

DataMirror, an IBM Company

Printed in Canada

149

The default setting for this parameter is *SAME. Note: You cannot change the replication method in an object specifier for a *FILE object from *RRN to *UKEY or vice-versa. PFKEY Indicates a physical file's unique key. An object name and library defines which file to use as the physical file's unique key. This parameter is available only if the PFUPDMTD parameter (see above) is set to *UKEY and the INCFLG parameter (see above) is set to *INCLUDE. It must be specified when the update method is by unique key. The object specifier must identify a unique index for the file. You can specify the unique key and its library or the following value:


Note:

*SAMEUses the current setting for this parameter. *AUTOIndicates that you want iCluster to automatically determine a unique key for every physical file being replicated by the object specifier.

If the unique key cannot be found on the target, iCluster suspends the physical file on the target with the UKM suspension code. You must identify the unique key and its library if you do not specify *AUTO. Prefix the physical file key with the name of the library where the key is located (for example, LIB1/OBJ1).

CRWNR Indicates the object-level rules by which iCluster will resolve conflicts for the objects selected to a *MSTRMSTR replication group. Specify one of the following values:

*SAMEUses the current setting for this parameter. *GROUPIndicates that the object specifier inherits conflict resolution rules and the user exit program configured at the group-level. *SRCIndicates that the source wins if there is a conflict. Source data is applied to the target, which ensures that target data matches source data and mirroring continues. *TGTIndicates that the target wins if there is a conflict. iCluster does not apply data to the target. This rule preserves data on the target and mirroring continues. *EXITIndicates that you would like to resolve data conflicts through a user exit program. With this option, you must specify a user exit program and library in the CRUSREXIT parameter below. *NONEIndicates that you do not want to enable conflict detection and resolution rules. If there is a conflict, iCluster suspends the file from replication and sends a message to the event log. This is the default behavior for iCluster.

The default setting for this parameter is *SAME. Note: This parameter only applies to iBalance and *MSTRMSTR replication groups. See iBalance and MasterMaster Replication on page 321 for more information on this feature. CRUSREXIT The name of the user exit program that you want to call to resolve data conflicts. A user exit program allows you to define a conflict resolution strategy that is not covered by one of the standard resolution methods in the CRWNR parameter. Specify the name of a user exit program or one of the following values:


150

*SAMEUses the current setting for this parameter. *NONEIndicates that you do not want to specify a user exit program.

Printed in Canada

iClusterVersion 5.1

Native AS/400 Object Commands

The library where the user exit program resides must be identified if you do not specify *NONE. Prefix the name of the user exit program name with the name of the library where the program is located (for example, LIB1/USREXIT1). See Parameter List Descriptions for a Conflict Resolution User Exit Program on page 326 for more information about the values you can pass to the user exit program. The default setting for this parameter is *NONE. You cannot specify *NONE for this parameter if you specify *EXIT for the CRWNR parameter. Note: This parameter only applies to iBalance and *MSTRMSTR replication groups. See iBalance and MasterMaster Replication on page 321 for more information on installing this feature.

Examples DMCHGOBJSL GROUP(GRP1) OBJ(LIB1/OBJ1) OBJTYPE(*AUTL) DESC('Authorization list OBJ1 in LIB1') Changes the description associated with selection of object OBJ1 in library LIB1 that has an object type of *AUTL (authorization list) to replication group GRP1. DMCHGOBJSL GROUP(GRP2) OBJ(LIB2/OBJ*) OBJTYPE(*USRSPC) INCFLG(*EXCLUDE) Changes the selection of individual objects in library LIB2 that have names which start with OBJ (for example, OBJ2, OBJTEST, and so on) and an object type of *USRSPC (user spaces) to replication group GRP2. The referenced objects will not be replicated within the replication group when cluster operations are started. DMCHGOBJSL GROUP(GRP3) OBJ(LIB3/OBJ3) OBJTYPE(*FILE) OBJATTR(PFDTA) INCFLG(*INCLUDE) Changes the selection of object OBJ3 in the library LIB3 that has an object type of *FILE to replication group GRP3. Object OBJ3 will be replicated within the replication group when cluster operations are started. Use You must issue this command on an active node in the cluster. The specified replication group must be inactive when you issue this command. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 15 Work With Object Specifiers screen - Option 2

DMDSELOBJDe-select Objects from Group


DMDSELOBJ GROUP( ) OBJ( ) OBJTYPE( ) OBJATTR( ) Use this command to de-select an object specifier from the replication group identified through the first parameter. De-selecting an object specifier from a replication group prevents referenced objects from being replicated within the group. Input Parameters

GROUP The name of the defined replication group that will have objects de-selected from it. OBJ The object name component of the specifier that you want to de-select. Enter a specific or generic name (to identify multiple objects in a library), or the following value:

*ALLSpecifies all objects in a library.

DataMirror, an IBM Company

Printed in Canada

151

You must identify the library where the objects reside. Prefix the object specification with the name of the library where the objects are located (for example, LIB1/OBJ1).

OBJTYPE The object type component of the specifier that you want to de-select. Specify an object type or the following value:

*ALLSpecifies all object types.

For a complete list of all object types that iCluster can replicate, see Object Specifiers and Types on page 50. OBJATTR The attribute component of the specifier you want to select. This parameter is only applicable when the OBJTYPE parameter (see above) is set to *FILE. Press F4 for a list of values or enter the following value:

Examples

*ALLSpecifies all object attributes. *ALL is not a valid system attribute but allows iCluster to gather all objects regardless of their attribute.

The default setting for this parameter is *ALL.

DMDSELOBJ GROUP(GRP1) OBJ(LIB1/OBJ1) OBJTYPE(*MSGF) De-selects the object OBJ1 in library LIB1 that has an object type of *MSGF (message file). The object specifier will be de-selected from the replication group GRP1. DMDSELOBJ GROUP(GRP2) OBJ(LIB2/OBJ*) OBJTYPE(*SRVPGM) De-selects the objects in library LIB2 that have names which start with OBJ (for example, OBJ2, OBJTEST, and so on) and an object type of *SRVPGM (service program). The individual objects referenced by the specifier will be de-selected and will no longer be replicated. DMDSELOBJ GROUP(GRP3) OBJ(LIB3/OBJ3) OBJTYPE(*FILE) OBJATTR(DSPF) De-selects the object OBJ3, which resides in library LIB3, from the replication group GRP3. The object specifier is a physical file object of the OS/400 standard type DSPF. Use You must issue this command on an active node in the cluster. The specified replication group must be inactive when you issue this command. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 14 Work With Object Specifiers screen - Option 4

DMWRKOBJWork with Object Specifiers


DMWRKOBJ BY( ) GROUP( ) Use this command to list the object specifiers that have been defined in iCluster. The BY and GROUP parameters allow you to filter the list by displaying the object specifiers that have been selected to a specific group. For more information about object specifiers, see Object Specifiers and Types on page 50.

152

Printed in Canada

iClusterVersion 5.1

Native AS/400 Object Commands

Input Parameters

BY The set of object specifiers that are listed by this command. Specify one of the following values:

*NONELists all object specifiers defined in iCluster.

*GROUPLists the object specifiers that have been selected to the group specified through the GROUP parameter (see below). The default setting for this parameter is *NONE.

GROUP The name of an existing group. Object specifiers selected to the named group are listed. This parameter is only applicable when the BY parameter (see above) is set to *GROUP.

Examples DMWRKOBJ BY(*NONE) Lists all object specifiers defined in iCluster. DMWRKOBJ BY(*GROUP) GROUP(GRP1) Lists all object specifiers selected to the group GRP1. Use You must issue this command on an active node in the cluster. Minimum Security Level User (*USER) Menu Access F22 (Shift+F10) - Option 16 Work With Groups screen - Option 12

DataMirror, an IBM Company

Printed in Canada

153

154

Printed in Canada

iClusterVersion 5.1

Byte Stream File (BSF) Commands

Byte Stream File (BSF) Commands


This section contains the following commands:

DMADDBSFAdd Path Object Specifier to Group on page 155 DMRMVBSFRemove Path Object Specifier to Group on page 158 DMCHGBSFChange Path Object Specifier to Group on page 159 DMWRKBSFWork with Path Object Specifiers on page 162

DMADDBSFAdd Path Object Specifier to Group


DMADDBSF GROUP( ) PATH( ) DESC( ) INCFLG( ) JOURNAL( ) POLLINT( ) NEWOBJACT( ) CRWNR( ) CRUSREXIT( ) Use this command to select one or more Byte Stream File (BSF) objects residing in the Integrated File System (IFS) to the specified replication group. The referenced BSF objects are replicated from the primary node to the backup node in the replication group. Note: This command can be issued when adding new object specifiers for active replication groups. See the NEWOBJACT parameter in this command for more information.

For more information about BSF objects, see Replicating BSF Objects on page 89. Input Parameters

GROUP The name of the defined replication group that will have BSF objects selected to it. You must define the replication group in iCluster before selecting BSF objects to the replication group. PATH The path that identifies the location of the BSF objects. The path must be enclosed in single quotes and start with a '/' (forward slash) character ('/Dir3/Dir4/file'). The path can be a maximum of 5000 characters, and you must enter at least two characters for the path. Generic path names of the form '/mydir*' are supported, where the generic indicator '*' is the final character of the path name. When using generic path names, all sub-directories are included recursively. For more information about path object specifiers, see Path Object Specifiers on page 53.

DESC A short description that allows you to identify this path object specifier selection amongst all others that have been defined in iCluster. The description can be a maximum of 50 characters long.

INCFLG Indicates whether the BSF objects referenced by the path object specifier will be replicated within the replication group. Specify one of the following values:

*INCLUDEIndicates that the referenced BSF objects will be replicated within the replication group when cluster operations are started. *EXCLUDEIndicates that the referenced BSF objects will not be replicated within the replication group when cluster operations are started.

The default setting for this parameter is *INCLUDE.

DataMirror, an IBM Company

Printed in Canada

155

Note:

BSF include/exclude specifiers cannot have symbolic links to directories as part of their paths. This is only permitted when the symbolic link is at the end of a non-generic specifier that points directly to the symbolic link. iCluster does not support using symbolic links to directories to make BSF specifiers shorter. JOURNAL Indicates how the BSF objects referenced by the path object specifier will be replicated with the replication group. Specify one of the following values:


Note: Note:

*NONEBSF objects matching this object specifier will not be journaled by iCluster. Only object-level changes to objects matching this specifier will be replicated. Changes to the contents of the objects matching this specifier will not be replicated unless the entire object is replaced. See Path Object Specifiers on page 53 for more information. *GROUPBSF objects matching this object specifier will use the journal specified at the group level. See the DMADDGRPAdd Group command for more information.

The default setting for this parameter is *NONE. The overlap of journaled and non-journaled path object specifiers is restricted in iCluster. For example, using both '/home/user/*' (non-journaled) and '/home/user/employees/*' (journaled) is not permitted. Objects within the QDLS directory cannot be journaled. iCluster will enforce the *NONE option for the JOURNAL parameter of any path specifier matching QDLS. POLLINT Indicates the current polling interval for the BSF objects referenced by the path object specifier. Using this parameter, you can indicate whether or not BSF objects will be polled. Specify one of the following values:


Note:

*GROUPIndicates that BSF objects will use the corresponding replication group value that is specified when adding or changing a replication group. See DMADDGRPAdd Group on page 113 for more information. *NONEIndicates that BSF objects will not be polled.

The default setting for this parameter is *GROUP. Note that it is only possible to poll BSF objects in the QDLS folder. NEWOBJACT Indicates the method by which replication is to begin for the objects that come into replication scope when an object specifier is added. Specify one of the following values:

*NONEThis value does not change the replication status of new, in-scope objects, and is intended to support initial group configuration. If this value is selected, mirroring must be started with a refresh of the entire group, or at a user-specified position with the DMSETPOSSet Journal Start Position, DMMRKPOSMark Current Journal Positions, or DMREGPOSRegister Positions commands. *CURRENTReplication of journal entries for new, in-scope objects will begin at the time the object specifier is added. Journal entries related to new, in-scope objects created after that time will be replicated. Journal entries related to new, in-scope objects created before that time will not be replicated.

Note:

This value is not allowed if replication of the group is active.

Note: Note:

This value is only permitted when the group is active. If this value is selected, no changes should occur on the new, in-scope objects until the OMI0320 event for the object specifier appears in the event log.

Note:

*REFRESHNew in-scope objects will be refreshed one at a time. Replication of journal entries for new, in-scope objects begins for each object as it is refreshed.

This value is only permitted when the group is active.

156

Printed in Canada

iClusterVersion 5.1

Byte Stream File (BSF) Commands

Note:

If this option is selected, all the objects that match the specifier and do not match an exclude specifier for the group will be refreshed. Objects that were already in replication scope, but also match the new object specifier, will be refreshed as part of the DMADDBSFAdd Path Object Specifier to Group command processing. The default setting for this parameter is *NONE. CRWNR Indicates the object-level rules by which iCluster will resolve conflicts for the non-journaled BSF objects selected to a *MSTRMSTR replication group.

Note:

See the JOURNAL parameter in this command for more information on how to specify a non-journaled BSF. Specify one of the following values:

Note:

*GROUPIndicates that the object specifier inherits conflict resolution rules and the user exit program configured at the group-level.

If you specify *GROUP for the CRWNR parameter and set the CRWNR parameter at the group level to *TGT, iCluster will enforce the *NONE conflict resolution rule for all objects matching this specifier.

*SRCIndicates that the source wins if there is a conflict. Source data is applied to the target, which ensures that target data matches source data and mirroring continues. *EXITIndicates that you would like to resolve data conflicts through a user exit program. With this option, you must specify a user exit program and library in the CRUSREXIT parameter in this command. *NONEIndicates that you do not want to enable conflict detection and resolution rules. If there is a conflict, iCluster suspends the file from replication and sends a message to the event log. This is the default behavior for iCluster.

The default setting for this parameter is *GROUP. If you want to resolve conflicts through a user exit program, you must change the logic in your user exit program to use the correct BSF path. Note: This parameter only applies to iBalance and *MSTRMSTR replication groups. See iBalance and MasterMaster Replication on page 321 for more information on this feature. CRUSREXIT The name of the user exit program that you want to call to resolve data conflicts. A user exit program allows you to define a conflict resolution strategy that is not covered by one of the standard resolution methods in the CRWNR parameter. Specify the name of a user exit program or one of the following values:

*NONEIndicates that you do not want to specify a user exit program.

The library where the user exit program resides must be identified if you do not specify *NONE. Prefix the name of the user exit program name with the name of the library where the program is located (for example, LIB1/USREXIT1). See Parameter List Descriptions for a Conflict Resolution User Exit Program on page 326 for more information about the values you can pass to the user exit program. You cannot specify *NONE for this parameter if you specify *EXIT for the CRWNR parameter. Note: This parameter only applies to iBalance and *MSTRMSTR replication groups. See iBalance and MasterMaster Replication on page 321 for more information on this feature.

Examples DMADDBSF GROUP(GRP1) PATH('QDLS/DIR1/DIR2/DIR3/FILEA') DESC('BSF Object') INCFLG(*INCLUDE) JOURNAL(*NONE) POLLINT(*GROUP) NEWOBJACT (*CURRENT) Selects the BSF object FILEA in /DIR1/DIR2/DIR3 to replication group GRP1. Provides a description to be associated with the object selection.

DataMirror, an IBM Company

Printed in Canada

157

FILEA will be included for replication within group GRP1 when cluster operations are started. BSF objects matching this object specifier will not be journaled to the default BSF journal for the cluster. The polling interval that was set in the DMADDGRPAdd Group command will be used. Replication of journal entries for new, in-scope objects will begin at the time the object specifier is added. DMADDBSF GROUP(GRP2) PATH('QDLS/DIR1/DIR2/*') INCFLG(*INCLUDE) JOURNAL(*GROUP) POLLINT(*NONE) NEWOBJACT (*REFRESH) Selects the generic path name '/DIR1/DIR2/*' to replication group GRP2. This allows iCluster to include all path objects in the directory /DIR1/DIR2 for replication when cluster operations are started. BSF objects matching this object specifier will use the journal specified at the group level. BSF objects will not be polled and therefore do not have content-level mirroring. New in-scope objects will be refreshed one at a time. Replication of journal entries for new, in-scope objects begins for each object as it is refreshed. Use You need to issue this command on an active node in the cluster. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 18 Work With Path Object Specifiers screen - F6

DMRMVBSFRemove Path Object Specifier to Group


DMRMVBSF GROUP( ) PATH( ) Use this command to de-select BSF objects from the replication group identified through the first parameter. De-selecting BSF objects from a replication group prevents referenced objects from being replicated within the group. For more information about BSF objects, see Replicating BSF Objects on page 89. Input Parameters

GROUP The name of the defined replication group that will have BSF objects de-selected from it. PATH The path object specifier that identifies the location of the BSF objects. The path object specifier must be currently selected to the replication group specified through the GROUP parameter (see above). The path must be enclosed in single quotes and start with a '/' (forward slash) character ('/Dir3/Dir4/file'). The path can be a maximum of 5000 characters, and you must enter at least two characters for the path. Generic path names of the form '/mydir*' are supported, where the generic indicator '*' is the final character of the path name. When using generic path names, all sub-directories are included recursively. For more information about path object specifiers, see Path Object Specifiers on page 53.

Examples DMRMVBSF GROUP(GRP1) PATH('/DIR1/DIR2/DIR3/FILEA') De-selects the BSF object FILEA in /DIR1/DIR2/DIR3 from replication group GRP1.

158

Printed in Canada

iClusterVersion 5.1

Byte Stream File (BSF) Commands

DMRMVBSF GROUP(GRP2) PATH('/DIR1/DIR2/*') De-selects the generic path name '/DIR1/DIR2/*' from replication group GRP2. Use You must issue this command on an active node in the cluster. The specified replication group must be inactive when you issue this command. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 19 Work With Path Object Specifiers screen - Option 4

DMCHGBSFChange Path Object Specifier to Group


DMCHGBSF GROUP( ) PATH( ) DESC( ) INCFLG( ) JOURNAL( ) POLLINT( ) CRWNR( ) CRUSREXIT( ) Use this command to change specific attributes of a BSF object selection to a replication group. You can change the description currently associated with the object selection (DESC), modify the flag that determines whether the referenced objects are replicated within the group (INCFLG), and change the polling interval (POLLINT). The journaling option for BSF objects matching this specifier can also be changed with this command. For more information about BSF objects, see Replicating BSF Objects on page 89. Input Parameters

GROUP The name of the defined replication group that will be affected by the change to the object selection. The BSF objects referenced by the PATH parameter (see below) must be currently selected to the replication group. PATH The path object specifier that identifies the location of the BSF objects that are currently selected to the replication group identified through the GROUP parameter (see above). The path must be enclosed in single quotes and start with a '/' (forward slash) character ('/Dir3/Dir4/file'). The path can be a maximum of 5000 characters, and you must enter at least two characters for the path. Generic path names of the form '/mydir*' are supported, where the generic indicator '*' is the final character of the path name. When using generic path names, all sub-directories are included recursively. For more information about path object specifiers, see Path Object Specifiers on page 53.

DESC A short description that allows you to identify this path object specifier selection amongst all others that have been defined in iCluster. The description can be a maximum of 50 characters long. Specify a short description or the following value:

*SAMEUses the description that is currently associated with the object selection to the replication group.

The default setting for this parameter is *SAME. INCFLG Indicates whether the BSF objects referenced by the path object specifier will be replicated within the replication group.

DataMirror, an IBM Company

Printed in Canada

159

Specify one of the following values:

*SAMEUses the current setting for this parameter. *INCLUDEIndicates that the referenced BSF objects will be replicated within the replication group when cluster operations are started. *EXCLUDEIndicates that the referenced BSF objects will not be replicated within the replication group when cluster operations are started.

The default setting for this parameter is *SAME. JOURNAL Indicates how the BSF objects referenced by the path object specifier will be replicated with the replication group. Specify one of the following values:

*SAMEUses the current setting for this parameter. *GROUPBSF objects matching this object specifier will use the journal specified at the group level. See the DMADDGRP command for more information. *NONEBSF objects matching this object specifier will not be journaled by iCluster. Only object-level changes to objects matching this specifier will be replicated. Changes to the contents of the objects matching this specifier will not be replicated unless the entire object is replaced. See Path Object Specifiers on page 53 for more information.

The default setting for this parameter is *SAME. Note: Note: The overlap of journaled and non-journaled path object specifiers is restricted in iCluster. For example, using both '/home/user/*' (non-journaled) and '/home/user/employees/*' (journaled) is not permitted. DLO objects in the QDLS directory will be replicated in real-time using object-level only support (*NONE). POLLINT Indicates the current polling interval for the BSF objects referenced by the path object specifier. Using this parameter, you can indicate whether or not BSF objects will be polled. Specify one of the following values:


Note:

*SAMEUses the current setting for this parameter. *GROUPIndicates that BSF objects will use the corresponding replication group value that is specified when adding or changing a replication group. See DMADDGRPAdd Group on page 113 for more information. *NONEIndicates that BSF objects will not be polled.

The default setting for this parameter is *SAME. Note that is only possible to poll BSF objects in the QDLS folder. CRWNR Indicates the object-level rules by which iCluster will resolve conflicts for the non-journaled BSF objects selected to a *MSTRMSTR replication group. Note: See the JOURNAL parameter in this command for more information on how to specify a non-journaled BSF. Specify one of the following values:


Note:

*SAMEUses the current setting for this parameter. *GROUPIndicates that the object specifier inherits conflict resolution rules and the user exit program configured at the group-level.

If you specify *GROUP for the CRWNR parameter and set the CRWNR parameter at the group level to *TGT, iCluster will enforce the *NONE conflict resolution rule for all objects matching this specifier.

160

*SRCIndicates that the source wins if there is a conflict. Source data is applied to the target, which ensures that target data matches source data and mirroring continues.
Printed in Canada

iClusterVersion 5.1

Byte Stream File (BSF) Commands

*EXITIndicates that you would like to resolve data conflicts through a user exit program. With this option, you must specify a user exit program and library in the CRUSREXIT parameter in this command. *NONEIndicates that you do not want to enable conflict detection and resolution rules. If there is a conflict, iCluster suspends the file from replication and sends a message to the event log. This is the default behavior for iCluster.

The default setting for this parameter is *SAME. If you want to resolve conflicts through a user exit program, you must change the logic in your user exit program to use the correct BSF path. Note: This parameter only applies to iBalance and *MSTRMSTR replication groups. See iBalance and MasterMaster Replication on page 321 for more information on this feature. CRUSREXIT The name of the user exit program that you want to call to resolve data conflicts. A user exit program allows you to define a conflict resolution strategy that is not covered by one of the standard resolution methods in the CRWNR parameter. Specify the name of a user exit program or one of the following values:

*SAMEUses the current setting for this parameter. *NONEIndicates that you do not want to specify a user exit program.

The library where the user exit program resides must be identified if you do not specify *NONE. Prefix the name of the user exit program name with the name of the library where the program is located (for example, LIB1/USREXIT1). See Parameter List Descriptions for a Conflict Resolution User Exit Program on page 326 for more information about the values you can pass to the user exit program. The default setting for this parameter is *SAME. You cannot specify *NONE for this parameter if you specify *EXIT for the CRWNR parameter. Note: This parameter only applies to iBalance and *MSTRMSTR replication groups. See iBalance and MasterMaster Replication on page 321 for more information on this feature.

Examples DMCHGBSF GROUP(GRP1) PATH('/DIR1/DIR2/DIR3/FILEA') DESC('Text File') INCFLG(*SAME) JOURNAL(*SAME) Changes the description associated with the selection of BSF object FILEA in /DIR1/DIR2/DIR3 to replication group GRP1. The parameter setting that determines whether the BSF object is replicated within the group is not changed from its current value. The JOURNAL parameter uses the settings that were set in the DMADDBSFAdd Path Object Specifier to Group command. DMCHGBSF GROUP(GRP2) PATH('/DIR1/DIR2/*') DESC(*SAME) INCFLG(*INCLUDE) JOURNAL(*NONE) POLLINT(*SAME) CRWNR(*SRC) Changes the INCFLG parameter setting associated with the selection of a generic path name '/DIR1/DIR2/*' to replication group GRP2. This allows iCluster to exclude all path objects in the directory /DIR1/DIR2 from replication when cluster operations are started. The description associated with the BSF object selection is not changed. BSF objects matching this object specifier will not be journaled by iCluster. The polling interval that was set in the DMADDGRPAdd Group command will be used. The source will win if there is a conflict. Use You must issue this command on an active node in the cluster. The specified replication group must be inactive when you issue this command.

DataMirror, an IBM Company

Printed in Canada

161

Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 20 Work With Path Object Specifiers screen - Option 2

DMWRKBSFWork with Path Object Specifiers


DMWRKBSF BY( ) GROUP( ) Use this command to list the path object specifiers that have been defined in iCluster. The BY and GROUP parameters allow you to filter the list by displaying the path object specifiers that have been selected to a specific replication group. For more information about path object specifiers, see Path Object Specifiers on page 53. Input Parameters

BY The set of path object specifiers that are listed by this command. Specify one of the following values:

*NONELists all path object specifiers defined in iCluster. *GROUPLists the path object specifiers that have been selected to the replication group specified through the GROUP parameter (see below).

The default setting for this parameter is *NONE. GROUP The name of an existing replication group. Path object specifiers selected to the named replication group are listed. This parameter is only applicable when the BY parameter (see above) is set to *GROUP. Examples DMWRKBSF BY(*NONE) Lists all path object specifiers defined in iCluster. DMWRKBSF BY(*GROUP) GROUP(GRP1) Lists all path object specifiers selected to the replication group GRP1. Use You must issue this command on an active node in the cluster. Minimum Security Level User (*USER) Menu Access F22 (Shift+F10) - Option 21 Work With Groups screen - Option 13

162

Printed in Canada

iClusterVersion 5.1

Switchable Device Commands

Switchable Device Commands


This section contains the following topics:

DMADDSWDEVAdd Switchable Device Entry to Group on page 163 DMDSPASPGPDisplay Switchable Device Entry to Group on page 164 DMCHGSWDEVChange Switchable Device Entry for Group on page 164 DMRMVSWDEVRemove Switchable Device Entry for Group on page 165

DMADDSWDEVAdd Switchable Device Entry to Group


DMADDSWDEV GROUP( ) SWDEV( ) ONLINE( ) Use this command to add a switchable disk storage device entry to a switchable device replication group. A replication group of type *SWDEV can have a switchable disk storage device associated with it. A switchable disk storage device (called an Independent Auxiliary Storage Pool (IASP) device) controls a disk unit that is assigned to the primary node of a group but can be re-assigned to the new primary node after a switchover or failover of the group. Input Parameters

GROUP Specifies the name of the switchable resource group (type *SWDEV) to which you want to add a switchable disk storage device entry. SWDEV Specifies the name of the switchable disk storage device which you want to add to the group. You can associate a maximum of 256 switchable disk storage devices with a single group. ONLINE Indicates whether the switchable disk storage device being added to the switchable resource group is varied on or varied off when the group is switched over from one node to another or when it is failed over to another node. Enter one of the possible values:


Example

*YESIndicates that the switchable disk storage device will be varied on when the group is switched over from one node to another, or when it is failed over to another node. *NOIndicates that the switchable disk storage device will not be varied on when the group is switched over from one node to another or when it is failed over to another node.

DMADDSWDEV GROUP(ASP33) SWDEV(IASP1) ONLINE(*YES) Indicates that the switchable disk storage device IASP1 will be added to group ASP33, and that the IASP1 will be varied on. Use You must issue this command on an active node in the cluster. Menu Access Work with Groups screen - Option 25 Minimum Security Level *ADMIN

DataMirror, an IBM Company

Printed in Canada

163

DMDSPASPGPDisplay Switchable Device Entry to Group


DMDSPASPGP GROUP( ) GRPTYPE( ) PRIMNODE( ) BACKUP( ) DESC( ) DEVICES( ) This command displays the parameters of a switchable resource group (type *SWDEV) in the cluster. Input Parameters

GROUP Specifies the name of the switchable resource group that you want to display. GRPTYPE Indicates the type of group you want to display. The only possible value is:

*SWDEVIndicates that you want to display a group for switchable devices.

PRIMNODE The primary node in the recovery domain for the specified switchable resource group. BACKUP Lists the backup node in the recovery domain of the specified switchable resource group. DESC Specifies a short description that allows you to identify this switchable resource group amongst all others that have been defined in iCluster. DEVICES The name of a switchable device that is associated with this group. Online at switchover Indicates whether the switchable device associated with the switchable resource group is varied on or left off when the group is switched over from one node to another or when it is failed over to another node. The possible values are:


Example

*YESThe switchable device that is associated with the group will be varied on when the group is switched over from one node to another or when it is failed over to another node. *NOThe switchable device that is associated with the group will be not varied on when the group is switched over from one node to another or when it is failed over to another node.

DMDSPASPGP GROUP(ASP33) Displays the ASP33 group. Use You must issue this command on an active node in the cluster.

DMCHGSWDEVChange Switchable Device Entry for Group


DMCHGSWDEV GROUP( ) SWDEV( ) ONLINE( ) Use this command to change the parameters of a switchable disk storage device entry for a switchable device replication group. A replication group of type *SWDEV can have a switchable disk storage device associated with it. A switchable disk storage device (called an Independent Auxiliary Storage Pool (IASP) device) controls a disk unit that is assigned to the primary node of a group but can be re-assigned to the new primary node after a switchover or failover of the group.

164

Printed in Canada

iClusterVersion 5.1

Switchable Device Commands

Input Parameters

GROUP Specifies the name of the switchable resource group (type *SWDEV) for which you want to change a switchable disk storage device entry. SWDEV ONLINE Indicates whether the switchable disk storage device being changed for the switchable resource group is varied on or varied off when the group is switched over from one node to another or when it is failed over to another node. Enter one of the following values:

Specifies the name of a switchable disk storage device which you want to change for the group.


Example

*YESSpecifies that the switchable disk storage device will be varied on when the group is switched over from one node to another or when it is failed over to another node. *NOSpecifies that the switchable disk storage device will not be varied on when the group is switched over from one node to another or when it is failed over to another node.

DMCHGSWDEV GROUP(ASP33) SWDEV(IASP1) ONLINE(*NO) Indicates that the switchable disk storage device IASP1 for group ASP33 will be varied off at switchover. Menu Access Work with Groups screen - Option 26 Minimum Security Level *ADMIN Use You must issue this command on an active node in the cluster. The nodes in the group must be enabled for switchable resources.

DMRMVSWDEVRemove Switchable Device Entry for Group


DMRMSWDEV GROUP( ) SWDEV( ) Use this command to remove a switchable disk storage device entry from a switchable device replication group. Input Parameters

GROUP Specifies the name of the switchable resource group (type *SWDEV) from which you want to remove a device entry. SWDEV Specifies the name of a switchable disk storage device which you want to remove from the group.

Example DMRMVSWDEV GROUP(ASP33) SWDEV(IASP1) Indicates that the switchable disk storage device IASP1 will be removed from group ASP33. Menu Access Work with Groups screen - Option 27

DataMirror, an IBM Company

Printed in Canada

165

Minimum Security Level *ADMIN Use You must issue this command on an active node in the cluster.

166

Printed in Canada

iClusterVersion 5.1

Resilient Application Commands

Resilient Application Commands


This section contains the following topics:

DMADDAPPAdd Resilient Application on page 167 DMDSPAPPGPDisplay Resilient Application Group on page 170 DMUPDAPPUpdate Resilient Application on page 172 DMCHGAPPChange Resilient Application on page 172 DMRMVAPPRemove Resilient Application on page 175 DMADDBACKAdd Backup Node to Recovery Domain on page 176 DMRMVBACKRemove Backup Node from Recovery Domain on page 176 DMWRKAPPWork with Resilient Applications on page 177

DMADDAPPAdd Resilient Application


DMADDAPP APPNAME( ) PRODLIB( ) TKOVRIPADR( ) DMNSRC( ) PRIMNODE( ) BACKUPS( ) JRNLOC( ) BSWUSREXIT( ) ASWUSREXIT( ) EXITDATA( ) DESC( ) Use this command to add a new resilient application to iCluster. To identify a resilient application, you must specify the library where the QCSTHAAPPI data area for the application is located on the primary node. This data area is defined by the application vendor and contains settings that are referenced by iCluster to define the resilient application. Another data area (QCSTHAAPPO) within the same library will contain information that confirms the addition of a resilient application through this command. Input Parameters

APPNAME

The name of the resilient application that you are adding. The name that you specify does not have to be the actual name of the application that is defined as being resilient in iCluster. However, DataMirror recommends that the specified name allows you to identify the application easily. If necessary, use the DESC parameter (see below) to identify the application.

PRODLIB The name of the library on the primary node that contains the definition of the resilient application as specified by the vendor. This library contains the data area (QCSTHAAPPI) that is provided by the application vendor so that the application can operate in a clustered environment. Within the same library, the QCSTHAAPPO data area will contain information that confirms the addition of a resilient application through this command. The library specified through the PRODLIB parameter (see above) must exist on this node.

TKOVRIPADR The takeover IP address that will be associated with the resilient application on all nodes in the recovery domain. When the resilient application is started, the takeover IP address will be activated on the application's primary node. When a failover or switchover occurs, the takeover IP address will be moved to the resilient application's new primary node. Moving the takeover IP address avoids having to modify client configurations with the resilient application after operations have been activated on another node. Client interaction with the resilient application is essentially seamless even in the event of a failover or switchover.

DataMirror, an IBM Company

Printed in Canada

167

In the absence of a takeover IP address, a different IP address would have to be used for the same application on each node in the recovery domain. After a failover or switchover in this case, a new IP address must be specified on the client to support interaction with the application on the new primary node. Therefore, a takeover IP address simplifies the process of working with the resilient application after a failover or switchover, since no IP address changes are required on the client. The takeover IP address must be specified in dotted quad notation (for example, 125.4.3.55). Note: This IP address is not the same IP address of the primary or backup node that is specified when adding a node to the cluster. See DMADDNODEAdd Node for more information. DMNSRC The name of an existing resilient application or replication group that you want to use to define the recovery domain for the new resilient application. This parameter allows you to conveniently define a recovery domain for the new resilient application that has the same primary and backup nodes as the recovery domain for an existing resilient application or replication group. Defining two or more recovery domains with the same nodes is useful when you want multiple applications to be resilient across the same nodes. Specify the name of a replication group, resilient application, or the following value:

*LISTIndicates that you want to explicitly identify the primary and backup nodes in the recovery domain (see PRIMNODE and BACKUPS below) as opposed to basing this selection on an existing resilient application or replication group.

The default setting for this field is *LIST.

PRIMNODE The name of a node that will be the primary node in the recovery domain for the resilient application that is being defined. The node you specify must have been added to the cluster, and must be currently active. See DMADDNODEAdd Node on page 99 for more information. This parameter is only applicable if the DMNSRC parameter (see above) is set to *LIST.

Note:

Both primary and backup (see BACKUPS below) nodes in a resilient application must be located in the same subnet. BACKUPS The name of a node that will be the backup node in the recovery domain for the resilient application you are defining. At this time, only one backup node can be specified. The node you specify must have been added to the cluster, and must be currently active. See DMADDNODEAdd Node on page 99 for more information. This parameter is only applicable if the DMNSRC parameter (see above) is set to *LIST.

Note:

Both primary (see PRIMNODE above) and backup nodes in a resilient application must be located in the same subnet. JRNLOC The location of the database journal where scraping will occur. You can specify the following value:

*LOCALIndicates that the database journal(s) on the primary node are scraped during mirroring. *REMOTEIndicates that the remote database journal(s) are scraped on the backup node during mirroring.

The default setting for this parameter is *LOCAL. After changing the journal location with this parameter, you must set the position of the local journal to the position of the last applied entry by running the DMSETPOSSet Journal Start Position command with the JRNPOS(*LASTAPY) parameter.

168

Printed in Canada

iClusterVersion 5.1

Resilient Application Commands

BSWUSREXIT The name of the user exit program that you want to call immediately before the role change is performed. The user exit program will be called on both nodes of the resilient application for switchover, but only on the new primary node for a failover. Specify the name of a user exit program or the following value:

*NONEIndicates that you do not want to specify a user exit program.

The default setting for this parameter is *NONE. The library where the user exit program resides must be identified if you do not specify *NONE. Prefix the name of the user exit program name with the name of the library where the program is located (for example, LIB1/USREXIT1). See Passing Arguments to Role Switch User Exit Programs on page 347 for more information about the arguments that can be passed to the user exit program.

ASWUSREXIT The name of the user exit program that you want to call immediately after the role change is performed. After a role change occurs, the user exit program will be called on both nodes of the resilient application. Specify the name of a user exit program or the following value:

*NONEIndicates that you do not want to specify a user exit program.

The default setting for this parameter is *NONE. The library where the user exit program resides must be identified if you do not specify *NONE. Prefix the name of the user exit program name with the name of the library where the program is located (for example, LIB1/USREXIT1). See Passing Arguments to Role Switch User Exit Programs on page 347 for more information about the arguments that can be passed to the user exit program.

EXITDATA Identifies the user-defined data that you want to pass to the user exit programs specified through the BSWUSREXIT and ASWUSREXIT parameters (see above). If you specify two different user exit programs (one program before the role switch, and a different program after the role switch), the same user-defined data is passed to both programs. A maximum of 256 bytes of data can be passed to the user exit programs. If your data contains spaces or non-alphanumeric characters (commas, periods, and so on), you must enclose your data in single quotes.

DESC A short description that allows you to identify this resilient application among all others that have been defined in iCluster. Use this parameter to identify the application that will be resilient in the recovery domain. The description can be a maximum of 50 characters long.

Examples DMADDAPP APPNAME(OEPACK) PRODLIB(LIB1) TKOVRIPADR(125.32.2.4) DMNSRC(*LIST) PRIMNODE(NODE1) BACKUPS(NODE2) JRNLOC(*LOCAL) BSWUSREXIT(LIB1/USREXIT1) ASWUSREXIT(*NONE) EXITDATA(ARJ123908KPJ230982) DESC('Order Entry Application') Adds the resilient application OEPACK to iCluster. Library LIB1 contains the data areas and files that are provided by the application vendor to define the resilient application. The floating IP address 125.32.2.4 can be used exclusively for communications with the application on the primary node in the recovery domain. The primary and backup nodes in the recovery domain are explicitly specified through the PRIMNODE and BACKUPS parameters.

DataMirror, an IBM Company

Printed in Canada

169

The node NODE1 in the cluster is the primary node for the resilient application, while NODE2 in the cluster assumes the role of backup node. The database journal(s) on the primary node are scraped during mirroring. The user exit program USREXIT1 in library LIB1 will be called immediately before a role change is performed. No user exit programs will be called immediately after a role change is performed. User-defined data consisting of a sequence of characters will be passed to the user exit programs. The description associated with the resilient application indicates that the application provides support for order entry. DMADDAPP APPNAME(INVPACK) PRODLIB(LIB1) TKOVRIPADR(125.44.7.1) DMNSRC(OEPACK) JRNLOC(*LOCAL) BSWUSREXIT(*NONE) ASWUSREXIT(LIB1/USREXIT1) EXITDATA(ARJ123908KPJ230982) DESC('Inventory Application') Adds the resilient application INVPACK to iCluster. Library LIB1 contains the data areas and files that are provided by the application vendor to define the resilient application. The floating IP address 125.44.7.1 can be used exclusively for communications with the application on the primary node in the recovery domain. The primary and backup nodes in the recovery domain for the resilient application are the same nodes that are in the recovery domain for the resilient application OEPACK. The database journal(s) on the primary node are scraped during mirroring. No user exit programs will be called immediately before a role change is performed. The user exit program USREXIT1 in library LIB1 will be called immediately after a role change is performed. User-defined data consisting of a sequence of characters will be passed to the user exit programs. The description associated with the resilient application indicates that the application provides support for inventory. Use You must issue this command on an active node in the cluster, and all specified nodes in the recovery domain must be active. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 23 Work With Resilient Applications screen - Option 6 or F6

DMDSPAPPGPDisplay Resilient Application Group


DMDSPAPPGP GROUP( ) GROUPTYPE( ) DESC( ) PRIMNODE( ) BACKUP( ) TKOVRIPADR( ) APPNAME( ) JRNLOC( ) BSWUSREXIT( ) ASWUSREXIT( ) EXITDATA( ) This command displays the parameters of a group that is associated with a resilient application. This command can be used on any active node of the cluster. Input Parameters

GROUP The name of a group that is associated with a resilient application. GROUPTYPE The type of a group that is associated with a resilient application. The possible values are:

170

*APPLIndicates an application resource group

Printed in Canada

iClusterVersion 5.1

Resilient Application Commands

*REPLIndicates a replication resource group

DESC The description that is assigned to the resilient application with which this group is associated. The description can be a maximum of 50 characters long. PRIMNODE The name of the group's primary node. BACKUP The name of the group's first backup node. TKOVRIPADR The takeover IP address for an application group. This field is left blank for replication groups. APPNAME The name of the resilient application defined in iCluster with which this group is associated. JRNLOC The location of the database journal where scraping will occur. The possible values are:

*LOCALIndicates that the database journal(s) on the primary node are scraped during mirroring. *LOCAL is the default setting for this parameter. *REMOTEIndicates that the remote database journal(s) are scraped on the backup node during mirroring.

BSWUSREXIT Specifies the name of the user exit program that you want to call immediately before a role switch is performed. The possible values are:

*NONEIndicates that you do not want to specify a user exit program. user-exit-program-nameRefers to the name of the user exit program to be called.

You must specify the library where the user exit program resides if you do not specify *NONE. Prefix the name of the user exit program name with the name of the library where the program is located (for example, LIB1/USREXIT1). ASWUSREXIT Specifies the name of the user exit program that you want to call immediately after a role switch is performed. The possible values are:

*NONEIndicates that you do not want to specify a user exit program. user-exit-program-nameRefers to the name of the user exit program to be called.

Yo must specify the library where the user exit program resides if you do not specify *NONE. Prefix the name of the user exit program name with the name of the library where the program is located (for example, LIB1/USREXIT1). EXITDATA Identifies the user-defined data that you want to pass to the user exit programs specified through the BSWUSREXIT and ASWUSREXIT parameters. If you specify two different user exit programs, the same user-defined data is passed to both programs. A maximum of 256 bytes of data can be passed to the user exit programs. If your data contains spaces or non-alphanumeric characters (commas, periods, and so on), you must enclose your data in single quotes. Examples DMDSPAPPGP GROUP(APPGRP1)

DataMirror, an IBM Company

Printed in Canada

171

Displays informtion for the APPGRP1 group.

DMUPDAPPUpdate Resilient Application


DMUPDAPP APPNAME( ) PRODLIB( ) Use this command to update a resilient application in iCluster when the data areas and files provided by the application vendor change on the primary node. When the QCSTHAAPPI data area, along with related data areas and files, is updated on the application's primary node, this command must be used to update the corresponding resilient application in iCluster. You can use this command to remove and re-define the application groups currently associated with the resilient application. The recovery domain takeover IP address and the description of the application are not changed by this command. Input Parameters

APPNAME The name of the resilient application that you are updating. The resilient application that you specify must have been added to iCluster through the DMADDAPPAdd Resilient Application command.

PRODLIB The name of the library on the primary node that contains the updated definition of the resilient application as specified by the vendor. This library contains the data areas and files that are provided by the application vendor so that the application can operate in a clustered environment. When these data areas and files are modified, this command must be used to update the corresponding resilient application in iCluster.

Example DMUPDAPP APPNAME(OEPACK) PRODLIB(LIB1) Updates the resilient application OEPACK in iCluster. Library LIB1 contains the data areas and files that are provided by the application vendor, but have been changed on the application's primary node. Use You must issue this command on an active node in the cluster. The resilient application must not be running when you issue this command. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 24 Work With Resilient Applications screen - Option 3

DMCHGAPPChange Resilient Application


DMCHGAPP APPNAME( ) TKOVRIPADR( ) BSWUSREXIT( ) ASWUSREXIT( ) EXITDATA( ) JRNLOC( ) DESC( ) Use this command to change the takeover IP address or description for the specified resilient application. You can also change the name of the user exit programs that are called before and after a role change, and the user-defined data that is passed to these programs.

172

Printed in Canada

iClusterVersion 5.1

Resilient Application Commands

Note that the recovery domain for an existing resilient application cannot be changed through this command. However, you can modify the recovery domain for a resilient application by using the commands for adding or removing backup nodes. See DMADDBACKAdd Backup Node to Recovery Domain on page 135 and DMRMVBACKRemove Backup Node from Recovery Domain on page 135. Input Parameters

APPNAME The name of the resilient application that will have its takeover IP address and/or description changed by this command. The resilient application that you specify must have been added to iCluster through the DMADDAPPAdd Resilient Application command.

TKOVRIPADR The takeover IP address that will be associated with the resilient application on all nodes in the recovery domain (see note below). When the resilient application is started, the take over IP address will be activated on the application's primary node. When a failover or switchover occurs, the takeover IP address will be moved to the resilient application's new primary node. Moving the takeover IP address avoids having to modify client configurations with the resilient application after operations have been activated on another node. Client interaction with the resilient application is essentially seamless even in the event of a failover or switchover. In the absence of a takeover IP address, a different IP address would have to be used for the same application on each node in the recovery domain. After a failover or switchover in this case, a new IP address must be specified on the client to support interaction with the application on the new primary node. Therefore, a takeover IP address simplifies the process of working with the resilient application after a failover or switchover, since no IP address changes are required on the client. It must be specified in dotted quad notation (for example, 125.4.3.55). Specify the IP address for the application or the following value:

Note:

*SAMEUses the current setting for this parameter.

The default setting for this parameter is *SAME. This IP address is not the same IP address of the primary or backup node that is specified when adding a node to the cluster. See DMADDNODEAdd Node on page 99 for more information. BSWUSREXIT The name of the user exit program that you want to call immediately before the role change is performed. The user exit program will be called on both nodes of the resilient application for switchover, but only on the new primary node for a failover. Specify the name of a user exit program or the following value:

*SAMEUses the current setting for this parameter. *NONEIndicates that you do not want to specify a user exit program.

The default setting for this parameter is *SAME. The library where the user exit program resides must be identified if you do not specify *NONE. Prefix the name of the user exit program name with the name of the library where the program is located (for example, LIB1/USREXIT1). See Passing Arguments to Role Switch User Exit Programs on page 347 for more information about the arguments that can be passed to the user exit program.

ASWUSREXIT The name of the user exit program that you want to call immediately after the role change is performed. After a role change occurs, the user exit program will be called on both nodes of the resilient application.

DataMirror, an IBM Company

Printed in Canada

173

Specify the name of a user exit program or the following value:

*SAMEUses the current setting for this parameter. *NONEIndicates that you do not want to specify a user exit program.

The default setting for this parameter is *SAME. The library where the user exit program resides must be identified if you do not specify *NONE. Prefix the name of the user exit program name with the name of the library where the program is located (for example, LIB1/USREXIT1). See Passing Arguments to Role Switch User Exit Programs on page 347 for more information about the arguments that can be passed to the user exit program.

EXITDATA Identifies the user-defined data that you want to pass to the user exit programs specified through the BSWUSREXIT and ASWUSREXIT parameters (see above). If you specify two different user exit programs (one program before the role switch, and a different program after the role switch), the same user-defined data is passed to both programs. A maximum of 256 bytes of data can be passed to the user exit programs. If your data contains spaces or non-alphanumeric characters (commas, periods, and so on), you must enclose your data in single quotes. Specify the user-defined data that you want to pass to the user exit programs or the following value:

*SAMEUses the current setting for this parameter.

The default setting for this parameter is *SAME. JRNLOC The location of the database journal where scraping will occur. You can specify the following value:

*SAMEUses the current setting for this parameter. *LOCALIndicates that the database journal(s) on the primary node are scraped during mirroring. *REMOTEIndicates that the remote database journal(s) are scraped on the backup node during mirroring.

The default setting for this parameter is *SAME. After changing the journal location with this parameter, you must set the position of the local journal to the position of the last applied entry by running the DMSETPOSSet Journal Start Position command with the JRNPOS(*LASTAPY) parameter.

DESC A short description that allows you to identify this resilient application amongst all others that have been defined in iCluster. Use this parameter to identify the application that will be resilient in the recovery domain. The description can be a maximum of 50 characters long. Specify a short description or the following value:

Example

*SAMEUses the current setting for this parameter.

The default setting for this parameter is *SAME.

DMCHGAPP APPNAME(OEPACK) TKOVRIPADR(125.32.2.5) JRNLOC(*LOCAL) BSWUSREXIT(LIB1/USREXIT1) ASWUSREXIT(*NONE) EXITDATA(ARJ123908KPJ230982) DESC('Order Entry Application') Changes the resilient application OEPACK in iCluster.

174

Printed in Canada

iClusterVersion 5.1

Resilient Application Commands

The floating IP address 125.32.2.5 can be used exclusively for communications with the application on all nodes in the recovery domain. The database journal(s) on the primary node are scraped during mirroring. The user exit program USREXIT1 in library LIB1 will be called immediately before a role change is performed. No user exit programs will be called immediately after a role change is performed. User-defined data consisting of a sequence of characters will be passed to the user exit programs. The description associated with the resilient application indicates that the application provides support for order entry. Use You must issue this command on an active node in the cluster. The resilient application must not be running when you issue this command. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 25 Work With Resilient Applications screen - Option 2

DMRMVAPPRemove Resilient Application


DMRMVAPP APPNAME( ) Use this command to remove the specified resilient application in iCluster. This command does not delete the software application itself. Input Parameter

APPNAME The name of the resilient application that you are removing. The resilient application that you specify must have been added to iCluster through the DMADDAPP command.

Example DMRMVAPP APPNAME(OEPACK) Removes the resilient application OEPACK in iCluster. Use You must issue this command on an active node in the cluster. The resilient application must not be running when you issue this command. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 26 Work With Resilient Applications screen - Option 6

DataMirror, an IBM Company

Printed in Canada

175

DMADDBACKAdd Backup Node to Recovery Domain


DMADDBACK NAME( ) NODE( ) BACKIASP( ) Use this command to add a backup node to the recovery domain for an existing replication group. You can add only a single backup node through this command. The recovery domain for the replication group or resilient application must already have a defined primary node. You can only add a backup node to the recovery domain for inactive replication groups or resilient applications that are not currently running. You must add a backup node to the recovery domain before replication can be started for a resilient application or replication group. Input Parameters

NAME The name of the group or resilient application that will have a backup node added to its recovery domain. NODE The name of the node in the cluster that will be added to the recovery domain for the specified group or resilient application. You must specify a node that has been added to the cluster. For an *SWDEV group, the node must have switchable disk storage devices enabled (SWITCHRES parameter). See the DMADDNODEAdd Node on page 99 for more information.

BACKIASP The name of the independent auxiliary storage pool (IASP) on the backup node to which you want to replicate. Specify the name of an existing IASP or the following value:

Example

*SYSBASIndicates that you are using a system ASP rather than an independent ASP for storing the objects that will be replicated.

The default setting for this parameter is *SYSBAS.

DMADDBACK NAME(GRP1) NODE(NODE1) BACKIASP(DMC_3) Adds the backup node NODE1 to replication group GRP1. The name of the IASP on the backup node is DMC_3. Use You must issue this command on an active node in the cluster. The specified node must also be active. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 9 or Option 27 Accessible from the Work With Groups screen (Option 22) and the Work With Resilient Applications screen (Option 22).

DMRMVBACKRemove Backup Node from Recovery Domain


DMRMVBACK NAME( ) NODE( ) Use this command to remove the backup node from the recovery domain for an existing group or resilient application.

176

Printed in Canada

iClusterVersion 5.1

Resilient Application Commands

Note that you can remove a backup node only using this command. The recovery domain for the group or resilient application must already have defined primary and backup nodes. You can remove backup nodes only from recovery domains for inactive groups or resilient applications that are not currently running. Input Parameters

NAME The name of the group or resilient application that will have a backup node removed from the recovery domain. NODE The name of the backup node in the cluster that will be removed from the recovery domain for the specified group or resilient application.

Example DMRMVBACK NAME(GRP1) NODE(NODE1) Removes the backup node NODE1 from group GRP1. Use You must issue this command on an active node in the cluster. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 10 or Option 28 Accessible from the Work With Groups screen (Option 23) and the Work With Resilient Applications screen (Option 23).

DMWRKAPPWork with Resilient Applications


DMWRKAPP BY( ) NODE( ) GROUP( ) Use this command to display the resilient applications in iCluster. The BY, NODE, and GROUP parameters allow you to filter the list by displaying the resilient applications that contain a specific node in their recovery domains, or the application that is associated with a specific group. In addition, the application status that is currently assigned to the resilient application is displayed, and can be one of the following:

*ACTIVESpecifies that the cluster statuses of all the groups under the resilient application are active. The groups' recovery domains are the same. *INACTIVESpecifies that the cluster statuses of all the groups under the resilient application are inactive. The groups' recovery domains are the same. *INDOUBTIndicates if the groups' recovery domains are different, or if one of the cluster or replication status is different from other groups. *UNKNOWNIndicates that the status of the resilient application cannot be determined. *IN_ERRORIndicates that an internal iCluster error may have occurred. If this state persists, contact DataMirror Technical Support. See Contacting Technical Support on page 547 for more information. *NONEApplications that have the necessary data to be defined as a resilient application in the cluster but are not yet defined as a resilient application.

Input Parameters BY

DataMirror, an IBM Company

Printed in Canada

177

The set of resilient applications. Specify one of the following values:

*NONELists all resilient applications in iCluster. *NODELists the resilient applications that contain the node specified through the NODE parameter (see below) in their recovery domains. *GROUPIdentifies the resilient application that is associated with the group specified through the GROUP parameter (see below). The group can be a resilient application group or a data replication group associated with the resilient application.

The DMWRKAPPWork with Resilient Applications panel will display the full list of resilient application definitions on the current system, whether or not they have been defined in iCluster as resilient applications. The default setting for this parameter is *NONE.

NODE

The name of an existing node. Resilient applications that contain the named node in their recovery domains are listed. This parameter is only applicable when the BY parameter (see above) is set to *NODE. GROUP The name of an existing replication group. The resilient application associated with the named group is identified. This parameter is only applicable when the BY parameter (see above) is set to *GROUP. Examples DMWRKAPP BY(*NONE) Lists all resilient applications in iCluster. DMWRKAPP BY(*NODE) NODE(NODE1) Lists all resilient applications that contain the node NODE1 in their recovery domains. DMWRKAPP BY(*GROUP) GROUP(GRP1) Identifies the resilient application that is associated with the group GRP1. Use You must issue this command on an active node in the cluster. Minimum Security Level User (*USER) Menu Access Main Menu - Option 3 F22 (Shift+F10) - Option 29

178

Printed in Canada

iClusterVersion 5.1

MQSeries Commands

MQSeries Commands
This section contains the following topics:

RBDHAMQMRebuild iCluster MQSeries on page 179

RBDHAMQMRebuild iCluster MQSeries


RBDHAMQM MQSRLS( ) QMNAME( ) Use this command on the backup node that is being turned into a primary node to rebuild the WebSphere MQ environment after a switchover, and re-creates all WebSphere MQ objects from the information stored in the WebSphere MQ journal and mirrored WebSphere MQ BSF files. The operations performed by this command may take a long period of time (over 20 minutes). The length of time depends on the number of WebSphere MQ objects originally present on the primary node, and the number of messages stored on the WebSphere MQ queues if a refresh before mirror was done on the primary node. An increase in the number of operations (for example, creation, deletion, attribute change, message addition, and removal) performed on the WebSphere MQ objects while mirroring was active will increase the length of time required for both mirroring and refresh before mirroring. Note: If you issue RBDHAMQM for a particular queue manager on the backup node for backup purposes or other reasons, the group that mirrors this queue manager must always be restarted with a refresh. This will ensure data integrity on the backup node the next time the WebSphere MQ queue manager starts.

Input Parameters

MQSRLS The product version of WebSphere MQ that you are using. WebSphere MQ versions V5R2M0, V5R3M0, and V6R0M0 are supported. The default setting for this parameter is V5R3M0.

QMNAME The name of the WebSphere MQ queue manager that must be rebuilt. Multiple queue managers are not supported. If you want to mirror multiple queue managers, use the DMADDGRPAdd Group on page 113 command to define a group for each of them. Enter specific names. Do not use *DFT or generic names.

Output Relevant operating system messages to the job log. The output can be long and can contain warnings if WebSphere MQ attempts to rebuild many objects. Examples RBDHAMQM MQSRLS(V5R3M0) QMNAME(QM1) This command rebuilds the WebSphere MQ environment on a machine running WebSphere MQ version V5R3M0. QM1 is the name of the queue manager being rebuilt and activated. Use You can issue this command on the current backup node to rebuild and activate a WebSphere MQ queue manager that has been successfully replicated after ending your groups. You should only use this command on the new primary node after a switchover or failover, and the WebSphere MQ queue manager has not been activated.

DataMirror, an IBM Company

Printed in Canada

179

180

Printed in Canada

iClusterVersion 5.1

Administration Commands

Administration Commands
This section contains the following topics:

DMSETSVALSet Cluster System Values on page 181 DMCHGTIMEChange System Date and Time on page 193 DMDSPLOGDisplay Cluster Event Log on page 195 DMCLRLOGClear Cluster Event Log on page 199 HAPNGTCPPing Using TCP on page 200 JRNHADADQJournal Data Areas and Data Queues on page 201 STRHATCPStart TCP/IP Listener on page 202 WRKHAJOBWork with Active Cluster Jobs on page 203 DMSTRDMStart Definition Manager on page 203 DMDLTCLSTRDelete Cluster on page 203 DMSYSINFSystem Information on page 204 DMWRKSSPLFWork with Suspended Spooled Files on page 205 DMACTSPLFActivate Spooled File on page 205

DMSETSVALSet Cluster System Values


DMSETSVAL OPER( ) ACT( ) OBJ( ) SPLF( ) PF( ) BSF( ) EVNTLOG( ) LATENCY( ) CLUSTER( ) PERFORM( ) Use this command to set certain cluster-wide values that affect different aspects of the clustered environment you have defined through iCluster. These cluster system values allow you to control different behaviors of your cluster. In addition, some of these values are used when corresponding parameters in other commands are set to *CLUSTER. Each cluster system value that can be set through this command belongs to one of the following categories:

Operational (OPER)Cluster system values that affect operations within the cluster. Automatic Reactivation (ACT)Cluster system values that affect the automatic reactivation of suspended objects. Object (OBJ)Cluster system values that pertain to objects replicated within the cluster. Spool File (SPLF)Cluster system values that affect the replication of spool files within the cluster. Physical File (PF)Cluster system values that affect the mirroring of physical files within the cluster. Byte Stream File (BSF)Cluster system values that affect the replication of Byte Stream File (BSF) objects within the cluster. Event Log (EVNTLOG)Cluster system values that affect the information displayed through the event log. Latency (LATENCY)Cluster system values that affect the latency threshold settings within the cluster. Cluster Values (CLUSTER)Controls whether or not iCluster uses IBM Cluster Resource Services as its failover mechanism. Performance (PERFORM)Controls the performance of iCluster in certain scenarios.

Unless otherwise stated, you must restart your groups for the changes made with this command to take effect. Input Parameters OPER

DataMirror, an IBM Company

Printed in Canada

181

Specifies settings for operational parameters. Default Polling Interval The time interval (expressed in HHMMSS format) that determines how often iCluster should check for content changes to user spaces. You set the interval by specifying the number of hours (first two digits), minutes (middle two digits) and the seconds (last two digits) between consecutive polls. The polling interval only applies to user spaces (*USRSPC). Specify a polling interval from 000010 to 235959, or one of the following values:

*SAMEUses the current setting for this cluster system value. *NONESpecifies that user spaces should not be polled.

The default setting for this parameter is 5 minutes (000500). Communications Timeout The waiting period that has to expire before a communications failure can be declared by iCluster. During the waiting period specified through this parameter, iCluster will attempt to establish any communications between the nodes. If communications cannot be established during this time, a communications failure is reported. Specify a waiting period from 000015 to 235959, or the following value:

*SAMEUses the current setting for this cluster system value.

The default setting for this parameter is 1 hour (010000). Object Compression Indicates whether you want to compress objects in save files that are generated by iCluster and replicated to backup nodes. Specify one of the following values:

*SAMEUses the current setting for this cluster system value. *NODoes not compress all objects. *YESCompresses all objects in save files before replication.

The default setting for this parameter is *NO. Compressing objects consumes CPU cycles, but it may lead to faster transfer times of the save files. If objects are compressed on the primary node, iCluster automatically de-compresses the objects when they are received on the backup node. Save Active Indicates whether an object can be updated and saved at the same time it is being transferred to the backup node. Specify one of the following values:

*SAMEUses the current setting in the DMADDGRPAdd Group command for this cluster system value. *NODoes not allow objects that are in use to be saved and updated. Objects cannot be updated while being saved. *YESAllows objects that are in use by another job to be saved and updated. Objects may not be in a consistent state in relationship to each other. *SYNCAllows objects that are in use by another job to be saved and updated. All of the objects are saved in a consistent state in relationship to each other.

The default setting for this parameter is *NO. Save/Restore Operation Output

182

Printed in Canada

iClusterVersion 5.1

Administration Commands

Indicates whether restore operations will create a spool file that identifies which objects were restored. This parameter only applies to refresh, since mirroring does not generate spool files. You can use this spool file to indicate which objects need to be refreshed. Specify one of the following values:

*SAMEUses the current setting for this cluster system value. *ERRORGenerates a spool file for restore operations that produce an error (all other restore and save operations will not generate a spool file). *FULLGenerates a spool file to identify restored and not restored objects. *NONEDoes not generate a spool file for restore operations.

The default setting for this parameter is *ERROR. Default Job Description The name of the job description that you want to designate as the default iCluster job description for replication jobs. Specify the name of a job description or the following value:

*SAMEUses the current setting for this cluster system value.

The library where the job description resides must be identified if you do not specify *SAME. Prefix the job description with the name of the library where the job description is located (for example, LIB2/SJD), or one of the following values: *PRODLIBSpecifies your iCluster installation library. *LIBLSpecifies the set of libraries in your library list (the libraries are searched in order for the first occurrence of the specified default job description).

The default setting for this parameter is *PRODLIB/CSJOBD. Group Job Start Delay The number of seconds (from 1 to 60) of delay between the start of replication processes when cluster operations are initiated for groups. This delay is only used when multiple replication processes are started through a single command invocation. It is intended for working environments that consist of relatively small systems. This setting can be used to distribute the start of replication processes over a period of time so as to avoid high peaks in CPU usage that would typically occur if these processes are started at the same time. Specify the number of seconds (between 1 and 60, inclusively), or the following value:


ACT

*SAMEUses the current setting for this cluster system value.

The default setting for this parameter is two seconds. Specifies settings for the automatic reactivation of suspended objects. The following parameters combine to define the automatic reactivation settings. For more information about automatic reactivation, see Suspended Objects on page 72. Automatic reactivation Specifies whether iCluster should try to reactivate suspended objects. Enter one of the following values:

*SAMEKeeps the present setting for this parameter. *YESSpecifies that iCluster should try to reactivate suspended objects. This is the default value for this parameter. *NOSpecifies that iCluster should not reactivate suspended objects.

DataMirror, an IBM Company

Printed in Canada

183

Reactivation interval The number of minutes between automatic retries. Valid entries range between 1 and 1440 (one day). Enter the number of minutes between intervals or the following value:

*SAMEKeeps the present setting for this parameter.

The product default is 10 minutes. Max. reactivation attempts The number of automatic retries before halting activation. Valid entries range between 1 and 32767. Enter the maximum number of retries or one of the following values:

*SAMEKeeps the present setting for this parameter. *NOMAXNever gives up on automatic reactivation. This is the default value for this parameter.

Max. reactivation size The largest object size (in bytes) to be included in the reactivation. The size of an object can affect network performance and introduce mirroring latency. Enter the maximum size or one of the following values:

*SAMEKeeps the present setting for this parameter. *NOMAXIncludes objects of all sizes in the reactivation. This value could have serious performance issues on the primary node and network bandwidth issues if very large objects are suspended frequently. This is the default value for this parameter.

*NOMAX is the default value for this parameter.

OBJ Specifies settings for object parameters. Lock Files on Backup Nodes Indicates whether journaled files should be locked on the backup node. When locked, no other users can modify these files on the backup node. Specify one of the following values:

*SAMEUses the current setting for this cluster system value. *NOIndicates that files will not be locked when the group is active, meaning that users can modify these files on the backup node. *YESIndicates that files cannot be modified on the backup node when the group is active.

The default setting for this parameter is *NO. Maximum Refresh Size Indicates the size of the largest physical file (in kilobytes) that can be refreshed automatically over the network. The size of an object can affect network performance and introduce mirroring latency. If a physical file is too large to be refreshed, it will be marked as suspended and will not be refreshed by iCluster. In this case, you are responsible for ensuring the physical file is refreshed to the backup node by some other means (tape, for example) and activated for replication. Note: This parameter applies to the automatic reactivation of database files, refresh of objects, and the activation of objects. See the DMACTOBJActivate Object command.

184

Printed in Canada

iClusterVersion 5.1

Administration Commands

Journal entries added after activating the suspended physical file will be sent to the backup node. Journal entries added before the file is activated will not be sent to the backup node. As a result, you will need to make sure that the file was not changed between the time it was saved on the primary node and the time it was activated. Specify a maximum refresh size or one of the following values:

*SAMEUses the current setting for this cluster system value. *NOMAXIndicates that there is no maximum refresh size.

The default setting for this parameter is *NOMAX. Changes made to the maximum refresh size take effect immediately. Hold Configuration Object Source on Backup Node Indicates whether you want iCluster to create configuration objects automatically and immediately after they are received on a backup node or hold the commands for creating them in specific physical source files so that they can be created at a later time. Specify one of the following values:

*SAMEUses the current setting for this cluster system value. *YESHolds commands to create configuration objects in specific physical source files so that they can be created at a later time. *NOAutomatically creates configuration objects as soon as they are received on the backup node.

The default setting for this parameter is *YES. If configuration objects that are being replicated already exist on backup nodes, this value should be set to *YES to prevent iCluster from trying to create objects when they are in use. For more information about configuration objects, see Replicating Configuration Objects on page 90. Replicated User Profile Status The status that you want to assign to user profiles that have been replicated to a backup node. Specify one of the following values:

*SAMEUses the current setting for this cluster system value. *DISABLEDIndicates that all user profiles will be set to a status of *DISABLED. *PRIMARYIndicates that the user profile status will be set to the same status that is currently assigned to the corresponding user profile on the primary node. *NOCHGIndicates that the current status of each user profile will not be changed by iCluster and the user profile status on the backup node is set to *DISABLED by default.

The default setting for this parameter is *DISABLED. User Profile Replication Level Indicates whether or not dependent user profiles should be replicated when a main user profile is replicated. Dependent user profiles include object owner profiles, group profiles, supplemental profiles, and profiles on an authority list associated with the replicated profile. If you replicate dependent user profiles, then the relationship between user profiles is preserved so that there is an exact mirroring of user profiles. However, replicating all dependent user profiles may affect performance if the number of dependent user profiles is considerable. Specify one of the following values:

*SAMEUses the current setting for this cluster system value. *FULLIndicates that all dependent profiles are replicated. This includes group and supplemental profiles, profile owners as well as dependent profiles that are dependent on dependent profiles, and so on.
Printed in Canada 185

DataMirror, an IBM Company

*BASICIndicates that only profiles that match the selected object specifier will be replicated. During replication, iCluster assumes that all dependent profiles already exist on the backup node. Error messages will be generated if the dependent profiles are not on the backup node, though replication will continue.

The default setting for this parameter is *FULL. Replicate User Profiles for Authorization Lists Indicates whether you want to replicate authorization lists with or without the user profiles. An authorization list object consists of a list of user profiles. This parameter dictates whether authorization lists are replicated with or without these user profiles. If user profiles are replicated, it is important to recognize which user profiles will be sent to the backup node, as you may want to restrict access to this node. On the other hand, if a user profile in an authorization list does not exist on the backup node, the replicated authorization list will not be the same as the authorization list on the primary node if user profiles are not replicated. Specify one of the following values:

*SAMEUses the current setting for this cluster system value. *NODoes not replicate user profiles with the authorization lists. *YESReplicates user profiles with the authorization lists.

The default setting for this parameter is *NO. Replicate Q* Profiles Indicates whether you want to replicate user profiles that start with the letter Q. Usually, all profiles that start with the letter Q are system-owned user profiles (for example, QSECOFR) and should not be replicated from one node to another. However, in case you have defined user profiles that start with the letter Q that are not system-owned profiles, setting this parameter to *YES will allow you to replicate those profiles. Profiles that are owned by QSYS will not be replicated even when this parameter is set to *YES. Specify one of the following values:

*SAMEUses the current setting for this cluster system value. *NODoes not replicate any user profiles that start with the letter Q. *YESReplicates non-system-owned profiles that start with the letter Q.

The default setting for this parameter is *NO. SPLF Specifies settings for spool files. Maximum Wait for Spool Files The time period (expressed in HHMMSS format) you want iCluster to wait before abandoning the replication of a spool file. A spool file cannot be replicated unless it has a status of *READY. Therefore, if iCluster is up-to-date with the audit journal, it may start processing a spool file before it is ready. iCluster will only wait the amount of time set in this parameter for the spool file to have a status of *READY. If the spool file is not ready after waiting the time specified in this parameter, iCluster will abandon the replication of this spool file and issue a message in the event log. Specify a waiting period from 000001 to 235959, or the following value:

*SAMEUses the current setting for this cluster system value.

The default setting for this parameter is 15 seconds (000015). Maximum Wait for Spool File Activity The time period (expressed in HHMMSS format) you want iCluster to wait before abandoning the replication of a spool file if no data is being written to it.

186

Printed in Canada

iClusterVersion 5.1

Administration Commands

In some cases, a job may be writing to a spool file. However, the data is first placed in a temporary buffer and only written to the spool file upon the completion of the job. In such a case, the spool file will be open and have zero pages until the job ends. This parameter allows you to specify the time to wait for changes to occur to an open spool file. If no additional data is written to an open spool file (that is, it is open and has zero pages) within the time specified by this parameter, iCluster will abandon the replication of this spool file and issue a message. This parameter provides added flexibility as the user can specify a shorter interval over which only spool file activity is monitored. As a result, an open spool file that has no data being written to it will be abandoned quickly, as opposed to waiting the full time specified in the MAXSPLWAIT parameter (see above). Specify a waiting period from 000001 to 235959, or the following value:

*SAMEUses the current setting for this cluster system value.

The default setting for this parameter is 5 seconds (000005). Replicate *OUTQ Contents Indicates whether you want to mirror the contents of spool files. If you specify *NO, then iCluster will only replicate *OUTQ objects but will not replicate the spool files in them. Specify one of the following values:


PF

*SAMEUses the current setting for this cluster system value. *YESIndicates that the spool files will be created and the contents will be mirrored. *NOIndicates that the spool files will be created, but the contents will not be mirrored.

The default setting for this parameter is *YES. Specifies settings for replicating physical files. Commitment Control Level The level of commitment control you want to use when replicating *FILE objects. Commitment control stages complete database transactions so that they are assembled before being applied, or additionally, opened in a commitment control environment to ensure backup database consistency. For more information, see Commitment Control on page 71. Specify one of the following values:

*SAMEUses the current setting for this cluster system value. *NONEIndicates that the update process on the backup node will not perform commitment control staging. *LEVEL1Indicates that all updates that comprise a transaction are assembled before being applied on the backup node. *LEVEL2Indicates that all updates in a transaction are applied in a commitment control environment to ensure backup database consistency. This option provides true commitment control.

The default setting for this parameter is *NONE. Note that if you select *LEVEL2 but a file on the backup node cannot be opened under commitment control, *LEVEL1 commitment control will be used for that file. Journal Images Indicates whether default journaling should include both before and after images. If a file is replicated using relative record number, it may be journaled with after images only. If you are using commitment control on the primary database or unique key update method, both before and after images must be journaled.

DataMirror, an IBM Company

Printed in Canada

187

Specify one of the following values:

*SAMEUses the current setting for this cluster system value. *AFTERIndicates that you want to journal the after image only. *BOTHIndicates that you want to journal both the before and after images.

The default setting for this parameter is *AFTER. Journal Objects on Backup Indicates whether replicated physical files, data areas, and data queues will be journaled on backup nodes. Specify one of the following values:

*SAMEUses the current setting for this cluster system value. *NOIndicates that the replicated physical files, data areas, and data queues will not be journaled on backup nodes. *YESIndicates that the replicated physical files, data areas, and data queues will be journaled on backup nodes.

The default setting for this parameter is *NO. Default Database Journal The name of the database journal that you want to use as your default. The journal that you specify will be used for files that are to be mirrored but are not yet journaled. Specify the name of the database journal or the following value:

*SAMEUses the current setting for this cluster system value. The library where the journal resides must be identified if you do not specify *SAME. Prefix the journal with the name of the library where the journal is located (for example, LIB1/JRN1), or one of the following values: *PRODLIBSpecifies your iCluster installation library. *LIBLSpecifies the set of libraries in your library list (the libraries are searched in order for the first occurrence of the specified default job description).

The default setting for this parameter is *PRODLIB/HADJRN. Delete Dependent Non-Group Logical Files Indicates whether you want to delete logical files that are dependent on physical files on the backup node during a refresh of the associated physical file. Note that the logical files are not necessarily the ones you have selected to a group. Physical files that have dependent logical files can only be deleted if the dependent logical files are deleted first. Note: If some of the logical files do not belong to the same group as the physical files, you can only delete the logical files by setting this system parameter to *YES. Specify one of the following values:

*SAMEUses the current setting for this cluster system value. *NOIndicates that you do not want to delete backup logical files that are dependent on physical files. You cannot delete the physical files until you have first deleted the dependent logical files. *YESIndicates that you want to delete backup logical files that are dependent on physical files in the event that the physical files are deleted.

The default setting for this parameter is *NO. Maximum Record-Level Errors The maximum number of record-level errors that are allowed to occur for a particular file before replication of the physical file is automatically stopped by iCluster and the file becomes suspended.

188

Printed in Canada

iClusterVersion 5.1

Administration Commands

Record-level errors occur when updating, inserting, or deleting records in a file during replication to a backup node. Specify the maximum number of errors or one of the following values:


BSF

*SAMEUses the current setting for this cluster system value. *NOMAXSpecifies that replication of physical files will continue regardless of the number of record-level errors that are generated.

The default setting for this parameter is one error. Specifies settings for replicating Byte Stream File (BSF) objects. See Replicating BSF Objects on page 89 for more information. Default BSF Journal The name of the journal that you want to use as the default for your BSF objects. Note that all BSF objects replicated within a group must be journaled to the same journal. Specify the name of the journal or one of the following values:

*SAMEUses the current setting for this cluster system value. HABSFJRNUses the default BSF journal supplied with iCluster.

The library where the journal resides must be identified if you do not specify *SAME. Prefix the journal name with the name of the library where the journal is located (for example, LIB2/JRN), or one of the following values: *PRODLIBSpecifies your iCluster installation library. *LIBLSpecifies the set of libraries in your library list. The libraries are searched in order for the first occurrence of the specified default BSF journal.

The default setting for this parameter is *PRODLIB/HABSFJRN. EVNTLOG Specifies settings for the cluster event log. For more information about the cluster event log, see Monitoring Replication on page 76. Default Event Message Queue The name of the message queue that will hold event messages generated by iCluster. If a message queue is identified, iCluster event messages will be placed in the message queue and the event log. Specify the name of the event message queue or one of the following values:

*NONEIndicates that no message queue is specified. Event messages will be placed in the event log only. HAMSGQRefers to the name of the event message queue that is supplied with iCluster.

The library where the event message queue resides must be identified if you do not specify *NONE. Prefix the message queue name with the name of the library where the message queue is located (for example, LIB2/MSGQ1), or one of the following values:

*PRODLIBSpecifies your iCluster installation library. *LIBLSpecifies the set of libraries in your library list. The libraries are searched in order for the first occurrence of the specified default event message queue.

The product default for this parameter is *NONE. Remote Date/Time Log Display Indicates which date and time settings should be used to generate event messages that originate from a remote node. This value is relevant if local and remote nodes are located in different time zones. Specify one of the following values:

DataMirror, an IBM Company

Printed in Canada

189

*SAMEUses the current setting for this cluster system value. *LOCALDisplays dates and times in the time zone where the local node is located. *REMOTEDisplays dates and times in the time zone where the remote node is located.

The default setting for this parameter is *LOCAL. Logged Message Lifetime The maximum length of time (in days) that messages in the event log should be kept before being removed. If the age of a specific message exceeds the time limit, this message is automatically removed when the user issues the DMDSPLOGDisplay Cluster Event Log command. Specify a time limit or one of the following values:

*SAMEUses the current setting for this cluster system value. *NOMAXDisables automatic removal of event messages. This means that messages will stay in the log until you remove them.

The default setting for this parameter is 30 days. Message Generation Levels Indicates the levels of messages that will be generated by iCluster. By default, iCluster generates only those messages that have a severity of 20, 30 or 40. Messages in all levels can be generated by specifying *ALL. Specify a message level or one of the following values:

*SAMEUses the current setting for this cluster system value. 00Generates information messages (Level 00) (for example, Savefile created). 10Generates non-critical status messages (Level 10). 20Generates stop/start messages and warning (Level 20) (for example, Mirroring started). 30Generates messages that report recoverable errors (Level 30). *ALLGenerates messages in all levels.

The default settings for this parameter are 20 and 30. When specific message levels are identified, messages in other levels are not generated by iCluster. However, all fatal error messages (Level 40) are always generated. Note that more than one message level can be specified by using *ALL or by separating each message level in the parameter with a space. For example, MSGLVLS (10 20) specifies that only status and warning messages should be generated.

LATENCY Latency in iCluster is the time difference between what is on the primary node and what is on the backup node. There are two types of latency in iCluster:

Source receive latency: The time difference between the last journal entry in the primary (source) node and the last journal entry received and put into the staging store on the backup node. Target apply latency: The time difference between the last journal entry in the staging store and the last journal entry applied on the backup node.

Total latency is the sum of source receive latency and target apply latency. iCluster checks latency and issues a warning message if latency is exceeded. The LATENCY system values let you configure iCluster's latency threshold settings. Note: iCluster will issue a warning message only after the latency threshold has been exceeded for one minute.

190

Printed in Canada

iClusterVersion 5.1

Administration Commands

Latency check interval (min) Specifies how often iCluster checks for latencies (source receive and target apply) and compares them with their corresponding thresholds. Enter a value ranging between 1 - 1440 (one day), or the following value:

*SAMEKeeps the present setting for this parameter.

The default value is 5 (minutes). Source Receive threshold (min) This threshold value indicates the amount of source receive latency that is tolerated before a latency warning message is issued. Source receive latency indicates the difference between the timestamp of the journal entry last processed by the backup receiver for the journal, and the timestamp of the last journal entry deposited in the journal on the primary (source) node. For idle or lightly used journals, iCluster determines the latency by putting an entry into a journal if it has been idle for one minute since the last journal entry. Enter a value ranging between 1 and 10080 (seven days), or the following value:

*SAMEKeeps the present setting for this parameter.

The default value is 60 (minutes). Target Apply threshold (min) This threshold value indicates the amount of apply latency that can be tolerated before a latency warning message is issued. The backup apply latency is the difference in the timestamps of the last entry received by the journal's receive process and the last entry applied by the journal's apply process. Enter a value ranging between 1 and 10080 (seven days) or the following value:

*SAMEKeeps the present setting for this parameter.

The default value is 240 (minutes). CLUSTER This setting allows you to specify which failover mechanism you want the cluster to use to detect node failures. See Choosing a Failover Mechanism on page 73 for more information about this parameter before changing its value. Specify one of the following values:

*SAMEUses the current setting for this cluster system value. *NOIndicates that you want to use SwitchOver System. *YESIndicates that you want to use IBM Cluster Resource Services.

The default setting for this parameter is *NO. PERFORM Specifies the cluster system values that affect the performance of iCluster in certain scenarios. Comms channel This setting allows you to specify whether a separate communications channel is used for each group or one channel for all groups. Specify one of the following values:

*SAMEUses the current setting for this cluster system value. *SHAREDUses one communications channel for all groups.

DataMirror, an IBM Company

Printed in Canada

191

*PERGROUPEach group has its own communications channel. With separate communications channels for each group, better line utilization can be obtained and problems in one group does not affect other groups. However, this requires more communications resources.

The default setting for this parameter is *SHARED. Staging store block management This setting allows you to control how iCluster manages used staging store blocks. iCluster normally re-allocates blocks to the memory pool after they are used, but now you can choose to not re-allocate the staging store blocks for a performance improvement in situations where you are using multiple apply jobs with large data volumes. Specify one of the following values:


Example

*SAMEUses the current setting for this cluster system value. *SHAREDStaging store blocks are re-allocated to the memory pool after they are used. This is the default behavior of iCluster. *PERGROUPStaging store blocks are not re-allocated to the memory pool after they are used. This can result in a performance improvement when you are using multiple apply jobs.

The default setting for this parameter is *SHARED.

DMSETSVAL OPER(003000 000020 NO NO FULL LIB1/DEFJD 5) ACT(*NO) OBJ(*NO *NOMAX *NO *DISABLED *FULL *YES *YES) SPLF(000100 000015 *YES) PF(*LEVEL2 *AFTER *YES *PRODLIB/HADJRN *NO 5) BSF(LIB1/BSFJRN) EVNTLOG(LIB1/MSGQ1 *LOCAL 120 00 20) LATENCY(5 60 240) PERFORM(*SHARED *SHARED) OPER The default polling interval is 30 minutes. The waiting period before a communications failure is declared is 20 seconds. Object compression will turned off. Objects are not saved when they are in use. A spool file is generated during all save operations to record what was saved by iCluster. The default job description is DEFJD in library LIB1. A five second delay between the start of replication processes will occur when cluster operations are initiated for groups. ACT Automatic reactivation will not be enabled for suspended objects. OBJ Objects will not be locked on backup nodes. There is no maximum refresh size for physical files. Configuration objects replicated to backup nodes will not be held in files for creation at a later time. iCluster will automatically create these objects immediately after they are received from a primary node. All replicated user profiles will be set to a status of *DISABLED. All dependent user profiles will be replicated. User profiles will be replicated with authorization lists. User profiles (except those owned by QSYS) starting with the letter Q will be replicated. SPLF iCluster will wait a maximum of one minute for a spool file to have a status of *READY before abandoning the replication of a spool file.

192

Printed in Canada

iClusterVersion 5.1

Administration Commands

iCluster will wait 15 seconds for changes to occur to an open spool file before abandoning the replication of a spool file. Spool file contents will be mirrored. PF *LEVEL2 commitment control will be applied to replicated files. Only after images will be journaled. Physical files replicated to backup nodes will be journaled. Physical files will be journaled to the journal supplied with iCluster, HADJRN, which is located in the library where iCluster was installed. Dependent logical files will not be deleted when refreshing a physical file. After five record-level errors are produced, iCluster will suspend the file. BSF BSF objects will be journaled to the journal BSFJRN, which is located in library LIB1. EVNTLOG In addition to the event log, iCluster messages will also be placed in the message queue MSGQ1 in library LIB1. Dates and times will be displayed in the time zone where the local node is located. All messages that have been in the cluster event log for more than 120 days will be automatically removed when the DMDSPLOGDisplay Cluster Event Log command is issued. iCluster will only generate information (Level 00), warning (Level 20 and higher severity), and fatal error (Level 40) messages. LATENCY iCluster checks the latencies (source receive and target apply) and compares them to their respective thresholds every 5 minutes. The primary receive threshold is 60 minutes, and the backup apply threshold is 240 minutes. Note: It is important that at least one space separates each item contained in the OPER, ACT, OBJ, SPLF, PF, BSF, and EVNTLOG parameters. Follow the example that is provided to specify these parameters correctly.

PERFORM One communications channel is used for all groups. Staging store blocks are re-allocated to the memory pool after they are used. Use You can issue this command on any active node in the cluster. You can also issue it on an inactive node, as long as the cluster does not exist and that node is the first node that will be defined in the cluster (master node). Minimum Security Level Administrator (*ADMIN) Menu Access Main Menu - Option 6 F22 (Shift+F10) - Option 30

DMCHGTIMEChange System Date and Time


DMCHGTIME CHGTYPE( ) SYSVAL( ) VALUE( ) SECONDS( ) MINUTES( ) HOURS( ) Use this command to change the system clock's date and time. Since journal entries are processed based on their timestamp, changing the system clock can affect the order in which journal entries are processed. The DMCHGTIME command helps to ensure that journal entries are applied in the correct sequence after the system time changes backwards.
DataMirror, an IBM Company Printed in Canada 193

You must use DMCHGTIME instead of your operating system's time adjustment commands if the following conditions are both true:

The operating system is OS/400 V5R2 or earlier. The time change is less than half an hour in the past. For example, you are changing the time from 2:00 AM to 1:45 AM.

If these conditions do not apply to your computer, then DataMirror recommends using your operating system's commands to change the system time. iCluster automatically detects and handles time changes in these situations and running this command is optional. You can change only one value at a time. To change both the system date and time, you must issue this command twice. If iCluster is currently scraping a large number of journals, then this command can take a long time to run. To reduce the processing time for this command, run DMCHGTIME when system activity is low. To use this command, you must be signed on as QPGMR, QSYSOPR, QSRV, or have *ALLOBJ authority. Input Parameters

CHGTYPE Specifies the method of changing the date and/or time system values. Enter one of the following values:

*SYSVALIndicates that the system date or time will be set explicitly using SYSVAL and VALUE parameters. *FORWARDIndicates that the system time will be changed by moving the system clock forward by a specified number of hours, minutes, and/or seconds entered as separate parameters. *BACKWARDIndicates that the system time will be changed by moving the system clock backward by a specified number of hours, minutes, and/or seconds entered as separate parameters.

SYSVAL Specifies the name of the system value that you want to change. You can change either the system date or the system time. Note that this parameter is valid only when you specify *SYSVAL for the CHGTYPE parameter. Note that the new value that you enter must meet the format for the system value you specify that you want to change. Enter one of the following values:

QDATEThe system date. Changes take effect immediately. QTIMEThe system time. Changes take effect immediately.

VALUE Specifies the new value for the system parameter (either the system date or time) that you want to change. The value that you enter must meet the format for the system parameter that you are changing. Note that this parameter is valid only when you specify *SYSVAL for the CHGTYPE parameter.

SECONDS The number of seconds that the system time is incremented or decremented if either *FORWARD or *BACKWARD respectively is selected for CHGTYPE parameter. Valid entries range from 0 - 59 seconds.

MINUTES The number of minutes that the system time is incremented or decremented if either *FORWARD or *BACKWARD respectively is selected for CHGTYPE parameter. Valid entries range from 0 - 59 minutes.

194

Printed in Canada

iClusterVersion 5.1

Administration Commands

HOURS The number of hours that the system time is incremented or decremented if either *FORWARD or *BACKWARD respectively is selected for CHGTYPE parameter. Valid entries range from 0 - 23 hours.

Output Depending on which system value you modified, either the system date or time will be modified. Examples DMCHGTIME CHGTYPE(*SYSVAL) SYSVAL(QDATE) VALUE('111905') Assuming the system date is in the format "mmddyy", this command changes the job date format to November 19, 2005. DMCHGTIME CHGTYPE(*BACKWARD) HOURS(1) Changes the system time backward by one hour on any node in iCluster. Minimum Security Level You must be signed on as QPGMR, QSYSOPR, or QSRV, or else have *ALLOBJ authority. Menu Access F22 (Shift+F10) - Option 31

DMDSPLOGDisplay Cluster Event Log


DMDSPLOG EVNTTYPE( ) REPLEVNT( ) COMMEVNT( ) CLUSEVNT( ) STRDATE( ) STRTIME( ) ENDDATE( ) ENDTIME( ) MSGID( ) OUTPUT( ) DETAIL( ) MSGLVLS( ) Use this command to display event messages generated by iCluster during cluster operations. You can filter messages by replication, communication, and cluster type events. You can also filter event messages by time and date, message ID, level of detail, and message level. For more information about event logs, see Monitoring Replication on page 76. Input Parameters

EVNTTYPE The type of event messages that you want to display. Specify one of the following values:


Note:

*REPLDisplays all event messages that provide information about replication. *ALLDisplays all types of event messages. *COMMDisplays all event messages that provide information about iCluster communications between nodes. *CLUSTERDisplays all event messages that provide information concerning cluster nodes and groups, as well as the outcome of some iCluster setup and configuration.

The default setting for this parameter is *REPL. REPLEVNT A parameter that determines which replication event messages are displayed. REPLEVNT only has to be specified when EVNTTYPE (see above) is set to *ALL or *REPL. The group parameter filters replication event messages. If EVNTTYPE is not *ALL or *REPL, the command ignores this parameter. Group Name

DataMirror, an IBM Company

Printed in Canada

195

The name of an existing group that will be used to determine which replication event messages are displayed. Only replication event messages that address the referenced group will be displayed. Specify a group name or the following value:

*ALLDisplays all replication event messages regardless of group.

The default setting for this parameter is *ALL. COMMEVNT A parameter that determines which communication event messages are displayed. COMMEVNT only has to be specified when EVNTTYPE (see above) is set to *ALL or *COMM. The node name parameter filters communication event messages. You cannot filter communication event messages by group name. Note: If EVNTTYPE is not *ALL or *COMM, the command ignores this parameter. Node Name The name of the node that generated the communication event messages. Specify a node name or one of the following values: *ALL - Displays communication event messages generated by all nodes. *LOCAL - Displays communication event messages generated by the node you are currently using. The default setting for this parameter is *ALL.

CLUSEVNT A parameter that determines which cluster event messages are displayed. CLUSEVNT only has to be specified when EVNTTYPE (see above) is set to *ALL or *CLUSTER. The node name parameter filters cluster event messages generated on the node you are currently using. You cannot filter cluster event messages by group name.

Note:

If EVNTTYPE is not *ALL or *CLUSTER, the command ignores this parameter. Node Name The name of the node that generated the cluster event messages.

Note:

At this time, only *LOCAL can be specified. This setting displays cluster event messages generated by the node you are currently using. STRDATE The earliest date from which iCluster will display event messages from the event log. The date must be entered in your local system date format. If you do not specify STRDATE, this command will filter event log messages starting from the beginning of the event log.

STRTIME The earliest time from which iCluster will display event messages from the event log. The time must be entered in your local system time format. If you specify STRTIME with no STRDATE, this command will ignore this parameter.

ENDDATE The date at which iCluster will stop displaying event messages from the event log. The date must be entered in your local system date format. If you do not specify ENDDATE, this command will filter event messages to the end of the event log.

ENDTIME The time at which iCluster will stop displaying event messages from the event log. The time must be entered in your local system time format. If you specify ENDTIME with no ENDDATE, this command will not filter on an ending date and time.

196

Printed in Canada

iClusterVersion 5.1

Administration Commands

MSGID Specifies whether you want to display those messages that match a message ID. You can find message IDs in the event log. Enter a message ID or one of the following values:

*ALLSpecifies that messages for all message IDs will be displayed. *LATNCYSpecifies that only messages whose message ID is OMI0308 will be displayed. These messages are generated when either the primary receive latency or the backup apply latency threshold has been exceeded.

The default setting for this parameter is *ALL. OUTPUT Indicates whether messages are displayed on the terminal or directed to a spool file for printing. Specify one of the following values:

*Displays messages on the terminal. *PRINTDirects messages to a spool file.

The default setting for this parameter is *. DETAIL Indicates the level of detail for each message that is displayed or directed to a spool file. Specify one of the following values:

*BASICDisplays first level message text. *FULLDisplays more detailed messages (first and second levels of message text).

The default setting for this parameter is *BASIC. MSGLVLS Specifies the severity levels of messages that will be displayed. Note that messages in more than one level can be displayed by specifying *ALL or by identifying each level (see below). Note: To display the messages of a particular severity level in iCluster, you have to ensure that they are generated by setting an appropriate MSGLVLS system value in the DMSETSVALSet Cluster System Values command. Specify one of the following values:

*ALLDisplays messages in all levels. 00Displays information messages (Level 00) (for example, Savefile created). 10Displays non-critical status messages (Level 10). 20Displays stop/start messages (Level 20) (for example, Start Mirroring). 30Displays messages that report recoverable errors (Level 30).

The default setting for this parameter is *ALL. When specific message levels are identified, messages in other levels are not displayed by iCluster. However, all fatal error messages (Level 40) are displayed. Note that more than one message level can be specified by using *ALL or by separating each message level in the parameter with a space. For example, MSGLVLS (10 20) specifies that only status and warning messages should be displayed.

DataMirror, an IBM Company

Printed in Canada

197

Note:

DataMirror recommends that you initially specify *ALL for this parameter. This ensures that you will see all messages being generated. At a later time, after you have defined nodes and groups, you can identify the specific level of messages that are displayed.

Examples DMDSPLOG EVNTTYPE(*ALL) REPLEVNT(*ALL) COMMEVNT(NODE2) CLUSEVNT(*LOCAL) OUTPUT(*) DETAIL(*FULL) MSGLVLS(*ALL) Displays all types of event messages based on the specified filters. The replication event messages that will be displayed refer to any group in the cluster. The communication event messages that will be displayed are those that were generated by node NODE2. The cluster event messages that will be displayed were generated by the local node. Messages contain first and second level text and will be displayed on the terminal. Messages in all levels will be displayed. DMDSPLOG EVNTTYPE(*REPL) REPLEVNT (*ALL) OUTPUT(*PRINT) DETAIL(*BASIC) MSGLVLS(00) Displays event messages that provide information about replication (communications and cluster event messages will be hidden). These replication event messages refer to any group in the cluster. Messages contain first level text, and will be directed to a spool file. Only information (Level 00) and fatal error (Level 40) messages will be displayed. DMDSPLOG EVNTTYPE(*COMM) COMMEVNT(NODE3) OUTPUT(*) DETAIL(*BASIC) MSGLVLS(10 20) Displays event messages that provide information about communications between primary and backup nodes (replication and cluster event messages will be hidden). The communication event messages that will be displayed are those that were generated by node NODE3. Messages contain first level text and will be displayed on the terminal. Only status (Level 10), warning (Level 20), and fatal error (Level 40) messages will be displayed. DMDSPLOG EVNTTYPE(*ALL) STRDATE('08/23/2003') STRTIME('09:00') ENDDATE('08/30/2003') ENDTIME('17:00') MSGID (*ALL) OUTPUT(*PRINT) DETAIL(*BASIC) MSGLVLS(00) Displays all event messages starting August 23, 2002 at 9 am to August 30, 2003 at 5 pm on a system where the date format is 'mmddyyyy'. Messages contain first level text, and will be directed to a spool file. Only information (Level 00) and fatal error (Level 40) messages will be displayed. DMDSPLOG EVNTTYPE(*REPL) ENDDATE('08/30/2002') ENDTIME('17:00') Displays all replication event messages until August 30, 2003 at 5pm. Use You can issue this command from any node that is either active or inactive in the cluster. Minimum Security Level User (*USER) Menu Access Main Menu - Option 4 F22 (Shift+F10) - Option 32

198

Printed in Canada

iClusterVersion 5.1

Administration Commands

DMCLRLOGClear Cluster Event Log


DMCLRLOG EVNTTYPE( ) REPLEVNT( ) COMMEVNT( ) CLUSEVNT( ) Use this command to remove event messages generated by iCluster during cluster operations. The messages can be filtered by replication, communication and cluster event parameters. For more information about event logs, see Monitoring Replication on page 76. Input Parameters

EVNTTYPE The type of event messages that you want to remove. Specify one of the following values:


Note:

*REPLRemoves all event messages that provide information about replication. *ALLRemoves all types of event messages. *COMMRemoves all event messages that provide information about iCluster communications between nodes. *CLUSTERDisplays all event messages that provide information concerning cluster nodes and groups, as well as the outcome of some iCluster setup and configuration.

The default setting for this parameter is *ALL. REPLEVNT A parameter that determines which replication event messages are removed. REPLEVNT only has to be specified when EVNTTYPE (see above) is set to *ALL or *REPL. If EVNTTYPE is not *ALL or *REPL, the command ignores this parameter. The parameter that filters replication event messages is as follows: Group Name The name of a group that will be used to determine which messages are removed from the event log. Only messages that address the named group will be removed. Specify a group name or the following value:

*ALLRemoves all replication event messages regardless of group.

The default setting for this parameter is *ALL. COMMEVNT A parameter that determines the communication event messages that are removed from the log. COMMEVNT only has to be specified when EVNTTYPE (see above) is set to *ALL or *COMM. You cannot filter communication event messages by group name. Note: If EVNTTYPE is not *ALL or *COMM, the command ignores this parameter. The node name parameter filters communication event messages. Node Name The name of the node that generated the communication event messages. Specify a node name or one of the following values:

*ALLRemoves messages generated by all nodes. *LOCALRemoves messages generated by the node you are currently using.

The default setting for this parameter is *ALL. CLUSEVNT

DataMirror, an IBM Company

Printed in Canada

199

A parameter that determines which cluster event messages are removed. CLUSEVNT only has to be specified when EVNTTYPE (see above) is set to *ALL or *CLUSTER. You cannot filter cluster event messages by group name. Note: If EVNTTYPE is not *ALL or *CLUSTER, the command ignores this parameter. The parameter that filters cluster event messages is as follows: Node Name The name of the node that generated the cluster event messages. Note: At this time, only *LOCAL can be specified. This setting removes cluster event messages generated by the node you are currently using.

Examples DMCLRLOG EVNTTYPE(*ALL) REPLEVNT(*ALL) COMMEVNT(NODE2) CLUSEVNT(*LOCAL) Removes all types of event messages based on the specified filters. The replication event messages that will be removed refer to any group in the cluster. The communication event messages that will be removed are those that were generated by node NODE2. The cluster event messages that will be removed were generated by the local node. DMCLRLOG EVNTTYPE(*REPL) REPLEVNT(*ALL) Removes event messages that provide information about replication (communications and cluster event messages will be kept). The replication event messages that will be removed refer to any group in the cluster. Use You can issue this command on a node that is active or inactive in the cluster. Minimum Security Level User (*USER) Menu Access Main Menu - Option 5 F22 (Shift+F10) - Option 33

HAPNGTCPPing Using TCP


HAPNGTCP RMTNME( ) RMTPRT( ) PKTLEN( ) NBRPKT( ) RMTLIB( ) JOBD( ) Use this command to attempt to contact a specified remote node in the cluster to determine whether the node is available and operational. After entering this command, you may have to wait a few seconds before receiving a response. You can use this command as a diagnostic aid if you are having trouble replicating objects and data to the remote node. This command allows you to verify iCluster communications. Input Parameters

RMTNME The host name of a remote node in the cluster. RMTPRT The port number on the remote node that has been reserved for iCluster communications. You should specify the port number that was defined during installation. For more information about specifying the port number during installation, see Adding a New Entry 'dmcluster' to the TCP/IP Service Table on page 37.

200

Printed in Canada

iClusterVersion 5.1

Administration Commands

The default remote port number is 4545.

PKTLEN The length, in bytes, of the packets you are sending to the remote node in the cluster. The length can range from 32 bytes to 32,760 bytes. The default packet length is 256 bytes.

NBRPKT The number of packets you are sending to the remote node in the cluster. This number can range from 1 to 999 packets. The default number of packets is 5.

RMTLIB The name of the library on the remote node where iCluster was installed. The default library is DMCLUSTER. JOBD The job description associated with iCluster jobs running on the remote node. The default job description is CSJOBD.

Example HAPNGTCP RMTNME(NYSYS1) RMTPRT(4545) PKTLEN(256) NBRPKT(5) RMTLIB(ICLUS) JOBD(ICJOBD) Attempts to contact the remote node that is identified by the host name NYSYS1, and whose remote port number is 4545. Five packets will be sent, with each packet being 256 bytes in length. On the remote node, iCluster is installed in the library ICLUS and the job description ICJOBD will be associated with iCluster jobs running on the remote node. Use To invoke this command, iCluster must be installed on both the local and remote nodes, and the TCP listener job must be running on the remote node. Menu Access F22 (Shift+F10) - Option 34

JRNHADADQJournal Data Areas and Data Queues


JRNHADADQ Use this command to start data area and data queue journaling by iCluster on the objects on the system. Note: This command should be run for every machine in the cluster. This command will start journaling for any unjournaled data areas and data queues that match an object specifier defined in your iCluster installation after the operating system is upgraded from any release prior to OS/400 V5R1. Journaling will be started to the default journal of the group to where the object specifier is selected. If you would prefer to use a different journal other than the default for the group, you must either change the group default before running this command, or manually journal the objects to another journal. After starting journaling on the objects manually, or by running this command, re-starting replication will automatically refresh the objects to achieve their initial synchronization. Through journaling, only changes to these objects are mirrored, which will increase throughput and reduce network bandwidth requirements.

DataMirror, an IBM Company

Printed in Canada

201

Input Parameters None. Output Relevant messages to the job log. Examples JRNHADADQ Starts journaling any unjournaled data areas and data queues that match a specified object specifier defined in your iCluster installation. Use You need to run this command only after the upgrade of the operating system is complete. If you do not run this command after the upgrade, data areas and data queues will no longer be mirrored.

STRHATCPStart TCP/IP Listener


STRHATCP JOBD( ) LIB( ) HOST( ) SERVICE( ) Use this command to start the iCluster TCP/IP listener job (DMCHATL) on the local node. This job must be running on all nodes that are defined in the cluster. Input Parameters

JOBD The job description that you want to associate with the TCP/IP listener job (DMCHATL) that is started by this command. The default setting for this parameter is CSJOBD. LIB The library that contains the job description you want to associate with the TCP/IP listener job (DMCHATL) that is started by this command. The default setting for this parameter is DMCLUSTER.

Note:

HOST The name of the local host to be used. This parameter is usually omitted to allow the listener job to accept incoming connection requests directed to any local address. You should specify this parameter only for a multi-homed site to restrict the listener to accept incoming connection requests to a single local address. SERVICE The name of the service that identifies the local port on which the listener job will listen. This parameter is usually omitted to allow the default service dmcluster to be selected. You should specify this parameter only when it is necessary to start multiple listeners on different ports.

Example STRHATCP JOBD(TCPJOBD) LIB(LIB1) Starts the TCP/IP listener job with the job description TCPJOBD in library LIB1. The host name and TCP service name are retrieved by the job from a pre-defined data area. Use You must issue this command on the node where the operation will be performed.

202

Printed in Canada

iClusterVersion 5.1

Administration Commands

Menu Access F22 (Shift+F10) - Option 35

WRKHAJOBWork with Active Cluster Jobs


WRKHAJOB Use this command to display the active cluster jobs for the subsystem that iCluster is running under (XDMCLUSTER), plus the subsystems QCMN and QSYSWRK. To view all active jobs regardless of the subsystem, execute the OS/400 command WRKACTJOB. Input Parameters None. Example WRKHAJOB Displays the Work with Active Jobs screen so that you can view active cluster jobs for the subsystem that iCluster is running under, plus the subsystems QCMN and QSYSWRK. Use You must issue this command on the node where the operation will be performed. Menu Access F22 (Shift+F10) - Option 36

DMSTRDMStart Definition Manager


DMSTRDM Starts the definition manager on the current node. Input Prameters None. Example DMSTRDM Starts the definition manager on the node where the command was entered. Use You must issue this command on the node where the operation will be performed. The node must be active before you start the definition manager.

DMDLTCLSTRDelete Cluster
DMDLTCLSTR CLSTR( ) If invoked on an active node, this command ends cluster operations and deletes cluster definitions maintained by iCluster on all active nodes in the cluster. If this command is invoked on an inactive node, cluster operations are stopped and cluster definitions are deleted only on the node where the command is invoked. Therefore, to ensure that all cluster operations are stopped and all cluster definitions are deleted, issue this command on each node in the cluster.

DataMirror, an IBM Company

Printed in Canada

203

If a communication failure occurs between two active nodes, issue this command on both partitioned nodes to ensure cluster operations are stopped and all cluster definitions are deleted. Input Parameter

CLSTR The name of the cluster that you want to delete. This command can be used to delete any iSeries cluster. In iCluster, the name of the cluster is set internally to DM_CLUSTER, and cannot be changed.

Example DMDLTCLSTR CLSTR(DM_CLUSTER) Stops cluster operations and deletes cluster definitions in the cluster DM_CLUSTER. If invoked from an active node, cluster operations will be stopped and cluster definitions will be deleted on all active nodes in the cluster. Use You can issue this command on any node in the cluster. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 37

DMSYSINFSystem Information
DMSYSINF OUTPUT( ) Use this command to display the following iCluster system information:

Node names System names Node IP addresses iCluster version Additional features Operating system version, model number, and serial number System times This screen displays the nodes in the order that they were added to the cluster. The first node is the master node. If a node is down, the only information displayed for the node is the node name and IP address.

This command tells you if you are using Cluster Resource Services. Note: Note:

Input Parameter

OUTPUT Indicates whether system information is displayed on the console or directed to a spool file for printing. Specify one of the following values:

*Displays system information on the console. *PRINTDirects system information to a spool file for printing.

The default for this parameter is '*'.

204

Printed in Canada

iClusterVersion 5.1

Administration Commands

Output iCluster system information is sent to the console or a spool file. Example DMSYSINF OUTPUT(*) Displays system information on the console. Minimum Security Level User (*USER) Menu Access Main Menu - Option 7 F22 (Shift+F10) - Option 38

DMWRKSSPLFWork with Suspended Spooled Files


DMWRKSSPLF GROUP( ) OUTQ( ) The Work with Suspended Spooled Files (DMWRKSSPLF) command displays the suspended spooled files for a group or a group and a specific output queue. After the suspended spooled files are displayed, you can then activate selected spooled files. Input Parameter

GROUP Specifies the name of an existing replication group. OUTQ Specifies the name of an existing output queue that is in the replication scope of the specified group. Specify one of the following values:

*ALLSpecifies that suspended spooled files to be displayed can be in any output queue that is replicated by the group. output-queue-nameSpecifies the name of the output queue whose suspended spooled files are to be displayed.

The library where the output queue resides must be identified, unless the special value *ALL is specified for the output queue. Prefix the output queue with the name of the library where the output queue is located (for example, LIB2/OUTQ1). Example DMWRKSSPLF GROUP(GRP1) OUTQ(LIB1/OUTQ1) Displays the suspended spooled files for group GRP1 and output queue OUTQ1. Minimum Security Level Operator (*Operator)

DMACTSPLFActivate Spooled File


DMACTSPLF GROUP( ) OUTQ( ) SPLF( ) SPLFNBR( ) JOBNAME( ) JOBUSER( ) JOBNBR( ) SRCSYSTEM( ) TGTLIB( ) The iCluster Activate Spooled File (DMACTSPLF) command activates a spooled file that is currently suspended from replication. After activating a spooled file, mirroring of the specified spooled file will start if the replication group is active. If the replication group is inactive, mirroring will start when the group is activated through the DMSTRGRP or DMSTRAPP command.

DataMirror, an IBM Company

Printed in Canada

205

Note:

The spooled file will be refreshed when it is activated.

This command must be invoked on an active node in the cluster. Input Parameter

GROUP Specifies the name of the replication group to which the output queue of the spooled file is selected. OUTQ The name of the output queue that contains the suspended spooled file that you want to activate. The library where the output queue resides must be identified, unless the special value *ALL is specified for the output queue. Prefix the output queue with the name of the library where the output queue is located (for example, LIB2/OUTQ1).

SPLF Specifies the name of the suspended spooled file that you want to activate. SPLFNBR Specifies the number of the suspended spooled file that you want to activate. JOBNAME Specifies the name of the job that created the suspended spooled file that you want to activate. JOBUSER Specifies the user of the job that created the suspended spooled file that you want to activate. JOBNBR Specifies the number of the job that created the suspended spooled file that you want to activate. SRCSYSTEM Specifies the machine name on which the suspended spooled file that you want to activate was created. TGTLIB Specifies the library of the output queue on the backup node to which the suspended spooled file will be refreshed when activated.

Example DMACTSPLF GROUP(GRP2) OUTQ(LIB2/OUTQ2) SPLF(QPJOBLOG) SPLFNBR(000001) JOBNAME(MYJOB) JOBUSER(USER1) JOBNBR(654321) SRCSYSTEM(MACHINEA) TGTLIB(LIB3) Activates the specified spooled file. Minimum Security Level Operator (*Operator) Menu Access F22 (Shift+F10) - Option 79

206

Printed in Canada

iClusterVersion 5.1

Cluster Operation Commands

Cluster Operation Commands


This section contains the following topics:

DMSTRNODEStart Cluster Operations at Node on page 207 DMENDNODEEnd Cluster Operations at Node on page 208 DMSTRGRPStart Cluster Operations at Group on page 208 DMSTRREPLStart Replication on page 211 DMENDGRPEnd Cluster Operations for Group on page 213 DMSTRWOSwitchover Group on page 215 DMREJOINiCluster Rejoin Cluster on page 216 DMSTRAPPStart Cluster Operations for Resilient Application on page 217 DMENDAPPEnd Cluster Operations for Resilient Application on page 218 DMSWOAPPSwitchover Resilient Application on page 220 DMSETPRIMPrepare Primary Node on page 220 DMCHGROLEChange Group Primary Node on page 221 DMGENEXCGenerate Command Exceptions on page 222

DMSTRNODEStart Cluster Operations at Node


DMSTRNODE NODE( ) Use this command to start cluster operations at the specified node. High availability support for active groups that have this node in their recovery domain is also started. This command sets the status of the specified node to *ACTIVE. If the node is the backup node of a group that has an active status, cluster operations for the group will also be started at the specified node. Input Parameter

NODE The name of the node where cluster operations will be started.

Example DMSTRNODE NODE(NODE1) Starts cluster operations at node NODE1. Sets the status of the node to active. If NODE1 is the backup node of an active group, cluster operations for the group will also be started at this node. Use You must issue this command on an active node in the cluster unless there are no active nodes in the cluster. Note: If this command is invoked on different nodes, separate clusters are effectively activated. To ensure that only a single cluster is maintained, issue this command for each node in the cluster from a single node. The first time you invoke the command, reference the name of the single node. Then, from the single node, issue the command for each other node in the cluster.

DataMirror, an IBM Company

Printed in Canada

207

Minimum Security Level Operator (*OPERATOR) Menu Access Main Menu - Option 11 F22 (Shift+F10) - Option 40 Work With Nodes screen - Option 1

DMENDNODEEnd Cluster Operations at Node


DMENDNODE NODE( ) Use this command to end cluster operations at the specified node. Use this command if you intend to re-start cluster operations at the specified node. Otherwise, use the DMRMVNODERemove Node command to remove the specified node from the cluster when it is active. This command sets the status of the specified node to *INACTIVE. If the node is the backup node of a replication group that has an active status, cluster operations for the group will also be stopped at the specified node before cluster operations at the node are ended. The replication group will still have a status of *ACTIVE even though replication operations have stopped. Note: Cluster operations at the node cannot be stopped if the specified node is a primary node in an active replication group.

Input Parameter

NODE The name of the node where cluster operations will be stopped.

Example DMENDNODE NODE(NODE1) Ends cluster operations at node NODE1. Sets the status of the node to inactive. If NODE1 is the backup node of an active replication group, cluster operations for the group will be ended at this node before cluster operations for the node are stopped. Use You must issue this command on an active node in the cluster. Minimum Security Level Operator (*OPERATOR) Menu Access Main Menu - Option 12 F22 (Shift+F10) - Option 41 Work With Nodes screen - Option 4

DMSTRGRPStart Cluster Operations at Group


DMSTRGRP GROUP( ) PRIMNODE( ) STRAPY( ) REFRESH( ) TRUNCATE( ) REPLACELFS( ) USEMARKED( )

208

Printed in Canada

iClusterVersion 5.1

Cluster Operation Commands

Use this command to start cluster operations for the specified cluster resource groups. The high availability support provided by iCluster is started for replication groups and WebSphere MQ groups. This command also sets the cluster status of the specified groups to *ACTIVE. If the groups are replication groups, the replication status of the groups will become *ACTIVE when replication processes are started. Note: Note: The STRAPY, REFRESH, and USEMARKED parameters are ignored if the group is a *SWDEV group. See DMADDGRPAdd Group on page 113 for more information. The REFRESH and USEMARKED parameters are ignored if the group is a *RFSH group. See DMADDGRPAdd Group on page 113 for more information.

Input Parameters

GROUP The name of the group that has cluster operations started by this command. Specify the name of the group or one of the following values:

*ALLStarts all groups on all nodes, regardless of their current recovery domain. *PRIMNODEStarts all groups with the primary node specified. If you specify this option, you must specify the name of the primary node in the PRIMNODE parameter (see below).

PRIMNODE Indicates the name of the primary node for the groups to be started. This parameter is only applicable when the GROUP parameter (see above) is set to *PRIMNODE. STRAPY Indicates whether the apply process for the replication group will be started on the backup node when mirroring begins. Specify one of the following values:

*NOCHGIndicates that the last operational status of the apply jobs on the backup node remains in affect. *YESIndicates that the apply jobs on the backup node for the replication group will be started. This does not apply to suspended files. *NOIndicates that the apply jobs on the backup node for the replication group will not be started.

The default for this parameter is *NOCHG. REFRESH Indicates whether an initial refresh of selected objects in the replication group is performed before mirroring is started. If the USEMARKED parameter is set to *YES, this parameter is ignored. Specify one of the following values:

*YESSpecifies that an initial refresh of selected objects in the replication group is performed. *NOSpecifies that an initial refresh of selected objects in the replication group is not performed. *MQRUNSTRRefreshes objects on the backup node for Websphere MQ groups and is recommended for environments where WMQ transactions may be started while the group is inactive. This option is similar to *YES, except that the apply jobs will process MQ journal entries from the time the group was last ended instead of from the time you run the command. You can only use this option with MQ Series groups that were previously active. If you unexpectedly began a refresh (by selecting the *YES option for the REFRESH parameter) and then ended the refresh before completion (due to system constraints), you must contact DataMirror technical support for assistance. See Contacting Technical Support on page 547 for more information. You must perform a number of steps following a discontinued refresh to allow mirroring to re-start properly. If these steps are not performed following a discontinued refresh, mirroring may not work as you intended.

The default setting for this parameter is *NO. Warning:

DataMirror, an IBM Company

Printed in Canada

209

If you intentionally began a refresh that ended unexpectedly (for example, power failure), you must re-start the refresh.

TRUNCATE Indicates whether you want to remove existing data before performing a refresh. Specify one of the following values:

*YESIndicates that you want to remove and recreate existing data files as part of a refresh. This is the default behavior for iCluster and is appropriate for standard iCluster replication. You can use this option for a mastermaster group if the data on the source system is known to be complete in order to ensure a synchronized starting point. With this value, logical files are replaced automatically because the deletion of a physical file requires the deletion of all logical files upon which it is based. *NOIndicates that you do not want to remove existing data before performing a refresh. This option is appropriate for master-master replication.

The default setting for this parameter is *NO. See Master-Master ReplicationOperations and Monitoring on page 323 for more information on the refresh options that are specific to master-master replication groups. Note: This parameter only applies to iBalance and *MSTRMSTR replication groups. See iBalance and MasterMaster Replication on page 321 for more information on this feature. REPLACELFS Indicates whether you want to replace logical files during a refresh. Specify one of the following values:


Note:

*YESIndicates that you want to replace logical files during a refresh. This is the default behavior for iCluster and is appropriate for standard replication. You can use this option for a master-master group if the logical files on the source system are the complete set required for your applications in order to ensure a synchronized starting point. *NOIndicates that you want to use existing logical files during a refresh. This option is appropriate for mastermaster replication.

iCluster does not require logical files based on the replicated physical file to be the same on source and target systems if they are not in replication scope. The default setting for this parameter is *NO. See Master-Master ReplicationOperations and Monitoring on page 323 for more information on the refresh options that are specific to master-master replication groups.

Note:

This parameter only applies to iBalance and *MSTRMSTR replication groups. See iBalance and MasterMaster Replication on page 321 for more information on this feature. USEMARKED Indicates whether mirroring is started at the marked journal positions for the specified replication group. Note that these journal positions are marked through the DMMRKPOSMark Current Journal Positions command, and are maintained in the iCluster metadata. Specify one of the following values:

*NOIndicates that iCluster replication will not start at positions marked using the DMMRKPOSMark Current Journal Positions command. Journal positions set using the DMSETPOSSet Journal Start Position command. Journal positions registered using the DMREGPOSRegister Positions command.

iCluster replication will start at either:

210

Printed in Canada

iClusterVersion 5.1

Cluster Operation Commands

The journal entry following the last journal position received on the backup system when replication was previously stopped. *YESIndicates that mirroring will start at the journal positions that have been marked for the specified replication group through the DMMRKPOSMark Current Journal Positions command. Note that the primary and backup nodes must have been synchronized at the time the DMMRKPOSMark Current Journal Positions command was issued. The REFRESH parameter is ignored when this parameter is set to *YES.

Note that specifying *YES on this parameter will overwrite any starting journal positions previously journaled by the DMSETPOSSet Journal Start Position or DMREGPOSRegister Positions commands. The default setting for this parameter is *NO. Note: If the DMMRKPOSMark Current Journal Positions command has not been invoked for the named replication group, and the value specified for this parameter is *YES, mirroring is started at the last replication position.

Examples DMSTRGRP GROUP(GRP1) STRAPY(*YES) USEMARKED(*YES) Mirroring will start at the journal positions that have been marked for GRP1 through the DMMRKPOS command. Update/apply jobs on the backup node will be started. DMSTRGRP GROUP(GRP2) STRAPY(*NO) REFRESH(*NO) TRUNCATE(*NO) REPLACELFS(*NO) USEMARKED(*NO) An initial refresh of selected objects in replication group GRP2 is not performed before mirroring is started. Existing logical files are not used during the refresh, and existing data is not removed before performing the refresh. Mirroring is started at the last replication positions for the replication group GRP2. The apply job on the backup node is not started when mirroring begins. Any updates that are in progress is stopped in a controlled manner. DMSTRGRP GROUP(*PRIMNODE) PRIMNODE(AS400HQ) STRAPY(*NO) USEMARKED(*NO) All groups that have node AS400HQ as their primary node are started. An initial refresh is not performed before mirroring is started. Replication starts at the last replication positions for all groups of type *REPL and *MQSERIES that have the specified primary node. A full refresh is performed for groups of type *RFSH that have the specified primary node. The apply job on the backup node is not started when mirroring begins. Any updates that are in progress are stopped in a controlled manner. Use You must issue this command on an active node in the cluster. Minimum Security Level Operator (*OPERATOR) Menu Access Main Menu - Option 13 F22 (Shift+F10) - Option 43 Work With Groups screen - Option 1

DMSTRREPLStart Replication
DMSTRREPL GROUP( ) STRAPY( ) REFRESH( ) USEMARKED( )

DataMirror, an IBM Company

Printed in Canada

211

Use this command to start replication for the specified replication group or resilient application. Note: This command should only be invoked for groups or resilient applications in *ACTIVE status. To start replication for an inactive group, use the DMSTRGRP command.

Before using this command, you must identify why replication is not active. If the reason for replication failing or not starting is unclear, contact DataMirror Technical Support for assistance. See Contacting Technical Support on page 547 for more information. Input Parameters

GROUP The name of the replication group or resilient application for which replication will be started by this command. STRAPY Indicates whether the apply process on the replication group's or resilient application's backup node will be started when mirroring begins. Specify one of the following values:

*NOCHGSpecifies that the current operational status of update/apply job on the backup node is not changed. *YESIndicates that the backup node update/apply job for the replication group or resilient application will be started. This does not apply to suspended files. *NOIndicates that the backup node update/apply job for the replication group or resilient application will not be started.

The default for this parameter is *NOCHG. REFRESH Indicates whether an initial refresh of objects selected to the replication group or resilient application is performed before mirroring is started. If the USEMARKED parameter (see below) is set to *YES, this parameter is ignored. Specify one of the following values:


Warning:

*YESSpecifies that an initial refresh of selected objects is performed. *NOSpecifies that an initial refresh of selected objects is not performed. If you unexpectedly began a refresh (by selecting the *YES option for the REFRESH parameter) and then ended the refresh before completion (due to system constraints), you should contact DataMirror technical support for assistance. See Contacting Technical Support on page 547 for more information. You must perform a number of steps following a discontinued refresh to allow mirroring to re-start properly. If these steps are not performed following a discontinued refresh, mirroring may not work as you intended.

The default setting for this parameter is *NO.

If you intentionally began a refresh that ended unexpectedly (for example, power failure), you should re-start the refresh.

USEMARKED Indicates whether mirroring is started at the marked journal positions for the specified replication group or resilient application. Note that these journal positions are marked through the DMMRKPOSMark Current Journal Positions command, and are maintained in the iCluster metadata. Specify one of the following values:

*NOIndicates that iCluster will start mirroring from either the saved journal positions when replication was previously stopped, the journal positions marked through the DMSETPOSSet Journal Start Position command prior to issuing this command, or if there are no saved or marked journal positions, mirroring will start at the last replication positions for objects selected to the replication group or resilient application.
Printed in Canada

212

iClusterVersion 5.1

Cluster Operation Commands

*YESStarts mirroring at the journal positions that have been marked for the specified replication group or resilient application through the DMMRKPOSMark Current Journal Positions command. Note that the primary and backup nodes must have been synchronized at the time the DMMRKPOSMark Current Journal Positions command was issued. The REFRESH parameter (see above) will be ignored when this parameter is set to *YES.

The default setting for this parameter is *NO. Note: If the DMMRKPOSMark Current Journal Positions command has not been invoked for the named replication group or resilient application, and the value specified for this parameter is *YES, mirroring is started at the last replication positions.

Examples DMSTRREPL GROUP(GRP1) STRAPY(*YES) USEMARKED(*YES) Mirroring will be started at the journal positions that have been marked for GRP1 through the DMMRKPOS command. Update/apply jobs on the backup node will be started. DMSTRREPL GROUP(APP2) STRAPY(*NO) REFRESH(*NO) USEMARKED(*NO) An initial refresh of objects selected to resilient application APP2 will not be performed before mirroring is started. Mirroring will be started at the last replication positions for the resilient application GRP2. The apply job on the backup node will not be started when mirroring begins. Any updates that are in progress will be stopped in a controlled manner. Use You can issue this command on an active node in the cluster when the replication group or resilient application has a status of *ACTIVE but is not replicating. Minimum Security Level Operator (*OPERATOR) Menu Access F22 (Shift+F10) - Option 44

DMENDGRPEnd Cluster Operations for Group


DMENDGRP GROUP( ) PRIMNODE( ) OPTION( ) DELAY( ) Use this command to end cluster operations for the specified groups. This command sets the cluster status of the specified groups to *INACTIVE. If replication for a group fails, the group should be ended using this command. Input Parameters

GROUP The name of the active group that will have cluster operations stopped by this command. Specify the name of the group or one of the following values:

*ALLEnds all groups on all nodes, regardless of their current recovery domain. *PRIMNODEEnds all groups with the specified primary node. If you specify this option, you must specify the name of the primary node in the PRIMNODE parameter (see below).

PRIMNODE

Indicates the name of the primary node of the groups that will end cluster operations. This parameter is only applicable when the GROUP parameter (see above) is set to *PRIMNODE.

DataMirror, an IBM Company

Printed in Canada

213

OPTION Indicates how replication for the group is stopped. Replication within the group can be stopped immediately or in a controlled manner. An immediate stop concludes replication at the point when the command is invoked. As a result, iCluster may not be able to guarantee that replication is stopped in the desired manner. On the other hand, a controlled stop allows iCluster to perform the necessary tasks to ensure that replication is gracefully ended. However, the completion of these tasks may take some time. DataMirror recommends performing a controlled stop when possible. Specify one of the following values:

*CNTRLDEnds replication for the group in a controlled manner. *IMMEDEnds replication for the group immediately.

The default setting for this parameter is *CNTRLD. DELAY The maximum amount of time (expressed in seconds) for replication to stop in a controlled manner without intervention. This parameter allows you to specify a timeout period for stopping replication. If, for some reason, replication cannot be completed within the timeout period, it will be immediately stopped after the timeout period expires. This parameter is only applicable when the OPTION parameter (see above) is set to *CNTRLD. The default setting for this parameter is 3600 seconds. Note: Long running refreshes or commitment control may require a longer timeout to ensure consistency of the data on the backup system. Note that there are certain conditions where the apply job(s) for a group may not end quickly. For example, if commitment control is used, the apply cannot end until it reaches a point where there are no open commit cycles. For a busy system, this may take a very long time (if ever) to happen. Another example would be when a large refresh is taking place. It is therefore important that situations such as those mentioned be considered and a timeout is set appropriately to ensure the backup database is in a consistent state while the apply is inactive. In general, the default setting for this parameter should be long enough, but individual circumstances may require a longer timeout. Examples DMENDGRP GROUP(GRP1) OPTION(*IMMED) Cluster operations for group GRP1 will be immediately stopped. DMENDGRP GROUP(GRP2) OPTION(*CNTRLD) DELAY(120) Cluster operations for group GRP2 will be stopped in a controlled manner. If replication cannot be stopped in a controlled manner within 120 seconds (two minutes) after the command was invoked, replication within GRP2 will be immediately stopped. DMENDGRP GROUP(*ALL) OPTION(*IMMED) Cluster operations are ended immediately for all groups on all nodes, regardless of your current recovery domain. UseYou must issue this command on an active node in the cluster. Minimum Security Level Operator (*OPERATOR) Menu Access Main Menu - Option 4 F22 (Shift+F10) - Option 45

214

Printed in Canada

iClusterVersion 5.1

Cluster Operation Commands

DMSTRWOSwitchover Group
DMSTRSWO GROUP( ) STRREPL( ) Use this command to initiate a role switch within the specified cluster resource group(s). Therefore, this command causes a switchover involving the primary and backup nodes in the group(s). When you issue this command, the current primary node becomes the backup node, and the current backup node assumes the role of the primary node. In addition, the user exit program(s) that may have been specified for the group will be invoked on the new primary node. See DMADDGRPAdd Group and DMCHGGRPChange Group for more information. This command must be invoked on an active node in the cluster. However, it can only be applied to active groups. Note: Note: This command supports spooled file replication on the primary and backup node(s) as of i5/OS V5R4. To initiate a group switchover, the status of low-level cluster support provided by IBM's OS/400 Cluster Resource Services for the group must be *ACTIVE. See DMWRKGRPWork with Groups for more information. A message stating whether or not the role switch completed successfully is placed into the event log on all nodes of the cluster. For more information about event logs, see Monitoring Replication on page 76.

Note:

Input Parameters

GROUP The name of the cluster resource group where the roles of the primary and backup nodes in the group will be reversed. Specify the name of a cluster resource group or the following value:

*ALLSwitches the roles of primary and backup nodes in all active groups defined in iCluster that are not part of a resilient application.

STRREPL Indicates whether or not to re-start replication after a switchover has completed. Specify one of the following values:

*YESIndicates that replication processes for the group will be re-started from the new primary node to the new backup node when switchover processing is complete. This is the default setting. *NOIndicates that replication processes for the group will not be re-started from the new primary node to the new backup node when switchover processing is complete. If this value is specified, the DMSTRREPLStart Replication command can be used to re-start replication at a later time. The Use marked journal positions (USEMARKED) parameter must be set to *YES when invoking the DMSTRREPLStart Replication command for the first time after a switchover.

Examples DMSTRSWO GROUP(GRP1) STRREPL(*YES) Switches the roles of primary and backup nodes in the active replication group GRP1. With the STRREPL parameter set to *YES, replication processing will be re-started from the new primary node to the new backup node when switchover processing is complete. This is the default setting. If one of the user exit program(s) was specified for group GRP1 through the DMADDGRPAdd Group or DMCHGGRP Change Group commands, they will be invoked on the new primary node. DMSTRSWO GROUP(*ALL) STRREPL(*NO) Switches the roles of primary and backup nodes in all active groups defined in iCluster that are not part of a resilient application. With the STRREPL parameter set to *NO, replication processing will not be re-started from the new primary node to the new backup node when switchover processing is complete.

DataMirror, an IBM Company

Printed in Canada

215

User exit programs that may have been specified for each group through the DMADDGRPAdd Group or DMCHGGRP Change Group commands will be invoked on the new primary nodes. Use You must issue this command on an active node in the cluster. However, it can only be applied to active groups. Minimum Security Level Administrator (*ADMIN) Menu Access Main Menu - Option 15 F22 (Shift+F10) - Option 46 Work With Groups screen - Option 20

DMREJOINiCluster Rejoin Cluster


DMREJOIN NUMTRIES( ) DELAY( ) STARTNEW( ) Use this command to re-start cluster node operations on the current machine in such a way that it rejoins the cluster of which it was a previously an active member. It also sets the status of the node on the current machine to active if the node successfully rejoins the cluster. If the current machine's node is the backup node of a group that has active status, cluster group operations will also be started at the current machine's node through this command. This command requires that the current machine is inactive in the cluster and is recognized as a node by at least one active node in the cluster. Note that this command may take a few minutes to complete. Input Parameters

NUMTRIES Specifies the number of attempts that will be made to rejoin an existing cluster. The default value is one attempt. DELAY Specifies the time interval in seconds between attempts to re-start cluster operations at the current node. The default delay time is 10 seconds. STARTNEW Specifies whether or not a new cluster will be started on the current machine if attempts to rejoin an existing cluster fail. Enter one of the following values:


Output

*YESIndicates that you want to start a new cluster on the current machine if attempts to rejoin an existing cluster fail. The new cluster will not be part of an existing cluster. *NOIndicates that you do not want to start a new cluster on the current machine if attempts to rejoin an existing cluster fail. The current node will remain inactive if attempts to rejoin an existing cluster fail. This is the default value for this parameter.

The status of the node should change to *ACTIVE. Example DMREJOIN NUMTRIES(5) DELAY(10) STARTNEW(*NO) iCluster will attempt to re-start operations, to a maximum of five times, on the current machine.
216 Printed in Canada

iClusterVersion 5.1

Cluster Operation Commands

Use You can issue this command only on an inactive node in the cluster. Minimum Security Level Administrator (*ADMIN) Menu Access F22 (Shift+F10) - Option 42

DMSTRAPPStart Cluster Operations for Resilient Application


DMSTRAPP APPNAME( ) STRAPY( ) REFRESH( ) USEMARKED( ) Use this command to start cluster operations for the specified resilient application. Objects associated with the application are identified through groups that are defined in the data areas and files provided by the application vendor. Therefore, this command ensures that application objects are mirrored to nodes in the application group to support a resilient application switchover or failover. See DMSWOAPPSwitchover Resilient Application on page 220 for more information. You can perform an initial refresh of the application objects before starting cluster operations. Cluster operations for groups that identify application objects are started in an indeterminate order. If the application requires operations to be started in a specific order, the order must be defined through a user exit provided by the application vendor. For groups that have no object specifiers, the replication process will not be started, and the group, and resilient application, if it is part of a resilient application, will stay in *ACTIVE status (even though its replication status will be *INACTIVE). This allows a switchover to be performed on the group and its resilient application, if applicable. Input Parameters

APPNAME The name of a resilient application that you have defined in iCluster. Cluster operations in application groups will be started. STRAPY Indicates whether the apply process for the replication groups associated with the resilient application will be started on the backup node when mirroring begins. Specify one of the following values:

*NOCHGIndicates that the current operational status of the apply jobs on the backup node is not changed. *YESIndicates that the apply jobs on the backup node for the replication groups associated with the resilient application will be started. This does not apply to suspended files. *NOIndicates that the apply jobs on the backup node for the replication groups associated with the resilient application will not be started.

The default setting for this parameter is *NOCHG. REFRESH Indicates whether an initial refresh of objects for replication groups is performed before mirroring is started. If the USEMARKED parameter (see below) is set to *YES, this parameter is ignored. Specify one of the following values:

*YESIndicates that an initial refresh of objects for replication groups will be performed. *NOIndicates that an initial refresh of objects for replication groups will not be performed.

DataMirror, an IBM Company

Printed in Canada

217

The default setting for this parameter is *NO. Warning: If you unexpectedly began a refresh (by selecting the *YES option for the REFRESH) and then ended the refresh before completion (due to system constraints), you should contact DataMirror technical support for assistance. See Contacting Technical Support on page 547 for more information. You must perform a number of steps following a discontinued refresh to allow mirroring to re-start properly. If these steps are not performed following a discontinued refresh, mirroring may not work as you intended.

If you intentionally began a refresh that ended unexpectedly (for example, power failure), you should re-start the refresh.

USEMARKED Indicates whether mirroring is started at the marked journal positions for the specified resilient application. Note that these journal positions are marked through the DMMRKPOSMark Current Journal Positions command, and are maintained in the iCluster metadata. Specify one of the following values:

*NOIndicates that iCluster will start mirroring from either the saved journal positions when replication was previously stopped, the journal positions marked through the DMSETPOSSet Journal Start Position command prior to issuing this command, or if there are no saved or marked journal positions, mirroring will start at the last replication positions for objects selected to the application groups. *YESIndicates that mirroring is started at the journal positions that have been marked for the specified resilient application through the DMMRKPOSMark Current Journal Positions command. Note that the primary and backup nodes must have been synchronized at the time the DMMRKPOSMark Current Journal Positions command was issued. The REFRESH parameter (see above) will be ignored when this parameter is set to *YES.

The default setting for this parameter is *NO. Note: If the DMMRKPOSMark Current Journal Positions command has not been invoked for the named resilient application, and the value specified for this parameter is *YES, mirroring is started at the last replication positions.

Example DMSTRAPP APPNAME(OEPACK) USEMARKED(*YES) Cluster operations are started for the resilient application OEPACK. Mirroring will be started at the journal positions that have been marked for OEPACK through the DMMRKPOSMark Current Journal Positions command. Use You must issue this command on an active node in the cluster. Minimum Security Level Operator (*OPERATOR) Menu Access Main Menu - Option 22 F22 (Shift+F10) - Option 47 Work With Resilient Applications screen - Option

DMENDAPPEnd Cluster Operations for Resilient Application


DMENDAPP APPNAME( ) OPTION( ) DELAY( ) Use this command to end cluster operations for the specified resilient application.

218

Printed in Canada

iClusterVersion 5.1

Cluster Operation Commands

Objects associated with the application are identified through groups that are defined in the data areas and files provided by the application vendor. Therefore, this command stops mirroring to the resilient applications backup node. You can specify the manner in which replication is stopped (either immediately or in a controlled manner). Replication within groups that identify application objects is stopped in an indeterminate order. If the application requires replication to be stopped in a specific order, the order must be defined through a user exit provided by the application vendor. If replication for a resilient application fails, you should end the resilient application using this command. Input Parameters

APPNAME

The name of a resilient application that you have defined in iCluster. Cluster operations in application groups will be stopped. OPTION Indicates how replication for the replication groups is stopped. Replication for the replication groups can be stopped immediately or ended in a controlled manner. An immediate stop concludes replication at the point when the command is invoked. As a result, iCluster may not be able to guarantee that replication is stopped in the desired manner. On the other hand, a controlled stop allows iCluster to perform the necessary tasks to ensure that replication is gracefully ended. However, the completion of these tasks may take some time. DataMirror recommends performing a controlled stop when possible. Specify one of the following values:

*CNTRLDEnds replication for the replication groups in a controlled manner. *IMMEDEnds replication for the replication groups immediately.

The default setting for this parameter is *CNTRLD. DELAY The maximum amount of time (expressed in seconds) for replication to stop in a controlled manner without intervention. This parameter allows you to specify a timeout period for stopping replication. If, for some reason, replication cannot be completed within the timeout period, it will be immediately stopped after the timeout period expires. This parameter is only applicable when the OPTION parameter (see above) is set to *CNTRLD. The default setting for this parameter is 3600 seconds. Example DMENDAPP APPNAME(OEPACK) OPTION(*CNTRLD) DELAY(60) Cluster operations are stopped for the resilient application OEPACK. Replication associated with OEPACK is stopped in a controlled manner. If replication cannot be stopped in a controlled manner within 60 seconds (one minute) after the command was invoked, replication will be immediately stopped. Use You must issue this command on an active node in the cluster. Minimum Security Level Operator (*OPERATOR) Menu Access Main Menu - Option 23 F22 (Shift+F10) - Option 48

DataMirror, an IBM Company

Printed in Canada

219

Work With Resilient Applications screen - Option 4

DMSWOAPPSwitchover Resilient Application


DMSWOAPP APPNAME( ) DELAY( ) STRREPL( ) Use this command to initiate a role switch within the groups associated with the specified resilient application. Therefore, this command causes a switchover involving the primary and backup nodes in the resilient application. After using this command, the current primary node in each group becomes the backup node, and the current backup node in each group assumes the role of the primary node. Note: A message stating whether or not the role switch completed successfully is placed into the event log on all nodes of the cluster. For more information about event logs, see Monitoring Replication on page 76.

Input Parameters

APPNAME

The name of a resilient application that you have defined in iCluster. A role switch will be performed in the groups associated with the specified resilient application. DELAY Specifies the time, in seconds, that is allowed between a switchover of the application groups associated with the specified resilient application, and switchover of the replication groups associated with the specified resilient application. STRREPL Indicates whether or not to re-start replication after a switchover has completed. Specify one of the following values:


Example

*YESIndicates that replication will re-start after a switchover. *NOIndicates that replication will not re-start after a switchover.

The default setting for this parameter is *YES.

DMSWOAPP APPNAME(OEPACK) DELAY (30) STRREPL(*YES) Switches the roles of primary and backup nodes in the groups associated with the resilient application OEPACK. There will be a delay of 30 seconds between the switchover of the associated application group and the replication group. Replication will re-start after the switchover. Use You must issue this command on an active node in the cluster. Minimum Security Level Administrator (*ADMIN) Menu Access Main Menu - Option 24 F22 (Shift+F10) - Option 49 Work With Resilient Applications screen - Option 20

DMSETPRIMPrepare Primary Node


DMSETPRIM GROUP( )

220

Printed in Canada

iClusterVersion 5.1

Cluster Operation Commands

Use this command to perform the necessary tasks to prepare a group or resilient application's primary node to be the source node for replication after a failover of the group's primary node has occurred. After preparation is complete, the node can be the source node for replication for the group or resilient application. This command is intended for groups that do not have the automatic role switch mechanism enabled (set to *NO). An automatic role switch is enabled or disabled by setting the ROLESWITCH parameter in the DMADDGRPAdd Group or DMCHGGRPChange Group commands. In this situation, this command will prepare the primary node to become the source node for replication as part of its failover processing. In addition, the user exit program(s) that may have been specified for the group will be invoked on the new primary node. See DMADDGRPAdd Group or DMCHGGRP Change Group for more information. Note: A message stating whether or not the role switch completed successfully is placed into the event log on all nodes of the cluster. For more information about event logs, see Monitoring Replication on page 76. This command is not available when the Use OS/400 Cluster Services system value is *NO. See DMSETSVALSet Cluster System Values on page 181 for more information on system values. Input Parameter

GROUP The name of the replication group or application that will have its primary node prepared by this command.

Examples DMSETPRIM GROUP(GRP1) After a failover (with *ROLESWITCH set to *NO), the GRP1 replication group will have its primary node prepared to be the active node for replication. If a user exit program was specified for group GRP1 through the DMADDGRPAdd Group or DMCHGGRPChange Group commands, it will be invoked on the new primary node. Use You must issue this command on an active node in the cluster. Minimum Security Level Operator (*OPER) Menu Access F22 (Shift+F10) - Option 50

DMCHGROLEChange Group Primary Node


DMCHGROLE GROUP( ) PRIMNODE( ) This command changes the specified groups' or resilient applications' primary node to the current first backup node. The groups or resilient applications will remain *INACTIVE until they are started with the DMSTRGRPStart Cluster Operations at Group or DMSTRAPPStart Cluster Operations for Resilient Application commands. The current backup is prepared to become the primary node in the same way as occurs if a failover happens when the group is active. Note: A message (CSI1314) stating whether or not the role switch completed successfully is placed into the event log on all nodes of the cluster. For more information about event logs, see Monitoring Replication on page 76.

Input Parameter

GROUP

The name of the group or resilient application. If you specify a group or resilient application, the group (or groups of the resilient application) has to be in *INACTIVE status.

DataMirror, an IBM Company

Printed in Canada

221

Specify the name of the group or resilent application or one of the following values:

*ALL - Performs a role switch for all groups and resilient applications in the cluster. Changes the primary node of all groups and resilient applications in the cluster to the current first backup node. *PRIMNODE - Performs a role switch for all groups and resilient applications whose primary node is specified on the PRIMNODE parameter. If you specify this option, you must specify the name of the primary node in the PRIMNODE parameter (see below).

PRIMNODE Indicates the name of the primary node of the groups and resilient applications for which you are performing a role switch. This parameter is only applicable when the GROUP parameter (see above) is set to *PRIMNODE.

Examples DMCHGROLE GROUP(GROUP1) Changes the primary node to the backup node and the backup node to the primary node. The group or resilient application must have a status of *INACTIVE. DMCHGROLE GROUP(*ALL) Changes the primary node to the backup node and the backup node to the primary node for all groups and resilient applications in the cluster. The groups or resilient applications must have a status of *INACTIVE. Use You can invoke the DMCHGROLEChange Group Primary Node command on an active node in the cluster for groups or applications in *INACTIVE status. Minimum Security Level Admin (*ADMIN) Menu Access F22 (Shift+F10) - Option 51 Work With Groups screen - Option 20 Work With Resilient Applications screen - Option 20

DMGENEXCGenerate Command Exceptions


DMGENEXC GENEXC( ) Use this command to generate an exception whenever an iCluster command fails or results in no action. For example, if you are running iCluster commands in a user exit program, this command allows you to detect command failures by generating an exception. Note: This command generates an exception with an ID of CSI9954. For more information on what command caused this exception, examine the previous messages in the job log or in the event log for each node in the cluster.

If you want to enable this feature in your role switch user exit program, you must place the call to DMGENEXC GENEXC *YES before any calls to commands in your user exit program. When iCluster encounters the CSI9954 exception, role switch processing is stopped and declared incomplete. Input Parameter

GENEXC Indicates whether exception generation is enabled or disabled for commands that fail or result in no action. Specify one of the following values:

222

Printed in Canada

iClusterVersion 5.1

Cluster Operation Commands


Example

*NODoes not generate exceptions for commands that fail. *YESGenerates exceptions for commands that fail.

The default setting for this parameter is *NO.

DMGENEXC GENEXC(*YES) iCluster generates an exception for commands that fail or result in no action. Use The scope of this command is limited to the job in which it is run. iCluster disables exception generation when the job ends. Minimum Security Level Operator (*OPERATOR) Menu Access F22 (Shift+F10) - Option 52

DataMirror, an IBM Company

Printed in Canada

223

224

Printed in Canada

iClusterVersion 5.1

Replication Operation Commands

Replication Operation Commands


This section contains the following topics:

DMSETPOSSet Journal Start Position on page 225 DMMRKPOSMark Current Journal Positions on page 228 CHGHAJRNChange Journal Receiver on page 229 DSPHAPOSDisplay Journal Information on page 230 RTVHAPOSRetrieve Journal Information on page 230 VFYHAJRNVerify Audit Journal on page 232 STRHABRCDStart BSF Recording on page 233 DSPHABRCDDisplay Recording for BSF Object on page 234 ENDHABRCDEnd Recording for BSF Object on page 234 DMSTRAPYStart Replication Apply Process on page 235 DMENDAPYEnd Replication Apply Process on page 236 DMACTOBJActivate Object on page 238 DMACTBSFActivate BSF Object on page 240 DMSUSOBJSuspend Object on page 241 DMSUSBSFSuspend BSF Object on page 242 DMSNDOBJSend Object Immediately on page 243 DMSETSYNCSet Sync Point on page 245 CRTCFGOBJCreate Configuration Objects on page 248 INITHAOBJInitialize Objects on page 249 RTVRCVPTRetrieve Recovery Checkpoint on page 250 RTVRCVPTRRetrieve Recovery Checkpoint (CL Program) on page 251 SYNCHATRGSynchronize Triggers on page 252 DMLOGENTLog Journal Entry on page 253

DMSETPOSSet Journal Start Position


DMSETPOS GROUP( ) JRN( ) JRNRCV( ) JRNPOSLRG( ) STRDATE( ) STRTIME( ) JRNPOS( ) Use this command to position iCluster to start replication at a specific entry in a database journal, system audit journal, or all journals scraped by a group or resilient application. The specific journal entry can be entered directly or determined by the command if a date and time is entered. Note: If you add an object specifier that maps to non-journaled objects, and then want to start mirroring after a save and restore of those objects, you should set the starting position for QAUDJRN. For non-journaled BSF objects, set the JOURNAL parameter to *NONE in the DMADDGRPAdd Group command.

If you add an object specifier that maps to journaled objects and want to start mirroring after performing a save and restore of those objects, then set the starting position for the default journal. For journaled BSF objects, set the JOURNAL parameter to *CLUSTER in the DMADDGRPAdd Group command. Note: This command supports spooled file replication on the primary and backup node(s) as of i5/OS V5R4.

DataMirror, an IBM Company

Printed in Canada

225

Input Parameters

GROUP The name of a replication group or resilient application. The starting entry in the journal will be set on the primary node in the recovery domain for the specified group or resilient application. The replication group or resilient application must be inactive when this command is invoked.

JRN The name of a database or system audit journal that has its starting position set through this command. Enter the name of a database journal, system audit journal or the following value:

*ALLSets starting positions for all journals that are being scraped by the replication group or resilient application identified in the GROUP parameter of this command. The JRNRCV parameter is set to *CURRENT or *CURCHAIN. A specific date and time is specified in the STRDATE/STRTIME parameters OR the *LASTAPY or *CURSRCPOS options are specified in the JRNPOS parameter.

If you specify the *ALL option, the following conditions must be true:

If you specify a database journal, then the database and audit journal starting positions are set for journaled objects selected for replication. If you specify the system audit journal, then the audit journal starting position is set for all non-journaled objects selected for replication. If you do not specify *ALL, the library where the journal resides must be identified. Prefix the journal with the name of the library where the journal is located (for example, LIB1/JRN1).

JRNRCV The name of a database or system audit journal receiver. Specify the name of a journal receiver or one of the following values:

*CURRENTSpecifies the current journal receiver for the specified journal. *CURCHAINSpecifies the journal receiver that is determined from the timestamp information of the starting entry that is provided through the STRDATE and STRTIME parameters (see below).

If you specify *CURCHAIN, you cannot specify a starting sequence number with the JRNPOS parameter. In this case, only the STRDATE and STRTIME parameters can be set. If you do not use the *CURCHAIN value, then you must specify the library where the journal receiver resides. Prefix the journal receiver with the name of the library where the journal receiver is located (for example, LIB1/JRNRCV1), or with the following value:

*LIBLSpecifies the set of libraries in your library list (the libraries are searched in order for the first occurrence of the specified journal receiver).

The default setting for this parameter is *LIBL. JRNPOSLRG The sequence number (up to 20 digits) of the entry in the journal that iCluster will start processing from when replication resumes. Any non-blank value in this parameter takes precedence over the JRNPOS parameter. You cannot use this parameter with STRDATE or STRTIME or if JRNRCV is set to *CURCHAIN. Specify the starting sequence number or one of the following values:

*LASTAPYStart journal processing at the last journal entry in the source journal that was applied to the target. You cannot use this value for a group that has never been replicated. Instead, refresh the group when you start it for the first time.

226

Printed in Canada

iClusterVersion 5.1

Replication Operation Commands

*CURSRCPOSStart journal processing at the last journal entry in the source journal.

STRDATE The date of the entry that iCluster will start processing from when mirroring is re-started. The date format must adhere to the journal's date format, which can be determined by displaying attributes for the attached journal receiver on the node. If you specify a starting date, the JRNRCV parameter (see above) can be set to special values.

STRTIME The time of the entry that iCluster will start processing from when mirroring is re-started. This parameter is only applicable when a value is specified for the STRDATE parameter (see above). If you specify a starting time, the JRNRCV parameter (see above) can be set to special values.

JRNPOS The sequence number of the entry in the journal that iCluster will start processing from when replication resumes. You cannot use this parameter with STRDATE or STRTIME or if JRNRCV is set to *CURCHAIN. Specify the starting sequence number or one of the following values:


Examples

*LASTAPYStart journal processing at the last journal entry in the source journal that was applied to the target. You cannot use this value for a group that has never been replicated. Instead, refresh the group when you start it for the first time. *CURSRCPOSStart journal processing at the last journal entry in the source journal.

DMSETPOS GROUP(GRP1) JRN(QSYS/QAUDJRN) JRNRCV(LIB1/JRNRCV1) JRNPOSLRG(25689653214569) The starting journal position is set for replication group GRP1. The starting position is set for journal QAUDJRN in library QSYS, and journal receiver JRNRCV1 in the same library. Journal processing starts at sequence number 25689653214569 in the specified journal when mirroring is re-started. DMSETPOS GROUP(GRP1) JRN(QSYS/QAUDJRN) JRNRCV(LIB1/JRNRCV1) JRNPOS(142345) The starting journal position is set for replication group GRP1. The starting position is set for journal QAUDJRN in library QSYS, and journal receiver JRNRCV1 in the same library. Journal processing starts at sequence number 142345 in the specified journal when mirroring is re-started. DMSETPOS GROUP(GRP2) JRN(QSYS/QAUDJRN) JRNRCV(*CURRENT) JRNPOS(*LASTAPY) The starting journal position is set for replication group GRP2. The starting position is set for journal QAUDJRN in library QSYS and the current journal receiver. Journal processing starts at the last journal entry in the source journal that was applied to the target. DMSETPOS GROUP(GRP3) JRN(QSYS/QAUDJRN) JRNRCV(*CURCHAIN) STRDATE('10/01/03') STRTIME('12:45:00') The starting journal position is set for replication group GRP3. The starting position is set for journal QAUDJRN in library QSYS. The journal receiver is determined from the starting time and date information specified through the STRDATE and STRTIME parameters. Journal processing starts at the entry timestamped October 1, 2003 at 12:45 p.m. in all journals when mirroring is re-started. DMSETPOS GROUP(GRP4) JRN(*ALL) JRNRCV(*CURCHAIN) STRDATE('10/01/03') STRTIME('12:45:00') The starting journal position is set for replication group GRP4. The starting position is set for all journals scraped by the group GRP4.

DataMirror, an IBM Company

Printed in Canada

227

The journal receiver is determined from the starting time and date information specified through the STRDATE and STRTIME parameters. When mirroring is re-started, journal processing starts at the entry timestamped October 1, 2003 at 12:45 p.m. in all journals. Use You must issue this command on an active node in the cluster when the specified replication group or resilient application is inactive. Minimum Security Level Operator (*OPERATOR) Menu Access F22 (Shift+F10) - Option 60

DMMRKPOSMark Current Journal Positions


DMMRKPOS GROUP( ) Use this command to establish the starting position for mirroring for the specified replication group or resilient application. The journal positions are journaled in the iCluster metadata on the primary node associated with the specified group or resilient application. Marking a journal position takes a snapshot of the state of the source system and the objects that match object specifiers at the time you issue this command. Marking journal positions can help prevent unsynchronized start-ups when starting mirroring. See the DMSTRREPLStart Replication command for more information. The marked positions are used in the DMSTRGRPStart Cluster Operations at Group and DMSTRAPPStart Cluster Operations for Resilient Application commands. A parameter provided in these commands allows you to start mirroring at the journal positions marked by this command. Therefore, this command is typically used to record starting points before starting replication. This command will journal any objects (that have not already been journaled) that match object specifiers for the group to the default journal for the group. To journal objects to a journal other than the default journal, it is your responsibility to start journaling for the objects prior to running this command. Note: Each time you issue this command, the previous results of this command are overwritten. Only those replication groups or resilient applications that are specified in the current invocation will have their journal positions overwritten in the iCluster metadata. This command supports spooled file replication on the primary and backup node(s) as of i5/OS V5R4.

Note:

Input Parameter

GROUP The name of an existing replication group or resilient application.

Example DMMRKPOS GROUP(GRP1) Marks the current positions for journals that are used by replication group GRP1. Use You must issue this command on an active node in the cluster when the replication group is inactive or the resilient application is not running. Minimum Security Level Operator (*OPERATOR)

228

Printed in Canada

iClusterVersion 5.1

Replication Operation Commands

Menu Access F22 (Shift+F10) - Option 61

CHGHAJRNChange Journal Receiver


CHGHAJRN JOURNAL( ) DLTRCV( ) DAYS( ) Use this command to change journal receivers for the system audit journal or a database journal on the primary node. This command can also delete fully processed receivers. A processed receiver is one where all of the journal entries in the receiver are completely applied to the backup node. In addition, you can specify the number of days that fully processed receivers must be older than before they are deleted. Note: Note: If the specified journal is used as a remote journal, this command deletes fully processed journal receivers on remote systems. If you are using this command for journals with remote journals attached, you should issue this command on the source system of the journal. In this situation, the journal must be *ACTIVE when you issue this command.

This journal cleanup procedure can be invoked while mirroring is active. Input Parameters

Note:

JOURNAL The name of the journal on the primary node for which you will be generating journal receivers. If the journal is used for remote journaling, you must specify the name of the source journal. You also need to identify the library where the journal resides. Prefix the journal with the name of the library where the journal receiver is located (for example, LIB1/JRN1).

DLTRCV Indicates whether you want to delete fully processed receivers that are associated with the named journal. Specify one of the following values:


Note:

*NOSpecifies that you do not want to delete fully processed journal receivers associated with the named journal. These will remain until you delete or archive them. *YESSpecifies that you want to delete fully processed receivers and remote receivers associated with the named journal.

The default setting for this parameter is *NO. DAYS Indicates the number of days that fully processed journal receivers must be older than before they are deleted. You must specify a positive number. The age of the fully processed journal receivers is based on the detach date and time attributes of the journal receiver. Specify the number of days or the following value:

Examples

*NONESpecifies that the age of the receivers is not considered when deleting fully processed journal receivers.

The default setting for this parameter is *NONE.

CHGHAJRN JOURNAL (LIB1/HADJRN) DLTRCV(*YES) DAYS(4) Generates new receivers for the default journal HADJRN located in the library LIB1 and deletes fully processed receivers older than 4 days.
DataMirror, an IBM Company Printed in Canada 229

CHGHAJRN JOURNAL (LIB1/JRN1) DLTRCV(*NO) DAYS(*NONE) Generates new receivers for the journal JRN1 located in the library LIB1. Fully processed receivers will not be deleted. Use DataMirror recommends that you schedule journal management procedures to run at least once a day and if you are dealing with high volumes, you should schedule it to run several times daily. This assures that journal receivers can be purged off the system if they become too large or grow too quickly. You must issue this command on the node that the operation will be performed on. The node does not have to be active in the cluster. Menu Access F22 (Shift+F10) - Option 62

DSPHAPOSDisplay Journal Information


DSPHAPOS JOURNAL( ) Use this command to display the journal sequence number, journal receiver and library, and replication group of the oldest position in the journal that iCluster is currently processing. You can also use this command to determine whether a journal receiver associated with the specified journal is being used by iCluster or to let the user know which receivers may be deleted. Any receiver that is older than the reported position is no longer required by iCluster and can be deleted. Input Parameter

JOURNAL The name of a journal being used by iCluster. The library where the journal resides must be identified. Prefix the journal with the name of the library where the journal receiver is located (for example, LIB1/JRN1).

Example DSPHAPOS JOURNAL(LIB1/JRN1) This command displays the journal sequence number, the journal receiver name and the journal receiver library for JRN1 (if it exists) in library LIB1. Use You must issue this command on the node where the journal resides. The node does not have to be active in the cluster. Menu Access F22 (Shift+F10) - Option 63

RTVHAPOSRetrieve Journal Information


RTVHAPOS JOURNAL( ) TARGET( ) GROUP( ) JRNENTLRG( ) JRNENTRY( ) JRNRCVNME( ) JRNRCVLIB( ) RESULT( ) Use this command to return the journal receiver, the library of the journal receiver, and the sequence number of the last fully processed entry for the specified journal. The node and replication group associated with the journal entry are also returned. Use this command to determine whether a journal receiver associated with the specified journal is being used by iCluster. Any receivers in the chain prior to the returned journal receiver that may have been fully processed and may be deleted. Note: Since this command uses return variables, it can only be executed from a CL program. Use the DSPHAPOSDisplay Journal Information command to obtain the same information from the command line.

230

Printed in Canada

iClusterVersion 5.1

Replication Operation Commands

Input Parameters

JOURNAL The name of a journal. The library where the journal resides must be identified. Prefix the journal with the name of the library where the journal is located (for example, LIB1/JRN1).

TARGET The name of a 10 character CL variable into which the name of the backup node for the group associated with the last fully processed entry for the specified journal will be copied. GROUP The name of a 10-character CL variable into which the name of the replication group associated with the last fully processed journal entry for the specified journal will be copied. JRNENTLRG The name of the CL program variable into which the sequence number of the last fully processed journal entry is copied. The variable must be a character variable with a length of 20. Both the JRNENTLRG and JRNENTRY parameters will return the last applied journal position if the journal position is less than 10000000000. However, if the journal position is 10000000000 or greater, only the JRNENTLRG parameter will be returned, and the JRNENTRY parameter will return the decimal value -1.

JRNENTRY The name of the CL program variable into which the sequence number of the last fully processed journal entry is copied. The variable must be a decimal variable that has a length of 10 positions with no decimal positions. JRNENTRY returns the last applied journal position if the journal position is less than 10000000000, and returns -1 if the journal position is 10000000000 or greater.

JRNRCVNME The name of a 10-character CL variable into which the name of the journal receiver that contains the last fully processed journal entry for the specified journal will be copied. JRNRCVLIB The name of a 10-character CL variable into which the name of the library that contains the journal receiver identified through the JRNRCVNME parameter (see above) will be copied. RESULT The name of a 10-character CL variable where the result of the command will be copied. If the command runs successfully, the result variable will contain the string '*SUCCESS'. Otherwise, the result variable will contain the string '*ERROR'.

Example RTVHAPOS JOURNAL(LIB1/JRN1) TARGET(&NODE) GROUP(&GRPVAR) JRNENTRY(&JRNEVAR) JRNRCVNME(&JRNRVAR) JRNRCVLIB(&JRNLVAR) RESULT(&RESVAR) This command retrieves the journal receiver, the library of the journal receiver, and the last fully processed journal entry for journal JRN1 in library LIB1. This information is received through the variables &JRNRVAR, &JRNLVAR, and &JRNEVAR, respectively. The node and replication group associated with the sequence number are returned through the variable &GRPVAR. The backup node associated with the sequence number is returned through the variable &NODE. Note: DataMirror recommends that you use the CL convention of '&' in front of the variable names.

DataMirror, an IBM Company

Printed in Canada

231

Use You must issue this command on the node where the journal resides. The node does not have to be active in the cluster. Menu Access F22 (Shift+F10) - Option 64

VFYHAJRNVerify Audit Journal


VFYHAJRN AUDQTEMP( ) AUDSPLF( ) Use this command to verify that the audit journal exists in the library QSYS and the audit related OS/400 system values are set appropriately for iCluster. The VFYHAJRN command can only be used if the profile that is running the command has *ALLOBJ or *SECOFR authority. After installing iCluster on a primary node, it is required that the level of security auditing on the system is appropriately set. It is important that you issue this command before starting iCluster. Note: This command sets two OS/400 system values (QAUDLVL, QAUDCTL) that are required for replication. Other system values that have been set for QAUDLVL and QAUDCTL are maintained and not affected by this command.

The VFYHAJRN command verifies that the audit journal exists in the library QSYS. The required system values for parameter QAUDLVL (security auditing level) are as follows:

*CREATE *DELETE *OBJMGT *SAVRST *SECURITY *SPLFDTA (if the AUDSPLF parameter is set to *YES).

This command also activates object-level auditing before using iCluster. The required system values for parameter QAUDCTL (auditing control) are as follows: *OBJAUD *AUDLVL *NOQTEMP (if the AUDQTEMP parameter is set to *YES).

Specifying *OBJAUD means that objects selected for audit via the CHGOBJAUD command will be audited. *AUDLVL ensures that object auditing changes controlled by the QAUDLVL system value will be performed. See the AUDQTEMP parameter for this command to obtain more information about *NOQTEMP. This command will also ensure that the new object auditing level is set correctly for iCluster. Input Parameters

AUDQTEMP Specifies whether you want to audit objects in the library QTEMP. DataMirror recommends that you avoid the auditing of objects in this library by specifying *NO for this parameter.

Warning:

Specify one of the following values:

*NODoes not audit objects in the library QTEMP by specifying *NOQTEMP for QAUDCTL. *YESAudits objects in the library QTEMP by not specifying *NOQTEMP for QAUDCTL.

The default setting for this parameter is *NO.


232 Printed in Canada

iClusterVersion 5.1

Replication Operation Commands

AUDSPLF Specifies whether you want to audit spool file functions (create spool file, delete spool file, display spool file, and so on). Specify one of the following values:


Example

*NODoes not audit spool file functions. *YESAudits spool file functions.

The default setting for this parameter is *NO.

VFYHAJRN AUDQTEMP(*YES) AUDSPLF(*NO) Verifies that the audit journal exists. Objects in the library QTEMP will not audited (the system value *NOQTEMP is set for QAUDCTL). Spool file functions will not be audited. Use You must issue this command on the node where the operation will be performed. The node does not have to be active in the cluster. Menu Access F22 (Shift+F10) - Option 65

STRHABRCDStart BSF Recording


STRHABRCD PATH( ) Use this command to start journaling a BSF object referenced by a path object specifier to the default BSF journal for the cluster specified in the DMSETSVALSet Cluster System Values command. Note that you cannot specify generics for this parameter. Generally, iCluster starts journaling a BSF object automatically so that you do not need to do so yourself. However, in uncommon circumstances where you want to start journaling yourself (such as starting journaling in advance of starting iCluster, or assuring that files are not changed before starting iCluster), then you can issue this command to start journaling. You can also use the IBM STRJRN command to start BSF journaling. See your iSeries documentation for more information. Note: This command starts journaling for a single file only.

Input Parameters

Output

PATH The full object path in the format of /Dir1/Dir2/file.

If journaling starts correctly, no messages are displayed. Error messages will be displayed if journaling cannot start. Examples STRHABRCD PATH(/Dir1/Dir2/file1) This starts journaling the BSF object named file1 that resides in the base path of /Dir1/Dir2/. Use You must issue this command on the node where the operation will be performed. The node does not have to be active in the cluster.
DataMirror, an IBM Company Printed in Canada 233

Menu Access F22 (Shift+F10) - Option 68

DSPHABRCDDisplay Recording for BSF Object


DSPHABRCD PATH( ) Use this command to display information about the journaling of BSF objects. If journaling is active, then this command displays the journal where the specified BSF objects are being journaled. If journaling is not active, then this command will indicate its inactive state. For more information about BSF objects, see Replicating BSF Objects on page 89. Input Parameter

PATH

The path that identifies the location of the BSF object for which journaled information will be displayed. Example DSPHABRCD PATH(/DIR1/DIR2/DIR3/FILEA) Displays information about the journaling of BSF object FILEA that resides in /DIR1/DIR2/DIR3/. Use You must issue this command on the node where the operation will be performed. The node does not have to be active in the cluster. Menu Access F22 (Shift+F10) - Option 66

ENDHABRCDEnd Recording for BSF Object


ENDHABRCD PATH( ) Use this command to end journaling of a Byte Stream File (BSF) object to its journal. You can also use the IBM ENDJRN command to end BSF journaling. See your iSeries documentation for more information. Input Parameter

PATH The path that identifies the location of the BSF object that will no longer be journaled to the default BSF journal.

Example ENDHABRCD PATH(/DIR1/DIR2/DIR3/FILEA) Ends journaling for the BSF object FILEA that resides in /DIR1/DIR2/DIR3/. Use You must issue this command on the node when the operation will be performed. The node does not have to be active in the cluster. Menu Access F22 (Shift+F10) - Option 67

234

Printed in Canada

iClusterVersion 5.1

Replication Operation Commands

DMSTRAPYStart Replication Apply Process


DMSTRAPY GROUP( ) BACKUP( ) OVRSTOP( ) FRCDRN( ) This command starts the apply processes on a backup node. Starting apply processes allow journal entries placed in the staging store by receive processes to be applied. For more information about staging stores, see Staging Objects for more information. The apply processes handle each journal entry in the staging store in chronological order. They remain active until the stop date/time is specified through the previous or subsequent DMENDAPYEnd Replication Apply Process command. The apply processes also end when the staging store has been drained and the send/receive processes are not running. Input Parameters

GROUP The name of the replication group or resilient application containing the backup node that will have its apply processes started. Specify the name of the group or resilient application or one of the following values:

*ALLStarts the apply processes on the backup node for all groups and resilient applications in the cluster. *BACKUPStarts the apply processes for all groups and resilient applications on the backup node. If you specify this option, you must specify the name of the backup node in the BACKUP parameter (see below).

BACKUP Indicates the name of the backup node that starts the apply processes for all groups and resilient applications that have the specified node as their backup node. This parameter is only applicable when the GROUP parameter (see above) is set to *BACKUP. Specify the name of the backup node or the following value:

*ALLStarts the apply processes for all groups and resilient applications on all backup nodes in the cluster.

The default setting for this parameter is *ALL. OVRSTOP Overrides a previously set stop date/time for the apply processes that is specified through the DMENDAPYEnd Replication Apply Process command. Specify one of the following values:

*YESThe previous stop date/time is disregarded. The apply processes will continue until a new DMENDAPY End Replication Apply Process command is issued. *NOThe apply processes will start, but the previous stop date/time specified through the DMENDAPYEnd Replication Apply Process command is still valid. Consequently, the processes will stop at that date/time unless it is reset by a subsequent invocation of the DMENDAPYEnd Replication Apply Process command.

The default setting for this parameter is *YES.

FRCDRN Specifies whether the staging store will be force drained. The apply processes merge entries from the audit and database journals. Depending on your selection, the apply processes will either continue draining the staging store even if one of the journals is empty (known as force draining), or it will stop draining when one of the journals is empty. Force draining stops once it reaches the stop date/time specified through the DMENDAPYEnd Replication Apply Process command (if one is specified). Otherwise, it will stop once the staging store is empty. Specify one of the following values:

DataMirror, an IBM Company

Printed in Canada

235

*NOIndicates that the staging store will not be force drained. The apply processes will merge entries from the audit and database journals and apply them in sequence. When one journal becomes empty, the apply processes will stop regardless of any entries remaining in the other journal. *YESIndicates that the staging store will be force drained. The apply processes will merge entries from the audit and database journals. Once it reaches the last entry of the journal with fewer entries, the merge will stop, and the apply processes will drain the other journal until it is empty.

The default setting for this parameter is *NO. Example DMSTRAPY GROUP(GRP1) OVRSTOP(*YES) FRCDRN(*YES) Starts the apply processes on the backup node for replication group GRP1. The staging store will be force drained. DMSTRAPY GROUP(*BACKUP) BACKUP(AS400BU) OVRSTOP(*YES) FRCDRN(*YES) Starts the apply processes for all groups and resilient applications that have the AS400BU backup node. The staging store is force drained. Use You can issue this command on any node in the cluster. Minimum Security Level Operator (*OPERATOR) Menu Access Main Menu - Option 16 F22 (Shift+F10) - Option 69

DMENDAPYEnd Replication Apply Process


DMENDAPY GROUP( ) BACKUP( ) OPTION( ) ENDDATE( ) ENDTIME( ) Use this command to end applying journal entries from the staging store on a backup node. For more information about staging stores, see Staging Objects on page 69. Even though this command stops the apply processes, iCluster continues to scrape and send journal entries for the replication group if it is active. The journal entries remain in the staging store until the apply processes are started through the DMSTRAPYStart Replication Apply Process command. Input Parameters

GROUP The name of the replication group or resilient application containing the backup node that will have its apply processes stopped by this command. Specify the name of the group or resilient application or one of the following values:

*ALLEnds the apply processes on the backup node for all groups and resilient applications in the cluster. *BACKUPEnds the apply processes for all groups and resilient applications that have the specified node as their backup node. If you specify this option, you must specify the name of the backup node in the BACKUP parameter (see below).

BACKUP

236

Printed in Canada

iClusterVersion 5.1

Replication Operation Commands

Indicates the name of the backup node that will end the apply processes for all groups and resilient applications. This parameter is only applicable when the GROUP parameter (see above) is set to *BACKUP. Specify the name of the backup node or one of the following values:

*ALLEnds the apply processes for all groups and resilient applications on all backup nodes in the cluster.

The default setting for this parameter is *ALL. OPTION Indicates how you want to stop the apply processes. Specify one of the following values:


Note:

*CTRLDIndicates a controlled end of the apply processes, allowing them to complete their current processing. DataMirror recommends performing a controlled end when possible. *INVLDInvalidates the pending end date/time for the apply processes. Applies will continue. *DATETIMEIndicates the date and time when the apply processes will end. If you select this setting, you must specify values for the ENDDATE and ENDTIME parameters (see below). *IMMEDIndicates that the apply processes will stop immediately.

The default setting for this parameter is *CTRLD. If either *CTRLD or *DATETIME is specified, the apply processes will stop once the current operation has been completed. Depending on the operation (for example, restoring a save file), it may take some time for the apply processes to stop. ENDDATE The date when the apply processes will be stopped. The date format must adhere to the system's date format. This parameter is only applicable if the OPTION parameter (see above) is set to *DATETIME.

ENDTIME The time when the apply processes will be stopped. The time format must adhere to the system's time format. This parameter is only applicable if the OPTION parameter (see above) is set to *DATETIME.

Examples DMENDAPY GROUP(GRP1) OPTION(*CTRLD) Ends the apply processes on the backup node in replication group GRP1. The apply processes are stopped in a controlled manner after the current operation has been completed. DMENDAPY GROUP(*ALL) OPTION(*DATETIME) ENDDATE(12/31/05) ENDTIME(235959) Ends the apply processes for all groups and resilients applications on all backup nodes in the cluster. Stops the apply processes at the specified date and time. Use You can issue this command on any active node in the cluster. Minimum Security Level Operator (*OPERATOR) Menu Access F22 (Shift+F10) - Option 70

DataMirror, an IBM Company

Printed in Canada

237

DMACTOBJActivate Object
DMACTOBJ GROUP( ) OBJ( ) OBJTYPE( ) MEMBER( ) RFSH( ) TRUNCATE( ) REPLACELFS( ) Use this command to activate an object that is currently suspended from replication. This command will also enable replication of objects that have been added into replication scope. After activating an object, mirroring of the specified object will start if the replication group is active. If the replication group is inactive, mirroring will start when the group is activated through the DMSTRGRPStart Cluster Operations at Group command. Note: Any changes made to an object while it is suspended will not be mirrored when it is activated through this command. Specify *YES for the RFSH parameter to verify that the object on the backup node is synchronized with the object on the primary node before activating the object for mirroring.

For more information about suspended objects, see Suspended Objects on page 72. Input Parameters

GROUP The name of the replication group to which the object is selected. OBJ The object name component of the suspended object that you want to activate. Enter a specific or generic name (to identify multiple objects in a library), or the following value:

Note:

*ALLSpecifies all objects in a library.

The library where the object resides must be identified. Prefix the object with the name of the library where the object is located (for example, LIB1/OBJ1). If you specify a generic name for this parameter, only *ALL is allowed for the MEMBER parameter. If you specify a specific name for this parameter, both *ALL and a specific name are allowed for the MEMBER parameter. OBJTYPE The type of object being activated. Enter an object type supported by iCluster or the following value:

*ALLSpecifies all objects in the library which has the same object name component (OBJ parameter) but different types.

See Object Types Replicated by iCluster on page 529 for more information on object types supported by iCluster. MEMBER This parameter is available only if you entered *FILE in the OBJTYPE parameter and the file is a source physical file. Specifies whether you want to activate a specific member of a source physical file. Enter a member name or the following value:

*ALLSpecifies all members for the specified source physical file.

RFSH Indicates whether you want to refresh the suspended object to the backup node in the replication group when the object is activated. The refresh method used is the one that was specified when the object was selected for replication within the group. See DMSELOBJSelect Objects to Group on page 141 for more information. This option allows you to activate an object without having to save and restore the object. Specify one of the following values:

238

Printed in Canada

iClusterVersion 5.1

Replication Operation Commands

*NOIndicates that you do not want the object to be refreshed on the backup node when the object is activated. In this case, you are responsible for refreshing the object and ensure that it is synchronized at the time the activate is performed. *YESIndicates that you want the suspended object to be refreshed on the backup node when the object is activated.

The default setting for this parameter is *YES. TRUNCATE Indicates whether you want to remove existing data before performing a refresh. Specify one of the following values:

*YESIndicates that you want to remove and recreate existing data files as part of a refresh. This is the default behavior for iCluster and is appropriate for standard iCluster replication. You can use this option for a mastermaster group if the data on the source system is known to be complete in order to ensure a synchronized starting point. With this value, logical files are replaced automatically because the deletion of a physical file requires the deletion of all logical files upon which it is based.

*NOIndicates that you do not want to remove existing data before performing a refresh. This option is appropriate for master-master replication.

The default setting for this parameter is *NO. See Master-Master ReplicationOperations and Monitoring on page 323 for more information on the refresh options that are specific to master-master replication groups. Note: This parameter only applies to iBalance and *MSTRMSTR replication groups. See iBalance and MasterMaster Replication on page 321 for more information on this feature. REPLACELFS Indicates whether you want to replace logical files during a refresh. Specify one of the following values:


Note:

*YESIndicates that you want to replace logical files during a refresh. This is the default behavior for iCluster and is appropriate for standard replication. You can use this option for a master-master group if the logical files on the source system are the complete set required for your applications in order to ensure a synchronized starting point. *NOIndicates that you want to use existing logical files during a refresh. This option is appropriate for mastermaster replication.

iCluster does not require logical files based on the replicated physical file to be the same on source and target systems if they are not in replication scope. The default setting for this parameter is *NO. See Master-Master ReplicationOperations and Monitoring on page 323 for more information on the refresh options that are specific to master-master replication groups.

Note:

This parameter only applies to iBalance and *MSTRMSTR replication groups. See iBalance and MasterMaster Replication on page 321 for more information on this feature.

Examples DMACTOBJ GROUP(GRP1) OBJ(LIB1/OBJ1) OBJTYPE(*FILE) RFSH(*YES) TRUNCATE(*NO) REPLACELFS(*NO) Activates the *FILE object named OBJ1 located in library LIB1 that is selected for replication within replication group GRP1. OBJ1 will be refreshed on the backup node before mirroring is started. Existing logical files are not used during the refresh, and existing data is not removed before performing the refresh. DMACTOBJ GROUP(GRP1) OBJ(LIB1/OBJ1) OBJTYPE(*FILE) MEMBER(MEM1)
DataMirror, an IBM Company Printed in Canada 239

Activates the member MEM1 of object named OBJ1 that is located in the library LIB1 and is part of the group GRP1. DMACTOBJ GROUP(GRP1) OBJ(LIB1/A*) OBJTYPE(*ALL) MEMBER(*ALL) Activates all objects located in library LIB1 and have 'A' as their first letter. These objects are also in the replication scope of GRP1. DMACTOBJ GROUP(GRP1) OBJ(LIB1/*ALL) OBJTYPE(*ALL) MEMBER(*ALL) RFSH(*YES) Activates all objects located in library LIB1. These objects are also in the replication scope of GRP1. Use You can issue this command on any active node in the cluster. Minimum Security Level Operator (*OPERATOR) Menu Access F22 (Shift+F10) - Option 71

DMACTBSFActivate BSF Object


DMACTBSF GROUP( ) PATH( ) TRUNCATE( ) Use this command to activate a suspended Byte Stream File (BSF) object that is currently suspended. It applies only to BSF objects residing in the Integrated File System (IFS). For more information about BSF objects, see Replicating BSF Objects on page 89. After activating a BSF object, it is refreshed to the backup node in the recovery domain if mirroring is active. The amount of latency in the system will also affect the refresh of a BSF object. Mirroring of the specified object will start if the replication group is active. If the replication group is inactive, mirroring will start when the group is activated through the DMSTRGRP Start Cluster Operations at Group command. For more information about suspended objects, see Suspended Objects on page 72. Input Parameters

GROUP The name of the replication group to which the BSF object is selected. PATH The path object specifier that identifies the location of the BSF object that will be activated through this command. The path must be enclosed in single quotes and start with the '/' (forward slash) character ('/Dir3/Dir4/file'). The path can be a maximum of 5000 characters, and you must enter at least two characters for the path. Generic path names of the form '/mydir*' are supported, where the generic indicator '*' is the final character of the path name. When using generic path names, all sub-directories are included recursively.

Note:

Only those objects that match the generic path specifier and are replicated by the group will be activated. For example, matching objects that are excluded from replication by the group will not be activated. For more information about path object specifiers, see Path Object Specifiers on page 53. TRUNCATE Indicates whether you want to remove existing data before performing a refresh. Specify one of the following values:

240

Printed in Canada

iClusterVersion 5.1

Replication Operation Commands

*YESIndicates that you want to remove and recreate existing data files as part of a refresh. This is the default behavior for iCluster and is appropriate for standard iCluster replication. You can use this option for a mastermaster group if the data on the source system is known to be complete in order to ensure a synchronized starting point. With this value, logical files are replaced automatically because the deletion of a physical file requires the deletion of all logical files upon which it is based.

*NOIndicates that you do not want to remove existing data before performing a refresh. This option is appropriate for master-master replication.

The default setting for this parameter is *NO. See Master-Master ReplicationOperations and Monitoring on page 323 for more information on the refresh options that are specific to master-master replication groups. Note: This parameter only applies to iBalance and *MSTRMSTR replication groups. See iBalance and MasterMaster Replication on page 321 for more information on this feature.

Examples DMACTBSF GROUP(GRP1) PATH('/DIR1/DIR2/DIR3/FILEA') Activates the BSF object named FILEA in /DIR1/DIR2/DIR3 that is selected for replication within replication group GRP1. FILEA will be refreshed to the backup node in the replication group. DMACTBSF GROUP(GRP2) PATH('QDLS/DIR1/DIR2/*') Activates all BSF objects in /DIR1/DIR2 that are selected for replication within replication group GRP2. The objects are refreshed to the backup node in the recovery domain if mirroring is active. Use You can issue this command on any active node in the cluster. Minimum Security Level Operator (*OPERATOR) Menu Access F22 (Shift+F10) - Option 71

DMSUSOBJSuspend Object
DMSUSOBJ GROUP( ) OBJ( ) OBJTYPE( ) MEMBER( ) Use this command to prevent an object from being replicated to a backup node in the specified replication group by suspending it. Journal entries created before an object was suspended will still be sent to the backup node. To activate an object that is suspended through this command, use the DMACTOBJActivate Object command. Note: Any changes made to an object while it is suspended will not be mirrored when it is activated. For more information about suspended objects, see Suspended Objects on page 72. Input Parameters

GROUP The name of the replication group to which the object is selected. OBJ

DataMirror, an IBM Company

Printed in Canada

241

The name of a valid object. The library where the object resides must be identified. Prefix the object with the name of the library where the object is located (for example, LIB1/OBJ1).

OBJTYPE The type of object being suspended. MEMBER This parameter is available only if you entered *FILE in the OBJTYPE parameter. Specifies whether you want to suspend a specific member of a source physical file. Enter a member name or the following value:

Example

*ALLSpecifies all members for the specified source physical file.

DMSUSOBJ GROUP(GRP1) OBJ(LIB1/OBJ1) OBJTYPE(*FILE) MEMBER(MEM1) Suspends the member MEM1 of the *FILE object named OBJ1 located in library LIB1 that is selected for replication within replication group GRP1. Use You must issue this command on an active node in the cluster. Minimum Security Level Operator (*OPERATOR) Menu Access F22 (Shift+F10) - Option 73

DMSUSBSFSuspend BSF Object


DMSUSBSF GROUP( ) PATH( ) Use this command to prevent a BSF object from being replicated to a backup node. The object will appear suspended with the SBU reason code. It applies only to BSF objects residing in the Integrated File System (IFS). For more information about BSF objects, see Replicating BSF Objects on page 89. Journal entries created before the object was suspended will still be sent to the backup node if the BSF object is journaled. To activate a BSF object that is suspended through this command, use the DMACTBSFActivate BSF Object command. Note: This command supports the suspension of directories and folders with the exception of those directories that match a BSF specifier with matching files that are journaled. See the DMADDBSFAdd Path Object Specifier to Group command for more information on journaled and non-journaled BSF files.

For more information about suspended objects, see Suspended Objects on page 72. Input Parameters

GROUP The name of the replication group to which the BSF objects are selected. PATH The path object specifier that identifies the location of the BSF objects that will be suspended through this command. The path must be enclosed in single quotes and start with a '/' (forward slash) character ('/Dir3/Dir4/file'). The path can be a maximum of 5000 characters, and you must enter at least two characters for the path.

242

Printed in Canada

iClusterVersion 5.1

Replication Operation Commands

For more information about path object specifiers, see Path Object Specifiers on page 53. Examples DMSUSBSF GROUP(GRP1) PATH('/DIR1/DIR2/DIR3/FILEA') Suspends the BSF object named FILEA in /DIR1/DIR2/DIR3 that is selected for replication within replication group GRP1. DMSUSBSF GROUP(GRP2) PATH('/DIR1/DIR2/FILEB') Suspends the BSF object named FILEB in /DIR1/DIR2 that is selected for replication within replication group GRP2. Use You must issue this command on an active node in the cluster. Minimum Security Level Operator (*OPERATOR) Menu Access F22 (Shift+F10) - Option 74

DMSNDOBJSend Object Immediately


DMSNDOBJ SRCNODE( ) TGTNODE( ) SNDTYPE( ) OBJ( ) OBJTYPE( ) OBJATTR( ) TGTLIB( ) PATH( ) Use this command to replicate one or more objects that are not necessarily part of a group to a target system immediately. This command allows you to send objects immediately without having to select them in a group. The referenced objects are essentially refreshed to the target node. The DMSNDOBJ command can be used to synchronize the backup node with the primary node before replication is started. Once replication is started, iCluster should detect the creation of new objects in replication scope and replicate them automatically. However, if replication is running and you have determined that some objects in replication scope are not found on the backup node, the DMSNDOBJ command should NOT be used to send these objects to the backup node if they are journaled objects. By doing this you will prevent these objects from being properly handled by the replication process, that is, setting up the metadata that iCluster requires for changes to these objects to be replicated and starting journaling of the objects if they are not journaled. The correct way to deal with this issue is to use the Activate Object command to activate and refresh the objects from the group's primary node to the backup node. Note: Note: Journaled objects are physical database files, logical files, data areas and data queues. This command cannot be used to refresh data areas and data queues when the source object is at OS/400 Version 5.1 or later. You can use DMACTOBJActivate Object on page 238 to refresh data areas and data queues that are replicated by an iCluster group.

Input Parameters

SRCNODE The name of the node where the source object is found. Enter the name of a node or the following value:

*CURRENTThe current node.

This is the default value for this parameter. TGTNODE The name of the node where the object will be sent. SNDTYPE The object type being sent.

DataMirror, an IBM Company

Printed in Canada

243

Specify one of the following values:


OBJ

*LIBRARYA native OS/400 object that resides in an OS/400 library. *PATHA path object.

The object name and library component of the object that you want to send. Enter a specific or generic name (to identify multiple objects in a library), or the following value:

*ALLSpecifies all objects in a library.

The library where the objects reside must be identified. Prefix the object specification with the name of the library where the objects are located (for example, LIB1/OBJ1). This parameter is used only when the SNDTYPE parameter is *LIBRARY.

OBJTYPE The object type component of the object that you want to send. Specify an object type or the following value:

*ALLSpecifies all object types.

This is the default setting for this parameter. For a complete list of all object types that iCluster can replicate, see Object Types Replicated by iCluster on page 529. This parameter is used only when the SNDTYPE parameter is *LIBRARY.

OBJATTR The attribute component of the object you want to send. This parameter is only applicable when the OBJTYPE parameter (see above) is set to *FILE. This field is free-form. Consequently, you can enter any value you want to describe the object, as long as the value conforms to OS/400 naming conventions. However, there are values that have special meaning to iCluster. They are PFSRC (source physical file), PFDTA (data physical file), and PF (any physical file). Other values listed are standard OS/400 file sub-types. If PF is used, the object specifier will match either PFSRC or PFDTA files. Press F4 for a list of values or enter the following value:

*ALLSpecifies all object attributes. *ALL is not a valid OS/400 object attribute but allows iCluster to gather all objects regardless of their attribute.

The default setting for this parameter is *ALL. This parameter is used only when the SNDTYPE parameter is *LIBRARY.

TGTLIB The name of the library on the backup system that will receive the replicated objects. Enter the name of the library or the following value:

*SRCSets the target library so that it is the same as the primary node library where the object resides.

If the primary and backup environments reside on the same physical system (local loopback implementation), the target library that you specify cannot be the same library where a selected object in the group currently resides. This restriction means that iCluster does not permit the special value *SRC in this situation. This parameter is used only when the SNDTYPE parameter is *LIBRARY.

PATH The path object specifier that identifies the location of the BSF objects.

244

Printed in Canada

iClusterVersion 5.1

Replication Operation Commands

Path object specifiers consist of a sequence of directories that identify the location of the BSF objects in the IFS. The path that is defined is similar to the path specification under Windows and UNIX operating systems. The defined path must be in single quotes. Generic path names of the form '/mydir*' are supported, where the generic indicator '*' is the final character of the path name. When using generic path names, all sub-directories are included recursively. For more information about path object specifiers, see Path Object Specifiers on page 53. This parameter is used only when the SNDTYPE parameter is *PATH. Output None. Examples DMSNDOBJ SRCNODE(*CURRENT) TGTNODE(TGT1) SNDTYPE(*LIBRARY) OBJ(LIB1/OBJ*) OBJTYPE(*FILE) OBJATTR(*ALL) TGTLIB(*SRC) This command will cause all FILE objects in library LIB1 that match the generic specifier OBJ* to be refreshed from the current node to the node named TGT1, into the LIB1 library. DMSNDOBJ SRCNODE(SRC1) TGTNODE(TGT1) SNDTYPE(*PATH) PATH('/home/mydir/ex*') This command will cause all path objects that in the /home/mydir directory that match the generic specifier 'ex*' to be refreshed from the node named SRC1 to the node named TGT1. Use The nodes named SRCNODE and TGTNODE must be active in the cluster.

DMSETSYNCSet Sync Point


DMSETSYNC GROUP( ) USREXIT( ) SCRAPE( ) RECEIVE( ) APPLY( ) USRDATA( ) Use this command to place checkpoint entries in journals that define sync points when journal entries are scraped and applied on the primary and backup nodes. Once the checkpoint condition is met, a user exit program can be called by one of the replication jobs on the primary or backup node. For scrape and apply jobs, the checkpoint condition implies that all jobs have reached the checkpoint and are waiting for the user exit program to be completed. Depending on the return code of the user exit program, these jobs will continue replication beyond the checkpoint or complete. For the receive jobs, the checkpoint condition is met when all the jobs except the last one have passed the checkpoint. In this case, it is the last job that fires the user exit program. Note: A replication job is any iCluster replication job associated with replication group or resilient application activities.

You can use checkpoint journal entries when it is necessary to synchronize operations on primary and backup nodes. After defining a checkpoint journal entry on the primary node, synchronization is achieved when the checkpoint is reached on the backup node. A user exit program can then be called to perform some operation with the user-defined data that is passed to the program. For example, you may want to backup a consistent database or perform summary calculations after all entries have been replicated from the primary node and applied on the backup node. Note: Note that a replication apply job on a backup node processes journal entries until it reaches the checkpoint journal entry that is generated by this command. At this point, the job waits for other specified replication jobs to reach this checkpoint journal entry. Synchronization is achieved when all active replication jobs reach the checkpoint journal entry. This means that one or more jobs will wait at the checkpoint journal entry until all replication jobs reach the sync point. After issuing the DMSETSYNC command, you cannot delete or change the checkpoint journal entry you defined. Therefore, it is important that you are aware of this consideration and exercise caution before issuing this command.

Note the following important considerations concerning the DMSETSYNC command:

DataMirror, an IBM Company

Printed in Canada

245

If the apply job has a checkpoint user exit, the update continues up to the point where you set the checkpoint. The update is resumed after the user exit program runs to completion, unless a special value is returned through one of the user exit program arguments that causes the apply job's completion. See Passing Arguments to Sync Point User Exit Programs on page 86.

Therefore, it may be necessary to minimize the execution time of your user exit program so that mirroring can resume as soon as possible. Input Parameters

GROUP The name of the replication group or resilient application that will synchronize at a checkpoint journal entry. Jobs associated with the specified replication group or resilient application will synchronize at the checkpoint journal entry. If you specify a group, it must be active. If you specify a resilient application, it must be running.

USREXIT The name of the user exit program that will be invoked when all active replication jobs reach the checkpoint journal entry. Note that the same user exit program can be invoked at different synchronization points (journal entry scrape, receive, and apply). If it is invoked when journal entries are being scraped, the program must reside on the primary node. If it is also invoked at journal receive or apply times, it must also reside in the same location on the backup node. If you want to specify a different user exit program at multiple sync points, issue the DMSETSYNC command (once for each sync point) so that a different user exit program can be specified for each invocation of the command.

Note:

User exit programs must be compiled with the Use adopted authority option set to *NO. Otherwise, the user exit programs cannot be executed and mirroring will continue. Specify the name of a user exit program or the following value:

*NONEIndicates that you do not want to specify a user exit program.

The library where the user exit program resides must be identified if you do not specify *NONE. Prefix the user exit program with the name of the library where the program is located (for example, LIB1/CHKPGM) or with the following value:

*PRODLIBSpecifies your iCluster installation library.

If iCluster cannot find the specified user exit program, an appropriate error message will be generated and mirroring will continue. See Passing Arguments to Sync Point User Exit Programs on page 86 for more information about the arguments that can be passed to the user exit program.

SCRAPE Indicates whether you want to synchronize group replication jobs when journal entries are scraped on the primary node. At this sync point, the user exit program specified through the USREXIT parameter (see above) will be invoked when all active scrape jobs on the primary node scrape process synchronize at the checkpoint journal entry. You can use a user exit to end mirroring by setting a return value. Setting the value for the scrape affects both the scrape and receive processes. The apply process is not affected. Specify one of the following values:


Note:

*NODoes not synchronize group replication jobs at checkpoint journal entry. The user exit program is not invoked. *YESSynchronizes group replication jobs at checkpoint journal entry and then invokes user exit program.

The default setting for this parameter is *NO. If the group uses a remote journal, then you must set this value to *NO. RECEIVE

246

Printed in Canada

iClusterVersion 5.1

Replication Operation Commands

Indicates whether you want the user exit program to be called when all the receive jobs have passed through the sync point. Note: Unlike the scrape and apply jobs, the receive jobs are not synchronized at sync point journal entries. The receive jobs pass through the sync point at their own pace. The user exit program specified through the USEREXIT parameter will be called asynchronously by the receive job that is the last one to receive a sync point journal entry. Unlike the scrape and apply jobs, you cannot end the receive jobs using a specific return code from the user exit program. However, the receive jobs will stop automatically if the scrape jobs are stopped. The possible values are:

*NOThe user exit program will not be called when all the receive jobs have passed the sync point (received sync point journal entry). *YESInvokes the sync point user exit program.

APPLY Indicates whether you want to synchronize replication jobs when journal entries are applied on the backup node. At this sync point, the user exit program specified through the USREXIT parameter (see above) will be invoked when all active replication jobs for the backup node apply processes synchronize at the checkpoint journal entry. You can use a user exit to end the apply jobs by setting a return value. Setting this value for the apply process affects only the apply process. Specify one of the following values:

*YESSynchronizes group replication jobs at the checkpoint journal entry and then invokes user exit program. *NODoes not synchronize group replication jobs at the checkpoint journal entry and then the user exit program is not invoked.

The default setting for this parameter is *YES. USRDATA Identifies the user-defined data that you want to pass to the user exit program specified through the USREXIT parameter (see above). You can pass a maximum of 400 bytes of data to the user exit program. If your data contains spaces or nonalphanumeric characters (commas, periods, and so on), you must enclose your data in single quotes. Note: This parameter is ignored if no user exit program is specified. See Passing Arguments to Sync Point User Exit Programs on page 86 for more information. Examples DMSETSYNC GROUP(GRP1) USREXIT(LIB1/CPUPGM) SCRAPE(*NO) APPLY(*YES) USRDATA(QTY400STS1PRC800) Jobs associated with replication group GRP1 will be synchronized at the checkpoint journal entries. The checkpoint user exit program CPUPGM is located in library LIB1. This program must reside on the backup node. Replication jobs will only be synchronized when journal entries are applied on the backup node. No sync points are established for journal scraping. User-defined data consisting of a sequence of characters will be passed to the user exit program CPUPGM. DMSETSYNC GROUP(GRP2) USREXIT(*NONE) SCRAPE(*YES) APPLY(*YES) Jobs associated with replication group GRP2 will be synchronized at the checkpoint journal entries. A user exit program has not been specified in this command. Replication jobs will be synchronized when journal entries are scraped on the primary node as well as applied on the backup node.

DataMirror, an IBM Company

Printed in Canada

247

DMSETSYNC GROUP(GRP3) USREXIT(*PRODLIB/CPUPGM) SCRAPE(*YES) APPLY(*YES) USRDATA('DJONES 750098 ASMITH 912457') Jobs associated with replication group GRP3 will be synchronized at the checkpoint journal entries. The checkpoint user exit program CPUPGM is located in the iCluster installation library. This program must reside in the same location on both the primary and backup nodes. Replication jobs will be synchronized when journal entries are scraped on the primary node and applied on the backup node. User-defined data consisting of a sequence of characters will be passed to the user exit program CPUPGM. Note that single quotes are required to enclose data that includes spaces and other non-alphanumeric characters. Use You must issue this command on an active node in the cluster when the replication group is active or the resilient application is running. Minimum Security Level Operator (*OPERATOR) Menu Access Main Menu - Option 40 F22 (Shift+F10) - Option 75

CRTCFGOBJCreate Configuration Objects


CRTCFGOBJ OBJ( ) OBJTYPE( ) OWNER( ) Use this command to create configuration objects that are replicated to a backup node. iCluster can automatically create configuration objects immediately after the data required for creating them is received on the backup node. Alternatively, the configuration objects can be created at a later time. If the latter approach is adopted, this command can be issued to create the configuration objects. For more information about configuration objects, see Replicating Configuration Objects on page 90. Input Parameters

OBJ The name of the configuration object that you want to create. Enter a specific or generic object name (to identify multiple objects), or the following value:

*ALLSpecifies all configuration objects whose data is being stored on the backup node. Once the objects have been successfully created, the data is removed from the backup node.

OBJTYPE The type of configuration object that you want to create. Specify *CNNL, *COSD, *CTLD, *DEVD, *IPXD, *LIND, *MODD, *NTBD, *NWID, *NWSD (to identify a specific type of configuration object) or the following value:

*ALL - Specifies all configuration object types.

See Object Types Replicated by iCluster on page 529 to identify the configuration object types that are listed above. OWNER The owner of the configuration object that is created. Specify the user name of the owner or the following value:

248

*CURRENTSpecifies the user name that is running this command is assigned ownership of the created object.

Printed in Canada

iClusterVersion 5.1

Replication Operation Commands

The default setting for this parameter is *CURRENT. Examples CRTCFGOBJ OBJ(OBJ1) OBJTYPE(*MODD) OWNER(SMITHB) Creates the mode description OBJ1. SMITHB will be assigned ownership of this mode description. CRTCFGOBJ OBJ(*ALL) OBJTYPE(*DEVD) OWNER(BLOGGSJ) Creates all device descriptions whose data is being stored on the backup node. BLOGGSJ will be assigned ownership of these device descriptions. CRTCFGOBJ OBJ(*ALL) OBJTYPE(*ALL) OWNER(*CURRENT) Creates all configuration objects whose data is being stored on the backup node. The user name that is running this command will be assigned ownership of all objects that are created. Use If the configuration object being created already exists on the backup node, this command can only be issued when the object is not in use. You must issue this command on the backup node where the configuration objects are created. However, the backup node does not have to be active. Menu Access F22 (Shift+F10) - Option 76

INITHAOBJInitialize Objects
INITHAOBJ TARGET( ) GROUP( ) Use this command to prepare objects for mirroring so that any changes made to the objects in questions are journaled. It changes the OS/400 parameter Object Auditing Value from *NONE to *CHANGE. Initializing objects should occur automatically, though you may need to issue this command in the following situations:

If the system auditing levels (QAUDLVL, and QAUDCTL) have been changed so that they no longer meet the required values for iCluster. See the VFYHAJRNVerify Audit Journal command for more information. If iCluster could not start auditing on one or more objects at the time the object specifier was added or modified. In this case a warning message will be logged in the job log to remind you to issue the INITHAOBJ command.

Any objects that are replicated by a group will have object auditing set to *CHANGE. Auditing should begin whenever an included specifier (BSF or native) is added to the group or whenever a specifier is changed to include an object or BSF. The following restrictions apply:

Excluded BSF objects are not respected when there is a more generic include. For example, /home/* *INC supersedes /home/dir1 *EXC or /home/dir1/* *EXC. The OS/400 parameter Object Auditing Value for BSF objects will always be set to *CHANGE.

Input Parameters TARGET The name of the backup node in the recovery domain for the replication group identified through the GROUP parameter (see below).

DataMirror, an IBM Company

Printed in Canada

249

GROUP The name of the replication group that will have its selected objects initialized through this command.

Example INITHAOBJ TARGET(NODE1) GROUP(GRP1) Initializes all objects selected to the replication group GRP1 that has NODE1 as a backup node. Use You must issue this command only on a primary node. You should issue it before you start mirroring in iCluster for the very first time and after you have selected an object specifier to a replication group. This command ensures the system auditing values and the system audit level are set to the values that iCluster needs for mirroring to work correctly. Menu Access F22 (Shift+F10) - Option 77

RTVRCVPTRetrieve Recovery Checkpoint


RTVRCVPT JRNKEY( ) JRN( ) OLDRCV( ) OLDPOS( ) OLDPOSLRG( ) Use this command to retrieve the recovery checkpoint position from the journal on the backup node given a journal key, journal, receiver, and position from the primary node. The journal key (JRNKEY) is specified in the DMADDGRPAdd Group command. You can use the recovery checkpoint to find the approximate backup node journal position corresponding to a given primary node journal position. This journal position can be used as the starting journal position in a recovery situation. Note: This command is intended to be issued from the command line only. To issue this command from a CL program, see the RTVRCVPTRRetrieve Recovery Checkpoint (CL Program) command. JRNKEY Specifies the key of a recovery checkpoint that was specified for the JRNKEY parameter of either the DMADDGRPAdd Group or DMCHGGRPChange Group command.

Parameters

JRN Specifies the name of the journal on the primary node. You need to identify the library where the journal resides. Prefix the journal with the name of the library where the journal is located (for example, LIB1/JRN1).

OLDRCV Indicates the name of the journal receiver on the primary node. You need to identify the library where the journal receiver resides. Prefix the journal receiver with the name of the library where the journal receiver is located (for example, LIB1/JRNRCV1).


Output

OLDPOS Indicates the journal position on the primary node. OLDPOSLRG Indicates the journal position of up to 20 digits on the primary node.

The journal receiver and journal position of the recovery checkpoint on the backup system is displayed in the job log.

250

Printed in Canada

iClusterVersion 5.1

Replication Operation Commands

Examples RTVRCVPT JRNKEY(RCVRYID1) JRN(LIB1/JRN1) OLDRCV(LIB2/JRNRCV2) OLDPOSLRG(242) Retrieves the recovery checkpoint based on the key RCVRYID1, journal JRN1, journal receiver JRNRCV2, and journal position 242. RTVRCVPT JRNKEY(RCVRYID1) JRN(LIB1/JRN1) OLDRCV(LIB2/JRNRCV2) OLDPOSLRG(2424546454533345) Retrieves the recovery checkpoint based on the key RCVRYID1, journal JRN1, journal receiver JRNRCV2, and journal position 2424546454533345. Use You may issue this command on the backup system as part of a recovery situation, such as after performing a switchover.

RTVRCVPTRRetrieve Recovery Checkpoint (CL Program)


RTVRCVPTR JRNKEY( ) JRN( ) OLDRCV( ) OLDPOS( ) OLDPOSLRG( ) RTNCDE( ) RTNRCVNME( ) RTVRCVLIB( ) RTNPOS( ) RTNPOSLRG( ) Use this command to retrieve the recovery checkpoint position from the journal on the backup node given a journal key, journal, receiver, and position from the primary node. The journal key (JRNKEY) is specified in the DMADDGRPAdd Group or DMCHGGRPChange Group command. You can use the recovery checkpoint to find the approximate backup node journal position corresponding to a given primary node journal position. This journal position can be used as the starting journal position in a recovery situation, such as after a switchover. Note: You must issue this command as part of a CL program. To issue this command from the command line, see the RTVRCVPTRetrieve Recovery Checkpoint command.

Input Parameters

JRNKEY Specifies the key of a recovery checkpoint that was specified for the JRNKEY parameter of either a DMADDGRP or DMCHGGRP command. JRN Specifies the name of the journal on the primary node. You need to identify the library where the journal resides. Prefix the journal with the name of the library where the journal is located (for example, LIB1/JRN1).

OLDRCV Indicates the name of the journal receiver on the primary node. You need to identify the library where the journal receiver resides. Prefix the journal receiver with the name of the library where the journal receiver is located (for example, LIB1/JRN1).

OLDPOS Indicates the journal position on the primary node. OLDPOSLRG Indicates the journal position of up to 20 digits on the primary node.

Output Parameters RTNCDE Indicates if the command succeeded or failed in retrieving a recovery checkpoint. One of the following values will be returned:

DataMirror, an IBM Company

Printed in Canada

251

*OKSpecifies that the command completed successfully. *ERRORSpecifies that the command did not complete successfully.

RTNRCVNME Indicates the name of the journal receiver on recovery machine. RTVRCVLIB Indicates the library where the journal receiver is located. RTNPOS Indicates the recovery checkpoint journal position on the backup machine. This is the journal position that is used in the DMSETPOSSet Journal Start Position command. RTNPOSLRG Indicates the recovery checkpoint journal position of up to 20 digits on the backup machine. This is the journal position that is used in the DMSETPOSSet Journal Start Position command.

Examples RTVRCVPTR JRNKEY(RCVRYID1) JRN(LIB1/JRN1) OLDRCV(LIB2/JRNRCV2) OLDPOS(262) RTNCDE (&RTNVAR) RTNRCVNME (&RCVNMEVAR) RTNRCVLIB (&RCVLIBVAR) RTNPOS (&POSVAR) Retrieves the recovery checkpoint position based on the key RCVRYID1, journal JRN1, journal receiver JRNRCV2, and journal position 262. Note: &RTNVAR, &RCVNMEVAR, &RCVLIBVAR and &POSVAR are CL variables. RTVRCVPTR JRNKEY(RCVRYID2) JRN(LIB2/JRN2) OLDRCV(LIB2/JRNRCV2) OLDPOSLRG(5612364789525458) RTNCDE (&RTNVAR) RTNRCVNME (&RCVNMEVAR) RTNRCVLIB (&RCVLIBVAR) RTNPOSLRG (&POSVARLRG) Retrieves the recovery checkpoint position based on the key RCVRYID2, journal JRN2, journal receiver JRNRCV2, and journal position 5612364789525458. Note: Use You need to issue this command from a CL program on the backup system as part of a recovery situation, such as after performing a switchover. &RTNVAR, &RCVNMEVAR, &RCVLIBVAR and &POSVARLRG are CL variables.

SYNCHATRGSynchronize Triggers
SYNCHATRG TARGET( ) GROUP( ) FILE( ) FILELIB( ) Use this command to refresh the triggers on the database files for a valid backup node or group. This command disables all synchronized triggers on the backup node. Input Parameters

TARGET The name of the backup node for the files whose triggers are going to be synchronized. Enter the name of a valid backup node or the following value:

*ALLAll targets will be used. If you select this value, then the command ignores the GROUP parameter.

GROUP The name of the group whose files are going to be synchronized. Enter the name of a valid group belonging to the specified backup node or the following value:

252

*ALLAll groups attached to the specified backup node.


Printed in Canada
iClusterVersion 5.1

Replication Operation Commands

FILE The database files whose triggers will be synchronized. These files must be within the replication scope of the backup node and group specified above. Enter a specific or a generic name or the following value: *ALL - All of the database files of the specified backup node or group.

FILELIB The library for the files whose triggers will be synchronized. Enter a specific name or the following value:

Output

*ALLAll libraries within replication scope of the backup node or group specified. The FILE parameter must be *ALL if you select this value.

Relevant messages are sent to the event and job logs. Examples SYNCHATRG TARGET(*ALL) GROUP(*ALL) FILE(*ALL) FILELIB(*ALL) Synchronizes triggers for all files within the replication scope for all libraries for all backup node and group combinations. SYNCHATRG TARGET(SITGT) GROUP(*ALL) FILE(*ALL) FILELIB(MYLIB1) Synchronizes triggers for all files within the replication scope of library MYLIB1 for all groups attached to target SITGT.' Use This command must be used on the source machine of the specified groups. The groups can be active or inactive when issuing the command, but actual synchronization will only occur when the group is active.

DMLOGENTLog Journal Entry


DMLOGENT GROUP( ) ENTTYP( ) USRDTA( ) DTAARA( ) Use this command to record the times that data is scraped and applied, which allows you to gauge the performance of specific groups in your cluster. You can also use this command to gain insight into the progress of your mirroring activities during batch runs or troubleshooting. This command creates the DMLOG database file on the backup node if it does not already exist. The log file has the following format:

Group (char 10): The name of the group or resilient application. ENTTYPE (4 bytes): Entry type Journal (char 20): Journal with library Receiver (char 20): Receiver with library Journal position sequence number (numeric 20) Scrape date/time: Filled in at run-time by a scraper job. Apply date/time: Filled in at run-time by an apply job. USRDTA (char 400): A user defined field. Data area contents (char 2000): Filled in at run-time by a scraper job.

Input Parameters GROUP

DataMirror, an IBM Company

Printed in Canada

253

The name of the group or resilient application for which logging information is deposited and recorded. Note: *REPL and *REFRESH groups are supported, while *MQSERIES and *SWDEV are not supported. ENTTYP Indicates the type of logging information. You can choose from a predefined type or create a user defined type. Specify an integer value between 1 and 2000 or one of the following values:

*INFOIndicates an informational entry. *STRRUNIndicates the beginning of mirroring. *ENDRUNIndicates the end of mirroring.

The default setting for this parameter is *INFO. USRDTA A user defined field of up to 400 characters that is optional. DTAARA The name of a data area that will be recorded in the log file. The data area cannot exceed 2000 bytes of character data. Specify the name of the data area or the following value:


Example

*NONEIndicates that no data area is specified.

The library where the data area resides must be identified if you do not specify *NONE. Prefix the data area name with the name of the library where the data area is located (for example, LIB2/DTAARA1), or the following value: *PRODLIBSpecifies your iCluster installation library. The default setting for this parameter is *NONE.

DMLOGENT GROUP(GRP1) ENTTYP(20) DTAARA(LIB3/DTAARA2) Logging information is tracked for GRP1. A user defined entry type of 20. The contents of DTAARA2 in library LIB3 will be recorded in the log file. Minimum Security Level Operator (*OPERATOR) Menu Access F22 (Shift+F10) - Option 78

254

Printed in Canada

iClusterVersion 5.1

Status and History Monitor Commands

Status and History Monitor Commands


This section contains the following topics:

DSPHASMONDisplay Source Monitor on page 255 WRKHASMONWork with Status Monitor on Primary Node on page 255 WRKHATMONWork with Status Monitor on Backup Node on page 256 CHGHASMONChange History Monitor on Primary Node on page 257 PRGHASMONPurge History Monitory on Primary Node on page 259 WRKHAOBJSTWork with Object Status on page 260 WRKHABSFSTWork with BSF Status on page 260 DMWRKOBJSTWork with Object Status by Group on page 261

DSPHASMONDisplay Source Monitor


DSPHASMON Use this command to display a simplified version of the Status Monitor on the primary system. This simplified Status Monitor allows you to view only the details and the status of objects for latency, throughput, object position, and journal information. No operational control of iCluster is provided from the resulting screen. Note: For additional functionality, you will need to issue the WRKHASMONWork with Status Monitor on Primary Node command. See the WRKHASMONWork with Status Monitor on Primary Node command for more information.

Input Parameters None. Output Relevant messages to the job log. Examples DSPHASMON Displays the simplified Status Monitor. Use You can issue this command at any time from the primary system. Menu Access F22 (Shift+F10) - Option 82

WRKHASMONWork with Status Monitor on Primary Node


WRKHASMON Use this command to display the Status Monitor on a primary node, which allows the replication status of both nodes to be viewed. The monitor reporting is based on group and journal combinations, which provide for both real time inquiry of active replication processes and historical inquiry of past activity. You can check object status and open the communication links from the Status Monitor. The following statuses and statistics may be viewed using the Status Monitor:

DataMirror, an IBM Company

Printed in Canada

255

Replication status for both active and inactive groups. Replication latency on the backup node. Primary and backup node journal positions. Run time totals for both primary and backup node replication processes. Throughput in transactions per hour for the backup node.

For more information about the features, functions, and displays provided by the monitor facility, see Working with the Status Monitor on page 291. Input Parameters None. Example WRKHASMON Displays the Status Monitor on the primary node of the group(s) Use You must issue this command on the primary node of the group(s) you want to monitor. Menu Access Main Menu - Option 80 F22 (Shift+F10) - Option 80

WRKHATMONWork with Status Monitor on Backup Node


WRKHATMON Use this command to display the Status Monitor on a backup node, which allows the replication status of both nodes to be viewed. The monitor reporting is based on group and journal combinations, which provides for both real time inquiry of active replication processes and historical inquiry of past activity. Using this command you can check object status. No communication with the primary node is required. The following statuses and statistics may be viewed using the Status Monitor:

Replication status for both active and inactive groups. Replication latency on the backup node. Primary and backup node journal positions. Run time totals for both primary and backup node replication processes. Throughput in transactions per hour for the backup node.

For more information about the features, functions, and displays provided by the monitor facility, see Working with the Status Monitor on page 291. Input Parameters None. Example WRKHATMON Displays the Status Monitor allowing the replication status of groups as well as transaction information to be viewed.

256

Printed in Canada

iClusterVersion 5.1

Status and History Monitor Commands

Use You must issue this command on the backup node of the groups you want to monitor. Menu Access Main Menu - Option 81 F22 (Shift+F10) - Option 81

CHGHASMONChange History Monitor on Primary Node


CHGHASMON TARGET( ) GROUP( ) STRDTE( ) STRTIM( ) POLINT( ) ENDDTE( ) ENDTIM( ) Use this command to change the history monitor collection process on a primary node. The collection process can be modified so that replication information is captured for different groups within different collection intervals. Monitor reporting is based on groups that provide for both real time inquiry and historical inquiry of replication processes. The following status and statistics can be viewed using the Status Monitor:

Replication status for both active and inactive groups. Replication latency on the backup node. Primary and backup node journal positions. Runtime totals for both primary and backup node replication processes. Throughput in transactions per hour for the backup node.

For more information about the features, functions, and displays provided by the monitor facility, see Working with the Status Monitor on page 291. Input Parameters

TARGET GROUP The name of the group for which data will be collected. The primary node in the group must be the system where this command is invoked. STRDTE The starting date for replication monitoring. The date must be supplied in a format specified in the user's job attributes. If the date specified precedes the current date, monitoring will start at the current date. Enter a specific date or one of the following values:

The name of the backup node for which you will be starting the history monitor collection.

*TODAYStarts monitoring on the current date. *SAMEUses the current setting for this parameter.

The default setting for this parameter is *TODAY. STRTIM The starting time for monitoring replication. The time must be entered as a six-digit integer, between 000000 (midnight) and 235959 (11:59:59 p.m.), that represents a valid time. Enter a specific time or one of the following values:

*IMMEDIf the starting date (see STRDTE above) is set to *TODAY or an earlier date, monitoring starts immediately. If the starting date is set to a later date, monitoring starts at 000000 on the specified date. *SAMEUses the current setting for this parameter.

DataMirror, an IBM Company

Printed in Canada

257

The default setting for this parameter is *IMMED. Note that if the date specified in the parameter STRDTE (see above) precedes the current date, monitoring will start immediately.

POLINT The polling interval for monitoring replication. This is the time interval that the monitoring system will use to take a snapshot of replication activity. This parameter must be entered as a six-digit integer, between 000010 and 235959. Specify a polling interval or the following value:

*SAMEUses the current setting for this parameter.

The default setting for this parameter is 001500 (15 minutes). ENDDTE The ending date for monitoring replication. The date must be supplied in a format specified in the user's job attributes. Enter a specific date or one of the following values:


Note:

*TODAYEnds monitoring on the current date. *NONEEnds monitoring when all replication processes end. *SAMEUses the current setting for this parameter.

This default setting for this parameter is *NONE. The history monitor collection process is always active when replication is active. Note that if the date specified precedes the current date, an error message will be issued asking you to correct their input.

ENDTIM The ending time for replication monitoring. The time must be entered as a six-digit integer, between 000000 (midnight) and 235959 (11:59:59 p.m.), that represents a valid time. Enter a specific time or one of the following values:


Note:

*NONEEnds monitoring when all replication processes end or when the CHGHASMON command is invoked. If the end date (see ENDDTE above) is set to *TODAY or a date in the future, monitoring will end at 23:59:59 (11:59:59 p.m.) on that date. *SAMEUses the current setting for this parameter.

The default setting for this parameter is *NONE. The history monitor collection process is always active when replication is active. Note that if the time specified precedes the current time, an error message will be issued asking the user to correct their input. However, the time specified may precede the current time if the end date (see ENDDTE above) has been set to a date in the future. Example CHGHASMON TARGET(NODE2) GROUP(GRP1) STRDTE(*TODAY) STRTIM(163000) POLINT(013000) ENDDTE('07/23/03') ENDTIM(175959) The monitor facility will collect information pertaining to the replication status of group GRP1 whose backup node is NODE2. Replicated objects will be monitored between 4:30 p.m. on the day the command is issued, and 6:00 p.m. on July 23, 2003. Replication activity will be captured every 90 minutes within this time interval. Use You must issue this command on the primary node of the groups you want to monitor.

258

Printed in Canada

iClusterVersion 5.1

Status and History Monitor Commands

Menu Access F22 (Shift+F10) - Option 83

PRGHASMONPurge History Monitory on Primary Node


PRGHASMON TARGET( ) ENDDTE( ) ENDTIM( ) Use this command to delete the historical information from the Status Monitor history database on the primary node. For more information about the features, functions, and displays provided by the monitor facility, see Working with the Status Monitor on page 291. Input Parameters

TARGET The name of the backup node for which records will be removed. Enter a specific name of a backup node or the following value:

*ALLRecords related to all backup nodes will be deleted.

This field requires an entry. ENDDTE The latest date for records to be deleted. All records timestamped before the specified date and time (see ENDTIM below) will be purged. The date must be supplied in a format specified in the user's job attributes. If the date specified follows the current date, all the historical information will be deleted. Enter a specific date or the following value:

*TODAYIndicates that history log records for all dates will be deleted.

The default setting for this parameter is *TODAY. ENDTIM The latest time for records to be deleted. All records timestamped before the specified date (see ENDDTE above) and time will be purged. The time must be entered as a six-digit integer, between 000000 and 235959, that represents a valid time. Enter a specific time or the following value:

Example

*NOWThe ending time for records to be deleted is the current time.

The default setting for this parameter is *NOW.

PRGHASMON TARGET(NODE2) ENDDTE('12/31/03') ENDTIM(235959) Purges the monitor of iCluster historical records that were written before the end of 2003 and whose backup node is NODE2. Use You must issue this command on the primary node of the groups that you want to monitor. Menu Access F22 (Shift+F10) - Option 85

DataMirror, an IBM Company

Printed in Canada

259

WRKHAOBJSTWork with Object Status


WRKHAOBJST TARGET( ) GROUP( ) JOURNAL( ) LOCATION( ) SOURCE( ) This command displays the Work with Object Status screen. This screen shows the status of a journal. See Working with Object Status on page 306 for more information. Input Parameters

TARGET Specifies the backup node of the specified group. GROUP Specifies the name of an existing replication group. JOURNAL Specifies the name of an existing journal. The library where the journal resides must be identified. Prefix the journal with the name of the library where the journal is located (for example, LIB2/JRN1). The possible values are:

*PRODLIBSpecifies your iCluster installation library. *UNKNOWNSpecifies a library-journal combination with the values *UNKNOWN/*UNKNOWN. You would specify *UNKNOWN when you want to check whether there are suspended objects associated with unknown journals and libraries. library-nameSpecifies the name of the library where the specified journal is located.

LOCATION Specifies whether you want to work with object status on the primary or backup node. The possible values are:

*SRCIndicates that you want to work with object status on the primary node. *TGTIndicates that you want to work with object status on the backup node.

SOURCE Specifies the name of the primary node where the objects you want to view the status for are located. This command only uses the value for this parameter when LOCATION is *SRC.

Example WRKHAOBJST TARGET(TGT1) GROUP(GRP1) JOURNAL(LIB1/JRN1) Displays the journal JRN1, located in the library LIB1, belonging to the group GRP1 and backup node TGT1.

WRKHABSFSTWork with BSF Status


WRKHABSFST TARGET( ) GROUP( ) JOURNAL( ) LOCATION( ) SOURCE( ) This command displays the Work with Object Status screen. This screen shows the status of a journal. See Working with BSF Status on page 310 for more information. Input Parameters

TARGET Specifies the backup node of the specified group.

260

Printed in Canada

iClusterVersion 5.1

Status and History Monitor Commands

GROUP Specifies the name of an existing replication group. JOURNAL Specifies the name of an existing journal. The library where the journal resides must be identified. Prefix the journal with the name of the library where the journal is located (for example, LIB2/JRN1). The possible values are:

*PRODLIBSpecifies your iCluster installation library. *UNKNOWNSpecifies a library-journal combination with the values *UNKNOWN/*UNKNOWN.

You would specify *UNKNOWN when you want to check whether there are suspended objects associated with unknown journals and libraries. library-nameSpecifies the name of the library where the specified journal is located.

LOCATION Specifies whether you want to work with object status on the primary or backup node. The possible values are:

*SRCIndicates that you want to work with object status on the primary node. *TGTIndicates that you want to work with object status on the backup node.

The default value is *SRC. SOURCE Specifies the name of the primary node where the objects you want to view the status for are located. This command only uses the value for this parameter when LOCATION is *SRC. Example WRKHABSFST TARGET(TGT1) GROUP(GRP1) JOURNAL(LIB1/JRN1) Displays the journal JRN1, located in the library LIB1, belonging to the group GRP1 and backup node TGT1.

DMWRKOBJSTWork with Object Status by Group


DMWRKOBJST GROUP( ) STRWITH( ) This command displays the Work with Object Status by Group screen. This screen displays the status of objects for a specified group. You can also use this screen to activate suspended native objects. You must run this command from the backup node of the specified group. Input Parameters

GROUP The name of the group you want to monitor. STRWITH Specifies which view you want to open this screen with. After running this command, you can change views by pressing F16. The possible values are:

*NTVStart with the native object view. *BSFStart with the BSF object view.

DataMirror, an IBM Company

Printed in Canada

261

The default value is *NTV. Example DMWRKOBJST GROUP(GRP1) STRWITH(*NTV) Displays the status of objects in the GRP1 group. When the screen first appears, it shows native objects.

262

Printed in Canada

iClusterVersion 5.1

Sync Check Commands

Sync Check Commands


This section contains the following topics:

DSPHASCDisplay Sync Check on page 263 SELSCATTRSelect Sync Check Attributes on page 265 STRHASCStart Sync Check on page 267 STRHASCUSRStart User Sync Check on page 270 DMSCRPTSync Check Report for IFS Objects on page 274 DMSCRPTNTVSync Check Report for Native Objects on page 275 PRGHASCPurge Sync Check Results on page 276

DSPHASCDisplay Sync Check


DSPHASC Use this command to access the results of the sync check. The results are contained in a spool file named <Group Name> Sync Check Report. You can display the results of the sync check by entering option 5 in the field beside the name of a selected spool file. The report contains the following sections that are organized by sync check type.

*FILEATTR Sync Check Type


This type of sync check contains the following sections: HA Sync Check Summary This section contains the following statistics about the sync check:

Total number of objects checked Total number of objects not matching Total number of members not matching Total number of extra members on backup Total number of objects not on backup Total number of members not on backup Total number of objects that cannot be allocated

Note that this section is not displayed if all objects exist on the backup system. Object List Report This section displays the following columns:

Object/Member: Displays the name of the object and member. An asterisk to the left of this column indicates a mismatch between the object on the primary and backup nodes. The type of mismatch is indicated in the last four columns. Src Lib: Displays the name of the library where the source object is located on the primary node. Tgt Lib: Displays the name of the library where the target object is located on the backup node. Type: Indicates the type of the object. Size: Indicates the size of the object on the primary node in bytes. Note that only mismatched objects are displayed (not in sync).

DataMirror, an IBM Company

Printed in Canada

263

#Attr checked: Displays the number of attributes that were checked in the sync check. You can modify the number of attributes that are checked. See the SELSCATTRSelect Sync Check Attributes command for more information. #Attr match: Indicates the number of attributes that matched on the primary and backup nodes for the object. #Attr not match: Indicates the number of attributes for the object that did not match on the primary and backup nodes. If you have non-matching attributes, then this object is not in sync. You should check the Object Differences Detail section to determine which attribute(s) did not match. Not found: A 'B' in this column indicates that the object was not found on the backup node.

Object Differences Detail This section provides information about any objects that did not match. It displays the name of the object that had unmatching attributes, the library where the object resides on both the primary and backup nodes, the object size, and the type of file. It also indicates the attribute(s) that did not match, and the attribute settings on the primary and backup nodes. If all objects matched, then this section will not be displayed in the sync check results. Unallocated Object List This section lists the objects that could not be sync checked because they were locked by another process and their attributes could not be retrieved. This section is displayed if one or more objects were locked during the sync check.

*LIST Sync Check Type


This type of sync check contains the following sections:

Object List Comparison Statistics Object List Comparison Details. This section displays information by object type and has an *OUTQ mismatch column that indicates how many output queue (*OUTQ) objects do not match between the primary node and the backup node. Objects Not Found or Mismatched on Backup. This section lists the objects and has a SPLF count column that indicates whether or not the number of spooled files in an *OUTQ object is the same on the primary node and the backup node. Total objects checked on primary Total objects found on backup Total objects not found or mismatched on backup. Number of objects that could not be accessed for checking

These sections display the following information:

*DTAARA Sync Check Type


This type of sync check contains the following sections: Data Area Sync Check Summary This section contains the following columns:


264

Data Area: The name of the data area. Src lib: Displays the name of the library where the source data area is located on the primary node. Tgt lib: Displays the name of the library where the target data area is located on the backup node. Identical: Specifies whether the two objects match. Not found: Specifies whether the data area exists on the backup node. Attr differ: Indicates the object attributes that differ on the backup node from the primary node. Contents differ: Specifies those data areas on the backup node whose contents are different from the primary node.

Printed in Canada

iClusterVersion 5.1

Sync Check Commands

Comparison failed: Identifies the objects that could not be compared, for example, because one of the objects was locked. Number of data areas checked Number of mismatched data areas

This section also displays the following items:

*BSF Sync Check Type


This type of sync check contains the following section: Object List Comparison Statistics This section contains the following statistics about the sync check:

Number of objects checked on primary Total number of objects found on backup Total number of objects not matching (checks for object existence, object authority, user/group/owner permission, and primary group) Number of objects not found on backup Number of objects that could not be accessed for checking To view the output for this type of sync check, you can run the DMSCRPTSync Check Report for IFS Objects command on the backup node.

Note:

Input Parameters None. Output This command displays the list of spool files generated by the sync check. A completion message for sync check will be put into the event log on the group's primary node. For more information about event logs, see Monitoring Replication on page 76. Example DSPHASC Displays all sync check spool files on the Work with All Spooled Files screen. Use You should issue this command from the group's primary node after performing a sync check. Menu Access F22 (Shift+F10) - Option 90

SELSCATTRSelect Sync Check Attributes


SELSCATTR USEDFT( ) Use this command to select file attributes that will be involved in a sync check operation. The file attributes that you can include are divided into four groups:

File attributes: These attributes relate to each file. Member attributes: These attributes relate to each member within each file. Record attributes: These attributes relate to the record formats contained within each file.

DataMirror, an IBM Company

Printed in Canada

265

Field attributes: These attributes relate to the fields of records contained within each file. You should select at least one file attribute at the file level. If you select attributes at the member level, then the File Member Name attribute will automatically be selected for the sync check. The number of attributes that you select can affect the performance of the sync check. The more attributes you select, then the longer the sync check will take to complete. If you are unsure which attributes to select, DataMirror recommends using the default values. When you first issue this command, all the defaults are selected.

When selecting attributes, you should note the following items:

Some attributes are included, by default, in a check. While you do not need to use the default attributes, DataMirror recommends that you do because they are important in determining primary and backup node synchronization. The default sync check attributes are as follows: File Level Attributes

Access path maintenance File generic key field count File generic key length Increment number of records Initial number of records Maximum key length Maximum members Maximum number of fields Maximum record length Null value duplicate indicator Number of constraints Number of key fields Primary key indicator Public authority at creation Record format level check Reuse deleted record indicator Total number of members Total number of record formats Unique constraint indicator

Member Level Attributes Current number of records File attribute File member name Number of deleted records

266

Printed in Canada

iClusterVersion 5.1

Sync Check Commands

You must specify the attributes you want to include in a sync check prior to launching the sync check program. Note that this attribute list is global, meaning that the attributes you include affect all sync checks. The list of attributes used by the sync check is stored in the database file scattrfile. The online help for the SELSCATTRSelect Sync Check Attributes command also contains a list of all the attributes that can be included during a sync check. Note that you can use this command for both the STRHASCStart Sync Check and STRHASCUSRStart User Sync Check commands. Input Parameter

USEDFT Indicates whether the default settings will be used. Enter one of the following values:


Note: Examples

*YESUses the default value for each attribute. Any changes that you have selected for the attributes are ignored. *NODoes not use the default attribute selections, and instead use the values that you have selected.

Use the Page Down key to view all of the attributes that you can select for a sync check.

SELSCATTR USEDFT(*YES) The default values will be used in the sync check. SELSCATTR USEDFT(*NO) The selections that you made will be applied in the sync check. Use Use this command to indicate the attributes that you want to use during a sync check. You should issue this command from a primary node. Menu Access F22 (Shift+F10) - Option 91

STRHASCStart Sync Check


STRHASC TARGET( ) GROUP( ) LOCK( ) SCTYPE( ) DATE( ) TIME( ) OUTPUT( ) Use this command to start the sync check program. A sync check allows you to check whether the objects on the backup node are the same as the objects on the primary node within a replication group. All objects for the specified replication group are checked. By comparison, the STRHASCUSR Start User Sync Check command allows you to perform a sync check on specific objects that are replicated in the replication group. You can perform the following types of sync checks:

The object list sync check compares the number of objects on the primary node with the number of objects on the backup node. It does not compare the attributes of the objects. The file attribute sync check checks for the existence of replicated *FILE objects on the backup node. It also compares the attributes of the primary and backup node *FILE objects. Note that the object list sync check compares all object types while the file attribute check examines only *FILE objects. You can also use this command to perform a data area sync check and a BSF sync check for BSF objects. See DSPHASCDisplay Sync Check for more information on the type of information that is displayed with a data area or BSF sync check. A check journaling sync check verifies that the native and BSF objects for a group are journaled on the backup node.

DataMirror, an IBM Company

Printed in Canada

267

How often you perform a sync check depends on how often you want to check that the primary and backup node objects are the same. Through the use of the SELSCATTRSelect Sync Check Attributes command, you can indicate the attributes that you want to include in a file attribute check. Note that the more attributes you include in the sync check, the longer the check will take. The results of the sync check are displayed in a spool file on the primary node. See DSPHASCDisplay Sync Check for more information. Input Parameters

TARGET The name of the backup node for the specified group on the GROUP parameter. GROUP The name of a replication group defined in iCluster. LOCK Indicates whether the files involved in the sync check will be locked during a file attribute sync check. Locking ensures that an accurate synchronization takes place between the primary and backup nodes, but it increases the amount of time required to complete the operation.

Note:

If you decide to lock objects during a sync check, DataMirror recommends that you do not initiate a sync check when the objects in question are being heavily used. DataMirror recommends that the DMSETSVALSet Cluster System Values parameter LOCKTGT is set to *YES to ensure that the backup node files are also not changed by users. Enter one of the following values:

*YESIndicates that files will be locked during the sync check. If a file cannot be locked, then it will not be involved in the sync check, and a message will be logged in a spool file. Note that locking files increases the time it takes to complete the sync check. *NOIndicates that files will not be locked during the sync check. You will have to make sure that the files are not modified during the course of the sync check. This is the default value for this parameter.

Not locking files decreases the amount of time required to complete the sync check. SCTYPE The type of sync check that you want to perform. Specify one of the following values:

*FILEATTRChecks whether the *FILE objects on the primary node exist on the backup node. It also checks that the attributes of the primary node *FILE objects match the attributes of the backup node *FILE objects. This type of check locks each object until the check for the individual object has been completed. Therefore, this option produces a slower sync check as each object has to be individually locked and then unlocked. However, each object is locked for a shorter period of time, which means that access to the object is possible while other objects are being checked. *FILEATTR sync check requires that the files being checked are journaled, and that all of the group's required database journal scrape and apply processes are active. Source physical files can be sync checked with *FILEATTR sync check if either of the following two requirements are met:


Note:

If the file is journaled and there is a scrape and apply process for the file's journal active for the group that is being sync checked. If the file is not journaled but there is a scrape and apply process active for the default database journal for the group that is being sync checked.

*FILEATTR sync check will check objects of attribute type PF-SRC only if the group the object belongs to replicates at least one object that is being journaled. For example, having at least one PF-DTA object in the group will ensure *FILEATTR sync checks will include the PF-SRC objects.

268

Printed in Canada

iClusterVersion 5.1

Sync Check Commands

Note:

*FILEATTR sync checks will not report object contents mismatches if you decide not to refresh or mirror the object contents with MIRRCNTS(*NO) in the DMSELOBJSelect Objects to Group command.

Note:

*LISTChecks whether the objects on the primary node exist on the backup node.

The objects for a *LIST sync check are restricted to native OS/400 objects (library objects). To perform a sync check on BSF (path) objects, the *BSF sync check type should be selected.

Note:

*BSFChecks all the BSF objects on the primary node that match the specified path object specifiers with the matching objects on the backup node.

DataMirror recommends that you run sync check for BSF objects only when latency for the group is negligible, or when little or no change is occurring for the objects being checked.

*DTAARAChecks whether data area objects on the primary node are replicated to the backup node with the correct attributes and contents.

If a certain data area does not exist on the primary node when you issue this command, it will not be included in the sync check. Note: *DTAARA sync checks will not report object contents mismatches if you decide not to refresh or mirror the object contents with MIRRCNTS(*NO) in the DMSELOBJSelect Objects to Group command.

*CHKJRNVerifies that the objects selected to this group are journaled on the backup node. This report considers objects to be out-of-sync if any of the following conditions are met: It is a *FILE, *DTAARA, or *DTAQ object that is not journaled on the backup node. It is a non-directory *STMF object that is journaled on the primary node and not journaled on the backup node. A journaled *STMF file or directory object exists on the primary node but not on the backup node.

You can only generate this report if the Journal Objects on Backup system value is set to *YES. See the Physical File values of the DMSETSVALSet Cluster System Values command for more information. The default setting for this parameter is *FILEATTR.

DATE The date when the sync check will be started. The date that you enter must be entered in MMDDYY format, where the first two digits represent the month, the second two digits represent the day, and the last two digits represent the year (for the year 2000, set YY to 00). Enter a specific date or the following value:

*CURRENTIndicates that the sync check will be performed when you issue this command.

The default setting for this parameter is *CURRENT. TIME The time when the sync check will be started. The time that you enter must be in the six-digit format HHMMSS, where the first two digits represent hours, the second two represent minutes, and the last two represent seconds. Enter a specific time or the following value:

*CURRENTIndicates that the sync check will be performed when you issue this command.

The default setting for this parameter is *CURRENT. OUTPUT The type of sync check report that should be generated. You can generate a complete sync check report that displays information about all objects included in the sync check, regardless of whether they are synchronized on the primary and backup nodes. Depending on the number of objects included in the sync check, this report can be long and difficult for navigation purposes.

DataMirror, an IBM Company

Printed in Canada

269

Note:

This parameter only applies to *FILEATTR, *LIST, and *DTAARA sync checks. *BSF sync check does not produce a listing of objects. Use the DMSCRPTSync Check Report for IFS Objects command to obtain a *BSF sync check report. Alternately, you can generate a report that displays only those objects that are not synchronized on the primary and backup nodes. Enter one of the following values:

*MISMATCHDisplays only those objects that are not synchronized when writing the sync check report. *ALLDisplays all objects, regardless of whether they match or not. *NONEIndicates that no spool file report is to be generated for the sync check. The output is still sent to a database file. Use the DMSCRPTSync Check Report for IFS Objects or DMSCRPTNTVSync Check Report for Native Objects command to view the sync check report in the database file.

The default setting for this parameter is *MISMATCH. Examples STRHASC TARGET(TGT1) GROUP(GRP1) SCTYPE (*LIST) DATE(*CURRENT) TIME(*CURRENT) OUTPUT(*MISMATCH) Indicates that an Object List sync check command will begin at the current date and time for the backup node TGT1 and group GRP1 for selected objects. The report displays only those objects that are not synchronized Use You must issue this command on the primary node of the specified replication group. Menu Access F22 (Shift+F10) - Option 92

STRHASCUSRStart User Sync Check


STRHASCUSR TARGET( ) GROUP( ) LOCK( ) SCTYPE( ) OBJSPEC( ) PATH( ) DATE( ) TIME( ) OUTPUT( ) Use this command to test if a set of user-specified objects are synchronized between th primary and backup nodes in a group. This command allows you to perform a synchronization check on a single object or a subset of objects replicated within the specified replication group. This can be useful when a replication group is replicating an object specifier with the *ALL setting, but you want to ensure synchronization for a single object that is referenced by that object specifier. By comparison, the STRHASCStart Sync Check command performs a sync check on all objects selected to the specified group. The following types of synchronization checks are available:

The object list check compares the number of objects on the primary node with the number of objects on the backup node. It does not compare the attributes of the objects. The file attribute check checks for the existence of replicated *FILE objects on the backup node. It also compares the attributes of the primary and backup node *FILE objects. Note that the object list sync check compares all object types while the file attribute check examines only *FILE objects. You can also use this command to perform a data area check and a BSF check for native and BSF objects, respectively. See DSPHASCDisplay Sync Check for more information on the type of information that is displayed with a data area or BSF synchronization check.

How often you test for synchronization depends on how often you want to check that the primary and backup node objects are the same. Through the use of the SELSCATTRSelect Sync Check Attributes command, you can indicate the attributes that you want to include in a file attribute sync check. Note that the more attributes you include in the sync check, the longer the check will take. The results of the sync check are displayed in a spool file on the primary node. See DSPHASCDisplay Sync Check on page 263 for more information.

270

Printed in Canada

iClusterVersion 5.1

Sync Check Commands

Input Parameters

TARGET GROUP LOCK Indicates whether the files involved in the sync check will be locked during a file attribute sync check. Locking ensures that an accurate sync check takes place between the primary and backup nodes, but it increases the amount of time required to complete the operation.

The name of the backup node for the specified group on the GROUP parameter. The name of a replication group defined in iCluster.

Note:

If you decide to lock objects during a sync check, DataMirror recommends that you do not initiate a sync check when the objects in question are being heavily used. DataMirror recommends that the DMSETSVALSet Cluster System Values parameter LOCKTGT is set to *YES to ensure that the backup node files are also not changed by users. Enter one of the following values:

*YESIndicates that files will be locked during the sync check. If a file cannot be locked, then it will not be involved in the sync check, and a message will be logged in a spool file. *NOIndicates that files will not be locked during the sync check. You will have to make sure that the files are not modified during the course of the sync check. This is the default value for this parameter.

Note that locking files increases the time it takes to complete the sync check.

Not locking files decreases the amount of time required to complete the sync check. SCTYPE The type of sync check that you want to perform. Specify one of the following values:

*FILEATTRChecks whether the *FILE objects on the primary node exist on the backup node. It also checks that the attributes of the primary node *FILE objects match the attributes of the backup node *FILE objects. This type of check locks each object until the check for the individual object has been completed. Therefore, this option produces a slower sync check as each object has to be individually locked and then unlocked. However, each object is locked for a shorter period of time, which means that access to the object is possible while other objects are being checked. *FILEATTR sync check requires that the files being checked are journaled, and that all of the group's required database journal scrape and apply processes are active. Source physical files can be sync checked with *FILEATTR sync check if either of the following two requirements are met:


Note:

If the file is journaled and there is a scrape and apply process for the file's journal active for the group that is being sync checked. If the file is not journaled but there is a scrape and apply process active for the default database journal for the group that is being sync checked.

*FILEATTR sync check will check objects of attribute type PF-SRC only if the group the object belongs to replicates at least one object that is being journaled. For example, having at least one PF-DTA object in the group will ensure *FILEATTR sync checks will include the PF-SRC objects.

*BSFChecks all the BSF objects on the primary node that match the specified path object specifier with the matching objects on the backup node. You can enter a path name of up to 5000 characters in length. The path name can be generic, for example "/home/adamsmith/*". A sync check will be performed on all objects in the "/home/adamsmith" directory.

DataMirror, an IBM Company

Printed in Canada

271


Note:

*LISTChecks whether the objects on the primary node exist on the backup node.

The objects for a *LIST sync check are restricted to native OS/400 objects (library objects). To perform a sync check on BSF (path) objects, the *BSF sync check type should be selected.

*DTAARAChecks whether data area objects on the primary node are replicated to the backup node with the correct attributes and contents. If a certain data area does not exist on the primary node when you issue this command, it will not be included in the sync check.

The default setting for this parameter is *FILEATTR.

Note: Note:

OBJSPEC The default setting for all object specifier parameters is *ALL. The set of parameters that will filter the objects you want to check. This parameter is ignored if the SCTYPE parameter is set to *BSF. Object The name of the objects that you want to include in the sync check. Note that you can enter a generic name to identify multiple objects in a library. Specify the name of the object or the following value:

*ALLIndicates that you want to include all object names in the sync check.

The examples illustrate how the library and object parameters are specified in OBJSPEC. Library The name of the library where the objects are located. The examples illustrate how the library and object parameters are specified in OBJSPEC. Object type The type of objects that you want to include in the sync check. This parameter is only used if the SCTYPE parameter is set to *LIST. Specify the object type or the following value:

*ALLIndicates that you want to include all object types in the sync check.

For a complete list of all object types that iCluster can replicate, see Object Types Replicated by iCluster on page 529. Object attribute The attribute of the objects that you want to include in the sync check. Note that the object attribute is applicable only if you specified a *FILE object in the Object type parameter. This field is free-form. Consequently, you can enter any value you want to represent the object, as long as the value conforms to OS/400 naming conventions. However, there are values that have special meaning to iCluster. They are PFSRC (source physical file), PFDTA (data physical file), and PF (any physical file). Other values listed are standard OS/400 file sub-types. If PF is used, the object specifier will match either PFSRC or PFDTA files. Specify an object attribute or the following value:

*ALLIndicates that you want to include all object attributes in the sync check.

PATH The path specifier that identifies the location of the BSF objects that you want to include in the sync check. The path must be enclosed in single quotes and start with a '/' (forward slash) character ('/Dir3/Dir4/file'). The path can be a maximum of 5000 characters, and you must enter at least two characters for the path.

272

Printed in Canada

iClusterVersion 5.1

Sync Check Commands

Generic path names of the form '/mydir*' are supported, where the generic indicator '*' is the final character of the path name. When using generic path names, all sub-directories are included recursively. This parameter is only used if the SCTYPE parameter is set to *BSF. For more information about path object specifiers, see Path Object Specifiers on page 53.

DATE The date when the sync check will be started. The date that you enter must be entered in MMDDYY format, where the first two digits represent the month, the second two digits represent the day, and the last two digits represent the year (for the year 2000, set YY to 00). Enter a specific date or the following value:

*CURRENTSpecifies that the sync check will be performed when you issue this command.

The default setting for this parameter is *CURRENT. TIME The time when the sync check will be started. The time that you enter must be in the six-digit format HHMMSS, where the first two digits represent hours, the second two represent minutes, and the last two represent seconds. Enter a specific time or the following value:

*CURRENTSpecifies that the sync check will be performed when you issue this command.

The default setting for this parameter is *CURRENT. OUTPUT The type of sync check report that should be generated. You can generate a complete sync check report that displays information about all objects included in the sync check, regardless of whether they are synchronized on the primary and backup nodes. Depending on the number of objects included in the sync check, this report can be long and difficult for navigation purposes. Alternately, you can generate a report that displays only those objects that are not synchronized on the primary and backup nodes. Note: This parameter only applies to *FILEATTR, *LIST, and *DTAARA sync checks. *BSF sync check does not produce a listing of objects. Use the DMSCRPTSync Check Report for IFS Objects command to obtain a *BSF sync check report. Enter one of the following values:

*MISMATCHDisplays only those objects that are not synchronized when writing sync check report. *ALLDisplays all objects, regardless of whether they match or not. *NONEIndicates that no spool file report is to be generated for the sync check. The output is still sent to a database file. Use the DMSCRPTSync Check Report for IFS Objects or DMSCRPTNTVSync Check Report for Native Objects command to view the sync check report in the database file.

The default setting for this parameter is *MISMATCH. Examples STRHASCUSR TARGET(TGT1) GROUP(GRP1) SCTYPE(*FILEATTR) OBJSPEC(*ALL LIB1 *FILE PF) DATE(*CURRENT) TIME(*CURRENT) OUTPUT(*MISMATCH) Indicates that the sync check command will be begin at the current date and time for the backup node TGT1 and the group GRP1. It will check the selected attributes for all *FILE objects in the library LIB1. The sync check report will display only those objects that are not synchronized. Note: It is important that at least one space separates each item contained in the OBJSPEC parameter. Follow the examples that are provided to specify this parameter correctly.

DataMirror, an IBM Company

Printed in Canada

273

Use You must issue this command on the primary node of the specified replication group. Menu Access F22 (Shift+F10) - Option 93

DMSCRPTSync Check Report for IFS Objects


DMSCRPT GROUP( ) SORTBY( ) OUTPUT( ) You can use this command to generate a report based on current information in the sync check database file. Using this command, you can:


Note: Note:

Display the report on your screen or send the results to a spool file. Sort output by group name or object name. List groups and objects that are out-of-sync as of the last sync check that was run for the group(s).

This command will only report results for the backup node where it is issued and for the group(s) that you specify. The node can be active or inactive. This command can be issued anywhere, but only reports sync check results for the backup node where it is issued. You can only run this command for the *BSF sync check type.

Input Parameters

GROUP The name of a group that has been sync checked and is used to generate a sync check report or the special value *LOCAL. Enter the name of the group or the following value:

*LOCALAll the groups that have the current node as their backup node are used in the sync check report.

*LOCAL is the default setting for this parameter. SORTBY This parameter allows you to sort the output (alphabetically) of the sync check report by group name or object name. Enter one of the following values:

*GROUPSort the sync check results by group name. *OBJECTSort the sync check results by object name.

*GROUP is the default setting for this parameter. OUTPUT This parameter allows you to specify whether you would like to view the sync check report on your screen or send the results to a spool file. Enter one of the following values:


Examples

*The sync check report is displayed on your screen. *PRINTThe sync check report is placed in a spool file.

'*' is the default setting for this parameter.

DMSCRPT GROUP(*LOCAL) SORTBY(*GROUP) OUTPUT(*)

274

Printed in Canada

iClusterVersion 5.1

Sync Check Commands

All the groups that have the current node as the backup node are used in the sync check report. The output of the report is sorted (alphabetically) by group name. The output of the report is displayed on your screen. Use The command must be used on the backup node for the group(s) that you specify in this command. The node can be active or inactive. Menu Access F22 (Shift+F10) - Option 94

DMSCRPTNTVSync Check Report for Native Objects


DMSCRPTNTV GROUP( ) DETAIL( ) You can use this command to generate a report based on current information in the sync check database file for native, library-based objects on the backup node. Using this command, you can:


Note: Note:

Send a report containing sync check results to a spool file. List groups and objects that are out-of-sync as of the last sync check that was run for the group(s).

This command will only report results for the backup node where it is issued and for the group(s) that you specify. The node can be active or inactive. This command can be issued anywhere, but only reports sync check results for the backup node where it is issued. You can only run this command for the *FILEATTR, *DTAARA, *LIST, and *CHKJRN sync check types.

Input Parameters

GROUP The name of a group that has been sync checked and is used to generate a sync check report or the special value *LOCAL. Enter the name of the group or the following value:

*LOCALAll the groups that have the current node as their backup node are used in the sync check report.

*LOCAL is the default setting for this parameter. DETAIL Controls whether detailed information about attribute mismatches is displayed. Enter one of the following values:


Note:

*NOMismatching objects are listed without attribute details. *YESMismatching objects are listed along with each of their attributes that differs.

*YES is valid for *FILEATTR and *DTAARA sync checks only. *NO is the default setting for this parameter.

Examples DMSCRPTNTV GROUP(*LOCAL) DETAIL(*NO) All the groups that have the current node as the backup node and for which a sync check has been performed are used in the sync check report. The output of the report is sent to a spool file named DMSCRPTNTV.

DataMirror, an IBM Company

Printed in Canada

275

Use The command must be used on the backup node for the group(s) that you specify in this command. The node can be active or inactive. Menu Access F22 (Shift + F10) - Option 95

PRGHASCPurge Sync Check Results


PRGHASC PURGE( ) Use this command to clear the sync check database files of obsolete records. Obsolete records are records for groups that no longer exist and objects that are no longer replicated. These records can accumulate when a group is removed or an object specifier is deselected from a group when a group's backup node is not available. This command also provides an option to clear all records from the sync check database files. Note: This command must be issued on the node where the sync check database files are located. This is always the backup node of a group.

Input Parameters

PURGE This parameter allows you to choose between removing obsolete records or all records from the sync check database files. Enter one of the following values:


Examples

*ALLPurge all records from the sync check database files. *OBSOLETEPurge only obsolete records from the sync check database files.

*OBSOLETE is the default setting for this parameter.

PRGHASC PURGE(*ALL) Removes all records from the sync check database files. Use This command must be issued on the node where the sync check database files are located. This is always the backup node of a group.

276

Printed in Canada

iClusterVersion 5.1

Registered iCluster User Commands

Registered iCluster User Commands


This section contains the following topics:

DMADDUSRAdd User on page 277 DMCHGUSRChange User on page 278 DMRMVUSRRemove User on page 280 DMWRKUSRWork with Users on page 281

DMADDUSRAdd User
DMADDUSR USER( ) AUTH( ) DESC( ) PASSWORD( ) Use this command to register an OS/400 user name in iCluster so that an administrator, operator, or user can perform certain cluster operations. For each user name that is added through this command, a security level (Administrator, Operator, or User) must be identified in order to define the cluster operations that can be performed by the user. The specified user is only registered on the node where this command is issued. If you are using the iCluster Administrator to manage remotely your clustered environment, the user name (USER) and password (PASSWORD) specified through this command must also be entered on the iCluster Administrator Login dialog box in order to work with the application on a Windows workstation. See iCluster Administrator for Windows on page 383 for more information about the iCluster Administrator. For more information about security in iCluster, see Command Security on page 63. Input Parameters

USER An OS/400 user profile name that is defined on the node where this command is issued. AUTH The security level that you want to assign to the user name specified through the USER parameter (see above). Specify one of the following values:


Note:

*USERGrants user privileges to the specified user. *ADMINGrants administrative privileges to the specified user. *OPERATORGrants operator privileges to the specified user.

iCluster administrators and operators must have *IOSYSCFG (input/output system configuration) authority to invoke commands at these levels. The default setting for this parameter is *USER. See Command Security on page 63 to identify the cluster operations that can be performed at each level.

DESC A short description that allows you to identify this user among all others that have been defined in iCluster. The description can be a maximum of 50 characters long. Typically, this description will be used to identify the full name of the user.

PASSWORD The iCluster password that you want to associate with the user name specified through the USER parameter (see above).

DataMirror, an IBM Company

Printed in Canada

277

This password is not the same one that is used to log on to the OS/400 under the same name. It is an iCluster password, and so it can be different from the current password used to log on to the OS/400 system. For security reasons, DataMirror recommends that a different password is used for iCluster. This password must be specified during the login process for iCluster Administrator. The password cannot exceed 10 characters in length, and must only contain alphanumeric characters. The specified password is also case-sensitive. Specify a password or the following value:

*Indicates that no password has to be specified with the user name identified through the USER parameter (see above). If you specify this value, you cannot log on to the iCluster Administrator, but you can use the iCluster commands identified in this guide.

The default setting for this parameter is *. Examples DMADDUSR USER(MJONES) AUTH(*OPERATOR) DESC('Mary Jones') PASSWORD(LEMONADE) Registers the OS/400 user name MJONES (Mary Jones) in iCluster with operator privileges. DMADDUSR USER(BSMITH) AUTH(*ADMIN) DESC('Bruce Smith') PASSWORD(APPLEJUICE) Registers the OS/400 user name BSMITH (Bruce Smith) in iCluster with administrative privileges. Use You cannot issue this command by the DMCLUSTER, OMIRROR, or HASUITE user names. These names are created for the installation of iCluster and other DataMirror products. Minimum Security Level QSECOFR or a user name having *SECADM authority in the following situations:

As part of their basic user profile. As part of their primary group profile. As part of any of their supplemental profiles.

Menu Access F22 (Shift+F10) - Option 101

DMCHGUSRChange User
DMCHGUSR USER( ) AUTH( ) DESC( ) PASSWORD( ) Use this command to change the security level of a user name that is currently defined in iCluster. The user name that is specified must have already been added through the DMADDUSRAdd User command. The specified user must be registered on the node where this command is issued. If you are using the iCluster Administrator to manage remotely your clustered environment, the user name (USER) and password (PASSWORD) specified through this command must also be entered on the iCluster Administrator Login dialog box in order to work with the application on a Windows workstation. See iCluster Administrator for Windows on page 383 for more information about iCluster Administrator. For more information about security in iCluster, see Command Security on page 63. Input Parameters

USER The iCluster user name that will have its security level changed by this command. This user name must already be registered on the node where this command is issued.

278

Printed in Canada

iClusterVersion 5.1

Registered iCluster User Commands

AUTH The security level that you want to change to for the user name specified through the USER parameter (see above). Specify one of the following values:


Note:

*USERChanges the security level to user for the specified user. *ADMINChanges the security level to administrative for the specified user. *OPERATORChanges the security level to operator for the specified user. *SAMEUses the current setting for this parameter.

iCluster administrators and operators must have *IOSYSCFG (input/output system configuration) authority to invoke commands at these levels. The default setting for this parameter is *SAME. See Command Security to identify the cluster operations that can be performed at each level.

DESC A short description that allows you to identify this user among all others that have been defined in iCluster. The description can be a maximum of 50 characters long. Typically, this description will be used to identify the full name of the user. Specify a short description or the following value:

*SAMEUses the current setting for this parameter.

The default setting for this parameter is *SAME. PASSWORD The iCluster password that you want to associate with the user name specified through the USER parameter (see above). You can change the password associated with the user name or keep it the same (see * below). This password is not the same one that is used to log on to the OS/400 under the same name. It is an iCluster password, and so it can be different from the current password used to log on to the OS/400 system. For security reasons, DataMirror recommends that a different password is used for iCluster. This password must be specified during the log in process for iCluster Administrator. The password cannot exceed 10 characters in length, and must only contain alphanumeric characters. The specified password is also case-sensitive. Specify a password or one of the following values:


Examples

*NONEIndicates that no password has to be specified with the user name identified through the USER parameter (see above). If you specify this value, you cannot log on to the iCluster Administrator, but you can use the iCluster commands identified in this guide. *Uses the current password for the user.

The default setting for this parameter is '*'.

DMCHGUSR USER(MJONES) AUTH(*OPERATOR) DESC('Mary Jones') PASSWORD(ROOTBEER) Changes the security level of user name MJONES (Mary Jones) to operator, and her iCluster password to ROOTBEER. DMCHGUSR USER(BSMITH) AUTH(*ADMIN) DESC('Bruce Smith') PASSWORD(*) Changes the security level of user name BSMITH (Bruce Smith) to administrative. The iCluster password associated with BSMITH is not changed.

DataMirror, an IBM Company

Printed in Canada

279

Use You cannot issue this command by the DMCLUSTER, OMIRROR, or HASUITE user names. These names are created for the installation of iCluster and other DataMirror products. Note: You must restart the iCluster Administrator before password changes will take effect.

Minimum Security Level QSECOFR or a user name having *SECADM authority in the following situations:

As part of their basic user profile. As part of their primary group profile. As part of any of their supplemental profiles.

Menu Access F22 (Shift+F10) - Option 102

DMRMVUSRRemove User
DMRMVUSR USER( ) Use this command to remove the OS/400 user name registered in iCluster. When a user is removed by this command, that user can no longer able to work with the cluster environment through iCluster. Note that issuing this command does not delete the OS/400 user name from the node on which it is invoked. Only user registration on the node where you issue this command is removed. For more information about security in iCluster, see Command Security on page 63. Input Parameter

USER The OS/400 user name that will be removed from iCluster. This user name must already be registered in iCluster on the node where this command is issued.

Example DMRMVUSR USER(MJONES) Removes the user name MJONES from iCluster. Use You cannot issue this command by the DMCLUSTER, OMIRROR, or HASUITE user names. These names are created for the installation of iCluster and other DataMirror products. Note: You must restart the iCluster Administrator before password changes will take effect.

Minimum Security Level QSECOFR or a user name having *SECADM authority in the following situations:

As part of their basic user profile. As part of their primary group profile. As part of any of their supplemental profiles.

Menu Access F22 (Shift+F10) - Option 103

280

Printed in Canada

iClusterVersion 5.1

Registered iCluster User Commands

DMWRKUSRWork with Users


DMWRKUSR Use this command to display a screen that allows you to work with the user names that have been granted certain privileges to work with nodes, groups, object specifiers, and other cluster components in iCluster. From the screen that is displayed, you can add or remove user names as well as change security attributes for a user. For more information security in iCluster, see Command Security on page 63. Input Parameters None. Example DMWRKUSR Displays a screen that allows you to work with user IDs that have been given certain privileges to view or modify iCluster components. Use You must issue this command on the node where the operation will be performed. Minimum Security Level QSECOFR or a user name having *SECADM authority in the following situations:

As part of their basic user profile. As part of their primary group profile. As part of any of their supplemental profiles.

Menu Access F22 (Shift+F10) - Option 100

DataMirror, an IBM Company

Printed in Canada

281

282

Printed in Canada

iClusterVersion 5.1

Exit Program Commands

Exit Program Commands


This section contains the following topics:

ADDPFEXPGMAdd Exit Program on page 283 RMVPFEXPGMRemove Exit Program on page 283

ADDPFEXPGMAdd Exit Program


ADDPFEXPGM Use this command to register a DataMirror exit program that provides the ability for iCluster to replicate changes to the following attributes for both physical and logical files: Text description, Maximum number of members, Access path maintenance, Access path recovery, and Records to force a write. This command also enables replication of changes to the Size attribute for physical files. Note: This command registers two exit programs (one for physical files and one for logical files) for the QIBM_QCA_RTV_COMMAND exit point. If there are more than 20 exit programs already defined for this exit point, then this command will not be able to add the exit programs.

Input Parameters None. Output Relevant messages to the job log. Examples ADDPFEXPGM This command registers the DataMirror exit program. Use You can issue this command on the primary node and backup node. This command is issued by the iCluster installation process on Version 4 Release 5 or later of the operating system.

RMVPFEXPGMRemove Exit Program


RMVPFEXPGM Use this command to remove a DataMirror exit program that provides the ability for iCluster to replicate changes to the following attributes for both physical and logical files: Text description, Maximum number of members, Access path maintenance, Access path recovery, and Records to force a write. Replication of changes to the Size attributes for physical files is also enabled by the ADDPFEXPGMAdd Exit Program command. Removing the exit program means that only the contents of physical and logical files will be replicated. Changes to the attributes listed above will not be replicated. You can re-add the exit program by issuing the ADDPFEXPGMAdd Exit Program command. See ADDPFEXPGMAdd Exit Program on page 283 for more information. Input Parameters None. Output Relevant messages to the job log.
DataMirror, an IBM Company Printed in Canada 283

Examples RMVPFEXPGM This command removes the DataMirror exit program. Use You can issue this command from the primary node and the backup node. This command is available only for Version 4, Release 5 or later of the operating system.

284

Printed in Canada

iClusterVersion 5.1

iCluster for Supported External Storage Systems

iCluster for Supported External Storage Systems


This section contains the following topics:

DMRBDNODERebuild Node on page 285 DMREGPOSRegister Positions on page 286

DMRBDNODERebuild Node
DMRBDNODE NODE( ) Use this command to rebuild the specified node as a node in the cluster, based on recovery domain information for all groups that have the specified node as their backup node. Typically, this command should be issued after a refresh for a supported external storage system. Note: This command is only available if the iCluster authorization code is installed. See Authorization Codes and Licensing on page 20 for more information. Saves the recovery domain for all groups with the backup node in the recovery domain. Removes the backup node from the cluster. Re-adds the backup node as a node in the cluster. Establishes the proper iCluster authorization code for the backup node. Restores the recovery domains for all groups with the backup node in the recovery domain prior to the refresh for supported external storage systems. This command should be used only if the specified node is no longer part of the cluster after performing a refresh for a supported external storage system.

Specifically, this command performs the following operations:

Warning:

Input Parameters

Output

NODE The system name of the backup node as set in the IPL exit program.

None. Examples DMRBDNODE NODE(NODE_B) The backup node, NODE_B, will be restored as a node in the cluster, based on recovery domain information for groups relating to NODE_B. Use You should note the following considerations about issuing this command:

The node to be rebuilt must be active or the cluster on that node must be deleted prior to invoking this command. The DMCLUSTER product library must be the current library when invoking this command. Replication must be inactive for all groups associated with the specified node at the time this command is invoked. This command assumes that no groups have the selected node as their primary node. For any groups for which the specified node is the primary node in the group, a failover will occur. See Failovers and Switchovers on page 47 for general information about failovers. See Failover Mechanisms on page 47 for more information about the different failover mechanisms available to you.

Warning:

DataMirror, an IBM Company

Printed in Canada

285

DMREGPOSRegister Positions
DMREGPOS GROUP( ) NODE( ) This command registers starting journal positions for a specific group or for all groups that have the specified node as the primary node of the group. The registered starting journal positions are used as starting points before starting replication for a supported external storage system. Note: Typically, you need to invoke this command manually during a refresh for a supported external storage system when the primary node is set to a restricted state.

Starting journal positions for a group registered with this command will be used automatically when replication is next started for the group. Once replication has been started successfully, the registered positions are not re-used. AIf you have used the DMREGPOS command to record registered starting journal positions, do not issue the CHGHAJRN command for any journals on the primary node prior to re-establishing replication. Once replication has started, you can then issue the CHGHAJRN command to remove fully processed journal receivers. The starting journal positions registered by this command will be overridden in the following situations:


Note:

Starting positions specified by a subsequent call to the DMSETPOSSet Journal Start Position command. Specifying *YES on the USEMARKED (Start with Marked Positions) parameter of the DMSTRGRPStart Cluster Operations at Group command. This command supports spooled file replication on the primary and backup node(s) as of i5/OS V5R4.

Input Parameters

GROUP The name of the group for which starting positions will be registered. Enter the name of a group or the following value:

*ALLSpecifies all groups.

NODE The name of a cluster node for which all groups having that node as the primary node of the group will have starting positions registered. This parameter may be specified only if the special value *ALL is specified on the GROUP parameter. Enter the name of the node or the following value:

Output

*CURNODESpecifies the current node. This is the default setting for this parameter.

Job log messages indicating successful completion or problems are interactively displayed. Example DMREGPOS GROUP(*ALL) NODE(*CURNODE) Starting journal positions are registered for all groups on the current node. Use You should note the following considerations about issuing this command:


286

The primary database must be inactive when this command is issued. If the primary database is active at the time this command is called, all transactions may not be replicated. Before mirroring is started, you need to make sure that the image of the backup database is consistent with the image of the primary database. Replication must be inactive for all groups specified at the time this command is invoked.

Printed in Canada

iClusterVersion 5.1

iCluster for Supported External Storage Systems

This command should not be invoked during the "duplicate time" if the system time is changed backwards. Unpredictable results may occur in these situations.

DataMirror, an IBM Company

Printed in Canada

287

288

Printed in Canada

iClusterVersion 5.1

Other Commands

Other Commands
This section contains the following topics:

SETHAREGRestore Communications Registries on page 289

SETHAREGRestore Communications Registries


SETHAREG Use this command to restore communications registries that have been corrupted through node failure, interruption, or other circumstances. Input Parameters None. Output None. Examples SETHAREG Restores communications registries on the local active node. Use You must issue this command on the node where the operation will be performed. The iCluster product library must be the library of the object that runs the command.

DataMirror, an IBM Company

Printed in Canada

289

290

Printed in Canada

iClusterVersion 5.1

Using the Status Monitor


This section contains the following topics:

Working with the Status Monitor on page 291 Simplified Status Monitor on page 292 Latency on page 292 Status of Apply Jobs on page 292 Real Time and Historical Statistics on page 292 Interactive Inquiry Screens on page 292 Real Time Statistics Views on page 293 Working with Object Status on page 306 Monitoring Historical Statistics on page 314

Working with the Status Monitor


iCluster allows you to monitor replication on both the primary and backup nodes. This is especially useful when the primary and backup nodes are located in different geographical regions. Regardless of where you happen to be situated (in either the primary or backup node environment), replication can be monitored from either site. Monitoring is an important component of a high availability solution because it allows you to identify conditions that may require your attention. Monitor reporting is based on group/journal combinations. The following statuses and statistics are provided for both real time inquiry of replication processes and historical inquiry of past activity:

Replication status (both active and inactive) Real time object latency Real time overall latency Backup node latency Runtime totals for both primary and backup replication processes Overall and current transactions per hour The throughput statistics are presented in units called transactions. This number is greater than or equal to the number of journal entries processed, due to the processing requirements of certain journal entries.

Note:

You can also perform the following operations for specified group/journal combinations:

Start and end replication Perform sync checks on objects (on the primary node only) View event logs View sync check results View suspended objects

All information for active or inactive groups is shown on the same screen. Except for the Status column, information about an active item will be highlighted. You can view expanded statistics to have complete information about replication performance and status. Note: The primary monitor must communicate with the backup node to retrieve its data, therefore there may be a delay in displaying the primary monitor screen.

DataMirror, an IBM Company

Printed in Canada

291

Simplified Status Monitor


In iCluster, you have the option of accessing the full Status Monitor, which contains sync check, activate, suspend operations, among others, or you can access the simplified Status Monitor, which displays only the details and the status of objects for latency, throughput, object position, and journal information. For more information about the simplified Status Monitor, see DSPHASMONDisplay Source Monitor on page 255.

Latency
Latency is the time interval between a journal entry being written on the primary node and it being applied on the backup node. It is sometimes expressed as the number of entries between the last journal entry written and the last journal entry applied. High latency can occur when the volume of transactions to be sent exceeds the available bandwidth. Latency may become very large (several hours) if the apply process is suspended. The scrape latency will not be affected during apply suspension as long as the staging store is large enough to hold all the journal information. See Staging Objects on page 69 for more information. iCluster provides statistics about real time and historical latency so that you can examine the speed of replication from the primary node to the backup node and take any necessary action. See Monitoring Latency on page 78 for more information about the latency monitoring tools that iCluster provides.

Status of Apply Jobs


You can use the Status Monitor to view the status of the apply jobs. These states are explained on each of the real time Status Monitor screens.

Real Time and Historical Statistics


iCluster provides interactive screens that allow you to view the runtime statistics of active and inactive replication processes. The interactive screens access replication processes to provide real time statistics. These statistics are recalculated upon screen refresh. iCluster also provides historical replication statistical screens. These screens allow you to view previous replication activity. The historical statistics consist of activity snapshots and job start and end statistics. With these historical statistics, you can determine replication trends (for example, periods of high activity) and reconcile replication processes. iCluster acquires historical statistics on the primary node by taking snapshots of the replication activity of group/journal combinations at a user-defined frequency. The replication process will read the replication statistics and write timestamped records to the Status Monitor history database. iCluster provides job start and end statistical records that are stored in the monitor database. These records are created at the start and end of processing, allowing the user to easily reconcile the replication activity. Normally, records will be written containing data for both the primary and backup nodes. In the event that data is unavailable, a partial data record (such as type SS, if only primary node start data is available) is written to the monitor database. You can control the frequency of data collection through the CHGHASMONChange History Monitor on Primary Node command on the primary node. Note: If the process reporting frequency is set to a high rate (providing almost real time statistics) the performance of the mirroring processes may be adversely affected.

Interactive Inquiry Screens


iCluster provides you with interactive screens that allow for the easy display of activity. From these screens, you can view the following replication information:

292

Printed in Canada

iClusterVersion 5.1

Monitoring Real Time Object Latency Monitoring Real Time Overall Latency Monitoring Real Time Object Position and Totals Monitoring Real Time Object Throughput Monitoring Historical Object Position and Totals Monitoring Historical Object Throughput

Real Time Statistics Views


The iCluster real time status monitor splits its information across multiple views. This section introduces the status monitor and provides information that is common across all of the status monitor views.

Starting the Status Monitor


To display statistics for the current node as a primary node, start the status monitor by either:

Selecting option 80 (Display the iCluster Primary Monitor) from the iCluster main menu. Running the WRKHASMONWork with Status Monitor on Primary Node command from the command line. Selecting option 81 (Display the iCluster Backup Monitor) from the iCluster main menu. Running the WRKHATMONWork with Status Monitor on Backup Node command from the command line.

To display statistics for the current node as a backup node, start the status monitor by either:

Cycling Through the Views


While the status monitor is open, you can cycle through its views by pressing F11. This will display the next view. The views that are available depend on if your terminal is set for 132 column display or 80 column display. If you are viewing the primary or backup monitor on a 132 column display, then you will see the views shown in Figure 1. Figure 1 View Sequence for 132 Column Terminals

DataMirror, an IBM Company

Printed in Canada

293

If your terminal is set for 80 column display, then you will not see the Real Time Overall Latency view. Figure 2 shows the sequence of views you will see. Figure 2 View Sequence for 80-Column Terminal

For more information on each of these views, see the following topics:

Monitoring Real Time Overall Latency on page 297 Monitoring Real Time Object Latency on page 299 Monitoring Real Time Object Position and Totals on page 301 Monitoring Real Time Object Throughput on page 302

Common Information on all Views


Each view shares columns and other informational fields. They are as follows:
Table 1 Common Information on All Views

Name Position to field

Description When you type a name in the Position to field, starting from the top of the list, the cursor moves to either the first backup node that matches your entry, or if there is no match in the list, then to the first backup node that appears prior to the item in the Position to field. You can also move to the top or the bottom of the list by entering *TOP or *BOT respectively. You can use the Position to field to search for primary nodes, backup nodes, groups and journals. You need to prefix your entry in the Position to field with an S for primary nodes, a T for backup nodes, G for groups or J for journal. Using these prefixes, you can perform a sequential search through the list from the current position for a primary node "S:", a backup node "T:", a group "G:" or a journal "J:". Again, if a match is not found, then the first item prior to what would match the text in the Position to field is selected. To search for a particular backup node, type the name of the backup node in the Position to field. Status Monitor will scroll to the specified backup node.

294

Printed in Canada

iClusterVersion 5.1

Table 1

Common Information on All Views

Name Elapsed time field

Description Displays the amount of time that has passed since the status monitor was last restarted. See Common Options for all Views on page 295 for more information on the restart option. When viewing the primary monitor, there will only be one entry for the primary node as you can monitor only one primary node at a time. When displaying the backup monitor, there can be more than one primary node entry, as there is conceptually no restriction on the number of primary nodes that can replicate to a particular backup node. This view lists all active and inactive primary/backup/group/journal combinations in the column. A primary system is indicated when the name is at the left of the column, a backup system is indicated when the name is indented by two spaces, a group is indicated when the name is indented by four spaces, and a journal is indicated when indented six spaces from the left side of the margin. Active backup nodes are highlighted.

Prm/Bkp/Grp/Jrn column

Common Options for all Views


This topic describes the options and tasks that you can perform from each status monitor view. Performing Tasks with Function Keys You can perform the following tasks at any time by pressing its associated function key.
Table 2 Function Keys

Key F5 F9

Label Refresh Sync Check Results

Description Refreshes the Status Monitor screen. Entries will stay in the same position in the list, and the cursor will remain in its current position. Runs the DSPHASCDisplay Sync Check command to display the Work with All Spooled Files screen. This shows the available sync check result files. Resets the timer that populates the Elapsed Time field in the topright corner of the status monitor. This also refreshes the Status Monitor. Displays the next view for the status monitor. See Real Time Statistics Views on page 293 for more information on the sequence of views. Displays an OS/400 command prompt. Exits the status monitor and displays the iCluster Main Menu.

F10

Re-Start

F11

Next View

F21 (SHIFT+F9) F22 (SHIFT+F10)

Command DM Cmds

DataMirror, an IBM Company

Printed in Canada

295

Selecting Options You can enter the following options in the Opt column to the left of a node, group, or journal to perform an action on a specific object.
Table 3 Options in the Status Monitor

Opt 1

Label Start

Description Starts replication for the selected group on the primary node. On the backup node, the apply process will start. This option runs DMSTRGRPStart Cluster Operations at Group on page 208.

Wrk Obj Specs

Show the object specifiers for the selected group. This option runs the DMWRKOBJWork with Object Specifiers command.

End

Ends replication on the primary node, or ends the apply processes on the backup node, for the selected group. The Status column will display "I", indicating that it is now inactive. This option runs the DMENDGRPEnd Cluster Operations for Group command.

Details

Display the name of the journal receivers on the primary and backup nodes, the libraries where the receivers reside and their last replication positions for the selected group/journal combination. Displays the cluster event log for the selected group. Displays the WRKHABSFSTWork with BSF Status screen for the selected group or journal. Displays the WRKHAOBJSTWork with Object Status screen for the selected group or journal. Opens a communications link to the backup node so that you can check the status of an apply job from the source monitor. Any group that is not active will display the unknown status in the Status column for the backup node. By default, the Status Monitor does not open the communications link so that it does not become delayed during initialization or refresh. However, once selected, the communication link stays in effect for as long as the screen is displayed or communication to that backup node is available. If communication fails for a backup node, the option is cancelled. This prevents a failed retry each time the screen is refreshed. You will need to select this option again to re-start communications. This option is only available from the primary monitor.

6 7 8 9

Msgs BSF Sts Obj Sts Chk backup

12

History

Displays the Monitoring Historical Latency screen the selected journal.

296

Printed in Canada

iClusterVersion 5.1

Table 3

Options in the Status Monitor

Opt 54

Label Start Synchck

Description Initiates a sync check for the selected group by running the STRHASC Start Sync Check command. This option is only available from the primary monitor. Initiates a user sync check for the selected group by running the STRHASCUSRStart User Sync Check command. This option is only available from the primary monitor.

56

Start User Synchck

Monitoring Real Time Overall Latency


The Real Time Overall Latency view (Figure 3) displays the real time overall latency for all primary/backup/group/journal combinations. Since this is a real time display, the information is recalculated every time the screen is refreshed. This provides a useful summary of the latency information for all of the backup nodes of the current node. Figure 3 Real Time Overall Latency View - Primary Monitor

Latency can only be calculated when the current node has an active connection to each backup node. This calculation will not occur for inactive backup nodes unless they are explicitly contacted using option 9. See Common Options for all Views on page 295 for more information on this option. Displaying this View To display this view, start either the primary or backup monitor with a 132 column terminal. From a running status monitor, press F11 to cycle through the views until you see this one. See Real Time Statistics Views on page 293 for more information.

DataMirror, an IBM Company

Printed in Canada

297

Reading this View The Real Time Overall Latency view displays the following information:
Table 4 Information on the Real Time Overall Latency Screen

Source Latency

Source latency indicates the difference between the timestamp of the journal entry last processed by the backup receiver for the journal, and the timestamp of the last journal entry deposited in the primary journal. It is displayed in HH:MM:SS format. For idle or lightly-used groups, the receive timestamp is resynchronized every minute to ensure that reported latencies remain below specified thresholds. If the primary latency threshold has been exceeded, then brackets, "<>", are displayed around the primary latency time. See the DMSETSVALSet Cluster System Values command for more information on setting latency thresholds.

Apply Latency

Apply latency is the difference between the timestamp of the journal entry last processed by the backup apply process for the journal, and the timestamp of the last journal entry processed by the backup receive process. It is displayed in HH:MM:SS format. If the apply latency threshold has been exceeded, then brackets, "<>", are displayed around the apply latency time. See the DMSETSVALSet Cluster System Values command for more information on setting latency thresholds.

Total Latency Total Latency Status

Total Latency is the sum of the source and target apply latency times. It is displayed in HH:MM:SS format. The Total Latency Status graphically represents the total latency. The bar gives an approximate indication of the Total Latency. Each character represents one unit of time depending on the sum of the Primary and Apply threshold values. The sum of the two thresholds appears 2/3 of the way across the bar graph. If no latency thresholds have been exceeded, the bar graph displays '.'. If either or both latency thresholds have been exceeded, the bar displays asterisks '*'.

Status

See Reading Status Information on page 303 for details on the status fields.

See Real Time Statistics Views on page 293 for descriptions of information available to all status monitor views. Performing Tasks See Common Options for all Views on page 295 for a complete list of options and tasks you can perform from this view. See Monitoring Latency on page 78 for more information on how to monitor latency in iCluster.

298

Printed in Canada

iClusterVersion 5.1

Monitoring Real Time Object Latency


The Real Time Object Latency view (Figure 4) displays the real time latency for all group and journal combinations. Since this is a real time display, the information is recalculated every time the screen is refreshed. This provides a useful summary of the latency information for all of the nodes connected to the current node. Figure 4 Real Time Object Latency View - Primary Monitor

Latency can only be calculated when the current node has an active connection to each backup node. This calculation will not occur for inactive backup nodes unless they are explicitly contacted using option 9. See Common Options for all Views on page 295 for more information on this option. Displaying this View To display this view, start either the primary or backup monitor and press F11 to cycle through the views until you see this one. See Real Time Statistics Views on page 293 for more information. Reading this View The Real Time Object Latency view displays the following information:
Table 5 Real Time Object Latency

Backup J/E Curr Trans Sent

The last journal entry applied to the backup node by the apply process. The current number of transactions processed on the primary node and received into the staging store since the start of the current replication process. This entry does not include omitted entries.

DataMirror, an IBM Company

Printed in Canada

299

Table 5

Real Time Object Latency

Curr Trans Applied

The current number of transactions processed by the primary node since the start of the last reset of the transaction counters that have been sent to the backup node and applied by the apply processes on the backup node. Note that inactive apply processes are not counted in the backup node and group summaries. Transaction counts are reset under the following conditions:


Trans to Process Status

After issuing the DMSETPOSSet Journal Start Position, DMMRKPOSMark Current Journal Positions, or DMREGPOS Register Positions commands Refresh before mirroring Counts exceed approximately 10 billion

The number of transactions which have been sent by the primary node, but have not yet been applied on the backup node. See Reading Status Information on page 303 for details on the status fields.

See Real Time Statistics Views on page 293 for descriptions of information available to all status monitor views. Performing Tasks See Common Options for all Views on page 295 for a complete list of options and tasks you can perform from this view.

300

Printed in Canada

iClusterVersion 5.1

Monitoring Real Time Object Position and Totals


The Real Time Object Position and Totals view (Figure 5) displays the real time position and totals for all active and inactive group/journal combinations. Active combinations will be highlighted. The positions and totals are retrieved prior to initial display as well as upon every refresh of the screen. This provides both primary and backup node processing positions and the total number of entries processed. The Elapsed time field displays the elapsed time since the last re-start (F10) or initial display of the screen after a refresh (F5). Figure 5 Real Time Object Position and Totals View - Primary Monitor

Displaying this View To display this view, start either the primary or backup monitor and press F11 to cycle through the views until you see this one. See Real Time Statistics Views on page 293 for more information. Reading this View The Real Time Object Position and Totals view displays the following information:
Table 6 Real Time Object Position and Totals View

Last J/E Primary J/E

Last J/EThe last journal entry written to the journal. The journal entry where the primary node journal scraper process is currently scraping the journal and has been received into the staging store. The last journal entry applied to the backup node by the apply process. The number of transactions which have been sent by the primary node, but have not yet been applied on the backup node. See Reading Status Information on page 303 for details on the status fields.

Backup J/E Trans to Process

Status

DataMirror, an IBM Company

Printed in Canada

301

See Real Time Statistics Views on page 293 for descriptions of information available to all status monitor views. Performing Tasks See Common Options for all Views on page 295 for a complete list of options and tasks you can perform from this view.

Monitoring Real Time Object Throughput


The Real Time Object Throughput view (Figure 6) displays the real time throughput in transactions per hour for the backup node apply for all active group/journal combinations. Active combinations will be highlighted. It displays both overall and current throughputs, providing 'at a glance' throughput values for all active backup nodes. These figures provide throughput in transactions per hour. Inactive group/journal combinations will appear on the screen but will not have throughput values. Figure 6 Real Time Object Throughput View - Primary Monitor

Overall throughput is calculated based on the backup node apply process using figures (time period and transactions processed) based on the elapsed run time of the backup node apply job. Therefore the time period used is the start of the job to the last time the information was updated. This throughput rate is expressed in transactions per hour. The time sample is calculated as follows: (Backup Node Update Timestamp) less (Backup Node Start Processing Timestamp). The number of transactions is the total of all transactions processed on the backup node. Current throughput will also be based on the throughput of the backup node apply process using figures based on when the screen was originally displayed or since the previous re-start, to when a refresh of the screen is requested (similar to WRKHAJOB). Displaying this View To display this view, start either the primary or backup monitor and press F11 to cycle through the views until you see this one. See Real Time Statistics Views on page 293 for more information.

302

Printed in Canada

iClusterVersion 5.1

Reading this View The Real Time Object Throughput view displays the following information:
Table 7 Real time Object Throughput View

Apply Str/End

The start/end date of the latest replication process for the backup node/ journal combination. If the Status column displays a status of I (inactive), then this field is displaying the end time. Otherwise, it indicates the start date.

Elapsed Days Hr Mn Overall Trans/Hr Current Trans/Hr

The elapsed time since the latest apply process for the journal of the backup node/group combination began. The number of transactions per hour based on the elapsed time of the backup node apply job. The number of transactions per hour based on the transactions performed since the last time the status monitor timer was restarted by pressing F10. When you change to this view or restart the status monitor timer, the Current Trans/Hr column will contain a '-' because the elapsed time is zero (0), and therefore no value can be calculated. Press F5 to refresh the screen. This will recalculate the value for this column based on the time that has passed since you restarted the status monitor timer. See Common Options for all Views on page 295 for more information on restarting the status monitor timer.

Status

See Reading Status Information on page 303 for details on the status fields.

See Real Time Statistics Views on page 293 for descriptions of information available to all status monitor views. Performing Tasks See Common Options for all Views on page 295 for a complete list of options and tasks you can perform from this view.

Reading Status Information


Each view screen has a set of columns that display status information for the nodes, groups, and journals being monitored. This topic describes each of the following status columns:

The RPB Status column on page 304 Suspended Objects (S/O) Status column on page 305 Out-of-Sync (OOS) Status Column on page 305 Operational (OP) Status Column on page 305 Current Object (Curr Object) Column on page 306

DataMirror, an IBM Company

Printed in Canada

303

The RPB Status column The RPB status column represents the status of replication processes for remote journals, primary and backup nodes. The R represents the replication status of remote journals, the P represents the status of the scrape process on the primary node, and the B represents the status of the receive and apply process on the backup node. Table 8 lists the status codes and their meanings.
Table 8 Remote Journal, Primary and Backup Status Codes

Status A I

Meaning Indicates that the replication process is active on the primary node, backup node, or remote journal. Indicates that the replication process is inactive on the primary node, backup node, or remote journal. This state occurs whenever replication is inactive. Indicates that a group is starting but not yet fully active, or is in the process of shutting down. Indicates that a refresh is active for a non-mirroring group. This status is not available for refresh before mirror. During a refresh before mirror, the status is S. This field also indicates those journals that are refreshing a particular entry. Indicates that the staging store is full, and is shown only on the primary node. Indicates that the journal is not being used by this process. If a journal is no longer required by a group on both the primary and backup nodes, it will no longer be displayed in the Status Monitor. In other words, a status combination of 'U U' is never displayed.

S R

F U

Indicates that the status is unknown for the primary node, backup node, or remote journal. The status can be unknown for the backup node when the primary node is not actively communicating with the backup node. It can also be unknown for a primary node that has not been involved in replication. Indicates that the journal may be unused. This is set at startup and can change to a status of 'A' or 'I' if the process uses the journal. A blank value only applies to remote journals and indicates that it is not a remote journal.

* blank

304

Printed in Canada

iClusterVersion 5.1

Table 9 describes some sample RPB codes and then explains what they mean.
Table 9 Sample RPB Status Codes

RPB -*I*I A*A -** AUIUI

Meaning The status of the remote journal is unknown. The journal may be unused on the primary node, and the status is unknown on the backup node. The remote journal is inactive. The journal may not be used on the primary node, and the apply process is inactive on the backup node. The remote journal is active. The journal may not be used on the primary node, and the apply process is active on the backup node. The status of the remote journal is unknown. The journal may not be used on both the primary and backup nodes. The remote journal is active. The journal is not being used on the primary node, and the status is unknown for the backup node. The remote journal is inactive. The journal is not being used on the primary node, and the latent apply on the now unused journal is inactive on the backup node. The journal is not a remote journal. The journal is not being used on the primary node, and the latent apply on the now unused journal is active on the backup node.

UA

Suspended Objects (S/O) Status column This column shows the number of suspended objects in this group. These objects match the object specifier but cannot be replicated. If there are no suspended objects, then this field will appear blank. Out-of-Sync (OOS) Status Column This column displays the sum of the OS/400 native objects and IFS objects that are out-of-sync for each group. This information is current as of the last sync check. Note: The OOS column is only available on backup monitor screens in a 132-column terminal session.

Operational (OP) Status Column This column indicates the current operational status for each journal being used. If an operation is being performed, then it will display one of the following codes:

RBD: The group is waiting for the system to finish rebuilding a logical file. RFS: The operation is refreshing a file or IFS object. This can be the result of a group refresh or of an individual file or IFS object being activated by a refresh. For database file members, the progress of the refresh is indicated as a percentage following this code. RGZ: The operation is reorganizing a file. SWO: The group is performing a switchover.

The OP column also indicates the switchover status for each group. This column displays a blank if a group is only being used for mirroring, but it will indicate if a switchover is in progress. The current step during the switchover is indicated in the adjacent Current Object column that is available on the backup monitor.

DataMirror, an IBM Company

Printed in Canada

305

Note:

The OP field is only available on primary and backup monitor screens in a 132-column terminal session.

Current Object (Curr Object) Column At the journal level, this column displays the name or path of the target object that the status in the OP column applies to. If the object is a native object, then this column will show the object as LIBRARY/FILENAME(FILEMEMBER). If the object is an IFS object, then the column will show the last thirty characters of the path and filename. Note: The Curr Object column is only available on backup monitor screens in a 132-column terminal session.

Working with Object Status


The Work with Object Status screen (Figure 7) displays the status of objects within the Status Monitor. For suspended objects, this screen also displays the reason for the suspension. For more information about suspended objects, see Suspended Objects on page 72. Figure 7 Work with Object Status Screen

Displaying the Object Status Screen To display the Object Status screen from the Status Monitor, enter option 8 (Obj Sts) in the Opt column next to the journal you want to display status information for. You can display this screen from either the primary or backup monitor. To display this screen from the command line, run the WRKHAOBJSTWork with Object Status command. The Object Status Screen This screen lists all objects for the specified group/journal combination. It contains three views. The first view shows only suspended objects. By pressing F16 (SHIFT+F4), you can cycle through the views to show only suspended objects, then only active objects, and then all objects. The backup node, name, group, and library of the journal is displayed at the top of the screen. The Object Status screen also displays the following information: StatusIndicates the status of each object. The possible statuses are as follows:

ACTIVEThe object is available for replication. PNDACTActive pending. The object is currently suspended and waiting to become active through a journal entry that must be scraped.

306

Printed in Canada

iClusterVersion 5.1

PNDSUSThe object is active and waiting to be suspended through a journal entry that must be scraped. SUSPNDThe object is currently suspended.

ObjectsThe replication object this status describes. TypeThe object type of the object. LibraryThe library the object belongs to. AttributeThe object extended attribute for the object. Jrn PosThe object's current journal position. ReasonIndicates the reason why the object was suspended. The three-character reason codes are as follows:

ABUThe object was activated by the user. AISThe object will be activated as soon as this entry is scraped from the journal by iCluster. APDThe object's activation has started but has not finished. AUDObject auditing cannot be started for a BSF object. AUSPrivate authorities associated with the BSF object could not be replicated or retrieved. AUTPrivate authorities for an object could not be retrieved. BTNMetadata for a BSF object cannot be found on the backup node. CDAThe change content operation to a data area failed. CHKTemporary state showing that iCluster tried to refresh file during rename/move. CILUnable to determine if a BSF object is a hard link. CJNA required journal entry associated with the object could not be found in the audit journal. COMAn object could not be refreshed. CPTA journal entry required to refresh the object could not be added to the database journal. CRTThe BSF object cannot be created on the backup node. DLTA BSF object could not be removed from the backup node. DTAThe BSF object could not be opened on the primary node for refreshing. EJFAn object was suspended on the primary node because journaling for the object ended on this node. EXSiCluster attempted to create an IFS folder that already existed. INTAn object was suspended as a result of an internal failure. Synchronization between objects on the primary and backup nodes cannot be assumed. IOFA read or write operation failed. JPFA logical file was suspended on the primary node because the associated physical file could not be journaled. JPOA required journal entry related to the object could not be found in the database journal. JRNJournal information for an object could not be retrieved, or the object could not be journaled. LCKA lock on an object could not be obtained. LNKThe BSF object is a hard link (replication of hard links is not supported by iCluster). MCNThe object is temporarily suspended during the renaming/moving of a database table, where the original object is selected with MIRRCNTS(*NO) and the new object with MIRRCNTS(*YES). The object will be activated by iCluster when the renaming/moving of the database table is complete on the target. For more information on the MIRRCNTS parameter, see the DMSELOBJSelect Objects to Group command. MDFA problem occurred when creating or updating metadata related to the object.

DataMirror, an IBM Company

Printed in Canada

307


308

MLFAn object was suspended on the backup node because a member-level failure (rename, delete, reorganize, and so on) occurred during replication. MMCA master-master data conflict occurred. MMLThe file is suspended on the primary node. LOB column replication is not supported in a master-master group. MMOA master-master object-level error occurred. MMRA master-master refresh failed. MRRAn object was suspended on the primary node. The object should have been refreshed manually, but it has yet to be activated. NFDObject not found on the system. NGPA logical file was suspended on the primary node because the associated physical file was not replicated in the same group as the logical file. NREFile has no record in the metadata. NSIA BSF object exists on the backup node, but not on the primary node. NSOObject replication is not supported in the current mode. NTIThe state associated with a BSF object could not be found on the backup node. OLFAn object level failure occurred while trying to rename or move a non-journaled object. OWNThe owner of BSF object could not be changed on the backup node. PCKCompression of the BSF object path was unsuccessful. PDAUncommited DO "delete object" entry is received for an active object under commitment control. PDSUncommited DO "delete object" entry is received for a suspended object under commitment control. PDUUncommited DO "delete object" entry is received for an object suspended by the user under commitment control. PGPThe primary group of a BSF object could not be changed on the backup node. PNDActivate pending for the object engine. RBCThe file was part of a cancelled rollback operation on the primary node. RDQThe receive operation to a data queue failed. RFFA refresh of a BSF object was unsuccessful. RFSA refresh of a BSF object could not be started from the primary node. RLEAn object was suspended on the backup node because the number of I/O errors generated when replicating to the object exceeded the value specified in the Max. record level errors cluster system value. See DMSETSVALSet Cluster System Values on page 181 for more information. RMVA RMVJRNCHG journal entry was processed for the object. The object is suspended and will be refreshed later by the automatic re-activation function. RNMRename or move operation failed. RSFAn object was suspended on the backup node. It should have been refreshed, but the restore operation failed on the backup node. RSTA BSF object was restored. The object needs to be refreshed. RTNAn unexpected return code while dealing with an object. RTVThe file's description could not be retrieved. RWAAn object was suspended on the primary node because a record-by-record refresh failed.

Printed in Canada

iClusterVersion 5.1

SBUAn object was explicitly suspended on the primary node as a result of issuing the DMSUSOBJSuspend Object or DMSUSBSFSuspend BSF Object command. SCTThe contents of an object could not be replicated by iCluster. SDQThe send operation to a data queue failed. SFDUnable to retrieve the file identifier of a BSF object. SISA suspend entry has been issued for an object. SIZAn object was suspended on the primary node. A refresh of the object was required, but the size of the object was greater than the value specified in the Maximum refresh size cluster system value. See DMSETSVALSet Cluster System Values on page 181 for more information. SNDAn object or its authorities could not be replicated. SPFA logical file was suspended on the primary node because the associated physical file was suspended. SPLAn *OUTQ object has suspended spooled files. The *OUTQ object itself is not suspended and will not be included in auto-reactivation processing (if enabled in iCluster). SRFA refresh of a BSF object has been started. SSCA BSF object was suspended on the primary node. STRJournaling for a BSF object has been started. The object must be refreshed. SWAActivate pending for files being refreshed manually. The file is waiting for the activate command. SWOThe object was suspended on the backup prior to a switchover. SVFAn object was suspended on the primary node. It should have been refreshed, but the save operation failed. This reason code appears only when displaying primary node statistics. TNEThe BSF object does not exist on the backup node. TNRThe path of a BSF object could not be resolved on the backup node. TNSThe BSF object is a type of object that cannot be replicated. TRGThe trigger information for the object could not be retrieved. UBIAn operation was found that could not be undone because the object in question does not have journaled before-images. UCCAn error occurred undoing a content change to a journaled object. UKMThe file is suspended on the backup node. The file's object specifier has been added with PFKEY (*AUTO), however a unique key could not be found for the file on the backup node. UOCAn object level change was encountered that cannot be undone. UPDA member of PF-SRC is open for update. The file will no longer be suspended once the application closes the file. UUTThe object type in question is not eligible for undoing.

If a reason code is not displayed for the object, this indicates that the object is not suspended. Performing Tasks From this screen, you have the following options: 1: Activate Activates a suspended object. Replication of this object to the backup node for the specified group will begin. 4: Suspend Suspends an active object on the primary node and backup node. It will not be replicated when you start refresh or mirroring.

DataMirror, an IBM Company

Printed in Canada

309

9: Event Log Displays the suspension event message in the event log. F5: Refresh Refreshes the Status Monitor screen. Entries will stay in the same position in the list, and the cursor will remain in its current position. F11: Sort Objects By default, file objects are sorted by library (Sort by Lib). To sort by file name, press F11 again (Sort by Object). Press the same key again to sort by file type (Sort by Type). F16 (or Shift+F4): Next View Cycles through the views for this screen. The views show only suspended objects, only active objects, and then all objects. F22 (or Shift+F10): DM Cmds Lists the iCluster commands. Select a command from the list to display a screen that prompts you for the command parameters.

Working with BSF Status


The Work with BSF Status screen (Figure 8) displays the status of BSF objects within the Status Monitor. The reason why an object was suspended is also displayed. Suspended BSF objects may be activated from the Object Status screen or activated automatically by iCluster. Figure 8 Work with BSF Status Screen

For more information about suspended objects, see Suspended Objects on page 72. For more information about working with the Object Status screen, see Working with Object Status on page 306. Displaying the BSF Status Screen To display the Object Status screen from the Status Monitor, enter option 7 (BSF Sts) in the Opt column next to the journal for which you want to display status information. You can display this screen from either the primary or backup monitor. To display this screen from the command line, run the WRKHABSFSTWork with BSF Status command.

310

Printed in Canada

iClusterVersion 5.1

Reading the BSF Status Screen This screen lists all objects for the specified group/journal combination. It contains three views. The first view shows only suspended objects. By pressing F16 (SHIFT+F4), you can cycle through the views to show only suspended objects, then only active objects, and then all objects. The backup node, name, group, and library of the journal is displayed at the top of the screen. This screen also displays the following information:
Table 10 The BSF Status Screen

Status

Indicates the status of each object. The possible statuses are as follows:


Type Objects Jrn Pos Reason

ACTIVEThe object is available for replication. PNDACTActive pending. The object is currently suspended and waiting to become active though a journal entry that must be scraped. PNDSUSThe object is active and waiting to be suspended though a journal entry that must be scraped. SUSPNDThe object is currently suspended.

Indicates the object type component that belongs to the specified group/journal combination. Indicates the location of the Byte Stream File (BSF) object. Indicates the journal position where the object was suspended. Indicates the reason why the object was suspended. For a complete listing of all of the three-character reason codes, see Working with Object Status on page 306 for more information. If a reason code is not displayed for the object, this indicates that the object is not suspended.

Performing Tasks From this screen, you have the following options: 1: Activate Activates a suspended object, and replication to the backup node for the specified group begins. 5: Display Displays the group and the full path object specifier of the byte stream file (BSF) object. F5: Refresh Refreshes the Status Monitor screen. Entries remain in the same position in the list, and the cursor remains in its current position. F9: Retrieve Retrieves the command previously invoked from the command line. F16 (or Shift+F4): Next View Cycles through the views for this screen. The views show only suspended objects, only active objects, and then all objects. F22 (or Shift+F10): DM Cmds

DataMirror, an IBM Company

Printed in Canada

311

Lists the iCluster commands. Select a command from the list to display a screen that prompts you for the command parameters.

Working with Object Status for Groups


The Working with Object Status for Groups screen (Figure 9) displays the status of objects within a group on the backup node. You can use it to determine why objects were suspended or are unsynchronized. This screen displays information for both native and BSF objects. Figure 9 Work with Object Status for Groups Screen

This screen only displays native objects that are either out-of-sync or suspended. Similarly, it only shows BSF objects that are out-of-sync. For more information about suspended objects, see Suspended Objects on page 72. Displaying the Object Status for Groups Screen To display the Object Status screen from the backup monitor, enter option 7 (BSF Sts) or 8 (Obj Sts) in the Opt column next to the journal you want to display status information for. Your choice selects the default view for the Work with Objects by Group screen. You can only display this screen from the backup monitor. To display this screen from the command line, run the DMWRKOBJSTWork with Object Status by Group command on the backup node of the group you want to view. Reading the Object Status for Groups Screen This screen lists all objects for the specified group/journal combination. It contains three views. The first view shows only suspended objects. By pressing F16 (SHIFT+F4), you can cycle through the views to show only suspended objects, then only active objects, and then all objects. The group's name and its primary and backup nodes are displayed at the top of the screen. This screen also displays the following information:
Table 11 Object Status for Groups Screen

Objects (Native View only) Type (Native View only)

The replication object this status describes. The object type of the object.

312

Printed in Canada

iClusterVersion 5.1

Table 11

Object Status for Groups Screen

Library (Native View only) Object Path (BSF View only) OOS Reason

The library the object belongs to. Indicates the location of the Byte Stream File (BSF) object. The three character reason code for out-of-sync status. The possible reason codes are as follows:


OOS Date-time Susp Reason

ATRThe object's attributes are out-of-sync. AUTThe object's authorities, owners, or permissions are out-of-sync. CNTThe object's contents are out-of-sync. LCKThe object was locked on the primary node during a sync check. NFDThe object does not exist on either the backup or the primary node. NJTThe object is not journaled on the backup node. SZEThe object's size attribute is out-of-sync.

Specifies the date and time when the object went out-of-sync. Indicates the reason why the object was suspended. For a complete listing of all of the three-character reason codes, see The Object Status Screen on page 306 for more information. If a reason code is not displayed for the object, this indicates that the object is not suspended.

Auto Recvy

Specifies whether or not the object is eligible for auto-recovery. '*YES' indicates that the object is eligible for auto-recovery. '*NO' indicates the object is not eligible for auto-recovery and manual steps will need to be taken to re-synchronize the object.

Performing Tasks From this screen, you have the following options: 1: Activate Activates a suspended native object. Replication of this object to the backup node for the specified group will begin. You cannot use this option on a BSF object. F5: Refresh Refreshes the Status Monitor screen. Entries will stay in the same position in the list, and the cursor will remain in its current position. F9: Retrieve Retrieves the command previously invoked from the command line. F16 (or Shift+F4): Next Object View Alternates between the native object view and the BSF object view. F22 (or Shift+F10): DM Cmds Lists the iCluster commands. Select a command from the list to display a screen that prompts you for the command parameters.

DataMirror, an IBM Company

Printed in Canada

313

Monitoring Historical Statistics


The iCluster history log displays historical information for a journal. It splits its information across multiple views. To view historical statistics from the status monitor, enter option 12 (History) next to the journal you want to see the statistics for. You can do this from either the primary or backup monitor. While the historical status monitor is open, you can cycle through its views by pressing F11. This will display the next view. Figure 10 shows the views for the history log. Figure 10 History Log View Sequence

For more information on each of these views, see the following topics:

Monitoring Historical Latency on page 314 Monitoring Historical Object Position and Totals on page 316 Monitoring Historical Object Throughput on page 318

Monitoring Historical Latency


The Historical Latency view (Figure 11) displays the historical latency for a selected group/journal combination. Historical latency is obtained by reading the records created by the batch collection process. Figure 11 Historical Latency View

314

Printed in Canada

iClusterVersion 5.1

Any existing activity snapshots and ending records for the selection will be displayed in ascending order according to the creation timestamp in the Type column. An asterisk (*) in this column denotes that a portion of the data required to display the entry is unavailable. When STR (starting record) appears in the Type column, the value displayed in the Last J/E column is the first entry being processed. If MON (monitor) appears in the Type column, the value displayed in the Last J/E column is the current entry being processed. If END (ending record) appears in the Type column, the value displayed in the Last J/E column is the last entry processed. Displaying the Historical Latency View To view historical statistics from the status monitor, enter option 12 (History) next to the journal you want to see the statistics for. You can do this from either the primary or backup monitor. You may need to cycle to this view by pressing F11. See Monitoring Historical Statistics on page 314 for more information on the history log views. Reading the Historical Latency View This screen lists all the historical activity for the selected group/journal combination, with the backup node and group name displayed at the top of the screen. This screen displays the following items of information that are briefly described along with the Position to date and Position to time fields:
Table 12 Historical Latency View

Type Date Time Last J/E Primary J/E Backup J/E Trans to Process Position to date

The type of entry that is displayed. The date when the activity occurred or end record was defined. The time when the activity occurred or end record was defined. The last journal entry written to the journal. The journal entry where the primary node journal scrape process is currently scraping the journal and has been received into the staging store. The last journal entry applied to the backup node by the apply process. The number of transactions which have been sent by the primary node, but have not yet been applied by the apply process on the backup node. Allows you to search for activity occurring on a particular date. The Status Monitor system will search for activities matching the entered date in the Date column. Allows you to search for activity occurring at a particular time. The Status Monitor system will search for activities matching the entered time in the Time column.

Position to time

Performing Tasks From this screen, you have the following options: F5: Refresh Refreshes the Status Monitor screen. Entries will stay in the same position in the list, and the cursor will remain in its current position. F11: Totals (View 2)

DataMirror, an IBM Company

Printed in Canada

315

Displays historical position and totals view. F22 (or Shift+F10): DM Cmds Lists the iCluster commands. Select a command from the list to display a screen that prompts you for the command parameters.

Monitoring Historical Object Position and Totals


The Historical Object Position and Totals view (Figure 12) displays the historical journal position and totals for a selected group/journal combination. Historical information is obtained by reading the records created by the batch collection process. Figure 12 Historical Object Position and Totals View

Any existing activity snapshots and ending records for the selection will be displayed in ascending order according to the creation timestamp in the Type column. An asterisk (*) in this column denotes that a portion of the data required to display the entry is unavailable. Displaying the Historical Object Position and Totals View To view historical statistics from the status monitor, enter option 12 (History) next to the journal you want to see the statistics for. You can do this from either the primary or backup monitor. You may need to cycle to this view by pressing F11. See Monitoring Historical Statistics on page 314 for more information on the history log views. Reading the Historical Object Position and Totals View This screen lists all the historical activity for the selected group/journal combination. It displays the name of the backup node and group. This screen displays the following items of information that are briefly described along with the Position to date and Position to time fields:
Table 13 Historical Object Position and Totals View

Type Date

The type of entry that is displayed. The date when the activity occurred or end record was defined.

316

Printed in Canada

iClusterVersion 5.1

Table 13

Historical Object Position and Totals View

Time Backup J/E Total Trans Sent

The time when the activity occurred or end record was defined. The last journal entry applied to the backup node by the apply process. The total number of transactions processed by the primary node since the last reset of the transaction counters, that will be sent to the backup node (entries that are associated with files to replicate). This number does not include omitted entries. Transaction counts are reset under the following conditions:


Total Trans Applied

After issuing the DMSETPOSSet Journal Start Position, DMMRKPOSMark Current Journal Positions, or DMREGPOS Register Positions commands. Refresh before mirroring. Counts exceed approximately 10 billion.

The total number of transactions processed by the backup node since the last reset of the transaction counters that have been sent to the backup node and applied by the apply process. The number of transactions which have been sent by the primary node, but have not yet been applied by the apply process on the backup node. Allows you to search for activity occurring on a particular date. The monitor system will search for activities matching the entered date in the Date column. Allows you to search for activity occurring at a particular time. The monitor system will search for activities matching the entered time in the Time column.

Trans to Process Position to date

Position to time

Performing Tasks From this screen, you have the following options: F5: Refresh Refreshes the Status Monitor screen. Entries will stay in the same position in the list, and the cursor will remain in its current position. F11: Throughput (View 3) Displays historical throughput view. F22 (or Shift+F10): DM Cmds Lists the iCluster commands. Select a command from the list to display a screen that prompts you for the command parameters.

DataMirror, an IBM Company

Printed in Canada

317

Monitoring Historical Object Throughput


The Historical Object Throughput view (Figure 13) displays the historical throughput for a selected group/journal combination. Historical information is obtained by reading the records created by the batch collection process. Figure 13 Historical Object Throughput View

Any existing activity snapshots and ending records for the selection will be displayed in ascending order according to the creation timestamp in the Type column. An asterisk (*) in this column denotes that a portion of the data required to display the entry is unavailable. Displaying the Historical Object Throughput View To view historical statistics from the status monitor, enter option 12 (History) next to the journal you want to see the statistics for. You can do this from either the primary or backup monitor. You may need to cycle to this view by pressing F11. See Monitoring Historical Statistics on page 314 for more information on the history log views. Reading the Historical Object Throughput View This screen lists all the historical activity for the selected group/journal combination. It displays the name of the backup node, as well as the name of the journal previously in use. This screen displays the following items of information that are briefly described along with the Position to date and Position to time fields:
Table 14 Historical Object Throughput View

Type Date Time Elapsed - Days Hr Mn

The type of entry that is displayed. The date when the activity occurred or end record was defined. The time when the activity occurred or end record was defined. The elapsed time since the latest replication (mirroring) process for the backup node - journal combination began. This timestamp is used to calculate throughput. The number of transactions performed in an hour based on the life of the backup job.

Overall Trans/Hr

318

Printed in Canada

iClusterVersion 5.1

Table 14

Historical Object Throughput View

Current Trans/Hr Position to date

The number of transactions performed in an hour based on the transactions performed since the last monitor record. Allows you to search for activity occurring on a particular date. The monitor system will search for activities matching the entered date in the Date column. Allows you to search for activity occurring at a particular time. The monitor system will search for activities matching the entered time in the Time column.

Position to time

Performing Tasks From this screen, you have the following options: F5: Refresh Refreshes the Status Monitor screen. Entries will stay in the same position in the list, and the cursor will remain in its current position. F11: Latency (View 1) Displays historical latency view. F22 (or Shift+F10): DM Cmds Lists the iCluster commands. Select a command from the list to display a screen that prompts you for the command parameters.

DataMirror, an IBM Company

Printed in Canada

319

320

Printed in Canada

iClusterVersion 5.1

iBalance and Master-Master Replication


With standard replication groups, iCluster replicates exact, synchronized copies of data from a source system to a target system. As your application performs updates on the source system, iCluster replicates identical updates to your target system (Figure 1): Figure 1 Replicating from Source to Target

After replicating your data, iCluster allows you to perform synchronization checks to ensure that replicated objects on the source and target systems are equivalent. After installing the iBalance feature, you can perform application updates to the same objects on both the source and the target systems. iCluster replicates these updates in both directions (Figure 2). This is referred to as master-master replication. Depending on the replication rules used, you can maintain identical copies of your data on both the source and the target systems. In addition, you can set up rules to control the updates to ensure that data is not overwritten on one of the servers: Figure 2 Master-Master Replication

For example, a company configures two servers, New York and Los Angeles, for master-master replication (Figure 2). If the same file is simultaneously updated on the New York server and on the Los Angeles server, master-master replication ensures that you can view the updates that originated on the other server. Conflict detection and resolution rules ensure data integrity on both servers and recursion prevention prevents updates from replicating back to the original system. For updates to data that is not synchronized on the two servers, a conflict log file located on your target machine allows you to monitor replication and make adjustments to your configuration when necessary. The iBalance feature and master-master replication is applicable to many different scenarios including load balancing and data distribution. It allows for active use of the second system for a variety of business needs, instead of reserving it for read-only operations like queries and backups, or for disaster recovery. Note: iBalance is a feature that requires different authorization codes. For more information on installing this feature, see Installing the iBalance Feature on page 23.

The following topics provide more information on how to configure, operate, and monitor master-master replication:

Configuration of Master-Master Replication on page 322 Configuring Master-Master Replication in iCluster Administrator on page 509 Master-Master ReplicationOperations and Monitoring on page 323

DataMirror, an IBM Company

Printed in Canada

321

Overview of Conflict Detection and Resolution on page 323 Configuration of Conflict Detection and Resolution on page 325 Parameter List Descriptions for a Conflict Resolution User Exit Program on page 326 Conflict Logging File on page 337 High Availability Considerations on page 340

Configuration of Master-Master Replication


This topic describes the tasks you must perform to configure master-master replication for two iSeries environments configured on system A and B. This example assumes that you are populating new data between these two systems while preserving the original data on these systems. The examples show the required parameters you must set to perform each step. For a complete list of parameters, see the documentation for each command. Note: Bold indicates values that are specific to master-master replication.

To configure master-master replication:


1 Create two master-master replication groups that mirror in opposite directions (A->B and B->A):
DMADDGRP GROUP('MyGroupAB') GRPTYPE(*MSTRMSTR) PRIMNODE('NodeA') BACKUPS('NodeB') DMADDGRP GROUP('MyGroupBA') GRPTYPE(*MSTRMSTR) PRIMNODE('NodeB') BACKUPS('NodeA')

You can also configure data conflict options and a logging file (on the backup node only) for each master-master replication group. For more information on these options, see Overview of Conflict Detection and Resolution on page 323. For more information on the DMADDGRP command and a complete list of parameters, see DMADDGRPAdd Group on page 113. 2 Select the object specifiers for each group that you created in the previous step. The object specifiers for each of the groups must be the same for true master-master replication. The example below mirrors two physical files (LIB1/FILE1, LIB2/FILE2).
DMSELOBJ GROUP('MyGroupAB') OBJ('LIB1/FILE1') OBJTYPE(*FILE) OBJATTR(PFDTA) PFUPMTD(*UKEY) PFKEY(*AUTO) DMSELOBJ GROUP('MyGroupAB') OBJ('LIB2/FILE2') OBJTYPE(*FILE) OBJATTR(PFDTA) PFUPMTD(*UKEY) PFKEY(*AUTO) DMSELOBJ GROUP('MyGroupBA') OBJ('LIB1/FILE1') OBJTYPE(*FILE) OBJATTR(PFDTA) PFUPMTD(*UKEY) PFKEY(*AUTO) DMSELOBJ GROUP('MyGroupBA') OBJ('LIB2/FILE2') OBJTYPE(*FILE) OBJATTR(PFDTA) PFUPMTD(*UKEY) PFKEY(*AUTO)

Keyed replication (*UKEY) is required for physical data files (PF). You must also specify a value for the PFKEY parameter. The PFKEY (*AUTO) option for master-master replication scans the logical files (LF) associated with physical files (PF) and selects a uniquely keyed LF that can be used for mirroring. The logical files must already exist on the target when they are needed for replication (run-time resolution). Note: You can use generics when selecting object specifiers for your groups. For more information on this command and a complete list of parameters, see DMSELOBJSelect Objects to Group on page 141. Note: In addition to the database files configured in this example, you can also configure master-master replication for non-journaled IFS files and data areas.

3 Start both groups with a refresh. The options for master-master replication prevent the refresh from truncating existing data and replacing or removing existing logical files.
DMSTRGRP GROUP('MyGroupAB') STRAPY(*YES) REFRESH(*YES) TRUNCATE(*NO) REPLACELFS(*NO)

322

Printed in Canada

iClusterVersion 5.1

DMSTRGRP GROUP('MyGroupBA') STRAPY(*YES) REFRESH(*YES) TRUNCATE(*NO) REPLACELFS(*NO)

For more information on the refresh options for master-master replication groups, see Master-Master ReplicationOperations and Monitoring on page 323. As with the steps above, any subsequent operations with master-master replication groups such as ending and re-starting groups are done in pairs.

Master-Master ReplicationOperations and Monitoring


iCluster has specific refresh options for master-master replication groups. There are also specific considerations for sync check when using master-master replication groups. The following sections go through the options that are available to you when using master-master replication groups. As with all operations involving master-master replication groups, you typically execute commands in pairs. Refresh Options for Master-Master Replication Groups When starting master-master replication groups with a refresh, you have the following options:

The *NO option for the TRUNCATE parameter in the DMSTRGRPStart Cluster Operations at Group and DMACTOBJ Activate Object commands prevents the truncation of existing data on the target system during a refresh. This option is appropriate for master-master replication and is used in the example configuration in Configuring Master-Master Replication. The *YES option for the TRUNCATE parameter in the DMSTRGRPStart Cluster Operations at Group and DMACTOBJ Activate Object commands removes and recreates existing data files as part of a refresh. This is the default option for iCluster and is appropriate for standard iCluster replication. You can use this option for a master-master group if the data on the source system is known to be complete in order to ensure a synchronized starting point.

The *NO option for the REPLACELFS parameter in the DMSTRGRPStart Cluster Operations at Group and DMACTOBJ Activate Object commands uses existing logical files during a refresh. This option is appropriate for master-master replication and is used in the example configuration in Configuring Master-Master Replication. iCluster does not require logical files to be the same on source and target systems except for the uniquely keyed logical files used for mirroring.

Note:

The *YES option for the REPLACELFS parameter in the DMSTRGRPStart Cluster Operations at Group and DMACTOBJ Activate Object commands replaces logical files during a refresh. This is the default option for iCluster and is appropriate for standard iCluster replication. You can use this option for a master-master group if the logical files on the source system are the complete set required for your applications in order to ensure a synchronized starting point. Refresh options for master-master replication groups follow conflict detection and resolution rules. See Overview of Conflict Detection and Resolution on page 323 for more information on these rules and configuring conflict detection and resolution. Sync Check for Master-Master Replication Groups Due to the nature of master-master replication, it is recommended that you initiate sync checks during maintenance windows or down time to get a more accurate picture of your state of synchronization. For more information about using sync check, see Monitoring Replication on page 76.

Overview of Conflict Detection and Resolution


With master-master replication of groups in iCluster, a conflict is defined as any operation attempted on the target system where the target system is not in the same state as the source system. Conflict detection and resolution in iCluster allows you to detect, log, and act on inconsistent data. This ensures your iSeries environment handles data conflicts automatically and in accordance with your business rules. Conflict detection and resolution allows you to detect conflicts in the apply process and to automatically resolve the conflicts when they are detected. As conflicts are detected and resolved, iCluster logs them in a file which allows you to analyze your conflicts and make adjustments to your mirroring or applications.

DataMirror, an IBM Company

Printed in Canada

323

Conflict Detection Rules Table 1 outlines the conflict detection rules for database files.
Table 1 Conflict Detection Rules for Database Files

Source Operation

Target Row

Conflict Insert Update Row exists No target row OR Before image differs from target row Before image differs from target row

No Conflict No row with that key Before image matches

Delete

No target row OR Before image matches

324

Printed in Canada

iClusterVersion 5.1

Table 2

Conflict Detection Rules for Data Areas

Source Operation

Target Data Area

Conflict Update Before image of the changed part of the data area differs from the target data area.

No Conflict Before image matches

Table 3

Conflict Detection Rules for IFS Files

Source Operation

Target Row Conflict No Conflict Object Does Not Exist Object Does Not Exist

Create Move/Rename Into Scope Move/Rename Out of Scope Object Changed

Object Exists Object Exists

Object Does Not Exist

Object Exists

Object Does Not Exist

Object Exists

Configuration of Conflict Detection and Resolution


iCluster resolves conflicts with various rules that you can configure at the group level in the DMADDGRPAdd Group command, or the object specifier level in the DMSELOBJSelect Objects to Group command. The CRWNR parameter in both of these commands gives you the following options:

*SRC: The source wins. If there is a conflict, source data is applied to the target which ensures that target data matches source data and mirroring continues. *TGT: The target wins. If there is a conflict, iCluster does not apply any data to the target. This rule preserves data on the target and mirroring continues. *EXIT: Indicates that you would like to resolve data conflicts through a user exit program. With this option you will also have to specify the user exit program and library in the CRUSREXIT parameter. The user exit program allows for more flexibility since you can choose the resolution method for data conflicts. See the DMADDGRPAdd Group and DMSELOBJSelect Objects to Group commands for more information. *NONE: Indicates that conflict resolution rules are not enabled and iCluster suspends the file from replication if there is a conflict. In addition, a message is sent to the event log. This is the default behavior of iCluster.

Resolved conflicts are silent (source wins, target wins, user exit) and no messages are generated in the event log. However, this information is logged in a special database file. See Conflict Logging File on page 337 for more information.

DataMirror, an IBM Company

Printed in Canada

325

Note:

Conflict resolution configuration with the DMSELOBJSelect Objects to Group command will override any conflict resolution configuration in the DMADDGRPAdd Group command. By using the *GROUP option in the DMSELOBJSelect Objects to Group command, iCluster uses the user exits configured at the grouplevel.

See the DMADDGRPAdd Group and DMSELOBJSelect Objects to Group commands for more information on the parameters available for conflict detection and resolution.

Parameter List Descriptions for a Conflict Resolution User Exit Program


When a conflict is detected, you can resolve it by invoking a customized user exit program. This program allows you to define a conflict resolution strategy that is not covered by one of the standard resolution methods (source wins, target wins, or take no action). The user exit program can resolve the conflict by directing the apply job on what to do with the source image. The user exit program returns a conflict resolution code of source wins, target wins, apply the desired image, or take no action. If you are applying the desired image, the user exit program also returns a desired image that is applied to the target object. You can define the user exit program at the group-level in the DMADDGRPAdd Group command or the object specifier level in the DMSELOBJSelect Objects to Group level. The object specifier level takes precedence when defining your user exit programs. Note: The iBalance feature includes a sample user exit program, cruesample.c, which sets up a source wins resolution code for a database record and a target wins resolution code for a data area.

The following sections outline the values you can pass to the user exit program. If the group has a database file, the user exit program may deal with the columns of a database row or the changed part of a data area since it is only provided with a raw image of the record.

Parameters Passed to the User Exit Program


Table 4 describes each of the parameters that are passed to the conflict resolution user exit program for database files, data areas, and Byte Stream Files (BSF).
Table 4 Parameters passed to the conflict resolution user exit program for Database files, Data Areas, and Byte Stream Files (BSF)

Parameter Control Structure (*pControl)

Description A pointer to the control structure containing various items of information about the source and target, as well as various indicators. Note: This parameter applies to database files, data areas, and BSFs.

For more information about the structure, see Control Structure on page 329. BSF Path Name (*pBsfPathName) A pointer to the string that specifies the BSF path terminated with a null character. Note: This parameter only applies to BSFs.

326

Printed in Canada

iClusterVersion 5.1

Table 4

Parameters passed to the conflict resolution user exit program for Database files, Data Areas, and Byte Stream Files (BSF)

Parameter Source Before Image (*pBeforeImage)

Description Database record: A pointer to the structure containing the image of the row in the source table before changes were applied to the row. Data area: A pointer to the structure containing the source before image of the changed part of the data area. Note: This parameter does not apply to BSF. For more information about the structure, see Image Structure on page 328. The control structure contains an indicator that you can use to determine whether or not this image was passed to the conflict resolution user exit program. For more information about this structure, see Control Structure.

Source After Image (*pAfterImage)

Database record: A pointer to the structure containing the image of the row in the source table after changes were applied to the row. Data area: A pointer to the structure containing the source after image of the changed part of the data area. Note: This parameter does not apply to BSF. For more information about the structure, see Image Structure on page 328. The control structure contains an indicator that you can use to determine whether or not this image was passed to the conflict resolution user exit program. For more information about this structure, see Control Structure.

DataMirror, an IBM Company

Printed in Canada

327

Table 4

Parameters passed to the conflict resolution user exit program for Database files, Data Areas, and Byte Stream Files (BSF)

Parameter Target Image (*pTargetImage)

Description Database record: A pointer to the structure containing the image of the row in the target table when the user exit program was called. Data area: A pointer to the structure containing the target image of the changed part of the data area. Note: This parameter does not apply to BSF. For more information about the structure, see Image Structure on page 328. The control structure contains an indicator that you can use to determine whether or not this image was passed to the conflict resolution user exit program. For more information about this structure, see Control Structure.

Result Image (*pDesiredImage)

Database record: A pointer to the structure containing the image of the row that will be applied to the target table if the user exit applies the desired image. If the conflict is resolved by the user exit program, this is the image defined in the user exit program, returned to the calling environment, and subsequently applied to the target table. This parameter applies only to conflicts caused by rows being inserted or updated in the source table. For row deletes, do not assign an image to this parameter. Data area: A pointer to the structure of the changed part of the data area that will be applied to the target if the user exit applies the desired image. Note: This parameter does not apply to BSF. For more information about the structure, see Image Structure on page 328. The control structure contains an indicator that you can use to determine whether or not this image can be returned by the user exit program. For more information about this structure, see Control Structure.

For important considerations regarding large object (LOB) data in the images, see LOB Considerations on page 329.

Image Structure
The structure that is used to represent an image is as follows:
typedef_Packed struct CrUeImage_T { int allocatedSize; int actualSize; unsigned int offsetToData; char data[1]; } CrUeImage_t;

328

Printed in Canada

iClusterVersion 5.1

Parameters in the Image Structure Table 5 describes the parameters in the image structure for database records and data areas. This structure is not applicable to BSF.
Table 5 Parameters in the Image Structure for Database Files and Data Areas

Parameter Allocated Size (allocatedSize)

Description Database record: The allocated size for the array of null indicators and record data for database files. Data area: The allocated size for the changed part of the data area.

Actual Size (actualSize)

Database record: The number of bytes used for the null map and record data. Data area: The number of bytes of the changed part of the data area. For *DEC data areas, this value equals the number of decimals divided by 2 plus 1.

(offsetToData) Data (data [1])

Offset in bytes from the starting address of the CrUeImage_t data structure to the buffer containing the image data. The image data is represented by an array of characters whose starting address is pointed to by the offsetToData field value. The array has variable length. Database record: It is the null map followed by the record buffer. Note: The first numberOfFields bytes are allocated for the null map only in null-capable files, otherwise they hold meaningless values.

Data area: The changed part of the data area. The starting position and length in bytes of the data change is indicated in the fieldOffset and fieldLength fields of CrUeField_T structure. For more information about the structure, see Field Structure on page 335.

LOB Considerations
Columns containing LOB data are not passed to conflict resolution user exit programs. In the row images passed to a user exit program, each LOB column is represented by a placeholder. The result image returned by the user exit program cannot return LOB data, and so the placeholder(s) should also be used in the result image. iCluster ensures that source LOB data is applied to the target table.

Control Structure
The structure that is used to pass and return various items of information to and from a user exit program is as follows:
typedef_Packed struct CrUeControl_T {

DataMirror, an IBM Company

Printed in Canada

329

int revision; char groupName [10]; int allocatedSize char objectName[10]; char member[10]; char objectType[10]; char objectAttr [10]; char sourceLibrary[10]; char sourceIASP[10]; char targetLibrary[10]; char targetIASP[10]; char operationType; char replicationMode; char conflictType; char hasBeforeImage; char hasAfterImage; char hasTargetImage; char returnCode; char resolutionCode; int numberOfFields; char isNullCapable; unsigned int offsetToFields; CrUeField fields[1]; } CrUeControl_t;

Parameters in the Control Structure Table 6 describes each of the parameters in the control structure.
Table 6 Parameters in the Control Structure

Parameter Revision (revision)

Description The internal revision number that is used to determine whether or not the user exit program is using the current structures. If the structures change in a future release, this parameter can be referenced in a user exit program to determine compatibility with those structures. In a user exit program, logic can be defined to take appropriate actions depending on the revision number. For iCluster Version 5.1, the revision number is set to 1 (DM_CR_UE_REVISION).

Group Name (groupName) Object Name (objectName)

The master-master (*MSTRMSTR) replication group name. The 10 character object name. Note: This field only applies to database records and data areas.

Member (member)

The member name. Note: This field only applies to database records.

330

Printed in Canada

iClusterVersion 5.1

Table 6

Parameters in the Control Structure

Parameter Object Type (objectType)

Description The 10 character object type. Database record: This will be *FILE. Data area: This will be *DTAARA. BSF: This will be *STMF for a stream file or *DIR for a directory.

Object Attribute (objectAttr)

Extended object attribute. Database record: This will be *PFDTA for *FILE object type. Data area: One of *CHAR, *DEC, or *LGL for *DTAARA object type. Note: This field is not applicable to BSFs.

Source Library (sourceLibrary)

The source library name. Note: This field only applies to database records and data areas.

Source IASP (sourceIASP) Target Library (targetLibrary)

The source IASP name. The target library name. Note: This field only applies to database records and data areas.

Target IASP (targetIASP) Operation Type (operationType)

The target IASP name. The source object-level operation that caused the conflict resolution user exit program to be called. Possible values for database records, BSFs, and data areas:

'I' (DM_CR_INSERT): Inserting a database record, or creating a BSF. 'U' (DM_CR_UPDATE): Updating a database record, or renaming a BSF. 'D' (DM_CR_DELETE): Deleting a database record. Not applicable to resolution code 'D'. 'R' (DM_CR_REFRESH_INSERT): Insert a database record during refresh. 'C' (DM_CR_CHG_DTAARA): Changing a data area.

DataMirror, an IBM Company

Printed in Canada

331

Table 6

Parameters in the Control Structure

Parameter Replication Mode

Description The modes of replication.


Note: Conflict Type (conflictType)

'R' (DM_CR_MODE_REFRESH): Refresh. 'W' (DM_CR_MODE_RWA): Refresh while active. 'M' (DM_CR_MODE_MIRRORING): Mirroring. This field only applies to database records.

The type of conflict that caused the conflict resolution user exit program to be called. Possible values for database records:

'E' (DM_CR_UE_EXIST): An attempt was made to insert a row into the source table, but the key value already exists in the target table. 'M' (DM_CR_UE_MISSING): An attempt was made to update or delete a row in the source table, but the key value does not exist in the target table. 'D' (DM_CR_UE_DIFF): An attempt was made to update or delete a row in the source table, but the images of the corresponding rows in the source and target tables do not match. 'D' (DM_CR_UE_DIFF): An attempt was made to update or delete an image in the source, but the images of the corresponding images in the source and target do not match. E (DM_CR_UE_EXISTING): BSF object of the same path name already exists on the target.

Possible values for data areas:

For BSFs, this field is always:

332

Printed in Canada

iClusterVersion 5.1

Table 6

Parameters in the Control Structure

Parameter Source Before Image Indicator (hasBeforeImage)

Description An indicator of whether or not the before image from the source has been passed to the conflict resolution user exit program. Possible values for database records:

0 (DM_CR_UE_FALSE): The before image has not been passed to the user exit program. 1 (DM_CR_UE_TRUE): The before image has been passed to the user exit program. You can reference this image in the user exit program. 1 (DM_CR_UE_TRUE): The after image has been passed to the user exit program. This image can be referenced in the user exit program. This field only applies to database records and data areas.

Possible values for data areas:

Note:

For information about the image, see Image Structure on page 328. Source After Image Indicator (hasAfterImage) An indicator of whether or not the after image from the source has been passed to the conflict resolution user exit program. Possible values for database records:

0 (DM_CR_UE_FALSE): Indicates that the row after image has not been passed to the user exit program. 1 (DM_CR_UE_TRUE): Indicates that the row after image has been passed to the user exit program. This image can be referenced in the user exit program. 1 (DM_CR_UE_TRUE): Indicates that the after image has been passed to the user exit program. This image can be referenced in the user exit program. This field only applies to database records and data areas.

Possible values for data areas:

Note:

For information about the image, see Image Structure on page 328.

DataMirror, an IBM Company

Printed in Canada

333

Table 6

Parameters in the Control Structure

Parameter Target Image Indicator (hasTargetImage)

Description An indicator of whether or not the image from the target has been passed to the conflict resolution user exit program. Returns either for database records:

0 (DM_CR_UE_FALSE): The image has not been passed to the user exit program. 1 (DM_CR_UE_TRUE): The image has been passed to the user exit program. This image can be referenced in the user exit program. 1 (DM_CR_UE_TRUE): The image has been passed to the user exit program. This image can be referenced in the user exit program. This field only applies to database records and data areas.

Returns the following for data areas:

Note:

For information about the image, see Image Structure on page 328. Return Code (returnCode) The code returned by the conflict resolution user exit program that indicates whether or not the program call was successful. In the user exit program, set this parameter to one of the following values:


Note: Resolution Code (resolutionCode)

0 (DM_CR_UE_FALSE): Indicates that the user exit program call was not successful. Returning this value ends all subsequent iCluster replication operations for the group. 1 (DM_CR_UE_TRUE): Indicates that the user exit program call was successful. This parameter applies to database files, data areas, and BSFs.

The action that iCluster must perform to resolve the conflict. Returns either:


Note:

'N' (DM_CR_UE_NONE): No action. Object is suspended with "CNR" reason code. 'D' (DM_CR_UE_DESIRED): iCluster performs operation with desired image. Not applicable to a row deletion operation. This value only applies to database records and data areas and does not apply to BSFs. 'T' (DM_CR_UE_TARGET): Target wins. 'S' (DM_CR_UE_SOURCE): Source wins. This parameter applies to database files, data areas, and BSFs.


Note:

334

Printed in Canada

iClusterVersion 5.1

Table 6

Parameters in the Control Structure

Parameter Number of Fields (numberOfFields)

Description Database record: The number of fields in a database record. Data area: The number of fields is always 1 for a data area. Note: This field does not apply to BSFs.

Null Capable (isNullCapable)

Indicates whether or not the file is null capable. Returns either:


Note: (offsetToFields)

0 (DM_CR_UE_FALSE): Indicates that the field is not null capable. 1 (DM_CR_UE_TRUE): Indicates that the field is null capable. This field is only applies to database records.

Offset in bytes from the starting address of the CrUeControl_t data structure to the array of field data. Note: This field only applies to database records and data areas.

Fields (fields[1])

This is an array of CrUeField_t elements whose starting address is pointed to by the offsetToFields field value. It is only meaningful for database records and data areas. Database record: The array has variable number of CrUeField_t elements. Each element describes a field in the database record. Array of structures containing the file fields attributes. For more information, see Field Structure on page 335. Data area: The array has only one CrUeField_t element, which describes the data area.

Field Structure
The structure that is used to pass information about the fields comprising the file record to the user exit program is as follows:
typedef_Packed struct CrUeField_T { int fieldOffset; int fieldLength; char isNullCapable; char fieldType; } CrUeField_t;

DataMirror, an IBM Company

Printed in Canada

335

Parameters in the Field Structure Table 7 describes each of the parameters in the control structure for database records and data areas. This structure is not applicable to BSFs.
Table 7 Parameters in Field Structure for Database Records and Data Areas

Parameter Field Offset (fieldOffset)

Description Database record: The offset to the field in the record buffer. Data area: The starting position in the data area that is changed. This is the same as indicated by the journal entry.

Field Length (fieldLength)

Database record: Length of the field. Data area: Length in bytes of the changed part of the data area. For *CHAR and *LGL data areas, this is the same as indicated by journal entry. For *DEC data areas, this value equals the length of the change in the journal entry divided by 2 plus 1, since the length of the change in the journal entry is not the number of bytes but the number of decimals.

Null Capable (isNullCapable)

An indicator of whether or not the field is null capable. In the user exit program, set this parameter to one of the following values:


Note: Field Type (fieldType)

0 (DM_CR_UE_FALSE): Indicates that the field is not null capable. 1 (DM_CR_UE_TRUE): Indicates that the field is null capable. This field is only used for database records.

Data type of the field. Possible values are:


Note:

'1': BLOB data type. '2': CLOB data type. '3': DBCLOB data type. '4': DATALINK data type. 'A': ALPHANUMERIC data type. 'B': BINARY data type. 'G': GRAPHIC data type. 'P': PACKED_DECIMAL data type. 'S': ZONED_DECIMAL data type. 'Z': TIMESTAMP data type. This field is only used for database records.

336

Printed in Canada

iClusterVersion 5.1

Conflict Logging File


When iCluster resolves a conflict between the source and target tables, it automatically records information about the nature of the resolution for database files and data areas in a conflict logging file. The log file is generated at run time in iCluster's product library when the first conflict is encountered. If there are no conflicts, iCluster does not generate this table. Note: For data areas, the images in the logging file are of the same format as the change data area journal entry. The DMCONFAUD table in the logging file allows you to track how conflict resolution affects your target table. For example, you can query the CNFTIME column to see when a change was made to the target table. Then you can review the contents of the BEFOREIMG and AFTERIMG columns to see the change on the source table that resulted in the data on the target table. This can help in identifying problems in your conflict resolution strategy. Table 8 describes the structure of the DMCONFAUD conflict resolution table for database files and data areas.
Table 8 DMCONFAUD Conflict Resolution Table

Column CNFTIME - timestamp SRCTIME - timestamp GROUP - char(10) SRCSCHEMA - char(30) SRCNAME - char(10) SRCMEMBER - char(10) TGTSCHEMA - char(30) TGTNAME - char(10) TGTMEMBER - char(10) OBJTYPE - char(10)

Description The date and time on the source system when the conflict was detected. The time the conflicting data was applied to the source object. The name of the master-master group name. The schema or library name for the source object. The name of the source table or data area. The source table member name. NULL for data areas. The schema or library for the target object. The name of the target table or data area. The target name is the same. The target table member name. NULL for data areas. The target member is the same. The object type. Database record: This will be *FILE. Data area: This will be *DTAARA. BSF: This will be *STMF for a stream file or *DIR for a directory.

OBJATTR - char(10)

The object attribute.

DataMirror, an IBM Company

Printed in Canada

337

Table 8

DMCONFAUD Conflict Resolution Table

Column OPTYPE - numeric(2)

Description The operation on the source server that caused the conflict. For database records, the value is one of the following:


CNFTYPE - numeric(2)

1 - A row was inserted into the source table. 2 - A row was updated on the source table. 3 - A row was deleted from the source table. 4 - A row was inserted during a refresh. 5 - A data area has changed. 1Create a BSF object on the source. 2Rename a BSF object on the source.

For data areas, the value can be the following: For BSF objects, the value can be one of the following:

The type of conflict that was detected. The value is one of the following for database records:


RESMTD - numeric(2)

1 - A row was inserted into the source table. The key for that row already exists in the target table. 2 - A row was updated or deleted on the source table. The key for that row does not exist in the target table. 3 - A row was updated or deleted on the source table. The images of the source and target tables do not match. 4 - An unexpected conflict was detected. 3 - A data area was changed, the images of the source and target data areas do not match. 1The BSF object already exists on the target.

For data areas, the value can be the following:

For BSF objects, the value is always the following:

The conflict resolution method that was used. The value is one of:

1 - Source wins. 2 - Target wins. 3 - User exit with no decision. This is for a delete with no row on the target. 4 - User exit with a source wins decision. 5 - User exit with a target wins decision. 6 - User exit generates a desired image to apply on the target.

If the resolution method was None, then a row will not be entered into this table. See Configuration of Conflict Detection and Resolution on page 325 for more information on these methods.

338

Printed in Canada

iClusterVersion 5.1

Table 8

DMCONFAUD Conflict Resolution Table

Column CNFRES - char(1)

Description Indicates if the conflict was resolved. The value is one of:


BEFORETRNC - char(1)

Y - The conflict was resolved. N - The conflict was not resolved.

Indicates if the before image stored in BEFOREIMG was truncated. The value is one of:


BEFOREIMG - varchar(8000)

Y - The value was truncated. N - The value was not truncated.

Database record: A representation of the row in the source table before it was changed. The representation is truncated to the first 8000 bytes if truncation occurs. Data area: A representation of the before image of the changed part of the data area. BSF objects: Used to store the BSF object path for BSF objects.

AFTERTRNC - char(1)

Indicates if the after image stored in AFTERIMG was truncated. The value is one of:


AFTERIMG - varchar(8000)

Y - The value was truncated. N - The value was not truncated

Database record: A representation of the row in the source table after it was changed. The representation is truncated to the first 8000 bytes if truncation occurs. Data area: A representation of the after image of the changed part of the data area.

TGTTRNC - char(1)

Indicates if the after image stored in TGTIMG was truncated. The value is one of:


TGTIMG - varchar(8000)

Y - The value was truncated. N - The value was not truncated.

Database record: A representation of the row in the target table before replication occurred. The representation is truncated to the first 8000 bytes if truncation occurs. Data area: A representation of the target data area before replication occurred.

DataMirror, an IBM Company

Printed in Canada

339

Table 8

DMCONFAUD Conflict Resolution Table

Column WINTRNC - char(1)

Description Indicates if the image stored in WINIMG was truncated. The value is one of:


WINIMG - varchar(8000)

Y - The value was truncated. N - The value was not truncated.

Database record: A representation of the final row in the target table after conflict resolution has occurred. The representation is truncated to the first 8000 bytes if truncation occurs. Data area: The image of the data area on the target after conflict resolution has occurred.

High Availability Considerations


There are special considerations when using master-master replication groups in disaster recovery (DR) scenarios. Since they mirror changes in both directions, master-master replication groups do not permit fail over like standard iCluster replication groups where the backup system is reserved to take over from the primary system during a failover. With master-master replication groups, you will have to migrate users to the surviving system which you can do manually or with a stand-alone CL program. This will place a heavier load on your surviving system, but it will give you time to fix your failed system so that you can resume mastermaster replication.

340

Printed in Canada

iClusterVersion 5.1

iSeries Clustering Overview

Switchover for IBM Cluster Resource Services (CRS)


This section contains information about the switchover and failover mechanisms for clusters that use IBM Cluster Resource Services. This section is for iCluster installations using IBM Cluster Resource Services as the failover mechanism. See Choosing a Failover Mechanism on page 73 for more information. DataMirror's iCluster works closely with IBM's low-level cluster support (OS/400 Cluster Resource Services). For more information about OS/400 Cluster Resource Services, see iSeries Clustering Overview on page 341. Warning: If your cluster is NOT configured to use IBM Cluster Resource Services for cluster operations, then DO NOT refer to this section. Instead, refer to Switchover for SwitchOver System (SOS) on page 369.

iSeries Clustering Overview


A cluster consists of a networked collection of iSeries systems (or nodes) that work together to provide seamless iSeries operations. iCluster is built on the underlying framework provided in the OS/400 operating system. This section introduces iSeries clustering concepts that are relevant to switchovers and failovers. Note: For more information about iSeries clustering concepts, see your iSeries documentation.

iSeries Clustering Concepts


This section provides information about the concepts related to iSeries clustering:

OS/400 Cluster Resource Services: A set of OS/400 system functions that allow for iSeries cluster operations and implementations. Node: A node is any iSeries server that is a member of a cluster. In iCluster, each node is identified by its iSeries system name. The iCluster node name is associated with one or more Internet Protocol addresses that represent an iSeries server. iCluster communications makes use of the TCP/IP protocol suite to provide the communications path between each node in the cluster. Cluster: A cluster consists of a set of iSeries systems that have been configured to work together in order to provide continuous, uninterrupted operations. A cluster of iSeries nodes is capable of recovering from anticipated or unexpected disruptions in the normal flow of operations by moving processing activities from one node in the cluster to another. Therefore, communications must exist between all nodes in the cluster. Cluster Resource Group (CRG): A CRG specifies a recovery domain that defines a group of nodes and the role of each node in the group. There are three kinds of CRGs: data, applications, and devices. Recovery domain: The ordered list of nodes in a Cluster Resource Group from the primary node to the first backup node to the second backup node, and so on. Switchover: When a user manually switches the role of a primary node over to the role of a backup node. A switchover is a planned procedure. Heartbeat: The mechanism within the cluster that verifies that every active node in the cluster is responding to signals across one or two networks. Distress message: A message, broadcast to all known nodes in the cluster subnet that indicates that a failure situation has been detected by a cluster node and the node will end clustering locally.

DataMirror, an IBM Company

Printed in Canada

341

Node failure: The detection of a distress message received from a failing cluster node before a heartbeat or message timeout is detected. Failover: When a group's primary node automatically switches over to a backup node because of a system failure. A failover is generally unplanned. Regardless of whether a failover or switchover occurs, OS/400 Cluster Resource Services provide the underlying mechanisms to switch operations to a backup node when the primary node is unable to provide business services.

Cluster partition: The detection of a heartbeat time-out with no detection of a distress message. Resilient applications: An application that is restarted on the new primary node after switchover or failover by OS/400 Cluster Resource Services. Application groups within a resilient application have a floating IP address associated with the group to allow users to access the application using the same IP address before and after the switchover or failover. For information about how iCluster handles switchovers of resilient applications, see iCluster and Resilient Applications on page 364.

Takeover IP addresses: A takeover IP address allows multiple nodes in the recovery domain to have the same IP address at different times. It facilitates a transparent switchover in a TCP/IP environment. Resilient devices: A resilient device is a physical resource represented by a configuration object, such as a device description, that is accessible from more than one node in a cluster. For information about how iCluster handles switchovers of resilient devices, see iCluster and Resilient Devices on page 365.

iCluster builds upon the OS/400 Cluster Resource Services for high availability and switchover capabilities. See iCluster Concepts on page 342 for more information.

iCluster Concepts
This section provides information about the clustering concepts related specifically to iCluster. For more information on the basic concepts in iCluster such as nodes in a cluster, groups, group types, failovers, and switchovers, see iCluster Basics on page 43.

iCluster and OS/400 Cluster Resource Services


There are two parts to the cluster definition:

Low-level definition maintained by OS/400 Cluster Resource Services. The OS/400 Cluster Resource Service definition includes the status of each node of the cluster and status of each cluster group. High-level definition maintained by iCluster. The iCluster portion of the definition includes the object specifiers, resilient applications, and the replication status of replication groups.

iCluster Groups and Role Switching


When OS/400 Cluster Resource Services determines that a node in the cluster has failed, it puts the node into *FAILED status on the other nodes of the cluster. If a group in *ACTIVE status has the failed node as its primary node, the group will be switched over at the operating system level, that is, the previous backup node becomes the primary node and the previous primary node becomes the backup node in the view of OS/400 Cluster Resource Services. Note: Inactive groups are not switched over, even if their primary node is the one that failed.

342

Printed in Canada

iClusterVersion 5.1

iCluster Concepts

In the following discussion, the terms "server A" and "server B" refer to physical machines as seen in the following figure. Figure 1 Typical Node Configuration

The terms "primary node" and "backup node" refer to roles that a physical machine can adopt in a replication group (Figure 1). Hence, server A may be either the primary node or the backup node of a group. In this discussion, server A is the primary node and server B is the backup node before the failover happens. After the failover happens, server B is the primary node and server A is the backup node in the view of OS/400 Cluster Resource Services.

ROLESWITCH Parameter
The ROLESWITCH parameter allows you to make the decision about whether to switch roles for a node. Each replication group defined in iCluster with the DMADDGRPAdd Group command has a ROLESWITCH parameter which can be set to *YES or *NO. It gives the administrator control over a group beyond the behavior of OS/400 Cluster Resource Services.

ROLESWITCH *NO means that when a failure of the group's primary node (for example, server A) is declared by OS/400 Cluster Resource Services, iCluster will not prepare the backup node (server B) to take over as the primary node. Replication will not start up automatically once server A is again active in the cluster. Note that even though server B has not been prepared to take over as the primary node, it will still appear as the primary node for the groups of which it was the backup node prior to the failure. *NO is the default setting for the ROLESWITCH parameter. Setting the ROLESWITCH parameter to *NO gives you the opportunity to decide if you would like to continue with a role switch, or continue with your current configuration. With this setting, the failed primary node will retain its role and resume its functions as the primary node once the appropriate commands have been issued. For minor system failures with a minimum amount of down time, this is probably the optimal situation. See the DMSETPRIMPrepare Primary Node command for more information.

ROLESWITCH *YES means that when a failure of the group's primary node (for example, server A) is declared by OS/400 Cluster Resource Services, iCluster will prepare the backup node (server B) to take over as the primary node. Once server A is again active in the cluster, replication will take place from server B, which is now the primary node, to server A, which is now the backup node. Note that the ROLESWITCH parameter is defined at the group level. It is not necessary or advisable to have user exits called for each group. Should you choose to set the ROLESWITCH parameter to *YES, you must have a thoroughly defined and tested switch plan. *YES means iCluster will prepare the backup node to take over as the primary node. This often involves, but is not limited to, enabling user profiles, varying on devices, and changing TCP/IP configurations. These steps would have to be reversed and could be time-consuming should a true failover not have occurred.

Note:

What iCluster Does During a Switchover and Failover


For both switchover and failover, the following steps prepare the backup node to become the primary node. The commands for switchover in iCluster are DMSTRWOSwitchover Group (for active independent groups, that is, groups that are not part of a resilient application), DMSWOAPPSwitchover Resilient Application (for active resilient applications), and DMCHGROLE Change Group Primary Node (for inactive groups or resilient applications). The same steps are automatically performed when a failover occurs, and the group's ROLESWITCH parameter is set to *YES.

DataMirror, an IBM Company

Printed in Canada

343

These commands automatically perform the following operations: 1 End replication if the group or resilient application is active. 2 Call the user-specified before role switch user exit for the group or resilient application. 3 Drain the staging store on the backup node by applying all staged entries. 4 Start journaling on backup files and objects. 5 Restore database triggers on backup files. 6 Perform the role switch at the operating system level. 7 Establish starting journal positions on the new primary node for the group or resilient application. 8 Call the user-specified after role switch user exit for the group or resilient application. 9 Start replication from the new primary to the new backup if the group or resilient application is active, and a backup node is available. Note: Local loopback groups (groups where the primary and backup nodes are the same) and groups that have a target library other than *PRIMARY, cannot undergo a role switch at the iCluster level.

Switchover Overview
A switchover occurs when a user manually switches a primary node over to a backup node. You would perform a switchover, for example, for maintenance or upgrade reasons. During a switchover, the primary node becomes the backup node and the backup node becomes the primary node. Note that a switchover procedure is planned by the user, while a failover is an unplanned procedure due to a system failure. You can use the commands DMSTRWOSwitchover Group (for replication groups) and DMSWOAPPSwitchover Resilient Application (for resilient applications) to perform manual switchovers.

Failover Overiew
A failover is a switch in roles of the backup node to the primary node as a result of the failure of the original primary system. This may occur automatically if the ROLESWITCH group parameter is set to *YES, or it may be done at the user's discretion by using the DMSETPRIMPrepare Primary Node command. The role switch in this case is unplanned.

Failovers and the ROLESWITCH parameter


The ROLESWITCH parameter in the DMADDGRPAdd Group command will control the behavior of the cluster in the case of a primary node failure.

ROLESWITCH *NO
If you would like the opportunity to decide if a role switch is necessary after a failover, set the ROLESWITCH parameter in the DMADDGRPAdd Group command to *NO. This setting gives you the opportunity to decide if you would like to proceed with a role switch, or continue with your current configuration. With this parameter set to *NO, the failed primary node will retain its role and resume its functions as the primary node once it recovers and rejoins the cluster. If you would like to complete a role switch after a failover has occurred, use the DMSETPRIMPrepare Primary Node and DMCHGROLE commands to prepare the new primary node (previous backup node) for replication. Note: The before and after user exit programs are called as part of issuing the DMSETPRIMPrepare Primary Node command.

344

Printed in Canada

iClusterVersion 5.1

Preparing the Cluster to Handle Switchovers and Failovers

For more information about the ROLESWITCH parameter, see DMSETPRIMPrepare Primary Node and DMCHGROLE Change Group Primary Node.

ROLESWITCH *YES
If you would like to automatically change the role of the backup node in the replication group to the primary node when a failover occurs, set the ROLESWITCH parameter in the DMADDGRPAdd Group command to *YES. The user exit programs that are specified through the BSWUSREXIT and ASWUSREXIT parameters in the DMADDGRPAdd Group command will be called automatically. See the DMADDGRPAdd Group command for more information about the ROLESWITCH parameter.

Preparing the Cluster to Handle Switchovers and Failovers


This section presents the considerations that you should note when preparing nodes and groups for handling switchovers or failovers.

ROLESWITCH Parameter
When creating or modifying groups using the DMADDGRPAdd Group or DMCHGGRPChange Group commands, you can enter a value for the ROLESWITCH parameter to control the behavior of the system on a failover. See iSeries Clustering Concepts on page 341 for more information about this parameter and the values that you can specify. Note: The ROLESWITCH parameter is not available for resilient applications. The behavior for resilient applications is always that of ROLESWITCH *YES.

User Exits
When adding a group or resilient application in iCluster, you can specify before and/or after user exits that you want to call immediately before the role change, or after the role change is performed. If you specify a user exit program for a group using the DMADDGRPAdd Group or DMCHGGRPChange Group commands, it will be called when the role of the node is changed within the group. If a failover occurs and the ROLESWITCH parameter for the group is *YES, the user exits will be called automatically when the failure is detected. If the ROLESWITCH parameter for the group is *NO, the user exit will not be called unless you decide to complete the failover of the node by calling the DMSETPRIM Prepare Primary Node command. Note: The specified user exit program is invoked for a switchover if you decide to prepare the backup node to be the primary node by issuing the DMSETPRIMPrepare Primary Node command. If you decide not to prepare the backup node to be the primary node, and just wait for the primary node to become active, the user exits are not called. See Passing Arguments to Role Switch User Exit Programs on page 347 for more information.

Journal Entry Processing


You may want to change your journal cleanup processes/schedule in your before role switch user exit program. You may have configured your target receivers to be cleaned up quickly on the backup node. If your group is configured for remote journaling, you will need the receivers created as a result of the failover-switch to properly re-synchronize your original primary node. You can change the schedule for journal receiver cleanup in the before role switch user exit program.

DataMirror, an IBM Company

Printed in Canada

345

Synchronous and Asynchronous Remote Journaling


Figure 2 shows the recommended configuration for remote journaling between two systems: System A (Primary Node) and System B (Backup Node). Figure 2 Setup for Synchronous and Asynchronous Remote Journaling

The example in Figure 2 shows remote journals configured for synchronous remote journaling. Note that the example also applies to configurations that involve asynchronous remote journaling. As shown in Figure 2, a remote journal should be configured on both System A and System B. The purpose of these remote journals is to receive journal entries from the other system when it acts as a primary node. Whenever a system acts as a primary node (System A in Figure 2), the remote journal that resides on that system (Remote Jrn A) should be inactive. This will prevent the unnecessary transmission of journal entries from the backup system (System B) to the remote journal on the primary node (System A). Note: Note that these transactions are unnecessary since they originate on System A and will already reside in Local Jrn A.

The remote journal should be inactivated from the backup node (System B in this case) with the CHGRMTJRN command. See Configuring Remote Journaling on page 84 for more information on the CHGRMTJRN command. Whenever a switchover is performed, the remote journal residing on the new backup node should be activated from the new primary node. In addition, the remote journal residing on the new primary node should be de-activated from the new backup node. This can be done with the CHGRMTJRN command on each machine. Note: Note: You can use the after role switch user exit program to activate (de-activate) the remote journals on the appropriate nodes. Note that a sample program, RMTJRNSWO, has been included with iCluster. This program is located in the QACLSRC file in the product library. The name of the member is RMTJRNSWO.

346

Printed in Canada

iClusterVersion 5.1

Passing Arguments to Role Switch User Exit Programs

Failover Message Queue


In iCluster, you can specify a failover message queue that will receive messages generated when a failover occurs. Note that you can specify a failover message queue only for replication groups.

Enabling Alerts in OS/400


To detect partition states more easily, the operator should set alert status to "on" using the appropriate OS/400 command. See your iSeries documentation for more information on enabling alerts. See Alertable Messages for Clustering on page 366 for a list of alertable messages that are generated by OS/400 Cluster Resource Services.

Line Controller Heartbeat


The communication line controller detects and records line errors. Within the line description are two parameters that determine at what point in time the system operator is notified of line errors. The default settings specify that if an error count limit of two is reached within the last five minute time interval, then the system operator is notified with a message that requires a response as to whether to continue retrying the line (G or R) or to no longer attempt retries (C). WRKLIND <Name of line description for TCP/IP line> Recovery Limits Count Limit: 2 (default) Time interval: 5 (default) For example, a LAN cable pull will result in one line error. Every 10 to 15 seconds a retry is attempted, resulting in additional errors. Thus with the default settings an operator message will be received within 20 to 30 seconds. This manual intervention should be eliminated so that the cluster heartbeat time-outs can take control. You may want to adjust these parameters to allow for a longer interval before the system message is generated. This would create a larger window in which OS/400 Cluster Resource Services can recover from line outages. Since increasing these parameters would mean that the system overall would detect line errors more slowly, the values that you specify depend on what is acceptable for your system.

Passing Arguments to Role Switch User Exit Programs


If you define a user exit program that will be called when a failover or switchover occurs, the following arguments will be passed to the program: Note: Note: The order of the arguments passed to the user exit program is very important, and they will be passed in the same order as they appear below. User exit programs must be compiled with the Use adopted authority option set to *NO. Otherwise, the user exit programs cannot be executed and mirroring will continue.

Group Name Type: Character Length: 10 bytes The name of the group in which the failover or switchover occurred.

DataMirror, an IBM Company

Printed in Canada

347

Reason Type: Character Length: 10 bytes The point where the user exit program was called. One of the following values will be passed through this argument:

*BEFORE: The user exit program is called immediately before a group is switched over at the operating system level on both nodes of the group. *AFTER: The user exit program is called immediately after a failover occurs on the new primary node of the group, or immediately after a switchover occurs on both nodes of the group.

Role Type: Character Length: 10 bytes The new role of the node that the user exit program is running on in the specified group. The value passed to the user exit program is one of the following:

*PRIMARY: The user exit is running on the primary node for the specified group. *BACKUP: The user exit is running on the backup node for the specified group.

User Data Type: Character Length: 256 bytes The user-defined data can be specified through the DMADDGRPAdd Group or DMCHGGRPChange Group commands.

Failed State Overview


This section provides an overview of the FAILED state, indicates how to detect it, and specifies the method of recovery depending on certain conditions.

Node Failure Detection in iCluster


If a node fails and sends a distress signal, then OS/400 Cluster Resource Services reports the node failure to the other nodes in the cluster and initiates a failover.

FAILED State Scenarios


The following scenarios will result in a detected node failure if OS/400 Cluster Resource Services detects a distress message from the failing cluster node. All of the active resources that are managed by OS/400 Cluster Resource Services on that node will go through the failover process. This includes all application Cluster Resource Groups (CRG)s, data CRGs, and device CRGs. Loss of utility power scenarios:

Internal Battery Backup Unit (BBU) installed and the internal battery timer times out. Internal BBU installed and internal battery low signal detected. UPS installed, UPS Utility Failure signal received by SPCN, and a timer set by system value QUPSDLYTIM system value times out. UPS installed and both UPS Utility Failure and UPS Battery Low signals received by SPCN.

348

Printed in Canada

iClusterVersion 5.1

Failed State Overview

Controlled shutdown scenarios:

Initial Program Load (white) button pushed to power down the system. PWRDWNSYS *IMMED command issued. PWRDWNSYS *CNTRLD command issued and cntrld function expires.

ENDSBS *ALL: *IMMED or *CNTRLD where a time limit on the controlled function expires.

ENDSYS on controlling subsystem: *IMMED or *CNTRLD where a time limit on the controlled function expires.

ENDSBS QSYSWRK: *IMMED or *CNTRLD where a time limit on the controlled function expires. Where OS/400 Cluster Resource Services and TCP/IP jobs reside.

ENDTCP: *IMMED or *CNTRLD where a time limit on the controlled function expires.

ENDJOB QCSTCTL is issued: *IMMED or *CNTRLD where a time limit on the controlled function expires.

ENDJOB QCSTCRGM is issued: *IMMED or *CNTRLD where a time limit on the controlled function expires.

Detecting a FAILED State


You can detect whether a node is in a FAILED state from either the iCluster Administrator interface or from the command line:

From the iCluster Administrator that is connected to a node in *ACTIVE status, select a node and examine the Node Status value in the table view. If the value displays *FAILED, then the node is in a FAILED state. From the iCluster command line, issue the DMWRKNODEWork with Nodes command. The status of the node will be displayed on the screen. If it displays *FAILED, then the node is in a FAILED state.

Once a node is in a FAILED state, you will need to recover the node. See FAILED State Recovery Paths for information about how to recover from a FAILED state.

Group Failover in iCluster


An active replication group whose primary node goes into *FAILED state undergoes failover in one of two ways, depending on the group's ROLESWITCH parameter: Note: Inactive groups do not undergo failover.

If the group's ROLESWITCH parameter is set to *YES, the group's backup node will become the group's primary node, and the group's new primary node will be prepared so that the group is ready to begin replication from the new primary node (the previous backup node) when a backup node for the group becomes available. See Preparing the Cluster to Handle Switchovers and Failovers on page 345 for more information on what is involved in the preparation.

If the group's ROLESWITCH parameter is set to *NO (the default), the group's backup node will become the group's primary node at the cluster level. However, the new primary node will not be prepared to be the group's primary node for replication.

DataMirror, an IBM Company

Printed in Canada

349

Setting the ROLESWITCH parameter to *NO gives you the opportunity to decide if you would like to continue with a role switch, or continue with your current configuration. With this setting, the failed primary node will retain its role and resume its functions as the primary node once it recovers and rejoins the cluster. It is the responsibility of the cluster administrator to decide whether to continue with the role switch processing and switch the group back to its original configuration, or to complete the failover processing and prepare the new primary node (the previous backup node) for replication as the primary node. For minor system failures with a minimum amount of down time, it is probably best to retain the original configuration. For more detailed information about these steps, see Failed State Recovery Paths.

Failed State Recovery Paths


This section indicates the recovery path that you should follow depending on certain conditions.

350

Printed in Canada

iClusterVersion 5.1

Failed State Recovery Paths

Recovery Paths for a FAILED State


Different recovery paths depend on certain conditions. Figure 3 displays the different options: Figure 3 Recovery Paths for Failed State (Part 1)

DataMirror, an IBM Company

Printed in Canada

351

352

Printed in Canada

iClusterVersion 5.1

Failed State Recovery Paths

The OS/400 Cluster Resource Services jobs that run in the QSYSWRK subsystem on an active cluster node are listed in the following table:
Table 1 OS/400 Cluster Resource Services Jobs in the QSYSWRK Subsystem

Job Name QCSTCRGM QCSTCTL QCSTINETD DM_INTGRP All other jobs whose function name is PGM-QCSTCRGJOB. The job names are the names of *CRG objects (cluster resource groups) in the cluster.

Function PGM-QCSTCRGMA PGM-QCSTCCJOB Not available. PGM-QCSTCRGJOB

DataMirror, an IBM Company

Printed in Canada

353

To view the job logs of these jobs if they end (Table 1), you can issue the command WRKSPLF QSYS and search for either the job name or the job function name. Figure 4 Recovery Paths for FAILED State (Part 2)

Any underlined text in Figure 3 and Figure 4 indicates a topic in this document that you should read for information about how to proceed. The topics are as follows: Note: "Server A" and "Server B" in the following links are in reference to Figure 1 on page 343. The > indicates the direction in which objects are replicated within the group.

(Server A > Server B): Restarting Active Groups with Mirroring in the Original Direction with ROLESWITCH *NO on page 359. (Server A > Server B): Restarting Active Groups with Mirroring in the Original Direction with ROLESWITCH *YES on page 360. (Server B -->Server A): Restarting Active Groups with Mirroring in the Opposite Dire