Icluster Commands4 0

DataMirror iCluster
Version 4.0
Commands Guide
iCluster - Commands Guide
Table of Contents
Chapter 1 - Introduction ........................................................................................................................... 11 Guide Organization............................................................................................................................... 11 iCluster Overview.................................................................................................................................. 12 New Features in iCluster ...................................................................................................................... 12 iCluster Documentation ........................................................................................................................ 14 Troubleshooting .................................................................................................................................... 14 Online Information and Technical Support ........................................................................................... 14 Training and Education......................................................................................................................... 15 Authorization Codes and Licensing ...................................................................................................... 15 Contacting DataMirror .......................................................................................................................... 15 Chapter 2 - Working with iCluster ........................................................................................................... 16 Working in a Clustered Environment .................................................................................................... 16 Failovers and Switchovers.................................................................................................................... 20 Object Specifiers and Types................................................................................................................. 23 Path Object Specifiers .......................................................................................................................... 25 Starting iCluster from the Command Line ............................................................................................ 26 iCluster Quick Start............................................................................................................................... 27 Chapter 3 - Administering iCluster.......................................................................................................... 29 Command Security ............................................................................................................................... 29 Failover Mechanisms............................................................................................................................ 31 Adding and Configuring Nodes............................................................................................................. 32 Initial Synchronization........................................................................................................................... 33 Application Resiliency........................................................................................................................... 34 Locked Objects ..................................................................................................................................... 34 Commitment Control............................................................................................................................. 36 Suspended Objects .............................................................................................................................. 36 Starting Replication and Journal Positions........................................................................................... 38 Monitoring Out-of-Sync Objects ........................................................................................................... 38 Viewing Sync Check............................................................................................................................. 40 Monitoring Latency ............................................................................................................................... 40 Restarting iCluster After Restarting a Node ......................................................................................... 42 Upgrading the Cluster Version ............................................................................................................. 42 Changing IP Addresses........................................................................................................................ 43 Removing Nodes .................................................................................................................................. 44 Journaling in iCluster ............................................................................................................................ 44
2 DataMirror Corporation
Remote Journaling ............................................................................................................................... 47

Remote Journaling......................................................................................................................................................... 47 Configuring Remote Journaling..................................................................................................................................... 47 Role Switching with Remote Journals........................................................................................................................... 48
Chapter 4 - Replicating Objects............................................................................................................... 50 Staging Objects .................................................................................................................................... 50 Replicating Database *FILE Objects .................................................................................................... 51 Replicating Byte Stream File (BSF) Objects ........................................................................................ 53 Replicating Configuration Objects ........................................................................................................ 55 Replicating User Profiles ...................................................................................................................... 56 Replicating LOBs .................................................................................................................................. 56 Replicating Triggers.............................................................................................................................. 56 Replicating Save Files .......................................................................................................................... 57 Replicating QDLS Objects.................................................................................................................... 58 Monitoring Replication .......................................................................................................................... 59 Chapter 5 - iCluster Commands .............................................................................................................. 61 iCluster Commands .............................................................................................................................. 61 Node Commands.................................................................................................................................. 66
DMADDNODE Add Node........................................................................................................................................... 66 DMDSPNODE Display Node ..................................................................................................................................... 72 DMCHGNODE Change Node.................................................................................................................................... 73 DMRMVNODE Remove Node................................................................................................................................... 80 DMWRKNODE - Work with Nodes ............................................................................................................................... 81
Group Commands ................................................................................................................................ 83

DMADDGRP Add Group............................................................................................................................................ 83 DMDSPGRP - Display Group ....................................................................................................................................... 95 DMCHGGRP Change Group..................................................................................................................................... 95 DMRMVGRP Remove Group .................................................................................................................................. 106 DMADDBACK Add Backup Node to Recovery Domain......................................................................................... 107 DMRMVBACK Remove Backup Node from Recovery Domain............................................................................. 109 DMCHGROLE - Change Group Primary Node.......................................................................................................... 110 DMWRKGRP Work with Groups ............................................................................................................................. 111
Native AS/400 Object Commands...................................................................................................... 114

DMSELOBJ Select Objects to Group ...................................................................................................................... 114 DMCHGOBJSL Change Object Selection to Group ............................................................................................... 119 DMDSELOBJ De-select Objects from Group.......................................................................................................... 122 DMWRKOBJ Work with Object Specifiers............................................................................................................... 124
Byte Stream File (BSF) Commands ................................................................................................... 125

DMADDBSF - Add Path Object Specifier to Group.................................................................................................... 125 DMRMVBSF - Remove Path Object Specifier from Group........................................................................................ 128
DataMirror Corporation 3
DMCHGBSF - Change Path Object Specifier ............................................................................................................ 129 DMWRKBSF Work with Path Object Specifiers...................................................................................................... 132
Switchable Device Commands........................................................................................................... 133

DMADDSWDEV - Add Switchable Device Entry to Group........................................................................................ 133 DMDSPASPGP Display Switchable Device Group ................................................................................................ 134 DMCHGSWDEV - Change Switchable Device Entry for Group................................................................................ 135 DMRMVSWDEV - Remove Switchable Device Entry from Group............................................................................ 136
Resilient Application Commands........................................................................................................ 137

DMADDAPP Add Resilient Application.................................................................................................................... 137 DMDSPAPPGP Display Resilient Application Group.............................................................................................. 142 DMUPDAPP - Update Resilient Application ............................................................................................................... 143 DMCHGAPP Change Resilient Application............................................................................................................. 144 DMRMVAPP Remove Resilient Application............................................................................................................ 148 DMWRKAPP Work with Resilient Applications ....................................................................................................... 149
MQSeries Commands ........................................................................................................................ 150

RBDHAMQM - Rebuild iCluster MQSeries................................................................................................................. 150
Administration Commands ................................................................................................................. 151

DMSETSVAL - Set Cluster System Values................................................................................................................ 151 DMCHGTIME Change System Date and Time....................................................................................................... 168 DMDSPLOG - Display Cluster Event Log................................................................................................................... 170 DMCLRLOG Clear Cluster Event Log ..................................................................................................................... 175 HAPNGTCP Ping Using TCP .................................................................................................................................. 177 JRNHADADQ - Journal Data Areas and Data Queues ............................................................................................. 178 STRHATCP Start TCP/IP Listener........................................................................................................................... 179 WRKHAJOB Work with Active Cluster Jobs............................................................................................................ 180 DMSTRDM Start Definition Manager....................................................................................................................... 180 DMDLTCLSTR Delete Cluster ................................................................................................................................. 181 DMSYSINF - System Information ............................................................................................................................... 181
Cluster Operation Commands ............................................................................................................ 182

DMSTRNODE Start Cluster Operations at Node.................................................................................................... 182 DMENDNODE - End Cluster Operations at Node ..................................................................................................... 183 DMSTRGRP Start Cluster Operations for Group.................................................................................................... 184 DMSTRREPL Start Replication................................................................................................................................ 187 DMENDGRP End Cluster Operations for Group..................................................................................................... 189 DMSTRSWO Switchover Group.............................................................................................................................. 191 DMREJOIN - iCluster Rejoin Cluster .......................................................................................................................... 193 DMSTRAPP Start Cluster Operations for Resilient Application.............................................................................. 194 DMENDAPP - End Cluster Operations for Resilient Application ............................................................................... 196 DMSWOAPP Switchover Resilient Application ....................................................................................................... 197 DMSETPRIM - Prepare Primary Node ....................................................................................................................... 199 DMGENEXC - Generate Command Exceptions........................................................................................................ 199
Replication Operation Commands...................................................................................................... 200

DMSETPOS Set Journal Start Position ................................................................................................................... 200 DMMRKPOS Mark Current Journal Positions......................................................................................................... 203 CHGHAJRN Change Journal Receiver ................................................................................................................... 204 DSPHAPOS Display Journal Information ................................................................................................................ 206 RTVHAPOS Retrieve Journal Information............................................................................................................... 207 VFYHAJRN Verify Audit Journal .............................................................................................................................. 208 STRHABRCD - Start BSF Recording ......................................................................................................................... 210 DSPHABRCD - Display Recording for BSF Object.................................................................................................... 211 ENDHABRCD - End Recording for BSF Object......................................................................................................... 211 DMSTRAPY Start Replication Apply Processes ..................................................................................................... 212 DMENDAPY End Replication Apply Processes...................................................................................................... 214 DMACTOBJ - Activate Object ..................................................................................................................................... 216 DMACTBSF - Activate BSF Object............................................................................................................................. 218 DMSUSOBJ - Suspend Object ................................................................................................................................... 219 DMSUSBSF - Suspend BSF Object ........................................................................................................................... 220 DMSNDOBJ - Send Object Immediately .................................................................................................................... 222 DMSETSYNC - Set Sync Point................................................................................................................................... 224 CRTCFGOBJ Create Configuration Object............................................................................................................. 228 INITHAOBJ Initialize Objects.................................................................................................................................... 229 RTVRCVPT - Retrieve Recovery Checkpoint ............................................................................................................ 230 RTVRCVPTR - Retrieve Recovery Checkpoint (CL Program).................................................................................. 231 SYNCHATRG - Synchronize Triggers ........................................................................................................................ 232 DMLOGENT - Log Journal Entry ................................................................................................................................ 233
Status and History Monitor Commands.............................................................................................. 235

DSPHASMON - Display Source Monitor .................................................................................................................... 235 WRKHASMON - Work with Status Monitor on Primary Node ................................................................................... 235 WRKHATMON Work with Status Monitor on Backup Node................................................................................... 236 CHGHASMON - Change History Monitor on Primary Node...................................................................................... 237 PRGHASMON Purge History Monitor on Primary Node ........................................................................................ 239 WRKHAOBJST Work with Object Status ................................................................................................................ 241 WRKHABSFST Work with BSF Status.................................................................................................................... 242 DMWRKOBJST - Work with Object Status by Group ................................................................................................ 243
Sync Check Commands ..................................................................................................................... 244

DSPHASC - Display Sync Check................................................................................................................................ 244 SELSCATTR - Select Sync Check Attributes............................................................................................................. 246 STRHASC - Start Sync Check .................................................................................................................................... 249 STRHASCUSR - Start User-Specified Synchronization Check................................................................................. 252 DMSCRPT - Sync Check Report for IFS Objects ...................................................................................................... 257 DMSCRPTNTV - Sync Check Report for Native Objects .......................................................................................... 258 PRGHASC - Purge Sync Check Results.................................................................................................................... 260
Registered iCluster User Commands ................................................................................................. 261

DMADDUSR - Add User ............................................................................................................................................. 261 DMCHGUSR - Change User....................................................................................................................................... 262 DMRMVUSR - Remove User...................................................................................................................................... 264 DMWRKUSR - Work with Users ................................................................................................................................. 265
Exit Program Commands ................................................................................................................... 266

ADDPFEXPGM - Add Exit Program ........................................................................................................................... 266 RMVPFEXPGM - Remove Exit Program ................................................................................................................... 266
iCluster for Supported External Storage Systems.............................................................................. 267

DMRBDNODE - Rebuild Node ................................................................................................................................... 267 DMREGPOS - Register Positions............................................................................................................................... 268
Other Commands ............................................................................................................................... 269

SETHAREG - Restore Communications Registries................................................................................................... 269
Chapter 6 - The Status Monitor.............................................................................................................. 271 Working with the Status Monitor......................................................................................................... 271 Monitoring Real Time Statistics .......................................................................................................... 273
Real Time Statistics Views .......................................................................................................................................... 273 Common Options for all Views .................................................................................................................................... 275 Monitoring Real Time Overall Latency ........................................................................................................................ 277 Monitoring Real Time Object Latency ......................................................................................................................... 278 Monitoring Real Time Object Position and Totals....................................................................................................... 280 Monitoring Real Time Object Throughput ................................................................................................................... 281 Reading Status Information ......................................................................................................................................... 282
Monitoring Object Status .................................................................................................................... 285

Working with Object Status.......................................................................................................................................... 285 Working with BSF Status............................................................................................................................................. 290 Working with Object Status for Groups ....................................................................................................................... 291
Monitoring Historical Statistics............................................................................................................ 296

Historical Statistics Views ............................................................................................................................................ 296 Monitoring Historical Latency....................................................................................................................................... 297 Monitoring Historical Object Position and Totals ........................................................................................................ 298 Monitoring Historical Object Throughput..................................................................................................................... 300
Appendix A - Object Types Replicated by iCluster ............................................................................. 303 Object Types Replicated by iCluster .................................................................................................. 303 Appendix B - Important Considerations ............................................................................................... 307 iCluster Limits and Recommendations............................................................................................... 307 Passing Arguments to Sync Point User Exit Programs...................................................................... 309 Passing Arguments to Role Switch User Exit Programs .................................................................... 310 WebSphere MQ Support .................................................................................................................... 311
DataMirror Corporation
Index ......................................................................................................................................................... 314
Copyright Notice This manual is Copyright DataMirror Corporation 1996-2006. All rights reserved. No part of this manual may be reproduced, distributed or transmitted, in whole or in part, in paper, electronic or any other form or by any means other than as expressly permitted in the applicable DataMirror Software License Agreement or Software License and Maintenance Agreement, or as otherwise expressly permitted by DataMirror Corporation ("DataMirror"). Trademark Notice CONSTELLAR, DATA FROM WHERE IT IS TO WHERE IT NEEDS TO BE, DATAMIRROR, DATAMIRROR DB/XML TRANSFORM, DATAMIRROR DB/XML VISION, DATAMIRROR SYNAPSE MOBILITY, DATAMIRROR TRANSFORMATION SERVER, DBMIRROR, ENTERPRISE ADMINISTRATOR, ERP GATEWAY, HA SUITE, HIGH AVAILABILITY SUITE, ICLUSTER, ICLUSTER FOR EMC SYMMETRIX, IDELIVER, IREFLECT, ITRANSMIT, JOBSCHEDULER, OBJECTMIRROR, QUICKMARTS, SWITCHOVER SYSTEM, THE EXPERIENCE OF NOW, TRANSFORMATION SERVER, TRANSFORMATION SERVER/ES, TRANSFORMATION SERVER/EVENT SERVER, and XTREMECACHE are registered, unregistered or pending trademarks of DataMirror Corporation and may not be used without the express written permission of DataMirror Corporation. POINTBASE, POINTBASE EMBEDDED, POINTBASE MICRO, POINTBASE UNISYNC, and TRANSFORMATION SERVER FOR MOBILE are trademarks of DataMirror Mobile Solutions Inc. ("PointBase") and DataMirror Corporations use of these trademarks is by way of license with PointBase. This list of trademarks may not be complete; other trademarks or registered trademarks may be owned by DataMirror from time to time and may be used in this manual. All other trademarks or service marks are the properties of their respective owners. Proprietary and Confidential Information Notice DataMirror software products contain valuable trade secrets and proprietary information and are protected internationally, including without limitation, by Canadian, United States and international copyright, trademark, and other intellectual property laws and treaties. DataMirror Corporations use of certain copyrights and trademarks in this manual is authorized by license from their respective owners and licensors. Unauthorized use of this manual or DataMirror software products is strictly prohibited and may result in civil damages and criminal prosecution. See the applicable DataMirror Software License Agreement or Software License and Maintenance Agreement for additional information. Disclaimers DataMirror reserves the right to revise this manual and make periodic changes to its content without obligation on DataMirror Corporations part to notify any person of such revisions or changes. DataMirror does not assume responsibility for the use of this manual. DataMirror makes no representation or warranty as to the accuracy of the contents of this manual. All statements made and information provided in this manual is provided on an errors and omission excepted (E. & O.E.) basis only.
Documentation Conventions
You should note the following conventions that are used throughout DataMirror documentation: Italics represent document, file, and directory names. Identifies points to remember, limitations, dependencies, and other items of information that are worth noting. Identifies hints, tips, shortcuts, and other techniques that allow you to work with the product in a more efficient or effective manner. Identifies warnings, cautions, and other items of information that must be followed to avoid adverse conditions. Indicates a jump or detour in the sequence of steps based on a particular selection.
Printing DataMirror Documentation

Introduction DataMirror Corporation distributes user documentation on CD-ROM in PDF and HTML Help formats. You can print all or selected topics of a publication using the procedures below. PDF The PDF format requires Adobe Acrobat Reader. You can download the latest version of the Adobe Acrobat Reader from Adobes web site. 1. Open a PDF file from the booklist.htm file. This file is located in the docs folder on your DataMirror CD-ROM. 2. Click Print on the toolbar. The Print dialog box is displayed. 3. 4. Select the print range that you want. Click OK to start printing.
HTML Help The HTML Help format requires Microsoft Internet Explorer (Version 4.0 or greater). It also requires Windows 95 or greater, or Windows NT (Version 4.0 or greater). 1. Open an HTML Help file from the booklist.htm file. This file is located in the docs folder on your DataMirror CD-ROM. 2. 3. 4. Click the Contents tab. From the table of contents, select the item that you want to print. Right-click and select Print from the shortcut menu. A dialog box that provides a set of print options is displayed. 5. Select a print option that meets your requirements and click OK. The Print dialog box is displayed. 6. 7. Select the print range that you want. Click OK to start printing.
10
Chapter 1 - Introduction
Guide Organization
This guide provides information on how to use the iCluster command interface to implement high availability. It is organized as follows: Chapter 1 Introduction Contains introductory information about the product, hardware/software requirements, authorization codes, and how you can contact DataMirror Technical Support. Chapter 2 Working with iCluster Introduces iCluster concepts and describes how to access the iCluster commands and menus. Chapter 3 Administering iCluster Provides information about configuring and managing iCluster. Chapter 4 Replicating Objects Describes information about replicating objects with iCluster. Chapter 5 iCluster Commands Contains detailed information about each command that iCluster supports. Descriptions of each command parameter are provided. Chapter 6 The Status Monitor Contains detailed information about the different features, commands, and displays provided with the Status Monitor. Appendix A Object Types Replicated by iCluster Contains a complete list of all the types of objects that iCluster can replicate.
11
Appendix B
Important Considerations Contains important information about replicating certain object types, mirroring physical files, journaling, synchronization, commitment control, and other issues.
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. See the iCluster Switchover Guide for your failover mechanism for more information on how to prepare for a switchover or failover. See Failover Mechanisms for more information on the available failover mechanisms. 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 for more information on iCluster.
New Features in iCluster

This topic introduces new features in this iCluster release. For more information about new features in this release, see iCluster Release Notes.
Optimization for Database Apply Updates

You can increase the apply performance in situations with large files that are significantly larger than the shared memory pool. See the OPTIMZAPY parameter in the DMADDGRP command for more information.
WebSphere MQ Support
This release of iCluster supports V6R0 of WebSphere MQ in addition to version V5R3 and V5R2.
12
Backup Monitor and Object Status Monitor

Through the new Backup Monitor in the iCluster Administrator, you can monitor the following information for each group in a single window: Latency and status information, including monitoring switchover progress. Suspended objects Out-of-sync objects Overall transactions per hour Time of the last status change
You can use this information to activate or suspend objects, and assure synchronization between the primary and backup systems. The iCluster Administrators Object Status Monitor displays status information for out-of-sync and suspended objects for each group on the backup node. From the Object Status Monitor you can activate or suspend objects. See the iCluster Administrator User Manual for more information.
New Commands
This release of iCluster includes the following new commands: DMLOGENT: This new command allows you 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 during batch runs or troubleshooting. See DMLOGENT for more information. DMGENEXC: This new command allows you to generate an exception whenever an iCluster command fails or results in no action. This command allows you to remain aware of errors in your switchover user exits. See DMGENEXC for more information. DMSYSINF: Use this command to conveniently display the following iCluster system information: node names, system names, node IP addresses, iCluster version, operating system version, system times. This command will also tell you if you are using Cluster Resource Services. See DMSYSINF for more information.
New Performance System Values

The new PERFORM category of system values controls 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. In certain cases, separate communications channels result in better network utilization. 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.
See DMSETSVAL for more information.
Remote Journaling
iCluster now automatically activates the remote journal (if it is not already activated) using the default value for the DELIVERY parameter in the CHGRMTJRN command.
13
See the JRNLOC parameter in the DMADDGRP command or Configuring Remote Journaling for more information.
CHKJRN Parameter and DMMRKPOS Processing

As of this release, the CHKJRN parameter in the DMADDGRP command now includes processing equivalent to the DMMRKPOS command during a role switch.
iCluster Documentation
Consult the following publications for information about installing and using iCluster: iCluster - iSeries Installation/Upgrade Guide: Describes how to install iCluster on an iSeries node. iCluster - Administrator User Manual: Describes how to install and use the iCluster Administrator and Event Viewer components on a Windows client workstation. iCluster - Switchover Guide: Describes how to perform a switchover among nodes on a cluster, and how to prepare for and recover from node failure. iCluster for EMC Symmetrix - Administration Guide: Describes how to combine the iCluster real-time high availability solution for iSeries systems with EMC Symmetrix's high performance storage system and business continuance solutions.
iCluster - Release Notes: Describes product changes and enhancements for this release. You can retrieve iCluster product documentation from the DataMirror web site (http://www.datamirror.com). A password issued by DataMirror is required to access the download page. Documentation is also provided on your iCluster CD-ROM. This guide also refers to various iSeries concepts, commands, and terminology. For more information about these topics, see the iSeries Information Center at http://www.ibm.com/eserver/iseries/infocenter.
Troubleshooting
Technical publications contain information about installing and using the product. Troubleshooting and diagnostic information is provided in the DataMirror Knowledge Base that you can access from the DataMirror web site (http://www.datamirror.com). Articles in the knowledge base are categorized by product, but you can also search for information using keywords and other attributes. The knowledge base also contains articles translated into different languages. You must complete a registration process before accessing the knowledge base.
Online Information and Technical Support

iCluster is a fully supported product. If you encounter problems using iCluster, follow the procedure outlined below: 1. 2. 3. 4. Consult the relevant sections of this guide, or consult the DataMirror knowledge base at http://www.datamirror.com. Consult your system or product event logs for messages that may contain relevant information for your problem. Attempt to re-create the problem. Document the steps used to do so. If the problem persists, record the full details of the clustered environment by issuing the DMSYSINF command from the command line or select option 7 in the iCluster Main Menu. This command allows you to view or print system information. You should also record any relevant messages found in the event log. 5. Contact DataMirror Technical Support. See the DataMirror web site at http://www.datamirror.com for technical support e-mail addresses and telephone numbers.
You can also access updates and platform compatibility information from the DataMirror web site.
If an issue you have raised with DataMirror Technical Support should be handled by IBM, you will be directed to an IBM representative in your region for assistance. If an issue you have raised with IBM should be handled by DataMirror Corporation, you will be directed to DataMirror Technical Support for assistance.
Training and Education

For hands-on training, DataMirror offers public education courses regularly at education centers in different parts of the world. During the training, participants will learn from experienced trainers the basic building blocks in implementing DataMirror technology and will be given the opportunity to test drive the technology in guided lab exercises. You can find course outlines and schedules on the DataMirror web site (http://www.datamirror.com/education). For more information, send email to education@datamirror.com.
Authorization Codes and Licensing

iCluster requires a valid authorization code to ensure that the application 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. You can obtain authorization codes from either 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.
Contacting DataMirror
DataMirror invites your suggestions on how to enhance iCluster and this commands guide. Send your suggestions or comments by contacting us at: Customer Comments DataMirror Corporation 3100 Steeles Avenue East, Suite 1100 Markham, Ontario, Canada L3R 8T3 Telephone: Facsimile: Email: 1-905-415-0310 1-905-415-0340 docs@datamirror.com
15
Chapter 2 - Working with iCluster

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
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 1 shows a cluster with four nodes. The lines indicate network connections between nodes.
16
Figure 1 A Four Node Cluster
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. Action 1. 2. 3. 4. 5. 6. TORONTO joins cluster NEWYORK joins cluster DALLAS joins cluster TORONTO leaves cluster TORONTO rejoins cluster NEWYORK fails Nodes in Cluster TORONTO TORONTO NEWYORK TORONTO NEWYORK DALLAS NEWYORK DALLAS NEWYORK DALLAS TORONTO DALLAS TORONTO Master Node TORONTO TORONTO TORONTO NEWYORK NEWYORK 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 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 object replication. MQSeries groups, which provide a high availability solution for WebSphere MQ. Application groups, which support application resiliency on clusters using IBM Cluster Resources. See Application Resiliency for more information. Switchable device groups, which use IBM Cluster Resources to support switchable disks.
17
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.
The replication process copies data and applications from the primary node to the backup node. For example, in the cluster in Figure 1, 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.
Figure 2 A Replication Group 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, 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 3 shows the sample cluster with its groups. The arrows indicate the groups and the group names appear in italics.
Figure 3 All Groups in the Cluster The figure shows the following groups:
18
TNGRP: Replicates from the TORONTO (primary) node to the NEWYORK (backup) node. DTGRP: Replicates from the DALLAS node to the TORONTO node.
TSGRP: Replicates from the TORONTO node to the SANJOSE node. NSGRP: Replicates from the NEWYORK node to the SANJOSE node.
This example also illustrates that the same node can serve multiple roles in the same cluster. In the example: 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).
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 4 shows these objects and the groups they are specified for.
Figure 4 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.
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 iCluster - Switchover Guide for SwitchOver System 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 iCluster - Switchover Guide for IBM Cluster Resource Services contains more information about this failover mechanism. See Failovers and Switchovers for more information about how each failover mechanism handles planned and unplanned outages. See Failover Mechanisms 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 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. 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). iCluster failover and switchover handling is not supported for local loopback groups, groups that have a target library other than *PRIMARY, and groups that have an object specifier selected whose target library is not *GRPSEL. 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 5 Initial Group Replicates from TORONTO to NEWYORK

Figure 6 NEWYORK Becomes the Primary Node after TORONTO Fails
Figure 7 After Repairing TORONTO, it Becomes NEWYORKs Backup Node
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 5). If TORONTO fails, then NEWYORK becomes the primary node in the group. Clients now connect to NEWYORK (Figure 6). After correcting the problem, TORONTO is available again and, by default, will be the groups backup node for replication (Figure 7).
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.
21
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 5).
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 6) 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. 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 6) or can fix the problem on the primary node and restart the group. See the iCluster - Switchover Guide for IBM Cluster Resource Services 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 5). Otherwise, the administrator must either failover control to the backup node (the end result is the same as an automatic failover, see Figure 6) or can fix the problem on the primary node and rejoin the group. See the iCluster - Switchover Guide for IBM Cluster Resource Services 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 5), 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 7). Depending on your failover mechanism, the failover and switchover options available to you will differ. See Failover Mechanisms for more information.
22
Object Specifiers and Types

In Working in a Clustered Environment, 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 Figure 4. An object specifier consists of the following elements: Object name Generic and special values for the object name can be specified to reference multiple objects. Library name The name of the library where this object is stored. Object type A special value for the object type can be specified to reference all object types that can be replicated by iCluster. Object attribute This element of the object specifier only applies to *FILE objects. 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.
Constructing Object Specifiers

For example, assume that the following set of objects exist on an 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 Type of 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
23
Table 1 Sample Objects on iSeries Node Table 2 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 2 to identify the addressed objects). OBJECT SPECIFIER Addressed Objects (see # in Table 1) Object Attribute PFDTA PF Not applicable 12 5, 6 No objects are addressed 2, 3 2 No objects are addressed 11 1, 11 5, 6 5, 6, 7 9, 10 8
Object SRCLG M* M3909
Library OLG TEST TEST
Object Type *FILE *FILE *PNLGRP
HLPA* HLPAT* HLPAT
HP1 HP1 HP1
*PNLGRP *PNLGRP *PNLGRP
Not applicable Not applicable Not applicable
*ALL *ALL M3* *ALL S1 H*
LIB1 LIB1 TEST TEST COM SLIB
*JOBD *ALL *ALL *ALL *ALL *PGM
Not applicable Not applicable Not applicable Not applicable Not applicable Not applicable
Table 2 List of Objects Addressed by Example Specifiers 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.
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 Byte Stream File (BSF) Objects 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.
24
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.
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. 2. 3. Exact specifiers (non-generic) have the highest precedence. INCLUDE and EXCLUDE specifiers have the same precedence when they are exact specifiers. Generic EXCLUDE specifiers have the next highest precedence. Generic INCLUDE specifiers have the lowest precedence.
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 the DMSELOBJ 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 Byte Stream File (BSF) Objects for more information.
25
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. 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. 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. See the DMADDBSF command for more information on non-journaled BSF support or Byte Stream File (BSF) Objects for more information on BSF objects. 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 the DMADDBSF command for more information on journaled BSF support or Byte Stream File (BSF) Objects for more information on BSF objects.
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. See the iCluster iSeries Installation Guide for more information. Procedure 1. Issue the following command on an OS/400 command line: > CHGCURLIB <iCluster product library> 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.
26
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.
iCluster Quick Start

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 for the complete list of commands and the individual command topics 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: Placeholder <lib> Description 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.
<port>
<primary>
<backup>
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 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) 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>) 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>) Add a replication group between the primary and backup nodes. > DMADDGRP GROUP(MYGROUP) GRPTYPE(*REPL) PRIMNODE(<primary>) BACKUPS(<backup>) 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) Start the replication group. This mirrors the data area to the backup node.
27
2.
3.
4.
5. 6.
7.
> 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 Starting iCluster from the Command Line DMADDNODE DMADDGRP DMSELOBJ DMSTRGRP
See the iSeries Information Center at http://www.ibm.com/eserver/iseries/infocenter for more information on the other commands in this tutorial.
28
Chapter 3 - Administering iCluster

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 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:
29
DMADDUSR
DMCHGUSR
DMRMVUSR
DMWRKUSR
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 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 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
30
Failover Mechanisms
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, 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 the IBM iSeries documentation for more information on Cluster Resource Services. This topic offers criteria for choosing a failover mechanism and provides instructions for changing to a different system.
Choosing a Switchover System

The following table lists key differences between the failover mechanisms. You can use it to determine which system meets the needs of your environment. Switchover System (SOS) Supports consecutive and non-adjacent 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. Handles communication failures through a single *FAILED state. This simplifies recovery from failures. Does not support resilient applications nor takeover IP addresses. Does not support switchable disk storage devices on the primary and backup nodes. IBM Cluster Resource Services (IBM CRS) 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. Uses *FAILED and *PARTITION states to handle communication failures. Supports resilient applications, including the ability to takeover IP addresses. Supports switchable disk storage devices.
Both SOS and IBM CRS support calling user exit programs before and after switchover operations.
We recommend 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

New iCluster installations use SOS by default.
To change an existing cluster to use SOS, you must perform the following tasks: 1. 2. 3. 4. 5. 6. On the Work with Cluster Nodes (DMWRKNODE) screen, ensure all nodes have a status of *ACTIVE. On the Work with iCluster Groups (DMWRKGRP) screen, ensure all groups have a replication status of *INACTIVE. On the iCluster System Values (DMSETSVAL) screen, change the Use OS/400 Cluster Services parameter to *NO and press Enter to save the change. Change the default switchover settings for each node using the DMCHGNODE command to ensure they meet your recovery needs. On the Work with Cluster Nodes (DMWRKNODE) screen, restart all of the nodes in the cluster. On the Work with iCluster Groups (DMWRKGRP) screen, restart all of the groups.
Your replication environment will now run with its previous configuration and SOS. After performing these tasks, you will no longer be able to use DMSETPRIM to perform a switchover. Instead, use the DMCHGROLE command.
Configuring iCluster to use IBM Cluster Resource Services

After installing iCluster for the first time on a computer, run DMSETSVAL 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. 2. 3. 4. 5. 6. Record the configuration of your current clustering environment including nodes, groups, and object specifiers. You will need this information when you recreate the cluster. Delete the current cluster by running DMDLTCLSTR on every node in the cluster. On the iCluster System Values (DMSETSVAL) screen, change the Use OS/400 Cluster Services parameter to *YES and press Enter to save the change. Delete residual cluster information by running DMDLTCLSTR on every node in the cluster, again. Repeat steps 2 and 3 on every node in the cluster. Add each node back to the cluster using the DMADDNODE command. The first node you add will become the master node. 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. 8. 9. Create the groups that will replicate objects using the DMADDGRP command. Use the information you recorded in Step 1 to help with this step. Specify the objects you want to be in each group using the DMSELOBJ and DMADDBSF commands. Use the information you recorded in Step 1 to help with this step. On the Work with iCluster Groups (DMWRKGRP) screen, restart all of the groups.
Your replication environment will now run using IBM CRS.
Adding and Configuring Nodes

The following information pertains to the configuration and addition of nodes to your clustered environment through iCluster.
32
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 nodes 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 the STRHATCP command 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 logs 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 the DMSETSVAL command for more information.
If you are using the IBM CRS failover mechanism, then nodes must also meet the following requirement: 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 the iSeries documentation for more information.
See Failover Mechanisms for more information.
Adding Nodes
To add a node to a cluster, call the DMADDNODE command. After the command completes, the node will be automatically started in the cluster. See the DMADDNODE command for more information.
Changing Nodes
To change a node that is currently in a cluster, call the DMCHGNODE command. You cannot change a node if it has any active replication groups. See the DMCHGNODE command for more information.
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 the DMSETSVAL command 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 the DMSTRGRP command 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 the DMSTRGRP command. 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 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 (DMADDAPP) and change (DMCHGAPP) a resilient application. Other commands allow you to start (DMSTRAPP) and end (DMENDAPP) 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 using the DMUPDAPP command. 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.
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 iSeries 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.
34
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. 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. 2. 3. Stop mirroring. Create a character data area called HA_DELAY in product library. 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> 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++'
*CHAR(5)
35
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.
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 for more information.
36
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 DMACTOBJ command for native objects and DMACTBSF command for IFS objects. See Activating Objects and Automatic Reactivation, below, 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 DMACTOBJ command for native objects, DMACTBSF 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. 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.
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 DMACTOBJ command for more information about activating objects manually. 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 DMSETSVAL 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 DMACTOBJ command), use the Maximum Refresh Size parameter in the DMSETSVAL command. For all other objects, use the Maximum Reactivation Size parameter in the DMSETSVAL 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 for a complete list of reason codes and their meanings.
Starting Replication and Journal Positions

This topic outlines some of the differences between DMSETPOS - Set Journal Start Position and DMMRKPOS Mark Current Journal Position, 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 DMSETPOS and DMMRKPOS commands: The DMSETPOS 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 DMMRKPOS command does not require you to specify a journal position for all journals in the specified group. DMMRKPOS automatically determines the journal position by using the current sequence number(s) in all relevant journals for the group. DMMRKPOS 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. See DMSETPOS and DMMRKPOS for more information on these commands.
Starting 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 DMSTRGRP and DMSTRREPL for more detailed information on these commands.
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 the STRHASC and STRHASCUSR commands. 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:
38
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 Using Sync Check below 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 below for more information.
Using Sync Check

To use sync check, perform the following tasks: 1. Use the SELSCATTR command to select the file attributes that you want to include in your sync check. 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 STRHASC and STRHASCUSR 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 for more information. 3. Use one of the following commands on the backup node to view the sync check: DSPHASC DMSCRPT DMSCRPTNTV
See Viewing Sync Check for more information on viewing sync checks.
Out-of-Sync (OOS) Count Column

The OOS Count Column (Figure 12) displays the sum of the OS/400 native objects and IFS objects that are out-ofsync for each group. This information is current as of the last sync check. The OOS field is only available on backup monitor screens in a 132-column terminal session. See Reading Status Information for more information on the OOS column in the Status Monitor. Related Topics DSPHASC Display Sync Check SELSCATTR Select Sync Check Attributes STRHASC Start Sync Check STRHASCUSR Start User Sync Check DMSCRPT - Sync Check Report for IFS Objects DMSCRPTNTV Sync Check Report for Native Objects
39
Viewing Sync Check
Viewing Sync Check

The command that you use to view the sync check is determined by the OUTPUT parameter in the STRHASC and STRHASCUSR commands. 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 DSPHASC 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 DMSCRPT command (*BSF sync check type) or DMSCRPTNTV command ( *FILEATTR, *DTAARA, and *LIST sync check types) to view the sync check report in the database file. If your sync check displays out-of-sync objects that are suspended, you can use the DMACTOBJ and DMACTBSF commands to activate and refresh the object(s) to the backup node. See Suspended Objects for general information about suspended objects. Use the PRGHASC command to clear the sync check database files of obsolete records. Related Topics DSPHASC Display Sync Check SELSCATTR Select Sync Check Attributes STRHASC Start Sync Check STRHASCUSR Start User Sync Check DMSCRPT - Sync Check Report for IFS Objects DMSCRPTNTV Sync Check Report for Native Objects Monitoring Out-of-Sync Objects
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 DMSETSVAL command:
40
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 journals receive process and the last entry applied by the journals 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 DMDSPLOG command for more information on how to display the OMI0308 latency message in the event log.
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 25).
Figure 25 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 25 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 DMSETSVAL 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 *. 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.
41
The third group, denoted by [3], has exceeded one of the latency threshold values set in the DMSETSVAL 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 for more information about using the Real Time Overall Latency screen in the Status Monitor.
Restarting iCluster After Restarting a Node

See the iSeries Information Center at http://www.ibm.com/eserver/iseries/infocenter 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. 2. Initialize TCP/IP processing by running the STRTCP command. Start the TCP/IP server by running the STRTCPSVR command. You must minimally start the *INETD server. For example: > STRTCPSVR SERVER(*INETD) Start the XDMCLUSTER subsystem by running the STRSBS command. For example: > STRSBS SBSD(XDMCLUSTER) Start the TCP/IP listener job on the local node by running the STRHATCP command. Rejoin the node by running the DMREJOIN command.
3. 4. 5.
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. See the iSeries Information Center at http://www.ibm.com/eserver/iseries/infocenter 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 clusters version has a limit of the minimum potential node version of the nodes in the cluster. For example, consider the following cluster: Node OS/400 Version Potential Node Version 2 2 3
ALPHA BRAVO CHARLIE
V5R2 V5R2 V5R3
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. DataMirror recommends upgrading your cluster to its highest possible version. This reduces the likelihood of versioning problems after future node upgrades.
42
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. 2. 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. 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.
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. 2. 3. 4. Stop all groups that use the node by running the DMENDGRP command. Change the node's IP address using the DMCHGNODE command. The node you are changing must be active when you run this command. End the node by running the DMENDNODE command. 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. 6. Start the node using the DMSTRNODE command. Start all groups that use the node using the DMSTRGRP 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. 2. 3. 4. 5. 6. 7. Ensure at least one other node in the cluster is active. The active node cannot be the node whose IP address you are changing. End all groups that use the node whose IP address you are changing by running the DMENDGRP command. End the node by running the DMENDNODE command. Change the node's IP address by configuring your network. See your operating system documentation for more information on this step. Change the node's IP address in iCluster using the DMCHGNODE command on an active node. Start the node whose IP address you changed by running the DMSTRNODE command. Start all groups that use the node using the DMSTRGRP command.
The cluster will now use the new IP address to connect to the node.
43
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. 2. 3. 4. Open the Work with Nodes screen by running DMWRKNODE from the command line. Alternatively, you can select 1 on the commands menu. 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. Enter option 6 next to the node you want to remove from the cluster. See DMRMVNODE for additional considerations before you remove the node. Press the Enter key to confirm the operation.
After performing these steps, the node will be removed from the cluster.
Journaling in iCluster
This topic explores some of the differences between traditional local journaling and remote journaling in iCluster.
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 27 gives you a more detailed view of the local journaling process in iCluster.
44
Figure 27 - 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 BSFs with non-journaled BSF support. See Path Object Specifiers 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. The default data update method for remote journaling is asynchronous mode. See Configuring Remote Journaling for more information on how to set the delivery modes for remote journaling. Figure 28 gives you a more detailed view of the remote journaling process in iCluster.
45
Figure 28 - Remote Journaling 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 for more information.
Related Topics For more information on remote journaling, see the following topics: Remote Journaling Configuring Remote Journaling Role Switching with Remote Journals
You can also visit the iSeries Information Center at http://www.ibm.com/eserver/iseries/infocenter for more information on remote journaling.
46
Remote Journaling
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. This section includes the following topics: Configuring Remote Journaling Role Switching with Remote Journals
See Journaling in iCluster for a comparison of local journaling and remote journaling. See the iSeries 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 iSeries 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) 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) 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) 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.
3.
4.
5.
47
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. 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 iSeries CHGRMTJRN documentation for more information about this command and setting. 7. On any node, add your group or application by running the DMADDGRP or DMADDAPP command, respectively. Alternatively, you can use the DMCHGGRP or DMCHGAPP 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. 2. TORONTO must deactivate its remote journal on NEWYORK. NEWYORK must activate its remote journal on TORONTO.
48
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 DMCHGGRP 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.
To change this property globally for all groups, set the journal images attribute of the PF property to *BOTH by running the DMSETSVAL 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 DMCHGGRP command.
49
Chapter 4 - Replicating Objects

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 DMADDNODE and DMCHGNODE 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.
50
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 DMSETPOS 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 DMSTRAPY 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 LOB Support for more information about the LOB staging store.
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.
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.
51
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.
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 Byte Stream File (BSF) Objects 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.
52
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.
Replicating Byte Stream File (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 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 the DMADDBSF or DMCHGBSF commands 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. Contentlevel 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 the DMADDBSF command 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 (*CLUSTER) 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 for more information. The number of objects (BSF and/or native) that may be journaled to a particular journal is limited. See the IBM iSeries 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.
53
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 the DMMRKPOS command 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.
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 the DMMRKPOS command. After journaling has been started, most changes to that object can be mirrored without accessing the object on the primary node. 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 DSPHABRCD - Display 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. See Working with the Status Monitor for more information.
iCluster Limitations for BSF Objects

iCluster currently does not provide support in the following areas:
54
Symbolic links and hard links are not supported.

Replication must be to the same directory on the backup node. iCluster does not support directory redirection of BSF objects. All BSF objects replicated within a group must be journaled to the same journal if they are journaled. 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 DMSETSVAL - Set Cluster System Values 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: Connection lists (*CNNL) 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 DMSETSVAL and DMADDNODE commands 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 CRTCFGOBJ - Create Configuration Object 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 DMSETSVAL, DMADDNODE, and DMCHGNODE 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.
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.
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. 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 6 identifies and briefly describes each code segment. 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
57
SAVE_IFS
SAVFEXIT01
SAVFEXIT02
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. SAVFEXIT03 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. Table 6 - Sample CL Programs 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. 3. Create a save file that the objects will be saved to (use the OS/400iSeries command CRTSAVF). 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 6) 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. 6. 7. 8. 9. Define the backup node that will be destination of the save files. Create a replication group that includes the backup node defined in the previous step. Create an object specifier that references the save files and select the specifier to the replication group created in the previous step. 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. Call the CL program (for example, SAVE_DLO or SAVE_IFS - see Table 6) 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 command 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 DMADDBSF 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/*')
58
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/*') 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) Repeat step 2 for any other folders you do not want to replicate from the QDLS file system.
2.
3.
When you start the replication group, it will mirror all of the QDLS file system folders, except the ones you specified in steps 2 and 3. The replication process will create the folders you excluded on the backup node, but these folders will be empty.
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 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 STRHASC and STRHASCUSR 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. 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.
59
iCluster provides the DMDSPLOG command that displays the messages that have been placed in the event log. You can use the DMCLRLOG command to remove specific categories of messages from the event log.
60
Chapter 5 - iCluster Commands

iCluster Commands
This chapter provides full descriptions of each command that is supported by iCluster. For each command that is described, the following items of information are provided: Command: Identifies the name of the command and lists the command parameters. Description: Briefly explains what the command does when it is invoked. 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. Related Topics: Identifies other commands that may be related in some way to the current command. 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. There are a number of different command categories. These categories and the commands that belong to each one are as follows:
Node Commands
DMADDNODE Add Node DMDSPNODE Display Node DMCHGNODE Change Node DMRMVNODE Remove Node
61
DMWRKNODE Work with Nodes
Group Commands
DMADDGRP Add Group DMDSPGRP Display Group DMCHGGRP Change Group DMRMVGRP Remove Group DMADDBACK Add Backup Node to Recovery Domain DMRMVBACK Remove Backup Node from Recovery Domain DMWRKGRP Work with Groups
Native OS/400 Object Commands

DMSELOBJ Select Objects to Group DMDSELOBJ De-select Objects from Group DMCHGOBJSL Change Object Selection to Group DMWRKOBJ Work with Object Specifiers
Byte Stream File (BSF) Commands

DMADDBSF Add Path Object Specifier to Group DMRMVBSF Remove Path Object Specifier from Group DMCHGBSF Change Path Object Specifier DMWRKBSF Work with Path Object Specifiers DMSNDOBJ Send Object Immediately
Switchable Device Commands

DMADDSWDEV Add Switchable Device Entry to Group DMDSPASPGP Display Switchable Device Group DMCHGSWDEV Change Switchable Device for Group DMRMSWDEV Remove Switchable Device Entry from Group
62
Resilient Application Commands

DMADDAPP Add Resilient Application DMDSPAPPGP Display Resilient Application Group DMUPDAPP Update Resilient Application DMCHGAPP Change Resilient Application DMRMVAPP Remove Resilient Application DMADDBACK Add Backup Node to Recovery Domain DMRMVBACK Remove Backup Node from Recovery Domain DMWRKAPP Work with Resilient Applications
WebSphere MQ Command
RBDHAMQM Rebuild iCluster MQSeries
Administration Commands
DMSETSVAL Set Cluster System Values DMCHGTIME Change System Date and Time DMDSPLOG Display Cluster Event Log DMCLRLOG Clear Cluster Event Log HAPNGTCP Ping Using TCP JRNHADADQ Journal Data Areas and Data Queues STRHATCP Start TCP/IP Listener WRKHAJOB Work with Active Cluster Jobs DMSTRDM Start Definition Manager DMDLTCLSTR Delete Cluster
Cluster Operation Commands

DMSTRNODE Start Cluster Operations at Node DMENDNODE End Cluster Operations at Node DMSTRGRP Start Cluster Operations for Group DMSTRREPL Start Replication
DMENDGRP End Cluster Operations for Group DMSTRSWO Switchover Group DMREJOIN - iCluster Rejoin Cluster DMSTRAPP Start Cluster Operations for Resilient Application DMENDAPP End Cluster Operations for Resilient Application DMSWOAPP Switchover Resilient Application DMSETPRIM Prepare Primary Node DMCHGROLE Change Group Primary Node
Replication Operation Commands

DMSETPOS Set Journal Start Position DMMRKPOS Mark Current Journal Positions CHGHAJRN Change Journal Receiver DSPHAPOS Display Journal Information RTVHAPOS Retrieve Journal Information VFYHAJRN Verify Audit Journal STRHABRCD Start BSF Recording DSPHABRCD Display Recording for BSF Object ENDHABRCD End Recording for BSF Object DMSTRAPY Start Replication Apply Processes DMENDAPY End Replication Apply Processes DMACTOBJ Activate Object DMACTBSF Activate BSF Object DMSUSOBJ Suspend Object DMSUSBSF Suspend BSF Object DMSNDOBJ Send Object Immediately DMSETSYNC Set Sync Point CRTCFGOBJ Create Configuration Object
64
INITHAOBJ Initialize Objects RTVRCVPT - Retrieve Recovery Checkpoint RTVRCVPTR - Retrieve Recovery Checkpoint (CL Program) SYNCHATRG Synchronize Triggers
Status and History Monitor Commands

DSPHASMON Display Source Monitor WRKHASMON Work with Status Monitor on Primary Node WRKHATMON Work with Status Monitor on Backup Node CHGHASMON Change History Monitor on Primary Node PRGHASMON Purge History Monitor on Primary Node WRKHAOBJST Work with Object Status WRKHABSFST Work with BSF Status DMWRKOBJST - Work with Object Status by Group
Sync Check Commands

DSPHASC Display Sync Check SELSCATTR Select Sync Check Attributes STRHASC Start Sync Check STRHASCUSR Start User Sync Check DMSCRPT - Sync Check Report for IFS Objects DMSCRPTNTV - Sync Check Report for Native Objects PRGHASC - Purge Sync Check Results
Registered iCluster User Commands

DMADDUSR Add User DMCHGUSR Change User DMRMVUSR Remove User DMWRKUSR Work with Users
65
Exit Program Commands

ADDPFEXPGM Add Exit Program RMVPFEXPGM Remove Exit Program
iCluster for Supported External Storage Systems

DMRBDNODE Rebuild Node DMREGPOS Register Positions
Other Commands
SETHAREG Restore Communications Registries
Node Commands
DMADDNODE Add Node
Command 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 DMENDNODE 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 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 Cluster Configuration. 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. You should consult the iCluster iSeries Installation Guide for important prerequisite 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).
Description
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 the iCluster iSeries Installation Guide. 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: *CLUSTER Refers to the cluster system value for this parameter that is specified through the DMSETSVAL 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: *CLUSTER Refers to the cluster system value for this parameter you specify through the DMSETSVAL command.
67
*PRIMARY Sets the user profile status to the same status that is currently assigned to the corresponding user profile on the primary node. *DISABLED Sets all user profiles to a status of *DISABLED. *NOCHG Does not change the current status of each user profile 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 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: *CLUSTER Refers to the cluster system value for this parameter that is specified through the DMSETSVAL command. *YES Holds commands to create configuration objects in specific physical files so that they can be created at a later time with the CRTCFGOBJ command. *NO Automatically 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. 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 in iCluster. STGSTORLIB The library where the staging store is located. SWITCHRES
68
Indicates whether you will be using switchable resources on the current node. Enter one of the following values: *YES Enables 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. *NO Does 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: *YES Test the primary IP address for communication failures. *NO Do 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: *YES Test the alternate IP address for communication failures. *NO Do 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 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
69
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. 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. 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. 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.
71
Minimum Security Level Menu Access
Administrator (*ADMIN)
F22 (Shift+F10) Option 1 Work With Nodes screen Option F6
Related Topics DMCHGNODE Change Node DMRMVNODE Remove Node DMDSPNODE Display Node DMWRKNODE Work with Nodes DMSTRNODE Start Cluster Operations at Node DMENDNODE End Cluster Operations at Node
DMDSPNODE Display Node

Command Description Input Parameter DMDSPNODE NODE( ) Use this command to display the current settings for the specified node. NODE The name of the node that you want to examine. Example DMDSPNODE NODE(NODE1) Displays the current settings for the node NODE1. Use Minimum Security Level Menu Access You can issue this command on an active node in the cluster. User (*USER)
F22 (Shift+F10) Option 4 Work With Nodes screen Option 5
Related Topics DMADDNODE Add Node DMCHGNODE Change Node DMRMVNODE Remove Node DMWRKNODE Work with Nodes DMSTRNODE Start Cluster Operations at Node DMENDNODE End Cluster Operations at Node
DMCHGNODE Change Node

Command 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 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: *SAME Uses the current setting for this parameter. The default setting for this parameter is *SAME. IPADDR2 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: *SAME Uses the current setting for this parameter.
Description
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: *SAME Uses 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: *SAME Uses the current setting for this parameter. *CLUSTER Refers 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: *SAME Uses the current setting for this parameter. *PRIMARY Sets the user profile status to the same status that is currently assigned to the corresponding user profile on the primary node. *DISABLED Sets all user profiles to a status of *DISABLED. *NOCHG Indicates that the current status of each user profile will not be changed by iCluster. *CLUSTER Refers 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.
74
Specify one of the following values: *SAME Uses the current setting for this parameter. *YES Holds commands to create configuration objects in specific physical files so that they can be created at a later time with the CRTCFGOBJ command. *NO Automatically creates configuration objects as soon as they are received on the node you are changing in the cluster. *CLUSTER Refers 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. 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: *SAME Uses the current setting for this parameter. The default setting for this parameter is *SAME. For more information about staging stores, see Staging in iCluster. Unlike the DMADDNODE 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 DMRMVNODE - Remove Node and DMADDNODE Add Node for more information. SWITCHRES Indicates whether you will be using switchable resources on the node. Enter one of the following values: *SAME Keeps the present setting for this parameter. This is the default
value. *YES Enables 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. *NO Does 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: *SAME Keeps the present setting for this parameter. This is the default value. *FAILED Use 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. See the iCluster - Switchover Guide for more information. 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: *SAME Use the current setting for this parameter. *YES Test the primary IP address for communication failures. *NO Do 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: *SAME Use the current setting for this parameter. *YES Test the alternate IP address for communication failures. *NO Do 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: *SAME Use the current settings for this parameter. LIBRARY/NAME The name and library of the message queue. *NONE Do 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 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: *SAME Use the current settings for this parameter. LIBRARY/NAME The name and library of the message queue. *NONE Do 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.
77
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. 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 On-line Information and Technical Support 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: *SAME Uses the current setting for this parameter. The default setting for this parameter is *SAME.
Examples
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. 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.
78
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. Administrator (*ADMIN)
Related Topics DMADDNODE Add Node DMRMVNODE Remove Node DMDSPNODE Display Node DMWRKNODE Work with Nodes DMSTRNODE Start Cluster Operations at Node DMENDNODE End Cluster Operations at Node
DMRMVNODE Remove Node

Command Description 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 DMDLTCLSTR 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 DMRMVGRP Remove Group and DMRMVAPP Remove Resilient Application for more information. End cluster operations at the node before removing it. See DMENDNODE End 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 DMDLTCLSTR command at that node. 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 DMDLTCLSTR command on the specified node only before attempting to re-add it to the cluster. Minimum Security Level Menu Access Administrator (*ADMIN)
Input Parameter
Related Topics DMADDNODE Add Node DMCHGNODE Change Node DMDSPNODE Display Node DMWRKNODE Work with Nodes DMSTRNODE Start Cluster Operations at Node
DMENDNODE End Cluster Operations at Node DMDLTCLSTR Delete Cluster
DMWRKNODE - Work with Nodes

Command Description 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: *ACTIVE Indicates that cluster operations are running on the node. *ACT_PEND Indicates that cluster operations are in the process of being started on the node. *INACTIVE Indicates that cluster operations are not running on the node. *INACT_PND Indicates that cluster operations are in the process of being stopped on the node. *NEW Indicates that the node has been defined in the cluster, but cluster operations have not been started on the node. *RMV_PEND Indicates that the node is in the process of being removed from the cluster. *FAILED Indicates that a system failure has occurred on the node. *PARTITION Indicates 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 DMWRKGRP Work with Groups for more information about group states. The iCluster Switchover Guide contains important information about system failures on nodes within your cluster configuration. *IN_ERROR Indicates that an internal iCluster error may have occurred. If this status persists, contact DataMirror Technical Support. See On-line Information and Technical Support for more information. *UNKNOWN Indicates 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. You should consult the iCluster iSeries Installation Guide for important prerequisite 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:
*NONE Lists all nodes defined in iCluster. *GROUP Lists the nodes that are included in the recovery domain for the group specified through the GROUP parameter (see below). *APPL Lists 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 Minimum Security Level Menu Access You must issue this command on an active node in the cluster. User (*USER)
Main Menu Option 1 F22 (Shift+F10) Option 5
Related Topics DMADDNODE Add Node DMCHGNODE Change Node DMRMVNODE Remove Node DMDSPNODE Display Node DMSTRNODE Start Cluster Operations at Node DMENDNODE End Cluster Operations at Node
82
Group Commands
DMADDGRP Add Group
Command DMADDGRP GROUP( ) GRPTYPE( ) DMNSRC( ) PRIMNODE( ) PRIMIASP( ) BACKUPS( ) BACKIASP( ) TGTLIB( ) MQVERSION( ) QMNAME( ) MSGQUEUE( ) ROLESWITCH( ) CHKJRN( ) BSWUSREXIT( ) ASWUSREXIT( ) EXITDATA( ) POLLINT( ) SAVACT( ) MAXSPLWAIT( ) SPLACTWAIT( ) DFTDBJRN( ) JRNLOC( ) CMTLVL( ) JRNBA( ) OPTIMZAPY( ) DFTBSFJRN( ) RCVRYEXP( ) JRNKEY( ) SWDEV( ) ONLINE( ) DESC( ) Use this command to add a group consisting of one primary node and possibly one backup node. After creating a group, use the DMSELOBJ and/or DMADDBSF 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 be 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: *REPL - Indicates that you want to create a group for continuous object replication between the primary and backup nodes. *RFSH Indicates that you want to create a refresh-only group. *SWDEV - Indicates that you want to create a group for the switchable disk storage devices on the primary and backup nodes. *MQSERIES Indicates that you want to create a WebSphere MQ group for object replication between the primary and backup nodes. 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: *LIST Indicates 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.
Description
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 DMADDNODE 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 DMADDNODE 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: *SYSBAS Indicates 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 DMADDNODE 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: *SYSBAS Indicates 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: *PRIMARY Sets 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 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
84
value *PRIMARY in this situation. *PRIMARY is the default setting for this parameter. Switchovers and role changes are not supported for groups that use a target library other than *PRIMARY. Consequently, because a nonprimary 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. 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 DMADDGRP command to define a group for each of them. Enter specific names. Do not use *DFT or generic names. 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: *NONE Indicates 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: *YES Automatically 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. *NO Does 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 groups 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. 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 the iCluster Switchover Guide. 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 groups CHKJRN parameter, iCluster may perform processing that is equivalent to the DMMRKPOS command when a role switch occurs. If the value of the group's CHKJRN parameter is *NO, iCluster does not perform DMMRKPOS 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 DMMRKPOS processing regardless of the CHKJRN parameter's value. The DMMRKPOS 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 DMMRKPOS 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: *YES Specifies 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.
*NO Specifies 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: *NONE Indicates 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). For more information about the arguments that can be passed to the user exit program, see Passing Arguments to Role Switch User Exit Programs. 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: *NONE Indicates 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 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 nonalphanumeric 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 DMSELOBJ command. Specify a time interval or one of the following values: *CLUSTER Refers to the cluster system value for this parameter that is specified through the DMSETSVAL command. *NONE Specifies 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 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: *YES Allows 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.
88
*NO Does not allow objects that are in use to be saved and updated at the same time. Objects cannot be updated while being saved. *SYNC Allows 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. *CLUSTER Refers to the cluster system value for this parameter that is specified through the DMSETSVAL 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: *CLUSTER Refers to the cluster system value for this parameter that is specified using the DMSETSVAL 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: *CLUSTER Refers to the cluster system value for this parameter that is specified through the DMSETSVAL command. The default setting for this parameter is *CLUSTER.
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 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: *CLUSTER Refers to the cluster system value for this parameter that is specified through the DMSETSVAL 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). 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: *LOCAL - Indicates that the database journal(s) on the primary node are scraped during mirroring. *REMOTE - Indicates 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.
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. Specify one of the following values: *NONE Indicates that the update process on the backup node will not perform commitment control staging.
90
*LEVEL1 Indicates that all updates that comprise a transaction are assembled before being applied on the backup node. *LEVEL2 Indicates 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. *CLUSTER Refers to the cluster system value for this parameter that is specified through the DMSETSVAL 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: *BOTH Indicates that you want to journal both the before and after images. *AFTER Indicates that you want to journal the after image only. *CLUSTER Refers to the cluster system value for this parameter that is specified through the DMSETSVAL 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: *NO Indicates that you do not want optimization for database apply updates. *YES Indicates 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 DMADDBSF command for more information. Specify the name of the BSF journal or one of the following values: *NONE Indicates that you do not require journaling for BSF replication. *CLUSTER - BSF objects selected to this group use the journal specified at the product level. See the DMSETSVAL 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). 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: *DISABLED - Indicates 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 RTVRCVPT or RTVRCVPTR command. This parameter only applies to replication groups. SWDEV The name of a switchable disk storage device that is associated with this group. 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.
92
Specify one of the following values: *YES The 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. *NO The 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. 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. 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.
93
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 groups 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. Administrator (*ADMIN)
Minimum Security Level Menu Access Related Topics
F22 (Shift+F10) Option 6
DMCHGGRP Change Group DMRMVGRP Remove Group DMADDBACK Add Backup Node to Recovery Domain DMRMVBACK Remove Backup Node from Recovery Domain DMDSPGRP Display Group DMWRKGRP Work with Groups
94
DMSTRGRP Start Cluster Operations for Group DMENDGRP End Cluster Operations for Group DMSTRSWO Switchover Group
DMDSPGRP - Display Group

Command Description DMDSPGRP GROUP( ) Use this command to display the current settings for the specified replication group. 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 Minimum Security Level Menu Access You must issue this command on an active node in the cluster. User (*USER)
Input Parameter
F22 (Shift+F10) Option 11 Work With Groups screen Option 5
Related Topics DMADDGRP Add Group DMCHGGRP Change Group DMRMVGRP Remove Group DMADDBACK Add Backup Node to Recovery Domain DMRMVBACK Remove Backup Node from Recovery Domain DMWRKGRP Work with Groups DMSTRGRP Start Cluster Operations for Group DMENDGRP End Cluster Operations for Group DMSTRSWO Switchover Group
DMCHGGRP Change Group

Command DMCHGGRP GROUP( ) GRPTYPE( ) TGTLIB( ) MSGQUEUE( ) ROLESWITCH( ) CHKJRN( ) BSWUSREXIT( ) ASWUSREXIT( ) EXITDATA( ) POLLINT( ) SAVACT( ) MAXSPLWAIT( ) SPLACTWAIT( ) DFTDBJRN( ) JRNLOC( ) CMTLVL( ) JRNBA( ) OPTIMZAPY( ) DFTBSFJRN( ) RCVRYEXP( ) JRNKEY( )
95
DESC( ) Description 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 DMADDBACK and DMRMVBACK commands. Input Parameters 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: *SAME Uses the current setting for this parameter. *REPL Indicates that you want to change a refresh-only group to a replication group. *RFSH Indicates that you want to change a replication group to a refresh-only group. 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: *SAME Uses the current setting for this parameter. *PRIMARY Sets 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. 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.
96
Note that this parameter is valid only for replication groups. Specify the name of a message queue or one of the following values: *SAME Uses the current setting for this parameter. *NONE Indicates 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: *SAME Uses the current setting for this parameter. *YES Automatically 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. *NO Does 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 groups 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 the iCluster - Switchover Guide 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 groups CHKJRN parameter, iCluster may perform processing that is equivalent to the DMMRKPOS command when a role switch occurs. If the value of the group's CHKJRN parameter is *NO, iCluster will not perform DMMRKPOS 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 DMMRKPOS processing regardless of the CHKJRN parameter's value. The DMMRKPOS 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 DMMRKPOS 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: *SAME - Keeps the present setting for this parameter. *YES Specifies 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. *NO Specifies 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. 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: *SAME Uses the current setting for this parameter. *NONE Indicates that you do not want to specify a user exit program.
98
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 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: *SAME Uses the current setting for this parameter. *NONE Indicates 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 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 nonalphanumeric characters (commas, periods, and so on), you must enclose your data in single quotes. Specify user-defined data or the following value: *SAME Uses the current setting for this parameter. The default setting for this parameter is *SAME.
99
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. 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 DMSELOBJ command. Specify a time interval or one of the following values: *SAME Uses the current time interval setting. *CLUSTER Refers to the cluster system value for this parameter that is specified through the DMSETSVAL command. *NONE Specifies 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: *SAME Uses the current setting for this parameter. *YES Allows 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. *NO Does not allow objects that are in use to be saved and updated. Objects cannot be updated while being saved. *SYNC Allows 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. *CLUSTER Refers to the cluster system value for this parameter that is specified through the DMSETSVAL command. The default setting for this parameter is *SAME.
100
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: *SAME Uses the current setting for this parameter. *CLUSTER Refers to the cluster system value for this parameter that is specified through the DMSETSVAL command. The default setting for this parameter is *SAME.
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. 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: *SAME Uses the current setting for this parameter. *CLUSTER Refers 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
101
but are not yet journaled. Specify the name of the database journal or one of the following values: *SAME Uses the current setting for this parameter. *CLUSTER Refers 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 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 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: *LOCAL - Indicates that the database journal(s) on the primary node are scraped during mirroring. *REMOTE - Indicates that the remote database journal(s) are scraped on the backup node during mirroring. *SAME Keeps 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 DMSETPOS command with the JRNPOS(*LASTAPY) parameter. 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. Specify one of the following values: *SAME Uses the current setting for this parameter. *NONE Indicates that the update process on the backup node will not perform commitment control staging. *LEVEL1 Indicates that all updates that comprise a transaction are assembled before being applied on the backup node.
102
*LEVEL2 Indicates 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. *CLUSTER Refers to the cluster system value for this parameter that is specified through the DMSETSVAL 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: *SAME Uses the current setting for this parameter. *BOTH Indicates that you want to journal both the before and after images. *AFTER Indicates that you want to journal the after image only. *CLUSTER Refers to the cluster system value for this parameter that is specified through the DMSETSVAL command. The default setting for this parameter is *SAME. OPTIMZAPY 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: *SAME Uses the current setting for this parameter. *NO Indicates that you do not want optimization for database apply updates. *YES Indicates that you want optimization for database apply updates. The default setting for this parameter is *SAME.
103
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 DMADDBSF command for more information. Specify the name of the BSF journal or one of the following special values: *SAME - Uses the current setting for this parameter. *NONE Indicates that you do not require journaling for BSF replication. *CLUSTER - BSF objects selected to this group will use the journal specified at the product level. See the DMSETSVAL 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 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. This parameter only applies to replication groups. Enter a recovery exposure value (number of journal entries) or one of the following values: *SAME - Uses the current setting for this parameter. *DISABLED - Indicates 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 RTCRCVPT or RTVRCVPTR command. This parameter only applies to replication groups. Specify the key or the following value:
104
*SAME - Uses the current setting for this parameter. The default setting for this parameter is *SAME. 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: *SAME Uses the current setting for this parameter. The default setting for this parameter is *SAME. Example 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. 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.
105
The default database journal will be JRN1 in library LIB1. The journal location is set to *LOCAL. Journal scraping will occur on the groups 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. Administrator (*ADMIN)
Related Topics DMADDGRP Add Group DMRMVGRP Remove Group DMADDBACK Add Backup Node to Recovery Domain DMRMVBACK Remove Backup Node from Recovery Domain DMDSPGRP Display Group DMWRKGRP Work with Groups DMSTRGRP Start Cluster Operations for Group DMENDGRP End Cluster Operations for Group DMSTRSWO Switchover Group
DMRMVGRP Remove Group

Command Description
106
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 Minimum Security Level Menu Access You must issue this command on an active node in the cluster. Administrator (*ADMIN)
Related Topics DMADDGRP Add Group DMCHGGRP Change Group DMADDBACK Add Backup Node to Recovery Domain DMRMVBACK Remove Backup Node from Recovery Domain DMDSPGRP Display Group DMWRKGRP Work with Groups DMSTRGRP Start Cluster Operations for Group DMENDGRP End Cluster Operations for Group DMSTRSWO Switchover Group
DMADDBACK Add Backup Node to Recovery Domain

Command Description 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.
107
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 DMADDNODE 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: *SYSBAS Indicates 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.
Example
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. Administrator (*ADMIN)
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).
Related Topics DMADDGRP Add Group DMCHGGRP Change Group DMRMVGRP Remove Group DMRMVBACK Remove Backup Node from Recovery Domain DMDSPGRP Display Group DMWRKGRP Work with Groups DMSTRGRP Start Cluster Operations for Group
108
DMENDGRP End Cluster Operations for Group DMSTRSWO Switchover Group DMSETPRIM Prepare Primary Node
DMRMVBACK Remove Backup Node from Recovery Domain

Command Description DMRMVBACK NAME( ) NODE( ) Use this command to remove the backup node from the recovery domain for an existing group or resilient application. 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 Minimum Security Level Menu Access You must issue this command on an active node in the cluster. Administrator (*ADMIN)
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).
Related Topics DMADDGRP Add Group DMCHGGRP Change Group DMRMVGRP Remove Group DMADDBACK Add Backup Node to Recovery Domain DMDSPGRP Display Group DMWRKGRP Work with Groups DMSTRGRP Start Cluster Operations for Group DMENDGRP End Cluster Operations for Group
DMSTRSWO Switchover Group DMSETPRIM Prepare Primary Node
DMCHGROLE - Change Group Primary Node

Command Description 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. 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. 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: *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 DMCHGROLE command on an active node in the cluster for groups or applications in *INACTIVE status.
110
Admin (*ADMIN)
F22 (Shift+F10) Option 51 Work With Groups screen Option 20 Work With Resilient Applications screen Option 20
Related Topic DMSETPRIM Prepare Primary Node
DMWRKGRP Work with Groups

Command Description 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: *ACTIVE Indicates that low-level cluster support within the group is running. *INACTIVE Indicates that low-level cluster support within the group is not running. *INIT_PEND Indicates that the group is in the process of being defined in iCluster. *ADDN_PEND Indicates that a node is in the process of being added to the group. *RMVN_PEND Indicates that a node is in the process of being removed from the group. *DLT_PEND Indicates that the group is in the process of being removed from iCluster. *STRT_PEND Indicates that low-level cluster operations are in the process of being started. *END_PEND Indicates that low-level cluster operations are in the process of being stopped. *SWO_PEND Indicates that a role switch is being performed within the group. *RESTORED Indicates 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_PEND Indicates that the replication group object (*CRG) for the group is in the process of being changed. *DLTCMD_PN Indicates that the replication group object (*CRG) for the
group is in the process of being deleted by the OS/400 command DLTCRG. *INDOUBT Indicates that the status of the group cannot be determined. *IN_ERROR Indicates that an internal iCluster error may have occurred. If this state persists, contact DataMirror Technical Support. See On-line Information and Technical Support for more information. *UNKNOWN Indicates 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: *ACTIVE Indicates that iCluster replication is currently being performed within the replication group. *INACTIVE Indicates that iCluster replication is not currently being performed within the replication group. *INDOUBT Indicates that some, but not all of the replication groups are running. *IN_ERROR Indicates that an internal iCluster error may have occurred. If this state persists, contact DataMirror Technical Support. See On-line Information and Technical Support for more information. *UNKNOWN Indicates 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. *SWOSTART Indicates that iCluster is starting switchover processing. *BEFUEXIT Indicates that iCluster is executing the before roleswitch user exit. *STSDRAIN Indicates that iCluster is draining the staging store. *STRJRN Indicates that iCluster is starting journaling on the journaled objects in replication scope. *TRIGGERS Indicates that triggers are being enabled on the new primary machine. *CONSTR Indicates that iCluster is enabling the referential integrity constrains on the new primary machine. *CHGROLES Indicates that iCluster is changing the roles of the primary and backup nodes. *MRKPOS Indicates that iCluster is marking the starting position for mirroring on the new primary node. *AFTUEXIT Indicates 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:
112
*NONE Lists all groups defined in iCluster. *NODE Lists the groups that contain the node specified through the NODE parameter (see below). *APPL Lists 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) 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 Minimum Security Level Menu Access You must issue this command on an active node in the cluster. User (*USER)
Related Topics DMADDGRP Add Group DMCHGGRP Change Group DMRMVGRP Remove Group DMADDBACK Add Backup Node to Recovery Domain DMRMVBACK Remove Backup Node from Recovery Domain DMDSPGRP Display Group DMSTRGRP Start Cluster Operations for Group DMENDGRP End Cluster Operations for Group
DMSTRSWO Switchover Group
Native AS/400 Object Commands

DMSELOBJ Select Objects to Group
Command DMSELOBJ GROUP( ) OBJ( ) OBJTYPE( ) OBJATTR( ) TGTLIB( ) DESC( ) INCFLG( ) POLLINT( ) NEWOBJACT( ) PFUPDMTD( ) PFKEY( ) 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. 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: *ALL Specifies 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: *ALL Specifies all object types.
Description
114
For a complete list of all object types that iCluster can replicate, see Object Types Replicated by iCluster. 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. 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 subtypes. 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: *ALL Specifies 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: *GROUP Specifies the same target library as specified in the DMADDGRP or DMCHGGRP commands. This is the default setting for this parameter. *PRIMARY Sets 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. 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. 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 for more information. Specify one of the following values: *INCLUDE Specifies that the referenced objects will be replicated within the replication group when cluster operations are started. *EXCLUDE Specifies 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. 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: *GROUP Refers to the replication group value for this parameter that is specified when adding or changing a replication group. See DMADDGRP Add Group and DMCHGGRP Change Group for more information about these two commands. *CLUSTER Refers to the cluster system value for this parameter that is specified through the DMSETSVAL command. *NONE Specifies 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.
116
Specify one of the following values: *NONE This value does not change the replication status of new, inscope 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 DMMRKPOS or DMREGPOS commands. The groups replication status cannot be *ACTIVE if you use this value. *CURRENT Replication 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 groups 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. *REFRESH Newly 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 groups replication status must be *ACTIVE for this option to take effect. The default setting for this parameter is *NONE. 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. If you change the replication method in an object specifier for a *FILE object from *UKEY to *RRN while the replication group is inactive, the file must be refreshed before replication can continue. Specify one of the following values: *RRN Indicates an update by relative record number. *UKEY Indicates 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.
117
The default setting for this parameter is *RRN. PFKEY Indicates a physical files unique key. An object name and library defines which file to use as the physical files 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 also need to identify the library where the objects reside. Prefix the physical file key with the name of the library where the key is located (for example, LIB1/OBJ1). 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 DMADDGRP or DMCHGGRP 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.
118
Use Minimum Security Level Menu Access
You must issue this command on an active node in the cluster. Administrator (*ADMIN)
F22 (Shift+F10) Option 13 Work With Object Specifier screen F6
Related Topics DMDSELOBJ De-select Objects from Group DMCHGOBJSL Change Object Selection to Group DMWRKOBJ Work with Object Specifiers DMMRKPOS Mark Current Journal Positions INITHAOBJ Initialize Objects
DMCHGOBJSL Change Object Selection to Group

Command DMCHGOBJSL GROUP( ) OBJ( ) OBJTYPE( ) OBJATTR( ) TGTLIB( ) DESC( ) INCFLG( ) POLLINT( ) 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: *ALL Specifies 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.
Description
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: *ALL Specifies all object types. For a complete list of all object types that iCluster can replicate, see Object Types Replicated by iCluster. 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: *ALL Specifies 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: *SAME - Keeps the present setting for this parameter. This is the default value. *PRIMARY Sets 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. *GROUP Specifies the same target library as specified in the DMADDGRP or DMCHGGRP 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.
120
The description can be a maximum of 50 characters long. Specify a short description or the following value: *SAME Uses the description that is currently associated with the object specifier selection to the replication group. The default setting for this parameter is *SAME. INCFLG 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 for more information. Specify one of the following values: *SAME Uses the current setting for this parameter. *INCLUDE Indicates that the referenced objects will be replicated within the replication group when cluster operations are started. *EXCLUDE Indicates 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 INITHAOBJ 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: *SAME Uses the current polling interval setting. *GROUP Refers to the replication group value for this parameter that is specified when adding or changing a replication group. See DMADDGRP Add Group and DMCHGGRP Change Group respectively for more information. *CLUSTER Refers to the cluster system value for this parameter that is specified through the DMSETSVAL command. *NONE Specifies 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. 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. Administrator (*ADMIN)
F22 (Shift+F10) Option 15 Work With Object Specifiers screen Option 2
Related Topics DMSELOBJ Select Objects to Group DMDSELOBJ De-select Objects from Group DMWRKOBJ Work with Object Specifiers
DMDSELOBJ De-select Objects from Group

Command Description
122
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: *ALL Specifies all objects in a library. 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: *ALL Specifies all object types. For a complete list of all object types that iCluster can replicate, see Object Types Replicated by iCluster. 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: *ALL Specifies 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. Examples 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.
123
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. Administrator (*ADMIN)
F22 (Shift+F10) Option 14 Work With Object Specifiers screen Option 4
Related Topics DMSELOBJ Select Objects to Group DMCHGOBJSL Change Object Selection to Group DMWRKOBJ Work with Object Specifiers
DMWRKOBJ Work with Object Specifiers

Command Description 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. Input Parameters BY The set of object specifiers that are listed by this command. Specify one of the following values: *NONE Lists all object specifiers defined in iCluster. *GROUP Lists 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.
124
DMWRKOBJ BY(*GROUP) GROUP(GRP1) Lists all object specifiers selected to the group GRP1. Use Minimum Security Level Menu Access You must issue this command on an active node in the cluster. User (*USER)
Related Topics DMSELOBJ Select Objects to Group DMDSELOBJ De-select Objects from Group DMCHGOBJSL Change Object Selection to Group
Byte Stream File (BSF) Commands

DMADDBSF - Add Path Object Specifier to Group
Command DMADDBSF GROUP( ) PATH( ) DESC( ) INCFLG( ) JOURNAL( ) POLLINT( ) NEWOBJACT( ) 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. 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 Byte Stream File (BSF) Objects. 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
Description
Specifiers. 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: *INCLUDE Indicates that the referenced BSF objects will be replicated within the replication group when cluster operations are started. *EXCLUDE Indicates 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. 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: *NONE BSF 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 for more information. *GROUP BSF objects matching this object specifier will use the journal specified at the group level. See the DMADDGRP 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/* (nonjournaled) 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: *GROUP Indicates that BSF objects will use the corresponding replication group value that is specified when adding or changing a
replication group. See DMADDGRP for more information. *NONE Indicates 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: *NONE This value does not change the replication status of new, inscope 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 DMSETPOS, DMMRKPOS, or DMREGPOS commands. This value is not allowed if replication of the group is active. *CURRENT Replication 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. 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. *REFRESH 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. This value is only permitted when the group is active. 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 DMADDBSF command processing. The default setting for this parameter is *NONE. 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. 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 DMADDGRP 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 Minimum Security Level Menu Access You need to issue this command on an active node in the cluster. Administrator (*ADMIN)
F22 (Shift+F10) Option 18 Work With Path Object Specifiers screen F6
Related Topics DMRMVBSF Remove Path Object Specifier from Group DMCHGBSF Change Path Object Specifier DMWRKBSF Work with Path Object Specifiers DMACTBSF Activate BSF Object DMSUSBSF Suspend BSF Object
DMRMVBSF - Remove Path Object Specifier from Group

Command Description 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 Byte Stream File (BSF) Objects. Input Parameters GROUP The name of the defined replication group that will have BSF objects deselected 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.
Examples
DMRMVBSF GROUP(GRP1) PATH(/DIR1/DIR2/DIR3/FILEA) De-selects the BSF object FILEA in /DIR1/DIR2/DIR3 from replication group GRP1. 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. Administrator (*ADMIN)
F22 (Shift+F10) Option 19 Work With Path Object Specifiers screen Option 4
Related Topics DMADDBSF Add Path Object Specifier to Group DMCHGBSF Change Path Object Specifier DMWRKBSF Work with Path Object Specifiers DMACTBSF Activate BSF Object DMSUSBSF Suspend BSF Object
DMCHGBSF - Change Path Object Specifier

Command Description DMCHGBSF GROUP( ) PATH( ) DESC( ) INCFLG( ) JOURNAL( ) POLLINT( ) 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 Byte Stream File (BSF) Objects. 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. 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: *SAME Uses 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. Specify one of the following values: *SAME Uses the current setting for this parameter. *INCLUDE Indicates that the referenced BSF objects will be replicated within the replication group when cluster operations are started. *EXCLUDE Indicates 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: *SAME Uses the current setting for this parameter. *GROUP BSF objects matching this object specifier will use the journal specified at the group level. See the DMADDGRP command for more information. *NONE BSF 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 for more information. The default setting for this parameter is *SAME. The overlap of journaled and non-journaled path object specifiers is restricted in iCluster. For example, using both /home/user/* (nonjournaled) 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: *SAME Uses the current setting for this parameter. *GROUP Indicates that BSF objects will use the corresponding replication group value that is specified when adding or changing a replication group. See DMADDGRP for more information. *NONE Indicates 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. 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 DMADDBSF command. DMCHGBSF GROUP(GRP2) PATH(/DIR1/DIR2/*) DESC(*SAME) INCFLG(*INCLUDE) JOURNAL(*NONE) POLLINT(*SAME) 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 DMADDGRP command will be used. 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. Administrator (*ADMIN)
F22 (Shift+F10) Option 20 Work With Path Object Specifiers screen Option 2
Related Topics DMADDBSF Add Path Object Specifier to Group DMRMVBSF Remove Path Object Specifier from Group DMWRKBSF Work with Path Object Specifiers DMACTBSF Activate BSF Object DMSUSBSF Suspend BSF Object
DMWRKBSF Work with Path Object Specifiers

Command Description 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. Input Parameters BY The set of path object specifiers that are listed by this command. Specify one of the following values: *NONE Lists all path object specifiers defined in iCluster. *GROUP Lists 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
132
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 Minimum Security Level Menu Access You must issue this command on an active node in the cluster. User (*USER)
Related Topics DMADDBSF Add Path Object Specifier to Group DMRMVBSF Remove Path Object Specifier from Group DMCHGBSF Change Path Object Specifier DMACTBSF Activate BSF Object DMSUSBSF Suspend BSF Object
Switchable Device Commands

DMADDSWDEV - Add Switchable Device Entry to Group
Command Description 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
133
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: *YES Indicates 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. *NO Indicates 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. Example 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 Menu Access Minimum Security Level Related Topics DMCHGSWDEV Change Switchable Device Entry for Group DMRMSWDEV Remove Switchable Device Entry from Group You must issue this command on an active node in the cluster. Work with Groups screen Option 25 *ADMIN
DMDSPASPGP Display Switchable Device Group

Command DMDSPASPGP GROUP( ) GRPTYPE( ) PRIMNODE( ) BACKUP( ) DESC( ) DEVICES( ) This command displays the parameters of a switchable resource group (type *SWDEV) in the cluster. 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: *SWDEV Indicates 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
Description
Input Parameters
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: *YES The 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. *NO The 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. Example DMDSPASPGP GROUP(ASP33) Displays the ASP33 group. Use Related Topics DMADDSWDEV Add Switchable Device Entry to Group DMCHGSWDEV Change Switchable Device Entry for Group DMRMSWDEV Remove Switchable Device Entry from Group You must issue this command on an active node in the cluster.
DMCHGSWDEV - Change Switchable Device Entry for Group

Command Description 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. 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 Specifies the name of a switchable disk storage device which you want to
change for the group. 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: *YES - Specifies 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. *NO - Specifies 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. Example 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 Minimum Security Level Use Work with Groups screen Option 26 *ADMIN
You must issue this command on an active node in the cluster. The nodes in the group must be enabled for switchable resources.
Related Topics DMADDSWDEV Add Switchable Device Entry to Group DMRMSWDEV Remove Switchable Device Entry from Group
DMRMVSWDEV - Remove Switchable Device Entry from Group

Command Description DMRMSWDEV GROUP( ) SWDEV( ) Use this command to remove a switchable disk storage device entry from a switchable device replication group. 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
136
Input Parameters
Work with Groups screen Option 27

Minimum Security Level Use Related Topics
*ADMIN
You must issue this command on an active node in the cluster.
DMADDSWDEV Add Switchable Device Entry to Group DMCHGSWDEV Change Switchable Device Entry for Group
Resilient Application Commands

DMADDAPP Add Resilient Application
Command 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 applications 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
Description
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. The takeover IP address must be specified in dotted quad notation (for example, 125.4.3.55). 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 DMADDNODE Add 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: *LIST Indicates 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 DMADDNODE Add Node for more information. This parameter is only applicable if the DMNSRC parameter (see above) is set to *LIST. 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 DMADDNODE Add Node for more information. This
parameter is only applicable if the DMNSRC parameter (see above) is set to *LIST. 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: *LOCAL - Indicates that the database journal(s) on the primary node are scraped during mirroring. *REMOTE - Indicates 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 DMSETPOS command with the JRNPOS(*LASTAPY) parameter. 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: *NONE Indicates 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 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: *NONE Indicates 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 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 nonalphanumeric 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. 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)
140
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. Administrator (*ADMIN)
F22 (Shift+F10) Option 23 Work With Resilient Applications screen Option 6 or F6
Related Topics DMUPDAPP Update Resilient Application DMCHGAPP Change Resilient Application DMRMVAPP Remove Resilient Application DMADDBACK Add Backup Node to Recovery Domain DMRMVBACK Remove Backup Node from Recovery Domain DMWRKAPP Work with Resilient Applications DMSTRAPP Start Cluster Operations for Resilient Application DMENDAPP End Cluster Operations for Resilient Application DMSWOAPP Switchover Resilient Application
141
DMDSPAPPGP Display Resilient Application Group

Command 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: *APPL Indicates an application resource group *REPL Indicates 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: *LOCAL Indicates that the database journal(s) on the primary node are scraped during mirroring. *LOCAL is the default setting for this parameter. *REMOTE Indicates 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:
Description
*NONE Indicates that you do not want to specify a user exit program. user-exit-program-name Refers 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: *NONE Indicates that you do not want to specify a user exit program. user-exit-program-name Refers 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) Displays informtion for the APPGRP1 group.
DMUPDAPP - Update Resilient Application

Command Description 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 DMADDAPP 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. Administrator (*ADMIN)
F22 (Shift+F10) Option 24 Work With Resilient Applications screen Option 3
Related Topics DMADDAPP Add Resilient Application DMCHGAPP Change Resilient Application DMRMVAPP Remove Resilient Application DMADDBACK Add Backup Node to Recovery Domain DMRMVBACK Remove Backup Node from Recovery Domain DMWRKAPP Work with Resilient Applications DMSTRAPP Start Cluster Operations for Resilient Application DMENDAPP End Cluster Operations for Resilient Application DMSWOAPP Switchover Resilient Application
DMCHGAPP Change Resilient Application

Command DMCHGAPP APPNAME( ) TKOVRIPADR( ) JRNLOC( ) BSWUSREXIT( ) ASWUSREXIT( ) EXITDATA( ) 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.
Description
144
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 DMADDBACK Add Backup Node to Recovery Domain and DMRMVBACK Remove Backup Node from Recovery Domain for more information. 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 DMADDAPP 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 applications 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: *SAME Uses 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 DMADDNODE Add Node 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: *SAME Uses the current setting for this parameter. *NONE Indicates 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 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: *SAME - Uses the current setting for this parameter. *NONE Indicates 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 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 nonalphanumeric 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: *SAME Uses 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: *SAME Uses the current setting for this parameter. *LOCAL - Indicates that the database journal(s) on the primary node are scraped during mirroring. *REMOTE - Indicates 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 DMSETPOS 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: *SAME Uses the current setting for this parameter. The default setting for this parameter is *SAME. Example 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. 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. Administrator (*ADMIN)
Related Topics DMADDAPP Add Resilient Application DMUPDAPP Update Resilient Application
147
DMRMVAPP Remove Resilient Application DMWRKAPP Work with Resilient Applications DMSTRAPP Start Cluster Operations for Resilient Application DMENDAPP End Cluster Operations for Resilient Application DMSWOAPP Switchover Resilient Application
DMRMVAPP Remove Resilient Application

Command Description 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. Administrator (*ADMIN)
Related Topics DMADDAPP Add Resilient Application DMUPDAPP Update Resilient Application DMCHGAPP Change Resilient Application DMWRKAPP Work with Resilient Applications DMSTRAPP Start Cluster Operations for Resilient Application DMENDAPP End Cluster Operations for Resilient Application DMSWOAPP Switchover Resilient Application
148
DMWRKAPP Work with Resilient Applications

Command Description 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: *ACTIVE - Specifies that the cluster statuses of all the groups under the resilient application are active. The groups' recovery domains are the same. *INACTIVE - Specifies that the cluster statuses of all the groups under the resilient application are inactive. The groups' recovery domains are the same. *INDOUBT - Indicates if the groups' recovery domains are different, or if one of the cluster or replication status is different from other groups. *UNKNOWN - Indicates that the status of the resilient application cannot be determined. *IN_ERROR Indicates that an internal iCluster error may have occurred. If this state persists, contact DataMirror Technical Support. See On-line Information and Technical Support for more information. *NONE Applications 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 The set of resilient applications. Specify one of the following values: *NONE Lists all resilient applications in iCluster. *NODE Lists the resilient applications that contain the node specified through the NODE parameter (see below) in their recovery domains. *GROUP Identifies 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 DMWRKAPP 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
149
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 Minimum Security Level Menu Access You must issue this command on an active node in the cluster. User (*USER)
Related Topics DMADDAPP Add Resilient Application DMCHGAPP Change Resilient Application DMUPDAPP Update Resilient Application DMRMVAPP Remove Resilient Application DMADDBACK Add Backup Node to Recovery Domain DMRMVBACK Remove Backup Node from Recovery Domain DMSTRAPP Start Cluster Operations for Resilient Application DMENDAPP End Cluster Operations for Resilient Application DMSWOAPP Switchover Resilient Application
MQSeries Commands
RBDHAMQM - Rebuild iCluster MQSeries
Command Description 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
150
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. 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 DMADDGRP 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.
Related Topic
DMADDGRP Add Group
Administration Commands
DMSETSVAL - Set Cluster System Values
Command
DMSETSVAL OPER( ) ACT( ) OBJ( ) SPLF( ) PF( ) BSF( ) EVNTLOG( )

151
LATENCY( ) CLUSTER( ) Description 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 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: *SAME Uses the current setting for this cluster system value. *NONE Specifies that user spaces should not be polled.
152
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: *SAME Uses 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: *SAME Uses the current setting for this cluster system value. *NO Does not compress all objects. *YES Compresses 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: *SAME Uses the current setting in the DMADDGRP command for this cluster system value. *NO Does not allow objects that are in use to be saved and updated. Objects cannot be updated while being saved. *YES Allows 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. *SYNC Allows 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 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: *SAME Uses the current setting for this cluster system value. *ERROR Generates a spool file for restore operations that produce an error (all other restore and save operations will not generate a spool file). *FULL Generates a spool file to identify restored and not restored objects. *NONE Does 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: *SAME Uses 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: *PRODLIB Specifies your iCluster installation library. *LIBL Specifies 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: *SAME Uses the current setting for this cluster system value.
154
The default setting for this parameter is two seconds. ACT 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. Automatic reactivation Specifies whether iCluster should try to reactivate suspended objects. Enter one of the following values: *SAME Keeps the present setting for this parameter. *YES Specifies that iCluster should try to reactivate suspended objects. This is the default value for this parameter. *NO Specifies that iCluster should not reactivate suspended objects. 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: *SAME Keeps 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: *SAME Keeps the present setting for this parameter. *NOMAX Never 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: *SAME Keeps the present setting for this parameter. *NOMAX Includes 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.
155
*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. Specify one of the following values: *SAME Uses the current setting for this cluster system value. *NO Indicates that files will not be locked when they are being updated, meaning that users can modify these files on the backup node. *YES Indicates that files cannot be modified on the backup node when they are being updated. 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. This parameter applies to the automatic reactivation of database files, refresh of objects, and the activation of objects. See the DMACTOBJ command. 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: *SAME Uses the current setting for this cluster system value. *NOMAX Indicates 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.
156
Specify one of the following values: *SAME Uses the current setting for this cluster system value. *YES Holds commands to create configuration objects in specific physical source files so that they can be created at a later time. *NO Automatically 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. 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: *SAME Uses the current setting for this cluster system value. *DISABLED Indicates that all user profiles will be set to a status of *DISABLED. *PRIMARY Indicates 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. *NOCHG Indicates that the current status of each user profile will not be changed by iCluster. 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: *SAME Uses the current setting for this cluster system value. *FULL Indicates 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. *BASIC Indicates 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: *SAME Uses the current setting for this cluster system value. *NO Does not replicate user profiles with the authorization lists. *YES Replicates 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: *SAME Uses the current setting for this cluster system value. *NO Does not replicate any user profiles that start with the letter Q. *YES Replicates 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
158
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: *SAME Uses 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. 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: *SAME Uses 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: *SAME Uses the current setting for this cluster system value. *YES Indicates that the spool files will be created and the contents will be mirrored. *NO Indicates that the spool files will be created, but the contents will not be mirrored.
159
The default setting for this parameter is *YES. PF 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. Specify one of the following values: *SAME Uses the current setting for this cluster system value. *NONE Indicates that the update process on the backup node will not perform commitment control staging. *LEVEL1 Indicates that all updates that comprise a transaction are assembled before being applied on the backup node. *LEVEL2 Indicates 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. Specify one of the following values: *SAME Uses the current setting for this cluster system value. *AFTER Indicates that you want to journal the after image only. *BOTH Indicates 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: *SAME Uses the current setting for this cluster system value. *NO Indicates that the replicated physical files, data areas, and data queues will not be journaled on backup nodes. *YES Indicates 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: *SAME Uses 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: *PRODLIB Specifies your iCluster installation library. *LIBL Specifies 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. Specify one of the following values: *SAME Uses the current setting for this cluster system value. *NO Indicates 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. *YES Indicates 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.
161
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. 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: *SAME Uses the current setting for this cluster system value. *NOMAX Specifies 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. BSF Specifies settings for replicating Byte Stream File (BSF) objects. See Byte Stream File (BSF) Objects 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: *SAME Uses the current setting for this cluster system value. HABSFJRN Uses 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: *PRODLIB Specifies your iCluster installation library. *LIBL Specifies 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. 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: *NONE Indicates that no message queue is specified. Event messages will be placed in the event log only. HAMSGQ Refers 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: *PRODLIB Specifies your iCluster installation library. *LIBL Specifies 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: *SAME Uses the current setting for this cluster system value. *LOCAL Displays dates and times in the time zone where the local node is located. *REMOTE Displays 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 DMDSPLOG command. Specify a time limit or one of the following values: *SAME Uses the current setting for this cluster system value. *NOMAX Disables 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: *SAME Uses the current setting for this cluster system value. 00 Generates information messages (Level 00) (for example, Savefile created). 10 Generates non-critical status messages (Level 10). 20 Generates stop/start messages and warning (Level 20) (for example, Mirroring started). 30 Generates messages that report recoverable errors (Level 30). *ALL Generates 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 iClusters latency threshold settings. iCluster will issue a warning message only after the latency threshold has been exceeded for one minute. 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: *SAME - Keeps the present setting for this parameter.
164
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: *SAME - Keeps 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 journals receive process and the last entry applied by the journals apply process. Enter a value ranging between 1 and 10080 (seven days) or the following value: *SAME - Keeps 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 Failover Mechanisms for more information about this parameter before changing its value. Specify one of the following values: *SAME Uses the current setting for this cluster system value. *NO Indicates that you want to use SwitchOver System. *YES Indicates 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
165
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: *SAME Uses the current setting for this cluster system value. *SHARED Uses one communications channel for all groups. *PERGROUP Each 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: *SAME Uses the current setting for this cluster system value. *SHARED Staging store blocks are re-allocated to the memory pool after they are used. This is the default behavior of iCluster. *PERGROUP Staging 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. Example 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. 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 DMDSPLOG 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. 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). Administrator (*ADMIN)
DMCHGTIME Change System Date and Time

Command 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. 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.
Description
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: *SYSVAL Indicates that the system date or time will be set explicitly using SYSVAL and VALUE parameters. *FORWARD Indicates 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. *BACKWARD Indicates 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: QDATE The system date. Changes take effect immediately. QTIME The 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.
169
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.
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. 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.
Examples
You must be signed on as QPGMR, QSYSOPR, or QSRV, or else have *ALLOBJ authority. F22 (Shift+F10) Option 31
DMDSPLOG - Display Cluster Event Log

Command 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. Input Parameters EVNTTYPE The type of event messages that you want to display. Specify one of the following values: *REPL Displays all event messages that provide information about replication. *ALL Displays all types of event messages. *COMM Displays all event messages that provide information about
Description
iCluster communications between nodes. *CLUSTER Displays 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 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: *ALL Displays 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. 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.
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. 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. 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: *ALL - Specifies that messages for all message IDs will be displayed. *LATNCY - Specifies 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. *PRINT Directs 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: *BASIC Displays first level message text. *FULL Displays 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). 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 DMSETSVAL command. Specify one of the following values: *ALL Displays messages in all levels. 00 Displays information messages (Level 00) (for example, Savefile created). 10 Displays non-critical status messages (Level 10). 20 Displays stop/start messages (Level 20) (for example, Start Mirroring). 30 Displays 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 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. User (*USER)
Related Topic DMCLRLOG Clear Cluster Event Log
DMCLRLOG Clear Cluster Event Log

Command Description 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. Input Parameters EVNTTYPE The type of event messages that you want to remove. Specify one of the following values: *REPL Removes all event messages that provide information about replication. *ALL Removes all types of event messages. *COMM Removes all event messages that provide information about iCluster communications between nodes. *CLUSTER Displays 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: *ALL Removes 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. 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: *ALL Removes messages generated by all nodes. *LOCAL Removes 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 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. 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. 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 Minimum Security Level Menu Access You can issue this command on a node that is active or inactive in the cluster. User (*USER)
Related Topic DMDSPLOG Display Cluster Event Log
HAPNGTCP Ping Using TCP

Command Description 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. 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 the iCluster iSeries Installation Guide. 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.
Input Parameters
177
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. F22 (Shift+F10) Option 34
Menu Access Related Topic
STRHATCP Start TCP/IP Listener
JRNHADADQ - Journal Data Areas and Data Queues

Command Description JRNHADADQ Use this command to start data area and data queue journaling by iCluster on the objects on the system. 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. Input Parameters Output Examples None. Relevant messages to the job log. 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.
STRHATCP Start TCP/IP Listener

Command Description 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. 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. 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
Input Parameters
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 predefined data area. Use Menu Access Related Topic HAPNGTCP Ping Using TCP You must issue this command on the node where the operation will be performed. F22 (Shift+F10) Option 35
WRKHAJOB Work with Active Cluster Jobs

Command Description 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 Example None. 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 Menu Access You must issue this command on the node where the operation will be performed. F22 (Shift+F10) Option 36
DMSTRDM Start Definition Manager

Command Description Input Parameters Example DMSTRDM Starts the definition manager on the current node. None. 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.
180
DMDLTCLSTR Delete Cluster

Command Description 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. 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 Minimum Security Level Menu Access You can issue this command on any node in the cluster. Administrator (*ADMIN)
DMSYSINF - System Information

Command Description DMSYSINF OUTPUT( ) Use this command to display the following iCluster system information: Node names System names Node IP addresses iCluster version Operating system version, model number, and serial number System times
This command tells you if you are using Cluster Resource Services.
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. 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. *PRINT Directs system information to a spool file for printing. The default for this parameter is *. Output Example iCluster system information is sent to the console or a spool file. DMSYSINF OUTPUT(*) Displays system information on the console. Minimum Security Level Menu Access User (*USER)
Cluster Operation Commands

DMSTRNODE Start Cluster Operations at Node
Command Description 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.
182
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. 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. Minimum Security Level Menu Access Operator (*OPERATOR)
Main Menu Option 11 F22 (Shift+F10) Option 40 Work With Nodes screen Option 1
Related Topic DMENDNODE End Cluster Operations at Node
DMENDNODE - End Cluster Operations at Node

Command Description 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 DMRMVNODE 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. 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 Minimum Security Level Menu Access You must issue this command on an active node in the cluster. Operator (*OPERATOR)
Main Menu Option 12 F22 (Shift+F10) Option 41 Work With Nodes screen Option 4
Related Topic DMSTRNODE Start Cluster Operations at Node
DMSTRGRP Start Cluster Operations for Group

Command Description DMSTRGRP GROUP( ) PRIMNODE( ) STRAPY( ) REFRESH( ) USEMARKED( ) 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. The STRAPY, REFRESH, and USEMARKED parameters are ignored if the group is a *SWDEV group. See DMADDGRP for more information. The REFRESH and USEMARKED parameters are ignored if the group is a *RFSH group. See DMADDGRP 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: *ALL Starts all groups on all nodes, regardless of their current recovery domain. *PRIMNODE Starts 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:
184
*NOCHG Indicates that the last operational status of the apply jobs on the backup node remains in affect. *YES Indicates that the apply jobs on the backup node for the replication group will be started. This does not apply to suspended files. *NO Indicates 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: *YES Specifies that an initial refresh of selected objects in the replication group is performed. *NO Specifies that an initial refresh of selected objects in the replication group is not performed. *MQRUNSTR Refreshes 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. The default setting for this parameter is *NO. 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 On-line Information and Technical Support 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 must re-start the refresh. 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 DMMRKPOS command, and are maintained in the iCluster metadata. Specify one of the following values: *NO Indicates that iCluster replication will not start at positions marked using the DMMRKPOS command. iCluster replication will start at either:
Journal positions set using the DMSETPOS command. Journal positions registered using the DMREGPOS command. The journal entry following the last journal position received on the backup system when replication was previously stopped.
*YES Indicates that mirroring will start at the journal positions that have been marked for the specified replication group through the DMMRKPOS command. Note that the primary and backup nodes must have been synchronized at the time the DMMRKPOS 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 DMSETPOS or DMREGPOS commands. The default setting for this parameter is *NO. If the DMMRKPOS 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) USEMARKED(*NO) An initial refresh of selected objects in replication group GRP2 is not performed before mirroring is started. 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 Minimum Security Level You must issue this command on an active node in the cluster. Operator (*OPERATOR)
186
Menu Access
Main Menu Option 13 F22 (Shift+F10) Option 43 Work With Groups screen Option 1
Related Topics DMSTRREPL Start Replication DMENDGRP End Cluster Operations for Group DMSTRSWO Switchover Group DMMRKPOS Mark Current Journal Positions DMSETPOS Set Journal Start Position DMREGPOS Register Positions INITHAOBJ Initialize Objects
DMSTRREPL Start Replication

Command Description DMSTRREPL GROUP( ) STRAPY( ) REFRESH( ) USEMARKED( ) Use this command to start replication for the specified replication group or resilient application. 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 On-line Information and Technical Support 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: *NOCHG Specifies that the current operational status of update/apply job on the backup node is not changed. *YES Indicates that the backup node update/apply job for the replication group or resilient application will be started. This does not apply to suspended files. *NO Indicates 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: *YES Specifies that an initial refresh of selected objects is performed. *NO Specifies that an initial refresh of selected objects is not performed. The default setting for this parameter is *NO. 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 On-line Information and Technical Support 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 replication group or resilient application. Note that these journal positions are marked through the DMMRKPOS command, and are maintained in the iCluster metadata. Specify one of the following values: *NO Indicates that iCluster will start mirroring from either the saved journal positions when replication was previously stopped, the journal positions marked through the DMSETPOS 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. *YES Starts mirroring at the journal positions that have been marked for the specified replication group or resilient application through the DMMRKPOS command. Note that the primary and backup nodes must have been synchronized at the time the DMMRKPOS 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. If the DMMRKPOS 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.
188
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. Operator (*OPERATOR)
DMSTRGRP Start Cluster Operations for Group DMENDGRP End Cluster Operations for Group DMSTRAPP Start Cluster Operations for Resilient Applications DMMRKPOS Mark Current Journal Positions DMSETPOS Set Journal Start Position DMREGPOS Register Positions
DMENDGRP End Cluster Operations for Group

Command Description 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: *ALL Ends all groups on all nodes, regardless of their current recovery
domain. *PRIMNODE Ends 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. 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: *CNTRLD Ends replication for the group in a controlled manner. *IMMED Ends 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. 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.
190
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. Use Minimum Security Level Menu Access You must issue this command on an active node in the cluster. Operator (*OPERATOR)
Related Topics DMSTRGRP Start Cluster Operations for Group DMSTRSWO Switchover Group
DMSTRSWO Switchover Group

Command Description 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 DMADDGRP Add Group and DMCHGGRP Change 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. To initiate a group switchover, the status of low-level cluster support provided by IBMs OS/400 Cluster Resource Services for the group must be *ACTIVE. See DMWRKGRP Work 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. 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.
191
Specify the name of a cluster resource group or the following value: *ALL Switches 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: *YES Indicates that replication processes for the group will be restarted from the new primary node to the new backup node when switchover processing is complete. This is the default setting. *NO Indicates that replication processes for the group will not be restarted from the new primary node to the new backup node when switchover processing is complete. If this value is specified, the DMSTRREPL (Start 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 DMSTRREPL 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 restarted 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 DMADDGRP or DMCHGGRP 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. User exit programs that may have been specified for each group through the DMADDGRP or DMCHGGRP 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. Administrator (*ADMIN)
Main Menu Option 15 F22 (Shift+F10) Option 46 Work With Groups screen Option 20
192
Related Topics DMSTRGRP Start Cluster Operations for Group DMENDGRP End Cluster Operations for Group DMSWOAPP Switchover Resilient Application
DMREJOIN - iCluster Rejoin Cluster

Command Description 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 machines node is the backup node of a group that has active status, cluster group operations will also be started at the current machines 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: *YES Indicates 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. *NO Indicates 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. Output Example The status of the node should change to *ACTIVE. DMREJOIN NUMTRIES(5) DELAY(10) STARTNEW(*NO) iCluster will attempt to re-start operations, to a maximum of five times, on the current machine. Use You can issue this command only on an inactive node in the cluster.
193
Administrator (*ADMIN)
DMSTRAPP Start Cluster Operations for Resilient Application

Command Description 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 DMSWOAPP Switchover Resilient Application 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: *NOCHG - Indicates that the current operational status of the apply jobs on the backup node is not changed. *YES Indicates 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. *NO - Indicates 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.
194
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: *YES Indicates that an initial refresh of objects for replication groups will be performed. *NO Indicates that an initial refresh of objects for replication groups will not be performed. The default setting for this parameter is *NO. 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 On-line Information and Technical Support 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 DMMRKPOS command, and are maintained in the iCluster metadata. Specify one of the following values: *NO Indicates that iCluster will start mirroring from either the saved journal positions when replication was previously stopped, the journal positions marked through the DMSETPOS 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. *YES Indicates that mirroring is started at the journal positions that have been marked for the specified resilient application through the DMMRKPOS command. Note that the primary and backup nodes must have been synchronized at the time the DMMRKPOS 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. If the DMMRKPOS 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)
195
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 DMMRKPOS command. Use Minimum Security Level Menu Access You must issue this command on an active node in the cluster. Operator (*OPERATOR)
Main Menu Option 22 F22 (Shift+F10) Option 47 Work With Resilient Applications screen Option
Related Topics DMSTRREPL Start Replication DMENDAPP End Cluster Operations for Resilient Application DMSWOAPP Switchover Resilient Application
DMENDAPP - End Cluster Operations for Resilient Application

Command Description DMENDAPP APPNAME( ) OPTION( ) DELAY( ) Use this command to end 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 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: *CNTRLD Ends replication for the replication groups in a controlled manner. *IMMED Ends 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 Minimum Security Level Menu Access You must issue this command on an active node in the cluster. Operator (*OPERATOR)
Main Menu Option 23 F22 (Shift+F10) Option 48 Work With Resilient Applications screen Option 4
Related Topics DMSTRAPP Start Cluster Operations for Resilient Application DMSWOAPP Switchover Resilient Application
DMSWOAPP Switchover Resilient Application

Command Description 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.
197
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. 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. 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: *YES Indicates that replication will re-start after a switchover. *NO Indicates that replication will not re-start after a switchover. The default setting for this parameter is *YES. Example 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 Minimum Security Level Menu Access You must issue this command on an active node in the cluster. Administrator (*ADMIN)
Main Menu Option 24 F22 (Shift+F10) Option 49 Work With Resilient Applications screen Option 20
Related Topics DMSTRAPP Start Cluster Operations for Resilient Application DMENDAPP End Cluster Operations for Resilient Application DMSTRSWO Switchover Group
198
DMSETPRIM - Prepare Primary Node

Command Description DMSETPRIM GROUP( ) Use this command to perform the necessary tasks to prepare a group or resilient applications primary node to be the source node for replication after a failover of the groups 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 DMADDGRP or DMCHGGRP 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 DMADDGRP Add Group or DMCHGGRP Change Group 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. This command is not available when the Use OS/400 Cluster Services system value is *NO. See DMSETSVAL 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 DMADDGRP or DMCHGGRP commands, it will be invoked on the new primary node. Use Minimum Security Level Menu Access Related Topic DMADDGRP Add Group You must issue this command on an active node in the cluster. Operator (*OPER)
DMGENEXC - Generate Command Exceptions

Command Description 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. 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: *NO Does not generate exceptions for commands that fail. *YES Generates exceptions for commands that fail. The default setting for this parameter is *NO. Example 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. Operator (*OPERATOR)
Replication Operation Commands

DMSETPOS Set Journal Start Position
Command Description DMSETPOS GROUP( ) JRN( ) JRNRCV( ) JRNPOS( ) STRDATE( ) STRTIME( ) 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. 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 DMADDGRP 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 DMADDGRP command. 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: *ALL Sets starting positions for all journals that are being scraped by the replication group or resilient application identified in the GROUP parameter of this command. If you specify the *ALL option, the following conditions must be true: 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 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: *CURRENT Specifies the current journal receiver for the specified journal. *CURCHAIN Specifies 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:
201
*LIBL Specifies 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. 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: *LASTAPY Start 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. *CURSRCPOS Start 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 journals 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. Examples 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. 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. Operator (*OPERATOR)
DMMRKPOS Mark Current Journal Positions CHGHAJRN Change Journal Receiver DSPHAPOS Display Journal Information RTVHAPOS Retrieve Journal Information VFYHAJRN Verify Audit Journal
DMMRKPOS Mark Current Journal Positions

Command Description 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
203
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 DMSTRREPL command for more information. The marked positions are used in the DMSTRGRP and DMSTRAPP 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. 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. 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. Operator (*OPERATOR)
DMSETPOS Set Journal Start Position CHGHAJRN Change Journal Receiver DSPHAPOS Display Journal Information RTVHAPOS Retrieve Journal Information VFYHAJRN Verify Audit Journal
CHGHAJRN Change Journal Receiver

Command Description 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. 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 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: *NO Specifies 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. *YES Specifies 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: *NONE Specifies that the age of the receivers is not considered when deleting fully processed journal receivers. The default setting for this parameter is *NONE. Examples 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.
205
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 Related Topics DMSETPOS Set Journal Start Position DMMRKPOS Mark Current Journal Positions DSPHAPOS Display Journal Information RTVHAPOS Retrieve Journal Information VFYHAJRN Verify Audit Journal F22 (Shift+F10) Option 62
DSPHAPOS Display Journal Information

Command Description DSPHAPOS JOURNAL( ) Use this command to display the journal sequence number, journal receiver and library, node 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. F22 (Shift+F10) Option 63
Menu Access Related Topics

206
DMSETPOS Set Journal Start Position DMMRKPOS Mark Current Journal Positions CHGHAJRN Change Journal Receiver RTVHAPOS Retrieve Journal Information VFYHAJRN Verify Audit Journal
RTVHAPOS Retrieve Journal Information

Command RTVHAPOS JOURNAL( ) TARGET( ) GROUP( ) 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. Since this command uses return variables, it can only be executed from a CL program. Use the DSPHAPOS command to obtain the same information from the command line. 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. JRNENTRY The name of the CL program decimal 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. 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.
Description
207
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. DataMirror recommends that you use the CL convention of & in front of the variable names.
Use
You must issue this command on the node where the journal resides. The node does not have to be active in the cluster. F22 (Shift+F10) Option 64
DMSETPOS Set Journal Start Position DMMRKPOS Mark Current Journal Positions CHGHAJRN Change Journal Receiver DSPHAPOS Display Journal Information VFYHAJRN Verify Audit Journal
VFYHAJRN Verify Audit Journal

Command Description 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. This command sets three OS/400 system values (QAUDLVL, QAUDCTL, and QCRTOBJAUD) 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. The required system values for the QCRTOBJAUD system value are as follows: Input Parameters *ALL, or *CHANGE 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. Specify one of the following values: *NO Does not audit objects in the library QTEMP by specifying *NOQTEMP for QAUDCTL. *YES Audits objects in the library QTEMP by not specifying *NOQTEMP for QAUDCTL. The default setting for this parameter is *NO. 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: *NO Does not audit spool file functions. *YES Audits spool file functions. The default setting for this parameter is *NO. Example 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. F22 (Shift+F10) Option 65
DMSETPOS Set Journal Start Position DMMRKPOS Mark Current Journal Positions CHGHAJRN Change Journal Receiver DSPHAPOS Display Journal Information RTVHAPOS Retrieve Journal Information
STRHABRCD - Start BSF Recording

Command Description 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 DMSETSVAL 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. This command starts journaling for a single file only. Input Parameters PATH The full object path in the format of /Dir1/Dir2/file.
210
Output
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. F22 (Shift+F10) Option 68
Menu Access
Related Topics ENDHABRCD End BSF Recording DSPHABRCD Display BSF Recording for File
DSPHABRCD - Display Recording for BSF Object

Command Description 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 Byte Stream File (BSF) Objects. 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. F22 (Shift+F10) Option 66
Menu Access Related Topic
ENDHABRCD End Recording for BSF Object
ENDHABRCD - End Recording for BSF Object

Command Description ENDHABRCD PATH( ) Use this command to end journaling of a Byte Stream File (BSF) object to its journal.
211
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. F22 (Shift+F10) Option 67
DSPHABRCD Display Recording for BSF Object Byte Stream File (BSF) Objects
DMSTRAPY Start Replication Apply Processes

Command Description 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 in iCluster 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 DMENDAPY command. The apply processes also ends when the staging store has been drained and the send/receive processes are not running. If the apply processes on the backup node cannot apply a journal entry to a file because it is exclusively locked either by another application or by the operating system, then you can configure the apply processes on the backup node to wait a certain amount of time and retry the apply 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. 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: *ALL Starts the apply processes on the backup node for all groups and resilient applications in the cluster. *BACKUP Starts 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: *ALL Starts 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 DMENDAPY command. Specify one of the following values: *YES The previous stop date/time is disregarded. The apply processes will continue until a new DMENDAPY command is issued. *NO The apply processes will start, but the previous stop date/time specified through the DMENDAPY command is still valid. Consequently, the processes will stop at that date/time unless it is reset by a subsequent invocation of the DMENDAPY 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 DMENDAPY command (if one is specified). Otherwise, it will stop once the
staging store is empty. Specify one of the following values: *NO Indicates 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. *YES Indicates 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 Minimum Security Level Menu Access You can issue this command on any node in the cluster. Operator (*OPERATOR)
Related Topic DMENDAPY End Replication Apply Processes
DMENDAPY End Replication Apply Processes

Command Description 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 in iCluster. 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 DMSTRAPY 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: *ALL Ends the apply processes on the backup node for all groups and resilient applications in the cluster. *BACKUP Ends 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 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: *ALL Ends 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: *CTRLD Indicates a controlled end of the apply processes, allowing them to complete their current processing. DataMirror recommends performing a controlled end when possible. *INVLD Invalidates the pending end date/time for the apply processes. Applies will continue. *DATETIME Indicates 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). *IMMED Indicates 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 systems 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 systems 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 Minimum Security Level Menu Access You can issue this command on any active node in the cluster. Operator (*OPERATOR)
Related Topic DMSTRAPY Start Replication Apply Processes
DMACTOBJ - Activate Object

Command Description DMACTOBJ GROUP( ) OBJ( ) OBJTYPE( ) MEMBER( ) RFSH( ) 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 DMSTRGRP command. 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. Input Parameters GROUP The name of the replication group to which the object is selected.
216
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: *ALL - Specifies 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: *ALL - Specifies all objects in the library which has the same object name component (OBJ parameter) but different types. See Object Types Replicated by iCluster 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: *ALL Specifies 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 DMSELOBJ Select Objects to Group 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: *NO Indicates 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. *YES Indicates that you want the suspended object to be refreshed on the backup node when the object is activated.
217
The default setting for this parameter is *YES. Examples DMACTOBJ GROUP(GRP1) OBJ(LIB1/OBJ1) OBJTYPE(*FILE) RFSH(*YES) 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. DMACTOBJ GROUP(GRP1) OBJ(LIB1/OBJ1) OBJTYPE(*FILE) MEMBER(MEM1) 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 Minimum Security Level Menu Access Related Topic DMSUSOBJ Suspend Object You can issue this command on any active node in the cluster. Operator (*OPERATOR)
DMACTBSF - Activate BSF Object

Command Description DMACTBSF GROUP( ) PATH( ) 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 Byte Stream File (BSF) Objects. 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 command. For more information about suspended objects, see Suspended Objects. Input Parameters GROUP The name of the replication group to which the BSF object is selected.
218
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. 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.
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 Minimum Security Level Menu Access Related Topics
You can issue this command on any active node in the cluster. Operator (*OPERATOR)
DMADDBSF Add Path Object Specifier to Group DMRMVBSF Remove Path Object Specifier from Group DMCHGBSF Change Path Object Specifier DMWRKBSF Work with Path Object Specifiers DMSUSBSF Suspend BSF Object
DMSUSOBJ - Suspend Object

Command Description DMSUSOBJ GROUP( ) OBJ( ) OBJTYPE( ) MEMBER( ) Use this command to prevent an object from being replicated to a backup node in
219
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 DMACTOBJ command. 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. Input Parameters GROUP The name of the replication group to which the object is selected. OBJ 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: *ALL Specifies all members for the specified source physical file. Example 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 Minimum Security Level Menu Access Related Topic DMACTOBJ Activate Object You must issue this command on an active node in the cluster. Operator (*OPERATOR)
DMSUSBSF - Suspend BSF Object

Command DMSUSBSF GROUP( ) PATH( )
220
Description
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 Byte Stream File (BSF) Objects. 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 DMACTBSF command. 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 DMADDBSF command for more information on journaled and non-journaled BSF files. For more information about suspended objects, see Suspended Objects.
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. For more information about path object specifiers, see Path Object Specifiers.
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 Minimum Security Level Menu Access Related Topics
You must issue this command on an active node in the cluster. Operator (*OPERATOR)
DMADDBSF Add Path Object Specifier to Group DMCHGBSF Change Path Object Specifier DMRMVBSF Remove Path Object Specifier from Group DMACTBSF Activate BSF Object DMWRKBSF Work with Path Object Specifiers
DMSNDOBJ - Send Object Immediately

Command 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 cannot be used to refresh data areas and data queues when the source object is at OS/400 Version 5.1 or later. The DMACTOBJ command can be used 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: *CURRENT The 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. Specify one of the following values: *LIBRARY A native OS/400 object that resides in an OS/400 library. *PATH A path object. OBJ 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: *ALL Specifies 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: *ALL Specifies all object types.
Description
222
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. 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 subtypes. 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: *ALL Specifies 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: *SRC Sets 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. 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. This parameter is used only when the SNDTYPE parameter is *PATH. Output Examples None. 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.
DMSETSYNC - Set Sync Point

Command 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. 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 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.
Description
Note the following important considerations concerning the DMSETSYNC command: 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. 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 jobs completion. See Passing Arguments to Sync Point User Exit Programs. 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. 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: *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 user exit program with the name of the library where the program is located (for example, LIB1/CHKPGM) or with the following value: *PRODLIB Specifies 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 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: *NO Does not synchronize group replication jobs at checkpoint journal entry. The user exit program is not invoked. *YES Synchronizes 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
Indicates whether you want the user exit program to be called when all the receive jobs have passed through the sync point. 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: *NO The user exit program will not be called when all the receive jobs have passed the sync point (received sync point journal entry). *YES - Invokes 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: *YES Synchronizes group replication jobs at the checkpoint journal entry and then invokes user exit program. *NO Does 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 non-alphanumeric characters (commas, periods, and so on), you must enclose your data in single quotes. This parameter is ignored if no user exit program is specified. See Passing Arguments to Sync Point User Exit Programs 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. 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
227
replication group is active or the resilient application is running. Minimum Security Level Menu Access Operator (*OPERATOR)
CRTCFGOBJ Create Configuration Object

Command Description 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. 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: *ALL Specifies 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 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: *CURRENT Specifies the user name that is running this command is assigned ownership of the created object. 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
INITHAOBJ Initialize Objects

Command Description 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 (QCRTOBJAUD, QAUDLVL, and QAUDCTL) have been changed so that they no longer meet the required values for iCluster. See the VFYHAJRN 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.
229
For example, /home/* *INC supersedes /home/dir1 *EXC or /home/dir1/* *EXC. Input Parameters The OS/400 parameter Object Auditing Value for BSF objects will always be set to *CHANGE. TARGET The name of the backup node in the recovery domain for the replication group identified through the GROUP parameter (see below). 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 Related Topics DMSELOBJ Select Objects to Group DMSTRGRP Start Cluster Operations for Group F22 (Shift+F10) Option 77
RTVRCVPT - Retrieve Recovery Checkpoint

Command Description RTVRCVPT JRNKEY( ) JRN( ) OLDRCV( ) OLDPOS( ) 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 DMADDGRP 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. This command is intended to be issued from the command line only. To issue this command from a CL program, see the RTVRCVPTR command. Parameters JRNKEY Specifies the key of a recovery checkpoint that was specified for the JRNKEY parameter of either the 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/JRNRCV1). OLDPOS Indicates the journal position on the primary node. Output The journal receiver and journal position of the recovery checkpoint on the backup system is displayed in the job log. RTVRCVPT JRNKEY(RCVRYID1) JRN(LIB1/JRN1) OLDRCV(LIB2/JRNRCV2) OLDPOS(000) Retrieves the recovery checkpoint based on the key RCVRYID1, journal JRN1, journal receiver JRNRCV2, and journal position 000. Use You may issue this command on the backup system as part of a recovery situation, such as after performing a switchover.
Examples
Related Topics RTVRCVPTR - Retrieve Recovery Checkpoint (CL Program)
RTVRCVPTR - Retrieve Recovery Checkpoint (CL Program)

Command RTVRCVPTR JRNKEY( ) JRN( ) OLDRCV( ) OLDPOS( ) RTNCDE( ) RTNRCVNME( ) RTNRCVLIB( ) RTNPOS( ) 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 DMADDGRP or DMCHGGRP 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. You must issue this command as part of a CL program. To issue this command from the command line, see the RTVRCVPT 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,
Description
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. Output Parameters RTNCDE Indicates if the command succeeded or failed in retrieving a recovery checkpoint. One of the following values will be returned: *OK - Specifies that the command completed successfully. *ERROR Specifies 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 DMSETPOS 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 that &RTNVAR, &RCVNMEVAR, &RCVLIBVAR and &POSVAR are CL variables. 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.
Related Topics RTVRCVPT - Retrieve Recovery Checkpoint
SYNCHATRG - Synchronize Triggers

Command Description SYNCHATRG TARGET( ) GROUP( ) FILE( ) FILELIB( ) Use this command to refresh the triggers on the database files for a valid backup node or group.
232
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: *ALL - All 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: *ALL - All groups attached to the specified backup node. 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: *ALL - All libraries within replication scope of the backup node or group specified. The FILE parameter must be *ALL if you select this value. Output Examples Relevant messages are sent to the event and job logs. 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.
DMLOGENT - Log Journal Entry

Command
DMLOGENT GROUP( ) ENTTYP( ) USRDTA( ) DTAARA( )

233
Description
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. GROUP The name of the group or resilient application for which logging information is deposited and recorded. *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: *INFO Indicates an informational entry. *STRRUN Indicates the beginning of mirroring. *ENDRUN Indicates 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: *NONE Indicates 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:
Input Parameters
234
*PRODLIB Specifies your iCluster installation library. The default setting for this parameter is *NONE. Example 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 Menu Access Operator (*OPERATOR)
Status and History Monitor Commands

DSPHASMON - Display Source Monitor
Command Description 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. For additional functionality, you will need to issue the WRKHASMON command. See the WRKHASMON command for more information. Input Parameters Output Examples None. Relevant messages to the job log. DSPHASMON Displays the simplified Status Monitor. Use Menu Access You can issue this command at any time from the primary system. F22 (Shift+F10) Option 82
WRKHASMON - Work with Status Monitor on Primary Node

Command Description
WRKHASMON Use this command to display the Status Monitor on a primary node, which allows
235
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: 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. Input Parameters Example None. 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. Main Menu Option 80 F22 (Shift+F10) Option 80 Related Topics WRKHATMON Work with Status Monitor on Backup Node CHGHASMON Change History Monitor on Primary Node PRGHASMON Purge History Monitor on Primary Node
Menu Access
WRKHATMON Work with Status Monitor on Backup Node

Command Description 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:
236
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. Input Parameters Example None. WRKHATMON Displays the Status Monitor allowing the replication status of groups as well as transaction information to be viewed. Use You must issue this command on the backup node of the groups you want to monitor. Main Menu Option 81 F22 (Shift+F10) Option 81 Related Topics WRKHASMON Work with Status Monitor on Primary Node CHGHASMON Change History Monitor on Primary Node PRGHASMON Purge History Monitor on Primary Node
Menu Access
CHGHASMON - Change History Monitor on Primary Node

Command 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.
Description
For more information about the features, functions, and displays provided by the monitor facility, see Working with the Status Monitor. Input Parameters TARGET The name of the backup node for which you will be starting the history monitor collection. 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 users 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: *TODAY Starts monitoring on the current date. *SAME Uses 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: *IMMED If 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. *SAME Uses the current setting for this parameter. 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: *SAME Uses 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 users job attributes. Enter a specific date or one of the following values: *TODAY Ends monitoring on the current date. *NONE Ends monitoring when all replication processes end. *SAME Uses 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: *NONE Ends 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. *SAME Uses 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. F22 (Shift+F10) Option 83
WRKHASMON Work with Status Monitor on Primary Node WRKHATMON Work with Status Monitor on Backup Node PRGHASMON Purge History Monitor on Primary Node
PRGHASMON Purge History Monitor on Primary Node

Command PRGHASMON TARGET( ) ENDDTE( ) ENDTIM( )
239
Description
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.
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: *ALL Records 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: *TODAY Indicates 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: *NOW The ending time for records to be deleted is the current time. The default setting for this parameter is *NOW.
Example
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. F22 (Shift+F10) Option 85
WRKHASMON Work with Status Monitor on Primary Node WRKHATMON Work with Status Monitor on Backup Node
CHGHASMON Change History Monitor on Primary Node
WRKHAOBJST Work with Object Status

Command Description 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 for more information. 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: *PRODLIB - Specifies your iCluster installation library. *UNKNOWN - Specifies 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-name - Specifies 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: *SRC - Indicates that you want to work with object status on the primary node. *TGT - Indicates 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
Input Parameters
GRP1 and backup node TGT1. Related Topics WRKHASMON Work with Status Monitor on Primary Node WRKHATMON Work with Status Monitor on Backup Node
WRKHABSFST Work with BSF Status

Command Description 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 for more information. 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: *PRODLIB - Specifies your iCluster installation library. *UNKNOWN - Specifies 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-name - Specifies 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: *SRC - Indicates that you want to work with object status on the primary node. *TGT - Indicates 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
Input Parameters
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. Related Topics WRKHASMON Work with Status Monitor on Primary Node WRKHATMON Work with Status Monitor on Backup Node
DMWRKOBJST - Work with Object Status by Group

Command Description 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: *NTV Start with the native object view. *BSF Start with the BSF object view. 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. Related Topics WRKHATMON Work with Status Monitor on Backup Node
243
Sync Check Commands

DSPHASC - Display Sync Check
Command Description 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: Object List Report This section is displayed only when *FILEATTR is specified from either the STRHASC or the STRHASCUSR command. 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). #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 SELSCATTR 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.
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 when *FILEATTR is specified as the sync check type.
*FILEATTR Sync Check Summary

This section is displayed only when *FILEATTR is specified from either the STRHASC or the STRHASCUSR command.
244
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 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. Object List Comparison Statistics This section is displayed only when *LIST is specified from either the STRHASC or the STRHASCUSR command. This section displays the following items: Total objects checked on primary Total objects found on backup Total objects not found on backup
Data Area Sync Check Summary This section is displayed only when *DTAARA is specified from either the STRHASC or the STRHASCUSR command. This section contains the following columns:
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
245
contents are different from the primary node. Comparison failed: Identifies the objects that could not be compared, for example, because one of the objects was locked.
This section also displays the following items: Number of data areas checked Number of mismatched data areas
BSF Sync Check Summary This section is displayed only when *BSF is specified from either the STRHASC or the STRHASCUSR command. This section contains the following statistics about the sync check: Input Parameters Output 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
None. 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 groups primary node. For more information about event logs, see Monitoring Replication.
Example
DSPHASC Displays all sync check spool files on the Work with All Spooled Files screen.
Use
You should issue this command from the groups primary node after performing a sync check. F22 (Shift+F10) Option 90
SELSCATTR Select Sync Check Attributes STRHASC Start Sync Check STRHASCUSR Start User Sync Check
SELSCATTR - Select Sync Check Attributes

Command Description 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:
246
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. Field attributes: These attributes relate to the fields of records contained within each file. When selecting attributes, you should note the following items: 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.
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
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 SELSCATTR 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 STRHASC and STRHASCUSR commands. Input Parameter USEDFT Indicates whether the default settings will be used. Enter one of the following values: *YES Uses the default value for each attribute. Any changes that you have selected for the attributes are ignored. *NO Does 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. Examples 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 Related Topics DSPHASC Display Sync Check SELSCATTR Select Sync Check Attributes STRHASC Start Sync Check STRHASCUSR Start User Sync Check DMSCRPT - Sync Check Report for IFS Objects DMSCRPTNTV Sync Check Report for Native Objects
STRHASC - Start Sync Check

Command 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 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 DSPHASC 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.
Description
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 SELSCATTR 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 DSPHASC 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. 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 DMSETSVAL 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: *YES Indicates 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. *NO Indicates 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: *FILEATTR Checks 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: 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. *LIST Checks 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. *BSF Checks 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
250
occurring for the objects being checked. *DTAARA Checks 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. *CHKJRN Verifies 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 BSF object that is journaled on the primary node and not journaled 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 DMSETSVAL 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: *CURRENT Indicates 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: *CURRENT Indicates 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. This parameter only applies to *FILEATTR, *LIST, and *DTAARA sync checks. *BSF sync check does not produce a listing of objects. Use the
DMSCRPT 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: *MISMATCH Displays only those objects that are not synchronized when writing the sync check report. *ALL Displays all objects, regardless of whether they match or not. *NONE - Indicates that no spool file report is to be generated for the sync check. The output is still sent to a database file. Use the DMSCRPT or DMSCRPTNTV 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. F22 (Shift+F10) Option 92
DSPHASC Display Sync Check SELSCATTR Select Sync Check Attributes STRHASCUSR Start User Sync Check DMSCRPT - Sync Check Report for IFS Objects DMSCRPTNTV - Sync Check Report for Native Objects
STRHASCUSR - Start User-Specified Synchronization Check

Command 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 STRHASC command performs a sync check on all objects selected to the specified group. The following types of synchronization checks are available:
252
Description
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 DSPHASC 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 SELSCATTR 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 DSPHASC 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 sync check takes place between the primary and backup nodes, but it increases the amount of time required to complete the operation. 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 DMSETSVAL 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: *YES Indicates 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. *NO Indicates 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: *FILEATTR Checks 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: 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. *BSF Checks 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. *LIST Checks 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. *DTAARA Checks 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. OBJSPEC The default setting for all object specifier parameters is *ALL. The set of parameters that will filter the objects you want to check. 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: *ALL Indicates 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. Specify the object type or the following value: *ALL Indicates 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. 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 subtypes. If PF is used, the object specifier will match either PFSRC or PFDTA files. Specify an object attribute or the following value: *ALL Indicates 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. 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. 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: *CURRENT Specifies 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: *CURRENT Specifies 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. This parameter only applies to *FILEATTR, *LIST, and *DTAARA sync checks. *BSF sync check does not produce a listing of objects. Use the DMSCRPT command to obtain a *BSF sync check report. Enter one of the following values: *MISMATCH Displays only those objects that are not synchronized when writing sync check report. *ALL Displays all objects, regardless of whether they match or not. *NONE - Indicates that no spool file report is to be generated for the sync check. The output is still sent to a database file. Use the DMSCRPT or DMSCRPTNTV command to view the sync check report in the database file. The default setting for this parameter is *MISMATCH.
256
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. 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.
Use
You must issue this command on the primary node of the specified replication group. F22 (Shift+F10) Option 93
DSPHASC Display Sync Check SELSCATTR Select Sync Check Attributes STRHASC Start Sync Check DMSCRPT - Sync Check Report for IFS Objects DMSCRPTNTV - Sync Check Report for Native Objects
DMSCRPT - Sync Check Report for IFS Objects

Command Description 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: 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: *LOCAL All 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: *GROUP Sort the sync check results by group name. *OBJECT Sort 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: * The sync check report is displayed on your screen. *PRINT The sync check report is placed in a spool file. * is the default setting for this parameter. Examples DMSCRPT GROUP(*LOCAL) SORTBY(*GROUP) OUTPUT(*) 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. F22 (Shift+F10) Option 94
DSPHASC Display Sync Check SELSCATTR Select Sync Check Attributes STRHASC Start Sync Check STRHASCUSR - Start User Sync Check DMSCRPTNTV - Sync Check Report for Native Objects
DMSCRPTNTV - Sync Check Report for Native Objects

Command
258
DMSCRPTNTV GROUP( ) DETAIL( )

Description
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: 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, and *LIST 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: *LOCAL All 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: *NO - Mismatching objects are listed without attribute details. *YES - Mismatching 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. 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. F22 (Shift + F10) - Option 95
DSPHASC Display Sync Check

SELSCATTR Select Sync Check Attributes STRHASC Start Sync Check STRHASCUSR - Start User Sync Check PRGHASC - Purge Sync Check Results DMSCRPT - Sync Check Report
PRGHASC - Purge Sync Check Results

Command Description 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 groups backup node is not available. This command also provides an option to clear all records from the sync check database files. 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: *ALL Purge all records from the sync check database files. *OBSOLETE Purge only obsolete records from the sync check database files. *OBSOLETE is the default setting for this parameter. Examples 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.
Related Topics DSPHASC Display Sync Check SELSCATTR Select Sync Check Attributes STRHASC Start Sync Check STRHASCUSR - Start User Sync Check DMSCRPT - Sync Check Report for IFS Objects DMSCRPTNTV - Sync Check Report for Native Objects
Registered iCluster User Commands

DMADDUSR - Add User
Command Description 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 the iCluster - Administrator User Manual for more information about the iCluster Administrator. For more information about security in iCluster, see Command Security. 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: *USER Grants user privileges to the specified user. *ADMIN Grants administrative privileges to the specified user. *OPERATOR Grants 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 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). 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. QSECOFR or a user name having *SECADM authority.
DMCHGUSR Change User DMRMVUSR Remove User DMWRKUSR Work with Users
DMCHGUSR - Change User

Command Description 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 DMADDUSR 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 the iCluster - Administrator User Manual for more information about the iCluster Administrator. For more information about security in iCluster, see Command Security. 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. 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: *USER Changes the security level to user for the specified user. *ADMIN Changes the security level to administrative for the specified user. *OPERATOR Changes the security level to operator for the specified user. *SAME Uses 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: *SAME Uses 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: *NONE 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. * Uses the current password for the user. The default setting for this parameter is *. Examples 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. 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. You must restart the iCluster Administrator before password changes will take effect. Minimum Security Level Menu Access Related Topics DMADDUSR Add User DMRMVUSR Remove User DMWRKUSR Work with Users QSECOFR or a user name having *SECADM authority.
DMRMVUSR - Remove User

Command Description 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. 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. You must restart the iCluster Administrator before password changes will take effect. Minimum Security Level Menu Access Related Topics DMADDUSR Add User DMCHGUSR Change User DMWRKUSR Work with Users QSECOFR or a user name having *SECADM authority.
DMWRKUSR - Work with Users

Command Description 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. Input Parameters Example None. 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 Minimum Security Level You must issue this command on the node where the operation will be performed. QSECOFR or a user name having *SECADM authority.
265
DMADDUSR Add User DMCHGUSR Change User DMRMVUSR Remove User
Exit Program Commands

ADDPFEXPGM - Add Exit Program
Command Description 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. 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 Output Examples None. Relevant messages to the job log. 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. Related Topic RMVPFEXPGM Remove Exit Program
RMVPFEXPGM - Remove Exit Program

Command Description 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
266
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 ADDPFEXPGM 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 ADDPFEXPGM command. See ADDPFEXPGM for more information. Input Parameters Output Examples None. Relevant messages to the job log. 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. Related Topic ADDPFEXPGM Add Exit Program
iCluster for Supported External Storage Systems

DMRBDNODE - Rebuild Node
Command Description 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. This command is only available if the iCluster authorization code is installed. See Authorization Codes for more information. Specifically, this command performs the following operations: 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.
267
Input Parameters
NODE The system name of the backup node as set in the IPL exit program.
Output Examples
None. 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 the iCluster Switchover Guide for more information about failovers.
Related Topic DMREGPOS Register Positions
DMREGPOS - Register Positions

Command Description 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. 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. If 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:
268
Starting positions specified by a subsequent call to the DMSETPOS command. Specifying *YES on the USEMARKED (Start with Marked Positions)
parameter of the DMSTRGRP command. 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: *ALL Specifies 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: *CURNODE Specifies the current node. This is the default setting for this parameter. Output Job log messages indicating successful completion or problems are interactively displayed. 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: 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. This command should not be invoked during the "duplicate time" if the system time is changed backwards. Unpredictable results may occur in these situations.
Example
Related Topic DMRBDNODE Rebuild Node
Other Commands
SETHAREG - Restore Communications Registries
Command Description SETHAREG Use this command to restore communications registries that have been corrupted through node failure, interruption, or other circumstances. None. None.
269
Input Parameters Output

Examples
SETHAREG Restores communications registries on the local active node.
270
Chapter 6 - The Status Monitor

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. 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. 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.
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 the DSPHASMON command.
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 in iCluster 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 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 CHGHASMON command on the primary node. 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: Real time object latency Real time overall latency Real time object position and totals Real time object throughput Historical latency Historical object position and totals Historical object throughput
Monitoring Real Time Statistics

Real Time Statistics Views
The iCluster real time status monitor splits its information across multiple views. This topic 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 WRKHASMON command from the command line.
To display statistics for the current node as a backup node, start the status monitor by either: Selecting option 81 (Display the iCluster Backup Monitor) from the iCluster main menu. Running the WRKHATMON command from the command line.
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 8.
Figure 8 - View Sequence for 132 Column Terminals
273
If your terminal is set for 80 column display, then you will not see the Real Time Overall Latency view. Figure 9 shows the sequence of views you will see.
Figure 9 - View Sequence for 80 Column Terminal For more information on each of these views, see the following topics: Monitoring Real Time Overall Latency Monitoring Real Time Object Latency Monitoring Real Time Object Position and Totals Monitoring Real Time Object Throughput
Common Information on all Views

Each view shares columns and other informational fields. They are: 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. Elapsed time field Displays the amount of time that has passed since the status monitor was last restarted. See Common Options for all Views 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
Prm/Bkp/Grp/Jrn column
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.
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. Key F5 Label Refresh 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 DSPHASC 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 top-right corner of the status monitor. This also refreshes the Status Monitor. Displays the next view for the status monitor. See Real Time Statistics Views for more information on the sequence of views. Displays an OS/400 command prompt. Exits the status monitor and displays the iCluster Main Menu.
F9
Sync Check Results
F10
Re-Start
F11
Next View
F21 (SHIFT+F9)
Command
F22 (SHIFT+F10)
DM Cmds
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. Label Description
275
Start
Starts replication for the selected group on the primary node. On the backup node, the apply process will start. This option runs the DMSTRGRP command.
Wrk Obj Specs
Show the object specifiers for the selected group. This option runs the DMWRKOBJ 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 DMENDGRP 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 Work With BSF Status screen for the selected group or journal. Displays the Work 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.
Msgs
BSF Sts
Obj Sts
Chk backup
History
Displays the Historical Latency screen the selected journal. Initiates a sync check for the selected group by running the STRHASC command. This option is only available from the primary monitor.
Start Synchck
276
Start User Synchck
Initiates a user sync check for the selected group by running the STRHASCUSR command. This option is only available from the primary monitor.
Monitoring Real Time Overall Latency

The Real Time Overall Latency view (Figure 14) 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 14 - 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 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 for more information.
Reading this View

The Real Time Overall Latency view displays the following information: 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
277
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 DMSETSVAL 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 DMSETSVAL command for more information on setting latency thresholds. Total Latency 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 for details on the status fields.
Total Latency Status
See Real Time Statistics Views for descriptions of information available to all status monitor views.
Performing Tasks
See Common Options for all Views for a complete list of options and tasks you can perform from this view. See Monitoring Latency for more information on how to monitor latency in iCluster.
Monitoring Real Time Object Latency

The Real Time Object Latency view (Figure 15) 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.
278
Figure 15 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 for more information on this option.

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 for more information.
Reading this View

The Real Time Object Latency view displays the following information: 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. 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
Curr Trans Applied
After issuing the DMSETPOS, DMMRKPOS, or DMREGPOS commands Refresh before mirroring Counts exceed approximately 10 billion
The number of transactions which have been sent by the primary node, but have
279
not yet been applied on the backup node. Status See Reading Status Information for details on the status fields.
Performing Tasks
See Common Options for all Views for a complete list of options and tasks you can perform from this view.
Monitoring Real Time Object Position and Totals

The Real Time Object Position and Totals view (Figure 16) 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 16 Real Time Object Position and Totals View Primary Monitor

Reading this View

The Real Time Object Position and Totals view displays the following information: Last J/E Primary J/E The 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.
280
Backup J/E Trans to Process
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 for details on the status fields.
Status
Performing Tasks
Monitoring Real Time Object Throughput

The Real Time Object Throughput view (Figure 22) 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 17 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.
281
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).

Reading this View

The Real Time Object Throughput view displays the following information: 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 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 for more information on restarting the status monitor timer. Status See Reading Status Information for details on the status fields.
Overall Trans/Hr
Current Trans/Hr
Performing Tasks
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: PB - Primary/Backup Status S/O - Suspended Objects Count OOS - Out of Sync Object Count OP - Operational Status Current Object
282
Primary/Backup (PB) Status Column
Figure 10 - The PB Status Column The PB field represents the status of replication processes on the primary and backup nodes. The first item in this field represents the status of the scrape process on the primary node and the second item represents the status of the receive and apply process on the backup node. Table 4 lists the status codes and their meanings. Meaning
Indicates that the replication process is active. Indicates an inactive status. 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. Indicates that the status is unknown. The status can be unknown for the backup node when the primary node is not actively communicating with the backup node. It could 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. Table 4 Primary and Backup Status Codes Table 5 describes some sample PB codes and then explains what they mean. Meaning
The journal may be unused on the primary node. The status is unknown on the backup node.
283
The journal may not be used on the primary node. The apply process is inactive on the backup node. The journal may not be used on the primary node. The apply process is active on the backup node. The journal may not be used on both the primary and backup nodes.
The journal is not being used on the primary node. The status is unknown for the backup node. The journal is not being used on the primary node. The latent apply on the now unused journal is inactive on the backup node. The journal is not being used on the primary node. The latent apply on the now unused journal is active on the backup node. Table 5 Sample PB Status Codes
Suspended Objects (S/O) Count Column
Figure 11 - The S/O Status Column This field 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) Count Column
Figure 12 - The 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. The OOS field is only available on backup monitor screens in a 132-column terminal session.
284
Operational (OP) Status Column
Figure 13 - The 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. The OP field is only available on primary and backup monitor screens in a 132-column terminal session.
Current 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. See Figure 13 for a sample. The Curr Object field is only available on backup monitor screens in a 132-column terminal session.
Monitoring Object Status

Working with Object Status
The Work with Object Status screen (Figure 18) 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.
285
Figure 18 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 WRKHAOBJST command.
Reading 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. This screen also displays the following information: Status Indicates the status of each object. The possible statuses are as follows: Objects Type Library Attribute Jrn Pos Reason ACTIVE - The object is available for replication. PNDACT - Active pending. The object is currently suspended and waiting to become active through a journal entry that must be scraped. PNDSUS - The object is active and waiting to be suspended through a journal entry that must be scraped. SUSPND - The object is currently suspended.
The replication object this status describes. The object type of the object. The library the object belongs to. The object extended attribute for the object. The object's current journal position. Indicates the reason why the object was suspended. The three-character reason codes are as follows:
286
ABU - The object was activated by the user. AIS - The object will be activated as soon as this entry is scraped from the journal by iCluster. APD - The object's activation has started but has not finished. AUD - Object auditing cannot be started for a BSF object. AUS - Private authorities associated with the BSF object could not be replicated or retrieved. AUT - Private authorities for an object could not be retrieved. BTN - Metadata for a BSF object cannot be found on the backup node. CDA - The change content operation to a data area failed. CHK - Temporary state showing that iCluster tried to refresh file during rename/move. CIL - Unable to determine if a BSF object is a hard link. CJN - A required journal entry associated with the object could not be found in the audit journal. COM - An object could not be refreshed. CPT - A journal entry required to refresh the object could not be added to the database journal. CRT - The BSF object cannot be created on the backup node. DLT - A BSF object could not be removed from the backup node. DTA - The BSF object could not be opened on the primary node for refreshing. EJF - An object was suspended on the primary node because journaling for the object ended on this node. EXS - iCluster attempted to create an IFS folder that already existed. INT - An object was suspended as a result of an internal failure. Synchronization between objects on the primary and backup nodes cannot be assumed. IOF - A read or write operation failed. JPF - A logical file was suspended on the primary node because the associated physical file could not be journaled. JPO - A required journal entry related to the object could not be found in the database journal. JRN - Journal information for an object could not be retrieved, or the object could not be journaled. LCK - A lock on an object could not be obtained. LNK - The BSF object is a hard link (replication of hard links is not supported by iCluster). MDF - A problem occurred when creating or updating metadata related to the object. MLF - An object was suspended on the backup node because a member-level failure (rename, delete, reorganize, and so on) occurred during replication. MRR - An object was suspended on the primary node. The object should have been refreshed manually, but it has yet to be activated. NFD - Object not found on the system. NGP - A logical file was suspended on the primary node because the associated physical file was not replicated in the same group as the logical file. NRE - File has no record in the metadata.
287
NSI - A BSF object exists on the backup node, but not on the primary node. NSO - Object replication is not supported in the current mode. NTI - The state associated with a BSF object could not be found on the backup node. OLF - An object level failure occurred while trying to rename or move a non-journaled object. OWN - The owner of BSF object could not be changed on the backup node. PCK - Compression of the BSF object path was unsuccessful. PDA - Uncommited DO "delete object" entry is received for an active object under commitment control. PDS - Uncommited DO "delete object" entry is received for a suspended object under commitment control. PDU - Uncommited DO "delete object" entry is received for an object suspended by the user under commitment control. PGP - The primary group of a BSF object could not be changed on the backup node. PND - Activate pending for the object engine. RBC - The file was part of a cancelled rollback operation on the primary node. RDQ - The receive operation to a data queue failed. RFF - A refresh of a BSF object was unsuccessful. RFS - A refresh of a BSF object could not be started from the primary node. RLE - An 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 DMSETSVAL Set Cluster System Values for more information. RMV - A RMVJRNCHG journal entry was processed for the object. The object is suspended and will be refreshed later by the automatic re-activation function. RNM - Rename or move operation failed. RSF - An object was suspended on the backup node. It should have been refreshed, but the restore operation failed on the backup node. RST - A BSF object was restored. The object needs to be refreshed. RTN - An unexpected return code while dealing with an object. RTV - A logical file was suspended on the primary node because iCluster could not determine which physical files were associated with the logical file. RWA - An object was suspended on the primary node because a record-by-record refresh failed. SBU - An object was explicitly suspended on the primary node as a result of issuing the DMSUSOBJ or DMSUSBSF command. SCT - The contents of an object could not be replicated by iCluster. SDQ - The send operation to a data queue failed. SFD - Unable to retrieve the file identifier of a BSF object. SIS - A suspend entry has been issued for an object. SIZ - An 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 DMSETSVAL Set Cluster System Values for more information. SND - An object or its authorities could not be replicated.
288
SPF - A logical file was suspended on the primary node because the associated physical file was suspended. SRF - A refresh of a BSF object has been started. SSC - A BSF object was suspended on the primary node. STR - Journaling for a BSF object has been started. The object must be refreshed. SWA - Activate pending for files being refreshed manually. The file is waiting for the activate command. SWO - The object was suspended on the backup prior to a switchover. SVF - An 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. TNE - The BSF object does not exist on the backup node. TNR - The path of a BSF object could not be resolved on the backup node. TNS - The BSF object is a type of object that cannot be replicated. TRG - The trigger information for the object could not be retrieved. UBI - An operation was found that could not be undone because the object in question does not have journaled before-images. UCC - An error occurred undoing a content change to a journaled object. UOC - An object level change was encountered that cannot be undone. UPD - A member of PF-SRC is open for update. The file will no longer be suspended once the application closes the file. UUT - The 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. 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).
289
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 19) 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 19 - Work With BSF Status Screen For more information about suspended objects, see Suspended Objects. For more information about working with the Object Status screen, see Working with Object Status.
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 WRKHABSFST command.
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: Status
290
Indicates the status of each object. The possible statuses are as follows:
Type Objects Jrn Pos Reason
ACTIVE - The object is available for replication. PNDACT - Active pending. The object is currently suspended and waiting to become active though a journal entry that must be scraped. PNDSUS - The object is active and waiting to be suspended though a journal entry that must be scraped. SUSPND - The 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 threecharacter reason codes, see Working with Object Status 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 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 20) 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.
291
Figure 20 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.
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 DMWRKOBJST 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: Objects (Native View only) Type (Native View only) Library (Native View only) Object Path (BSF View only) OOS Reason The replication object this status describes.
The object type of the object.
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:
292
OOS Date-time Susp Reason
ATR - The object's attributes are out-of-sync. AUT - The object's authorities, owners, or permissions are out-of-sync. CNT - The object's contents are out-of-sync. LCK - The object was locked on the primary node during a sync check. NFD - The object does not exist on either the backup or the primary node. NJT - The object is not journaled on the backup node. SZE - The objects 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. The three-character reason codes are as follows: ABU - The object was activated by the user. AIS - The object will be activated as soon as this entry is scraped from the journal by iCluster. APD - The object's activation has started but has not finished. AUD - Object auditing cannot be started for a BSF object. AUS - Private authorities associated with the BSF object could not be replicated or retrieved. AUT - Private authorities for an object could not be retrieved. BTN - Metadata for a BSF object cannot be found on the backup node. CDA - The change content operation to a data area failed. CHK - Temporary state showing that iCluster tried to refresh file during rename/move. CIL - Unable to determine if a BSF object is a hard link. CJN - A required journal entry associated with the object could not be found in the audit journal. COM - An object could not be refreshed. CPT - A journal entry required to refresh the object could not be added to the database journal. CRT - The BSF object cannot be created on the backup node. DLT - A BSF object could not be removed from the backup node. DTA - The BSF object could not be opened on the primary node for refreshing. EJF - An object was suspended on the primary node because journaling for the object ended on this node. EXS - iCluster attempted to create an IFS folder that already existed. INT - An object was suspended as a result of an internal failure. Synchronization between objects on the primary and backup nodes cannot be assumed. IOF - A read or write operation failed. JPF - A logical file was suspended on the primary node because the associated physical file could not be journaled. JPO - A required journal entry related to the object could not be found in the database journal. JRN - Journal information for an object could not be retrieved, or the object could not be journaled.
293
LCK - A lock on an object could not be obtained. LNK - The BSF object is a hard link (replication of hard links is not supported by iCluster). MDF - A problem occurred when creating or updating metadata related to the object. MLF - An object was suspended on the backup node because a member-level failure (rename, delete, reorganize, and so on) occurred during replication. MRR - An object was suspended on the primary node. The object should have been refreshed manually, but it has yet to be activated. NFD - Object not found on the system. NGP - A logical file was suspended on the primary node because the associated physical file was not replicated in the same group as the logical file. NRE - File has no record in the metadata. NSI - A BSF object exists on the backup node, but not on the primary node. NSO - Object replication is not supported in the current mode. NTI - The state associated with a BSF object could not be found on the backup node. NVR - The object was suspended because iCluster cannot replicate this object type. Note that the object cannot be activated. OLF - An object level failure occurred while trying to rename or move a nonjournaled object. OWN - The owner of BSF object could not be changed on the backup node. PCK - Compression of the BSF object path was unsuccessful. PDA - Uncommited DO "delete object" entry is received for an active object under commitment control. PDS - Uncommited DO "delete object" entry is received for a suspended object under commitment control. PDU - Uncommited DO "delete object" entry is received for an object suspended by the user under commitment control. PGP - The primary group of a BSF object could not be changed on the backup node. PND - Activate pending for the object engine. RBC - The file was part of a cancelled rollback operation on the primary node. RDQ - The receive operation to a data queue failed. RFF - A refresh of a BSF object was unsuccessful. RFS - A refresh of a BSF object could not be started from the primary node. RLE - An 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 DMSETSVAL Set Cluster System Values for more information. RMV - A RMVJRNCHG journal entry was processed for the object. The object is suspended and will be refreshed later by the automatic re-activation function. RNM - Rename or move operation failed. RSF - An object was suspended on the backup node. It should have been refreshed, but the restore operation failed on the backup node. RST - A BSF object was restored. The object must be refreshed.

294
RTN - An unexpected return code while dealing with an object. RTV - A logical file was suspended on the primary node because iCluster could not determine which physical files were associated with the logical file. RWA - An object was suspended on the primary node because a record-byrecord refresh failed. SBU - An object was explicitly suspended on the primary node as a result of issuing the DMSUSOBJ or DMSUSBSF command. SCT - The contents of an object could not be replicated by iCluster. SDQ - The send operation to a data queue failed. SFD - Unable to retrieve the file identifier of a BSF object. SIS - A suspend entry has been issued for an object. SIZ - An 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 DMSETSVAL Set Cluster System Values for more information. SND - An object or its authorities could not be replicated. SPF - A logical file was suspended on the primary node because the associated physical file was suspended. SRF - A refresh of a BSF object has been started. SSC - A BSF object was suspended on the primary node. STR - Journaling for a BSF object has been started. The object must be refreshed. SWA - Activate pending for files being refreshed manually. The file is waiting for the activate command. SWO - The object was suspended on the backup prior to a switchover. SVF - An 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. TNE - The BSF object does not exist on the backup node. TNR - The path of a BSF object could not be resolved on the backup node. TNS - The BSF object is a type of object that cannot be replicated. TRG - The trigger information for the object could not be retrieved. UBI - An operation was found that could not be undone because the object in question does not have journaled before-images. UCC - An error occurred undoing a content change to a journaled object. UOC - An object level change was encountered that cannot be undone. UPD - A member of PF-SRC is open for update. The file will no longer be suspended once the application closes the file. UUT - The 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. 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.
295
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.
Monitoring Historical Statistics

Historical Statistics Views
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 21 shows the views for the history log.
Figure 21 - History Log View Sequence For more information on each of these views, see the following topics:
296
Monitoring Historical Latency Monitoring Historical Object Position and Totals Monitoring Historical Object Throughput
Monitoring Historical Latency

The Historical Latency view (Figure 22) 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 22 Historical Latency 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. 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 Historical Statistics Views 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: Type
The type of entry that is displayed.

297
Date Time Last J/E Primary J/E
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.
Backup J/E 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: Totals (View 2) 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 23) 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.
298
Figure 23 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

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: Type Date Time Backup J/E Total Trans Sent 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 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.
299
Transaction counts are reset under the following conditions: Total Trans Applied After issuing the DMSETPOS, DMMRKPOS, or DMREGPOS 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.
Monitoring Historical Object Throughput

The Historical Object Throughput view (Figure 24) displays the historical throughput for a selected group/journal combination. Historical information is obtained by reading the records created by the batch collection process.
300
Figure 24 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

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: 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. 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
301
Overall Trans/Hr
Current Trans/Hr
Position to date
system will search for activities matching the entered date in the Date column. Position to time 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.
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.
302
Appendix A - Object Types Replicated by iCluster

Object Types Replicated by iCluster
This appendix lists the object types that iCluster can replicate. Object Type Alert table Authorization list Authority holder (see Note 8) Block special file Bind directory Chart format C locale description Class Command definition Connection list (see Note 5) Class-of-service description (see Note 5) Change request descriptor Communications side information Cross-system product map Cross-system product table
System Object Type *ALRTBL *AUTL *AUTHLR *BLKSF *BNDDIR *CHTFMT *CLD *CLS *CMD *CNNL *COSD *CRQD *CSI *CSPMAP *CSPTBL
303
Controller description (see Note 5) Device description (see Note 5) Directory Document Library Object Data area Data queue Edit description Exit registration Forms control table Folder File (see Note 12) Font resource Forms definition Font table resource Graphics symbol set Double-byte character set dictionary Double-byte character set font table Double-byte character set sort table Internet packet exchange description (see Note 5) Job description Job queue (see Note 9) Job scheduler Journal (see Note 10) Library (see Notes 1 and 2) Line description (see Note 5) Machine Advanced 36 machine configuration Menu Mode description (see Note 5) Module
304
*CTLD *DEVD *DIR *DOC *DTAARA *DTAQ *EDTD *EXITRG *FCT *FLR *FILE *FNTRSC *FORMDF *FTR *GSS *IGCDCT *IGCSRT *IGCTBL *IPXD *JOBD *JOBQ *JOBSCD *JRN *LIB *LIND *M36 *M36CFG *MENU *MODD *MODULE
Message file Message queue (see Note 9) Node group Node list NetBIOS description (see Note 5) Network interface description (see Note 5) Network server description (see Note 5) Output queue Overlay Page definition Page segment Printer description group Program Panel group Product availability Print Services Facility Configuration Query form Query manager query Query definition Reference code translation table System/36 machine description Subsystem description Search index Spelling help dictionary SQL package User defined SQL data type Service program Session description Byte Stream File Table
*MSGF *MSGQ *NODGRP *NODL *NTBD *NWID *NWSD *OUTQ *OVL *PAGDFN *PAGSEG *PDG *PGM *PNLGRP *PRDAVL *PSFCFG *QMFORM *QMQRY *QRYDFN *RCT *S36 *SBSD *SCHIDX *SPADCT *SQLPKG *SQLUDT *SRVPGM *SSND *STMF *TBL
305
User index User profile (see Replicating User Profiles for more information) User queue User space (see Note 14) Workstation customization
*USRIDX *USRPRF *USRQ *USRSPC *WSCST Table 3 - Object Types Replicated by iCluster
Since changes to user spaces (*USRSPC) are not usually journaled, iCluster uses polling to keep track of content changes for this type of object.
Notes:
1. 2. iCluster does not replicate system-supplied user profiles. It is important to recognize that replicating library objects (*LIB) does not automatically replicate objects contained in the library. Only the library object is sent to the backup node. To replicate all objects in a library, use the pre-defined value *ALL to define an object specifier that addresses all objects and all object types in a specific library. iCluster does not replicate OS/400 system values. iCluster supports user actions that can be applied to save file objects that are replicated to a backup node. For more information about user actions and how other types of objects can be replicated via save files, see User Actions for Save Files. For configuration objects to be successfully replicated by iCluster, any dependent lines, devices, modes, and so on must already exist on the backup node. Spool files in a replicated output queue (*OUTQ) will only be mirrored when they are created or deleted. iCluster does not mirror spool file updates to backup nodes. Due to OS/400 limitations, spool files containing Intelligent Printer Data Stream (IPDS) data will not be properly replicated. To replicate authority holders, you must specify *AUTHLR as the object type when defining an object specifier (authority holders are not referenced in an object specifier that uses the generic value of *ALL for the object type). iCluster only replicates authority holders for objects of type *FILE. iCluster replicates job queues (*JOBQ) and message queues (*MSGQ), but does not replicate changes to their contents.
3. 4.
5. 6. 7. 8.
9.
10. When replicating journals, each journal can only be mirrored to a library that has the name of the originating library. 11. iCluster does not currently support the mirroring of system-provided authorization lists (*AUTL). iCluster ignores change (ZC) journal entries for authorization list objects. 12. When replicating *FILE objects, there are certain considerations. These considerations are discussed in Database *FILE Objects. 13. The following object types cannot be replicated in a local loopback configuration: *JRN, *LIB, *USRPRF, and configuration objects. 14. For user spaces iCluster supports object-level only change replication and object and content-level change replication. Object-level only support will replicate creation, deletion, restore, and move/rename operations on user spaces. This is suitable for user spaces that are created and filled with data, but the data never changes. Content-level change support for user spaces is based on polling the objects at regular intervals to determine if they have changed. Note that since replication is based on polling, the Status Monitor cannot be relied upon to determine if the user spaces on the backup node are up-to-date.
Appendix B - Important Considerations

iCluster Limits and Recommendations
This topic describes various limits, maximum capacities, and design recommendations that are specific to iCluster. Exceeding these limits can produce unexpected results. See the iSeries Systems Management documentation for iSeries limits and capacities. All iSeries limits apply to iCluster unless stated in this topic.
iCluster Maximum Capacities

This section describes the maximum capacities for iCluster.
Cluster Limits
If your cluster uses the SwitchOver System failover mechanism, then each node cannot have more than 200 links. A link is created by having a node be either the primary or backup node in a group. Local loopback groups count as two links for a node. For example, Figure 26 shows a cluster with four nodes. The TORONTO node has three links, DALLAS has one link, and the NEWYORK and SANJOSE nodes each have two links.
307
Figure 26 Cluster Links If your cluster uses IBM Cluster Resource Services as its failover mechanism, then you cannot have more than 128 nodes in a cluster.
Minimum Staging Store Size

The minimum size of the staging store is directly related to the number of database journals on a node. Use the following formula to calculate the minimum size you need for a staging store: Minimum Size = ( 2 x <database journals> + 1 ) * 16 MB In this calculation, <database journals> is the number of database journals on the node. For example, if you had six database journals on a node, then the node would require a minimum of 208 MB of staging store space.
Uncommitted Transactions
Each journal in a group can have up to one terabyte of uncommitted transactions.
IFS Limitations
iCluster does not support in the following for IFS objects: Replicating symbolic links and hard links. Replicating to a different directory on the backup node. Replicating DLO extended object attributes. Suspending non-journaled IFS objects on the backup node. You must monitor the event log to track replication errors with IFS objects on the backup node. You can still suspend non-journaled library objects on the primary node. The maximum length of path names is 5000 bytes long. The Lock Files on Backup Node and Maximum Refresh Size system values, are not supported for path object specifiers. See Set Cluster System Values for more information about these system values. For more information about path object specifiers, see Work with Path Object Specifiers by Group.
Large Object (LOB) Constraints

The following constraints apply to LOBs:
iCluster stores staged LOB data on the backup node in IFS objects in the following directory: /home/DataMirror/HASUITE/LOB/<primarySN>/<backupNode>/<group>/<journalLib>/<journalName> where sourceSN is the serial number of the primary node, backupNode is the name of the backup node, group is the name of the group, journalLib is the journal library, and journalName is the journal name. This does not affect non-LOB data being replicated from the same database table.
Currently, the maximum store size on the target system does not include IFS space used when 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. HA Suite 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. The default journal iCluster uses for these files must have the RCVSIZOPT parameter of the CHGJRN command set to *MAXOPT2, otherwise iCluster will suspend the file. Consequently, DataMirror recommends that all journals use the highest receiver size option possible.
MQSeries Recommendations
Authority changes made through the GRTMQMAUT and RVKMQMAUT commands are not recorded by MQSeries and are, therefore, not mirrored by iCluster. IBM recommends that the operator use a CL program to apply the two commands to any MQSeries objects on the primary node 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 MQSeries objects. iCluster can replicate this program to the backup node, where it can be run after a switchover. This ensures all authority changes on the primary node are properly applied to the backup node.
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 DMSETSYNC 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 DMSETSYNC command.
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:
Group Name
Type: Character Length: 10 bytes The name of the group in which the failover or switchover occurred.
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 DMADDGRP or DMCHGGRP commands.
WebSphere MQ Support
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, once-only 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. 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: RBDHAMQM 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 nodes WebSphere MQ journal. DMSTRGRP starts the mirroring for the queue manager.
Multiple queue managers are supported in iCluster. Use the DMADDGRP 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 below for more information. Create a local relational database directory entry for each node in the cluster. See Creating a Local Relational Database Directory Entry below for more information.
311
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 below. Complete the steps in the Enabling WebSphere MQ Support section below.
PTFs for WebSphere MQ

Your system administrator should install the appropriate system PTFs before you can mirror WebSphere MQ objects with iCluster. See WebSphere MQ Support, service summary for OS/400 in IBMs online documentation for an up-todate 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. 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.
Enabling WebSphere MQ Support

Follow the procedure below to enable WebSphere MQ support.
Procedure
1. Use the DMADDGRP 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 DMADDGRP command for more information. 2. Use the DMSTRGRP command to start replicating WebSphere MQ objects. See the DMSTRGRP command for more information. MQSeries groups do not support checkpoint user exits. UseYou 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.
313
Index
*
*ACT_PEND, 82 *ACTIVE, 82, 112, 188, 190 *ADDN_PEND, 112 *ADMIN, 262, 263 *AFTER, 84, 96 *ALLOBJ authority, 169, 171 *BASIC, 153, 171 *BOT, 280 *BOTH, 84, 96, 153 *CHANGE, 230 *CHG_PEND, 112 *CHKJRN, 250 *CLUSTER, 68, 69, 74, 91, 92, 105, 115, 120, 172, 177, 188 *CNTRLD, 191, 197 *COMM, 172, 177 *CTRLD, 216 *CURCHAIN, 202, 203 *CURRENT, 202, 229, 250, 253 *DATETIME, 216 *DISABLED, 68, 71, 75, 79, 158, 167 *DLT_PEND, 112 *DLTCMD_PN, 112 *END_PEND, 112 *ERROR, 208 *EXCLUDE, 116, 122, 126, 130 *FAILED, 82 *FILE objects, 52, 307 considerations, 307 database, 52, 53 *FILEATTR, 251, 252, 254, 257 *FULL, 167, 171 *GROUP, 82, 116, 117, 121, 125, 133, 150 *IMMED, 115, 190, 197, 215, 238 *IN_ERROR, 82, 112 *INACT_PND, 82 *INACTIVE, 82, 112 *INCLUDE, 116, 122, 127, 130 *INDOUBT, 112 *INETD, 43 *INIT_PEND, 112 *INVLD, 215 *LAST, 108, 201 *LEVEL1, 37, 91, 103, 161 *LEVEL2, 37, 92, 103, 104 *LIST, 67, 138, 251, 252, 257 *LOCAL, 172, 177 *MAN, 84, 96, 115, 120 *MAX, 84, 96, 153 *NEW, 82 *NOCHG, 67, 74, 153, 185, 188 *NODE, 112, 150 *NOMAX, 157, 167, 213 *NONE, 82, 88, 89, 97, 101, 105, 112, 125, 133, 150, 153, 163, 225, 230, 238, 262, 263 *NOW, 240 *OPERATOR, 262, 263 *PARTITION, 82 *PRIMARY, 67, 74, 153 *PRINT, 171 *REMOTE, 153 *REPL, 172, 176 *RESTORED, 112 *RMV_PEND, 82 *RMVN_PEND, 112 *RRN, 118 *SAVRST, 84, 96, 115, 120, 153 *SECADM authority, 263, 265, 266 *STRT_PEND, 112 *SUCCESS, 208 *SWO_PEND, 112 *SYNC, 84, 96, 153 *SYSBAS parameter, 108 *TODAY, 238, 240 *TOP, 280 *UKEY, 115 *UNKNOWN, 82, 112 *USER, 262, 263
A
activating objects, 217, 219 BSF objects, 219 with generics, 217, 219 active cluster jobs, 181 working with, 181 adding groups, 27 nodes, 28, 33, 34, 67, 69, 70, 72, 73 ADDPFEXPGM - Add Exit Program, 267 addresses, 44 Administrator (*ADMIN), 30, 73, 80, 81, 95, 107, 108, 109, 110, 120, 123, 125, 126, 129, 133, 142, 145, 148, 149, 182, 193, 199, 200, 262, 263, 270 adding privileges, 262 changing privileges, 263 commands requiring privileges, 67, 74, 81, 84, 96, 107, 108, 110, 115, 120, 123, 138, 144, 145, 149, 182, 192, 198, 200, 270 definition, 30 after images, 92, 104, 106 default jo, 84 default journaling, 104 APPL (group by resilient application), 82, 112 application groups, 16 definition, 16 application resiliency, 16 about, 35 applications display group, 143
314
Index
remote journaling, 48, 49 APPLY (journal apply), 225 apply processes, 185, 188, 213, 214, 215 ending, 215 HA_OBJLCK, 213 starting, 186, 188, 213 waiting/retrying, 213 APPNAME (resilient application name), 138, 144, 145, 149, 195, 197, 198 ASWUSREXIT (after user exit), 84, 96 asynchronous journaling, 48 audit journal, 209, 211 verifying, 209 AUDQTEMP (audit QTEMP), 209 AUDSPLF (audit spool file functions), 209 AUTH (security level), 262, 263 AUTHCODE (authorization code), 74 authorization codes, 15, 74 changing, 74 specifying, 15 automatic failover, 20
C
capacities, 308 CFGSRCHLD (hold configuration objects), 67, 74 change group primary node, 111 changing IP addresses, 44 changing nodes, 33 changing the status of a node, 67, 74 CHGHAJRN - Change Journal Receiver, 205 CHGHASMON - Change History Monitor on Primary Node, 238 clear event log, 176 CLSTR (cluster name), 182 CLUSEVNT (cluster event messages), 171, 176 cluster, 16, 17, 18, 19, 20, 31, 153, 154, 155, 157, 158, 159, 160, 161, 162, 163, 164, 166, 167, 169, 181, 182 commands, 153, 157, 182 configuration, 16 definition, 16 deleting, 182 jobs, 181 name, 182 rejoining, 194 security, 30 cluster definition, 182 deleting, 182 cluster jobs, 181 working with, 181 cluster operations, 182, 183, 184, 185, 188, 190, 194, 195, 197, 198, 199 end for group, 190 end for resilient application, 197 ending at node, 184 rejoin at node, 194 start for group, 185 start for resilient application, 195 starting at node, 183 stopping all, 182 switchover, 192, 193, 194, 198, 199 Cluster Resource Services, 20, 32 cluster security, 30, 262, 263, 265, 266 commands, 262, 264, 265, 266 definition, 30 cluster system values, 153 event log, 153, 159, 163, 164, 167 object, 153, 154, 156, 157, 158, 159, 167 physical file, 153, 157, 163, 167 setting, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167 spool file, 153, 155, 159, 160, 167 cluster versions, 43 CMTLVL (commitment control), 84, 96 COMMEVNT (communications event messages), 171, 176 commitment control, 37, 91, 103, 106 considerations, 37 levels of, 37 suspended files, 37 Common Options for all Views, 276 communications, 270, 271 restoring registries, 270 configuration objects, 56, 69, 71, 75, 79, 229, 230 considerations, 56
315
B
backup nodes, 16, 108, 110, 139, 141, 192, 193, 237, 245, 250, 252, 253, 254, 257, 310 adding to recovery domain, 108 arguments to user exit programs, 310 definition, 16 object list comparison, 245 removing from recovery domain, 110 resilient applications, 142 role switching, 192 synchronization check, 250, 253 working with monitor, 237 BACKUPS (backup node), 84, 138 before images, 92, 104 BSF end journaling, 212 start journaling, 211 BSF objects status, 243, 244 BSWUSREXIT (before user exit), 84, 96 BY (list filter), 82, 112, 125, 133, 150 Byte Stream File (BSF) objects, 23, 54, 126, 129, 130, 133, 153, 163, 212, 219, 221 activating, 219 changing selection to group, 130 default journal, 153 de-selecting from group, 129 display recording, 212 ending recording, 212 initial synchronization, 55 journaling, 54, 55 limitations, 55 mirroring, 54, 55 path object specifiers, 25 refresh before mirroring, 55 selecting to group, 126 status monitor support for, 55 suspended, 222 working with, 133
creating, 229 dependencies when replicating, 56, 304 holding, 67, 74 owner, 229 Configuring Remote Journaling, 48 contacting a specified node, 178 controlled stop, 191, 215 apply processes, 215, 216, 217 cluster operations, 190, 191, 192 copyright notice for DataMirror, 8 CRTCFGOBJ - Create Configuration Object, 229 CRTSTORLIB (create staging store library), 67
D
data area and data queue journaling, 12, 179 data view, 280, 281, 282 real time object latency, 280 real time object position and totals, 281 real time object throughput, 282, 283 Database *FILE objects, 52 database files, 58 database journal, 91, 94, 102, 103, 106 default, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106 DataMirror, 15 contacting, 15 copyright and trademark notices, 8 DATE (synchronization check start date), 250, 253 date and time, 169 daylight saving time, 169 changing time to account for, 169 decoupling from IBM Cluster Resource Services, 32 definition manager start, 182 DELAY (delay period), 190, 197 delete cluster, 182 DESC (description), 67, 74, 84, 96, 115, 120, 126, 130, 138, 145 DETAIL (detail level), 171 DFTDBJRN (default database journal), 84, 96 disclaimers, 8 distress signal, 23 DLTRCV (delete journal receiver), 205 DMACTBSF - Activate BSF Object, 219 DMACTOBJ - Activate Object, 217 DMADDAPP - Add Resilient Application, 138 DMADDBACK - Add Backup Node to Recovery Domain, 108 DMADDBSF - Add Path Object Specifier to Group, 126 DMADDNODE - Add Node, 67 DMADDSWDEV - Add Switchable Device Entry to Group, 134 DMADDUSR - Add User, 262 DMCHGAPP - Change Resilient Application, 145 DMCHGBSF - Change Path Object Specifier, 130 DMCHGNODE - Change Node, 74 DMCHGOBJSL - Change Object Selection to Group, 120 DMCHGROLE - Change Group Primary Node, 111 DMCHGSWDEV - Change Switchable Device Entry for Group, 136 DMCHGTIME - Change System Date and Time, 169 DMCHGUSR - Change User, 263
316
DMCLRLOG - Clear Cluster Event Log, 176 dmcluster, 27, 67, 74, 180, 263, 265, 266 DMDLTCLSTR - Delete Cluster, 182 DMDSELOBJ - De-select Objects from Group, 123 DMDSPAPPGP - Display Resilient Application Group, 143 DMDSPASPGP - Display Switchable Device Group, 135 DMDSPGRP - Display Group, 96 DMDSPLOG - Display Cluster Event Log, 171 DMDSPNODE - Display Node, 73 DMENDAPP - End Cluster Operations for Resilient Application, 197 DMENDAPY - End Replication Apply Processes, 215 DMENDGRP - End Cluster Operations for Group, 190 DMENDNODE - End Cluster Operations at Node, 184 DMGENEXC - Generate Exceptions, 200 DMLOGENT - Log Journal Entry, 234 DMMRKPOS - Mark Current Journal Positions, 204 DMNSRC (use group), 84, 138 DMRBDNODE - Rebuild Node, 268 DMREGPOS - Register Positions, 269 DMREJOIN - iCluster Rejoin Cluster, 194 DMRMVAPP - Remove Resilient Application, 149 DMRMVBACK - Remove Backup Node from Recovery Domain, 110 DMRMVBSF - Remove Path Object Specifier from Group, 129 DMRMVGRP - Remove Group, 107 DMRMVNODE - Remove Node, 81 DMRMVSWDEV - Remove Switchable Device Entry from Group, 137 DMRMVUSR - Remove User, 265 DMSCRPT - Sync Check Report, 258 DMSCRPTNTV - Sync Check Report for Native Objects, 259 DMSETPOS - Set Journal Start Position, 201 DMSETPRIM - Prepare Primary Node, 200 DMSETSVAL - Set Cluster System Values, 153 DMSETSYNC - Set Sync Point, 225 DMSNDOBJ - Send Object Immediately, 223 DMSTRAPP - Start Cluster Operations for Resilient Application, 195 DMSTRAPY - Start Replication Apply Processes, 213 DMSTRDM - Start Definition Manager, 181 DMSTRGRP - Start Cluster Operations for Group, 185 DMSTRNODE - Start Cluster Operations at Node, 183 DMSTRREPL - Start Replication, 188 DMSTRSWO - Switchover Group, 192 DMSUSBSF - Suspend BSF Object, 221 DMSUSOBJ - Suspend Object, 220 DMSWOAPP - Switchover Resilient Application, 198 DMSYSINF - System Information, 182 DMUPDAPP - Update Resilient Application, 144 DMWRKAPP - Work with Resilient Applications, 150 DMWRKBSF - Work with Path Object Specifiers, 133 DMWRKGRP - Work with Groups, 112 DMWRKNODE - Work with Nodes, 82 DMWRKOBJ - Work with Object Specifiers, 125 DMWRKOBJST - Work with Object Status by Group, 244 DMWRKUSR - Work with Users, 266 documentation
Index
conventions, 9 printing, 10 Documentation Conventions, 9 DRAIN (drain staging store), 200 DSPHABRCD - Display Recording for BSF Object, 212 DSPHAPOS - Display Journal Information, 207 DSPHASC - Display Sync Check, 245 DSPHASMON - Display Source Monitor, 236
E
end cluster operations at node, 184 for group, 192 for resilient application, 197 ENDDATE (apply process end date), 215 ENDDTE (monitor end date), 238, 240 ENDHABRCD - End Recording for BSF Object, 212 ending nodes, 45 ENDTIM (monitor end time), 238, 240 ENDTIME (apply process end time), 215 event logs, 60, 153, 171, 176 about, 60, 171, 175 clearing messages, 176 displaying messages, 171 system values, 153 EVNTLOG (event lo, 153 EVNTTYPE (event type), 171, 176 EXITDATA (user exit data), 84, 96 expand generic names, 123
commands, 115, 126, 129, 130 definition, 16 de-selecting BSF objects from, 129 de-selecting objects from, 123 display resilient applications, 143 displaying, 96 ending apply processes, 215 ending operations, 190 initializing selected objects, 230 marking journal positions, 204 object status, 244 remote journaling, 48 removing, 107 replication, 16, 17, 18, 19 resilient applications, 143 retrieving journal position, 208 role switching, 192, 198 selecting BSF objects to, 126 selecting objects to, 115 setting journal position for, 201 setting primary node, 200 setting synchronization point for, 225 starting apply processes, 213 starting operations, 183, 185 starting replication, 188 starting synchronization check, 250, 253 switchable devices, 135 working by nodes, 82 working by objects, 125 working by resilient applications, 150 working with, 112 working with BSF objects, 133
F
failover, 20, 22, 23 definition, 20 remote journals, 49 failover mechanisms, 16, 20, 32 filtering event messages, 171 by event type, 171 by message ID, 171 FORCE (force role switch), 200
H
HA_OBJLCK, 213 HABSFJRN, 153 HAPNGTCP, 178 historical latency, 273, 298 historical object position, 274, 299, 300 historical object throughput, 272, 301, 302 historical object totals, 272, 299 Historical Statistics Views, 297 history monitor, 238, 239, 240 changing on primary node, 238 polling interval, 238 setting start date, 238 setting start time, 238 setting stop date, 238 setting stop time, 238 HOST (TCP/IP host name), 180 HTML Help printing, 10
G
generics activating objects, 217, 219 path object specifiers, 26, 27 GROUP (group), 82, 84, 96, 107, 115, 120, 123, 125, 126, 129, 130, 133, 150, 185, 188, 190, 192, 200, 201, 204, 208, 213, 215, 217, 219, 220, 221, 225, 230, 238, 250, 253 groups, 17, 18, 19, 82, 84, 85, 86, 88, 89, 90, 91, 92, 93, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 107, 108, 112, 113, 114, 115, 116, 121, 123, 126, 129, 130, 134, 150, 183, 185, 186, 187, 188, 190, 191, 192, 193, 200, 201, 204, 208, 214, 215, 216, 217, 225, 230, 236, 238, 240, 250, 253, 310 adding, 27, 84, 85 arguments to user exit programs, 310, 311 changing, 96 changing object selection, 120 changing selection of BSF objects to, 130 collecting monitor data, 238
I
IASP, 109 backup, 108, 109 IBM Cluster Resource Services, 32, 33 IBM CRS, 20, 23, 32, 33 iCluster, 12, 14, 15, 27, 30, 43, 62 about, 12 authorization codes, 15 commands, 62, 63, 64, 65, 66, 67
317
documentation, 14 installing, 15 list of commands, 62 menus, 27 object types replicated by, 307 product library, 27 re-starting after IPL, 43 security, 30 technical support for, 15 working with, 27 iCluster Administrator, 14, 262, 263 documentation, 14 iCluster considerations, 35 iCluster quick start, 27 IFS (Integrated File System), 58, 126, 129, 130, 212, 219, 221 immediate stop, 191, 215 INCFLG (include flag), 115, 120, 126, 130 INITHAOBJ, 23, 230 initial synchronization, 34 mirroring, 34, 35 refresh before mirroring, 34 system values, 34 initialize objects, 230 installation library, 14 IP addresses, 44, 67, 74, 138, 145 IPADDR (primary IP address), 67, 74 IPADDR2 (secondary IP address), 67, 74
setting start position, 201 start processing date, 201 start processing time, 201 system audit, 201, 202 verifying audit, 209 JRN (journal name), 201 JRNBA (journal before/after images), 84, 96 JRNENTRY (journal entry), 208 JRNHADADQ - Journal Data Areas and Data Queues, 179 JRNPOS (journal position), 201 JRNRCV (journal receiver name), 201 JRNRCVLIB (journal receiver library), 208 JRNRCVNME (journal receiver name), 208
L
latency, 272, 273, 278, 279, 280 monitoring, 42, 43 LIB (TCP/IP listener job library), 180 licensing, 15 limits, 308 LOB support, 57 Local Journaling, 45, 46 local loopback replication, 19 logical files, 52 refreshing, 52
J
job description, 67, 74, 179 for iCluster jobs, 178 for replication, 68, 74 for TCP/IP listener job, 180 JOBD (job description name), 178, 180 JOURNAL (journal name), 205, 207, 208 journal data areas and data queues, 179 journal receivers, 201, 205, 206, 207, 208 changing, 205 database, 201 displaying information, 207 managing, 205 obsolete, 205 processed, 205, 206 retrieving information, 208 system audit, 201, 205 journaling in iCluster, 45, 46, 47 remote, 48, 49 journals, 185, 188, 195, 201, 202, 203, 205, 207, 208, 209, 212, 225 applying, 225 BSF objects, 163, 167, 211, 212 database, 201, 202 displaying information, 207, 212 managing journal receivers, 205 marking current positions, 185, 188, 195, 204 physical files, 153 position number, 201 receiving, 225 retrieving information, 208 scraping, 228 setting checkpoints, 225
318
M
manual failover, 20 master node, 17, 67, 72, 80, 153 definition, 16 maximum capacities, 308 MAXOBJINSF (max. objects in save file), 84, 96 MAXSPLWAIT (max. wait for spool file replication), 84, 96 members, 53 message levels, 174 message queues, 84, 96 mirroring, 34 definition, 34 monitoring, 280 active backup nodes, 280 backup node, 237, 238 latency, 41, 42, 43 out-of-sync objects, 39 primary node, 236, 237, 272, 273 real time object latency, 280 real time overall latency, 278 Monitoring Latency, 41 Monitoring Out-of-Sync Objects, 39 monitoring replication, 60 using event logs, 60 using sync check, 60 using the Status Monitor, 60 MQSeries, 312, 314 enabling, 312, 313 introduction, 312 limitations, 312 pre-requisites, 312, 313 rebuilding MQSeries environment, 151 MSGLVLS (message levels), 171 MSGQUEUE (message queue), 84, 96
Index
N
NAME (group name), 108, 110 native objects status, 242, 243 native trigger support, 12 NBRPKT (number of packets), 178 network addresses, 44 new features, 12 NODE (node name), 67, 73, 74, 81, 82, 108, 110, 112, 150, 183, 184, 213, 215 nodes, 16, 17, 18, 19, 43, 67, 73, 76, 77, 80, 81, 82, 83, 108, 110, 112, 150, 184, 185, 200, 208, 216, 217, 236, 237, 238, 241, 250, 253 active status, 183 adding, 27, 34, 67, 68, 69 adding backup to recovery domain, 108 authorization code, 79 changing, 34, 74, 75, 79 changing history monitor, 238 definition, 16 deleting monitor information, 240 description, 67, 68, 71, 74, 75, 79 displaying, 73 ending, 45 ending apply processes, 215 ending operations, 184 IP address, 67, 68, 70, 71, 74, 77, 79 master, 67, 72, 80 prerequisites, 34 removing, 45, 81 removing backup from recovery domain, 110 requirements, 34 re-starting iCluster after IPL, 43 retrieving journal position, 208 role, 108 setting primary in group, 200 staging store size, 67, 74 starting operations, 183 starting synchronization check, 250, 253 stopping, 45 upgrading, 43, 45 working by group, 112 working by resilient applications, 150 working with, 82 working with monitor, 236, 237 notices for DataMirror, 8
O
OBJ (object name), 115, 120, 123, 217, 220, 229 OBJ (object system values), 153 OBJATTR (object attribute), 115, 120, 123 object specifiers, 23, 24, 25, 26, 52, 115, 116, 122, 123, 125, 245, 256 attributes, 24, 120, 121, 124 changing selection, 120 changing while replication is active, 23 commands, 116, 117, 119 definition, 23 de-selecting from groups, 123 for *FILE objects, 52, 54 generic, 23, 25, 26 initializing, 23
polling interval, 120, 122 rules of precedence, 25 selecting to groups, 115 synchronization check, 245, 253 target library, 120, 121 working with, 125 object types replicated by iCluster, 304 objects, 23, 24, 25, 26, 37, 38, 56, 58, 59, 84, 85, 87, 89, 91, 92, 97, 98, 101, 102, 103, 105, 106, 115, 116, 117, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 209, 210, 211, 217, 218, 219, 220, 222, 230, 231, 245, 253, 254, 255, 256, 257, 258, 272, 273, 280, 281, 282, 286, 287, 290, 291 activating, 217 activating BSF object, 219 activating file object, 37 attributes, 23, 116, 120, 123, 224, 253, 254, 256, 258 auditing in QTEMP, 209 changing selection, 120, 130 commands, 115, 121, 123, 126, 130 configuration, 56, 69, 71, 75, 79, 229, 230 de-selecting from groups, 123, 129 initializing, 230 Integrated File System (IFS), 58, 126, 129, 130 replicated by iCluster, 304 save files, 58, 59 selecting to groups, 115, 126 status, 286, 287, 290 status by group, 244 suspending, 220 suspending BSF objects, 221 suspending file object, 37 synchronization check, 245, 253, 272, 280, 281, 282 system values, 153 types, 24, 25, 115, 118, 120, 124, 253, 307 working with, 125 OBJSPEC (object specifier), 253 OBJTYPE (object type), 115, 120, 123, 217, 220, 229 OMIRROR, 263, 265, 266 on-line information, 14 OPER (operational system values), 153 operating system, 43, 44 Operator (*OPERATOR), 30, 126, 184, 185, 192, 197, 198, 204, 205, 215, 217, 219, 220, 221, 229, 262, 263 adding privileges, 262 changing privileges, 263 commands requiring privilege, 183, 184, 185, 190, 195, 197, 201, 204, 213, 215, 217, 219, 220, 221, 225 definition, 30 OPTION (stopping operations), 190, 197, 215 OS/400 Cluster Resource Services, 11, 12, 20, 183, 184, 185, 190, 192 out-of-sync objects, 39 OUTPUT (output device), 171 OVRSTOP (override stop date/time), 213 OWNER (configuration object owner), 229
P
PASSWORD (password), 262, 263 PATH (IFS path), 126, 129, 130, 212, 219, 221 path object specifiers, 23, 26, 133, 134 journaled, 27, 127, 128 naming conventions, 26
319
non-journaled, 27, 127 polling interval, 127, 128, 130, 132 working with, 23, 26, 133 PDF files printing, 10 PF (physical file system values), 153 PFKEY (physical file key), 115 PFUPDMTD (physical file update method), 115 physical files, 52, 89, 101, 118, 120, 153, 161, 162, 163, 167 refresh method, 52, 115, 120 system values, 153 unique key, 115 update method, 118, 119 ping, 178 using TCP, 178 PKTLEN (packet length), 178 POLINT (polling interval), 238 polling interval, 89, 101, 106, 117, 120, 239 changing, 103, 122 defining, 115 in Status Monitor, 238 POLLINT (polling interval), 84, 96, 115, 120 PORT (port number), 67, 74 port number, 68, 71, 74, 178, 179 position to field, 280 prepare primary node after failover, 200 PRGHASC - Purge Sync Check Results, 261 PRGHASMON - Purge History Monitor on Primary Node, 240 primary nodes, 16, 81, 138, 193, 200, 236, 238, 240, 245, 250, 253 changing history monitor, 238 definition, 16 deleting monitor information, 240 object list comparison, 245 preparing, 200 removing, 81 resilient applications, 138 role switching, 192, 198 setting in group, 200 synchronization check, 250, 253 working with monitor, 236 PRIMNODE (primary node), 84, 138 print device, 171 for printing event messages, 171 printing documentation, 10 PRODLIB (product library), 67, 138, 144 product library, 67, 138, 144 proprietary and confidential information, 8
commands requiring, 262, 263, 265, 266 QSRV, 169, 171 QSYSOPR, 171 QSYSWRK, 181 QTEMP, 210, 211 auditing objects in, 209 QTIME, 169 quick start, 27
R
RBDHAMQM - Rebuild iCluster MQSeries, 151 Reading Status Information, 283 real time object latency, 280 real time overall latency, 278 real time position, 281 Real Time Statistics Views, 274 real time throughput, 282 real time totals, 281 rebuilding MQSeries, 151 MQSeries version, 151 queue manager name, 151 RECEIVE (journal receive), 225 receiver, 299 recovery domain, 16, 108, 109, 110 adding backup nodes, 108 definition, 16 removing backup nodes, 110 refresh, 34, 35, 92, 104, 117, 120, 155, 157, 162, 167, 185, 186, 187, 195, 196, 218, 219 before mirroring, 34, 153, 186, 187, 189, 190, 196, 219 definition, 34 logical files, 52 maximum size of, 153 physical file method, 84, 96, 115, 120, 153 suspended file, 219 suspended object, 218 REFRESH (refresh before mirroring), 185, 188, 195 refreshing, 34, 52, 53 logical files, 53 physical files, 52, 53, 54 refresh-only groups, 16 rejoining a cluster, 194 relative record number, 118 remote journaling, 48 configuring, 48 journaling in iCluster, 45 role switching, 49 removing nodes, 45 REPLEVNT (replication event messages), 171, 176 replicating, 56, 57, 58, 307 configuration objects, 307 object types, 304, 307 QDLS objects, 59 triggers, 57, 58 user profiles, 57 replication, 34, 188, 189, 190 about, 34 monitoring, 60 object types, 304 send objects to target, 223 starting, 188 REPLJOBD (replication job description), 67, 74 requirements
Q
QAUDCTL, 181 QAUDLVL, 181 QCMN, 181 QCSTHAAPPI, 138, 144, 149 QCSTHAAPPO, 138 QDATE, 169 QDLS objects replicating, 59 QPGMR, 169, 171 QSECOFR, 263, 265, 266
320
Index
nodes, 33 resilient applications, 35, 110, 188, 197, 198 adding, 138 changing, 147 display group, 143 ending operations, 197 library, 138, 140, 141, 145 removing, 149 removing backup node, 110 role switch user exit programs, 138, 144, 145, 149 role switching, 198 starting operations, 195 starting replication, 188 takeover IP address, 138, 145 updating, 144 working by groups, 112 working by nodes, 82 working with, 150 RESULT (command result), 208 retrieve recovery checkpoint, 232 for CL programs, 232 RFSH (refresh suspended object), 217 RMTLIB (remote node product library), 178 RMTNME (remote node host name), 178 RMTPRT (remote node port number), 178 RMVPFEXPGM - Remove Exit Program, 267 ROLE (node role), 108 role switching, 84, 96, 192, 200, 311 user exit programs, 311 Role Switching with Remote Journals, 49 roles, 108 setting, 109 ROLESWITCH (role switch), 84, 96 RTVHAPOS, 208 RTVRCVPT - Retrieve Recovery Checkpoint, 231 RTVRCVPTR - Retrieve Recovery Checkpoint CL Program, 232
S
SAVACT (update/save object), 84, 96 save files, 58, 84, 96 user actions, 59 SAVFEXIT, 58, 59 SCRAPE (journal scrape), 225 SCTYPE (synchronization check type), 250, 253 security levels, 30 *SECADM, 30, 263, 265, 266 Administrator (*ADMIN), 30, 67, 74, 81, 84, 96, 107, 108, 110, 115, 120, 123, 129, 130, 138, 144, 145, 149, 169, 182, 192, 198, 200, 262, 263 Operator (*OPERATOR), 30, 188, 190, 195, 197, 201, 204, 213, 215, 217, 219, 220, 222, 225, 262, 263 QSECOFR, 30, 262, 263, 266 User (*USER), 30, 73, 82, 96, 112, 125, 133, 150, 262, 263 SELSCATTR - Select Sync Check Attributes, 247 SERVICE - TCP/IP service name, 180 SETHAREG - Restore Communications Registries, 270 setting auditing levels, 209 date and time, 169 synchronization point, 225 simplified Status Monitor, 236
SOS, 16, 20, 32, 33 SOURCE - primary node name, 208, 230, 238, 250, 253 specifying objects, 27 SPLACTWAIT (max. wait for spool file replication), 84, 96 SPLF (spool file system values), 153 spool files, 84, 96, 153, 155, 159, 160, 209 auditing functions, 209 system values, 153, 165, 166 staging store, 51, 52, 74, 76, 79, 200, 213, 214, 215 allocation, 51 considerations, 52 draining, 200 ending apply processes, 215 force draining, 214 library, 68, 69, 71 size, 69, 71, 76, 79 starting apply processes, 213 start definition manager, 181, 182 start cluster operations at node, 184 for group, 185 for resilient application, 195 starting journal positions, 269, 270 registering, 269 starting replication, 188 with refresh, 188 Starting Replication after Setting the Journal Position, 39 Starting Replication and Journal Position, 39 status BSF objects, 243 group, 244 journal, 242 native objects, 242 object by group, 244 object status, 242 path objects, 243 Status Monitor, 237, 238, 241, 273, 282, 283, 290, 299, 301, 303 active backup nodes, 281, 282 deleting on primary node, 240 historical latency, 298 historical position, 299 historical position and totals, 299 historical throughput, 301 historical totals, 299 object status, 286, 287 on backup node, 237 on primary node, 236 real time position, 281 real time throughput, 282 real time totals, 281 synchronization check, 280, 281, 282 working with, 236, 237, 272 status of apply processed, 280 STGSTORLIB (staging store library), 67 STGSTORSZ (staging store size), 67, 74 stopping nodes, 45 STRAPY (start apply process), 185, 188 STRDATE (start date), 201 STRDTE (monitor start date), 238 STRHABRCD - Start BSF Recording, 211
321
STRHASC - Start Sync Check, 250 STRHASCUSR - Start User Sync Check, 253 STRHATCP - Start TCP/IP Listener, 180 STRSBS (start subsystem), 43 STRTCP (start TCP/IP), 43 STRTCPSVR (start TCP/IP server), 43 STRTIM (monitor start time), 238 suspended objects, 38, 217, 219, 220, 221, 286 activating, 217, 219 Byte Stream File (BSF), 219, 222 consideration, 37 reason codes, 287 refresh after activating, 217 swi, 96 switchable device entries, 134, 136, 137 adding, 134 changing, 136 removing, 137 switchable device group, 16 definition, 16 switchable devices display group, 135 switchable resources, 69, 71, 76, 79 enabling and disabling, 67, 74 switchover, 20, 22, 23, 192, 198 definition, 20 for groups, 192 for resilient application, 198 initiating, 192, 198 remote journals, 50 SwitchOver System - SOS, 16, 20, 32 sync check, 39, 40, 245, 247, 249, 250, 251, 252, 253, 254, 255, 256, 257, 258 adding object specifiers, 115 de-selecting object specifiers, 123 displaying results of, 245 object differences, 245 object list comparison statistics, 245 object list summary, 245 objects not found, 245 removing object specifiers, 123 selecting attributes, 247 selecting object specifiers, 115 starting, 250, 253 types, 250, 253, 256 working with objects, 125 SYNCHATRG - Synchronize Triggers, 233 synchronization point, 225, 310 setting, 226, 227 user exit programs for, 225, 310 synchronizing triggers, 233 synchronous journaling, 48 system date/time, 169 changing, 169, 170 system object types, 304 system trigger support, 12 SYSVAL (system date/time), 169
host name, 181 job description, 180, 181 listener job library, 180 pinging, 178 re-starting after node IPL, 43 service name, 181 starting listener job, 43, 180 technical support, 14, 15 throughput, 302 TIME (synchronization check start time), 250, 253 TKOVRIPADR (takeover IP address), 138, 145 trademark notice for DataMirror, 8 Training and Education, 15 triggers, 200, 233, 234 disabling, 200 enabling, 200 TRIGGERS (enabling/disabling triggers), 200 Troubleshooting, 14 tutorial, 27, 28, 29
U
unique key, 53, 119 update methods, 52, 115 relative record number (RRN), 115 unique key, 52, 115 upgrading nodes, 43, 45 USEDFT (use default sync. check attribute settings), 247 USEMARKED (use marked journal positions), 185, 188, 195 User (*USER), 30, 73, 83, 114, 126, 134, 151, 176, 178, 262, 263 adding privileges, 262 changing privileges, 263 commands requiring privileges, 73, 82, 96, 112, 125, 133, 150, 171, 176 definition, 30 user exit programs, 86, 89, 98, 100, 226, 310, 311 data, 89, 90, 91, 92, 100, 102, 105, 106, 225, 228, 311, 312 role switch, 86, 88, 89, 98, 99, 100, 311 synchronization point, 225, 310 user profiles, 68, 71, 75, 79, 158, 159, 167 authorization lists, 159, 167 Q* user profiles, 153 replication level, 158 status, 68, 70, 71, 75, 77, 78, 79, 158, 159, 164, 167 USERID (user identifier), 262 users, 262, 263, 265, 266 adding, 262 changing, 263 removing, 265 working with, 266 USRDATA (user exit program data), 225 USREXIT (user exit program), 225 USRPRFSTS (user profile status), 67, 74
T
takeover IP address, 138, 145, 146 TARGET (node name), 208, 230, 238, 240, 250, 253 target libraries, 115 TCP/IP, 43, 179, 180, 181
322
V
VALUE (date/time value), 169 versions, 43 VFYHAJRN - Verify Audit Journal, 209 Viewing Sync Check, 41
Index
W
wildcards, 217, 219 Working with BSF Status, 291 Working with Object Status for Groups, 292 WRKHABSFST - Work with BSF Status, 243 WRKHAJOB - Work with Active Cluster Jobs, 181 WRKHAOBJST Work with Object Status, 242
WRKHASMON - Work with Status Monitor on Primary Node, 236 WRKHATMON - Work with Status Monitor on Backup Node, 237 www.datamirror.com, 14
X
XDMCLUSTER, 43
323

Icluster Commands4 0

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Icluster Commands4 0

Uploaded by

Copyright:

Available Formats

DataMirror iCluster

iCluster - Commands Guide

Remote Journaling ............................................................................................................................... 47

Group Commands ................................................................................................................................ 83

Native AS/400 Object Commands...................................................................................................... 114

Byte Stream File (BSF) Commands ................................................................................................... 125

iCluster - Commands Guide

Switchable Device Commands........................................................................................................... 133

Resilient Application Commands........................................................................................................ 137

MQSeries Commands ........................................................................................................................ 150

Administration Commands ................................................................................................................. 151

Cluster Operation Commands ............................................................................................................ 182

Replication Operation Commands...................................................................................................... 200

Status and History Monitor Commands.............................................................................................. 235

Sync Check Commands ..................................................................................................................... 244

iCluster - Commands Guide

Registered iCluster User Commands ................................................................................................. 261

Exit Program Commands ................................................................................................................... 266

iCluster for Supported External Storage Systems.............................................................................. 267

Other Commands ............................................................................................................................... 269

Monitoring Object Status .................................................................................................................... 285

Monitoring Historical Statistics............................................................................................................ 296

Index ......................................................................................................................................................... 314

iCluster - Commands Guide

iCluster - Commands Guide

Printing DataMirror Documentation

iCluster - Commands Guide

New Features in iCluster

Optimization for Database Apply Updates

Backup Monitor and Object Status Monitor

New Performance System Values

See DMSETSVAL for more information.

iCluster - Commands Guide

CHKJRN Parameter and DMMRKPOS Processing

Online Information and Technical Support

Training and Education

Authorization Codes and Licensing

iCluster - Commands Guide

Chapter 2 - Working with iCluster

Chapter 2 - Working with iCluster

Figure 1 A Four Node Cluster

iCluster - Commands Guide

Chapter 2 - Working with iCluster

Figure 4 Specifying Replication Objects

Local Loopback Replication

iCluster - Commands Guide

Failovers and Switchovers

Figure 5 Initial Group Replicates from TORONTO to NEWYORK

Chapter 2 - Working with iCluster

Figure 6 NEWYORK Becomes the Primary Node after TORONTO Fails

Figure 7 After Repairing TORONTO, it Becomes NEWYORKs Backup Node

iCluster - Commands Guide

Scenario 1: SOS Cannot Communicate with the Primary Node

Scenario 3: IBM CRS Loses Communication with the Primary Node

Chapter 2 - Working with iCluster

Object Specifiers and Types

Constructing Object Specifiers

iCluster - Commands Guide

Object SRCLG M* M3909

Library OLG TEST TEST

Object Type *FILE *FILE *PNLGRP

HLPA* HLPAT* HLPAT

HP1 HP1 HP1

Object Type FILE FILE *PNLGRP

PNLGRP PNLGRP *PNLGRP

ALL ALL M3* ALL S1 H

JOBD ALL ALL ALL ALL PGM