Installation Guide

Installation Guide

Replication Agent for DB2 UDB for OS/390

12.5

OS/390

DOCUMENT ID: 34256-01-1250-01

LAST REVISED: December 2002

Copyright © 1989-2002 by Sybase, Inc. All rights reserved.

This publication pertains to Sybase software and to any subsequent release until otherwise indicated in new editions or technical notes. Information in this document is subject to change without notice. The software described herein is furnished under a license agreement, and it may be used or copied only in accordance with the terms of that agreement.

To order additional documents, U.S. and Canadian customers should call Customer Fulfillment at (800) 685-8225, fax (617) 229-9845.

Customers in other countries with a U.S. license agreement may contact Customer Fulfillment via the above fax number. All other international customers should contact their Sybase subsidiary or local distributor. Upgrades are provided only at regularly scheduled software release dates. No part of this publication may be reproduced, transmitted, or translated in any form or by any means, electronic, mechanical, manual, optical, or otherwise, without the prior written permission of Sybase, Inc.

Sybase, the Sybase logo, AccelaTrade, ADA Workbench, Adaptable Windowing Environment, Adaptive Component Architecture, Adaptive Server, Adaptive Server Anywhere, Adaptive Server Enterprise, Adaptive Server Enterprise Monitor, Adaptive Server Enterprise Replication, Adaptive Server Everywhere, Adaptive Server IQ, Adaptive Warehouse, Anywhere Studio, Application Manager, AppModeler, APT Workbench, APT-Build, APT-Edit, APT-Execute, APT-FORMS, APT-Translator, APT-Library, Backup Server, BizTracker, ClearConnect, Client-Library, Client Services, Convoy/DM, Copernicus, Data Pipeline, Data Workbench, DataArchitect, Database Analyzer, DataExpress, DataServer, DataWindow, DB-Library, dbQueue, Developers Workbench, Direct Connect Anywhere, DirectConnect, Distribution Director, e-ADK, E-Anywhere, e-Biz Integrator, E-Whatever, EC-GATEWAY, ECMAP, ECRTP, eFulfillment Accelerator, Embedded SQL, EMS, Enterprise Application Studio, Enterprise Client/Server, Enterprise Connect, Enterprise Data Studio, Enterprise Manager, Enterprise SQL Server Manager, Enterprise Work Architecture, Enterprise Work Designer, Enterprise Work Modeler, eProcurement Accelerator, EWA, Financial Fusion, Financial Fusion Server, Gateway Manager, GlobalFIX, ImpactNow, Industry Warehouse Studio, InfoMaker, Information Anywhere, Information Everywhere, InformationConnect, InternetBuilder, iScript, Jaguar CTS, jConnect for JDBC, MainframeConnect, Maintenance Express, MDI Access Server, MDI Database Gateway, media.splash, MetaWorks, MySupport, Net-Gateway, Net-Library, New Era of Networks, ObjectConnect, ObjectCycle, OmniConnect, OmniSQL Access Module, OmniSQL Toolkit, Open Biz, Open Client, Open ClientConnect, Open Client/Server, Open Client/Server Interfaces, Open Gateway, Open Server, Open ServerConnect, Open Solutions, Optima++, PB-Gen, PC APT Execute, PC Net Library, Power++, power.stop, PowerAMC, PowerBuilder, PowerBuilder Foundation Class Library, PowerDesigner, PowerDimensions, PowerDynamo, PowerJ, PowerScript, PowerSite, PowerSocket, Powersoft, PowerStage, PowerStudio, PowerTips, Powersoft Portfolio, Powersoft Professional, PowerWare Desktop, PowerWare Enterprise, ProcessAnalyst, Rapport, Report Workbench, Report-Execute, Replication Agent, Replication Driver, Replication Server, Replication Server Manager, Replication Toolkit, Resource Manager, RW-DisplayLib, S-Designor, SDF, Secure SQL Server, Secure SQL Toolset, Security Guardian, SKILS, smart.partners, smart.parts, smart.script, SQL Advantage, SQL Anywhere, SQL Anywhere Studio, SQL Code Checker, SQL Debug, SQL Edit, SQL Edit/TPU, SQL Everywhere, SQL Modeler, SQL Remote, SQL Server, SQL Server Manager, SQL SMART, SQL Toolset, SQL Server/CFT, SQL Server/DBM, SQL Server SNMP SubAgent, SQL Station, SQLJ, STEP, SupportNow, S.W.I.F.T. Message Format Libraries, Sybase Central, Sybase Client/Server Interfaces, Sybase Financial Server, Sybase Gateways, Sybase MPP, Sybase SQL Desktop, Sybase SQL Lifecycle, Sybase SQL Workgroup, Sybase User Workbench, SybaseWare, Syber Financial, SyberAssist, SyBooks, System 10, System 11, System XI (logo), SystemTools, Tabular Data Stream, TradeForce, Transact-SQL, Translation Toolkit, UNIBOM, Unilib, Uninull, Unisep, Unistring, URK Runtime Kit for UniCode, Viewer, Visual Components, VisualSpeller, VisualWriter, VQL, WarehouseArchitect, Warehouse Control Center, Warehouse Studio, Warehouse WORKS, Watcom, Watcom SQL, Watcom SQL Server, Web Deployment Kit, Web.PB, Web.SQL, WebSights, WebViewer, WorkGroup SQL Server, XA-Library, XA-Server and XP Server are trademarks of Sybase, Inc. 07/02

Unicode and the Unicode Logo are registered trademarks of Unicode, Inc.

All other company and product names used herein may be trademarks or registered trademarks of their respective companies.

Use, duplication, or disclosure by the government is subject to the restrictions set forth in subparagraph (c)(1)(ii) of DFARS 52.227-7013 for the DOD and as set forth in FAR 52.227-19(a)-(d) for civilian agencies.

Sybase, Inc., One Sybase Drive, Dublin, CA 94568.

Contents

Replication Agent for DB2 UDB for OS/390 Installation Guide iii

About This Book ........................................................................................................................... ix

CHAPTER 1 Understanding Replication Agent ................................................. 1Understanding basic concepts of replication systems...................... 1

Primary database ...................................................................... 2Primary database log ................................................................ 2Replication Extract .................................................................... 4Log Transfer Manager for MVS................................................. 7Replication Server ..................................................................... 9Materialization ......................................................................... 10

Understanding the role of Replication Agent.................................. 10Replication Agent data flow..................................................... 11

Understanding connectivity in a replication system........................ 14Replication Agent-to-Replication Server connectivity.............. 15Replication Server-to-DB2 connectivity ................................... 15

Replication Agent users ................................................................. 15Understanding replication in a data-sharing environment .............. 17

Understanding data-sharing environment characteristics ....... 17Replicating transactions in a data-sharing environment.......... 18

Replication Agent task and documentation topics overview .......... 19What’s next .................................................................................... 21

CHAPTER 2 Understanding Replication Agent Installation Requirements .. 23Understanding team skill requirements.......................................... 23Understanding software requirements ........................................... 24

Mainframe software requirements........................................... 24LAN software requirements..................................................... 25

What’s next .................................................................................... 26

CHAPTER 3 Understanding Replication Agent Operational Considerations 27Understanding Sybase server operational considerations ............. 27

Heterogeneous datatype support (HDS) ................................. 27Replication Server-to-DB2 connectivity ................................... 28

Contents

iv Replication Agent for DB2 UDB for OS/390

Understanding DB2 database considerations................................ 28Support for DB2 features......................................................... 29DB2 log capacity ..................................................................... 29DB2 table size limit in Replication Server................................ 29DB2 utilities ............................................................................. 29

Understanding permissions requirements...................................... 30What’s next .................................................................................... 30

CHAPTER 4 Gathering Installation Information ............................................... 31Section 1: Recording user IDs ....................................................... 32Section 2: Recording the LTM for MVS start-up procedure name . 33Section 3: Recording Replication Agent installation information.... 34Section 4: Recording Replication Extract installation information .. 34

Specifying DB2 system libraries for multi-member datasharing 35Section 5: Recording TCP/IP configuration information................. 36

Recording TCP/IP information for Replication Server ............. 36Section 6: Recording TCP/IP information for Adaptive Server....... 37Section 7: Recording required configuration information ............... 39Replication Agent Installation Worksheet....................................... 41

1. User IDs .............................................................................. 422. LTM for MVS start-up procedure name............................... 433. Replication Agent installation .............................................. 444. Replication Extract installation panel information................ 455. TCP/IP information for Replication Server .......................... 466. TCP/IP information for Adaptive Server .............................. 477. LTM for MVS configuration information............................... 48

What’s next .................................................................................... 48

CHAPTER 5 Installing Replication Agent ......................................................... 49Task 1: Gather installation information........................................... 50Task 2: Start the installation program ............................................ 50Task 3: Customize the JCL ............................................................ 51Task 4: Transfer the data sets ....................................................... 52Task 5: Unpack LINKLIB data sets ................................................ 53Task 6: Perform systems programmer installation tasks ............... 54Task 7: Create the Replication Agent system tables ..................... 54Task 8: Grant LTMADMIN user ID permissions............................. 55Task 9: Install the Replication Agent interface ............................... 58Task 10: Define the LTM start-up procedure ................................. 59What’s next .................................................................................... 60

CHAPTER 6 Configuring Replication Extract................................................... 61

Contents

Replication Agent for DB2 UDB for OS/390 Installation Guide v

Task 1: Edit the PARMLIB library members................................... 61Task 1a: Edit the PLANS00 member ...................................... 62Task 1b: Edit the SETUP00 member ...................................... 63Task 1c: Edit the PDR member............................................... 65

Task 2: Bind the log extract plan.................................................... 67Example .................................................................................. 67

What’s next .................................................................................... 69

CHAPTER 7 Configuring TCP/IP for Replication Agent.................................. 71Task 1: Verify TCP/IP connectivity................................................. 72Understanding the SYGWHOST macro......................................... 73

Syntax ..................................................................................... 74Contents .................................................................................. 74

Task 2: Assemble and link the SYGWXCPH module .................... 75What’s next .................................................................................... 75

CHAPTER 8 Completing and Verifying Your Replication Agent Installation 77Task 1: Verify the LTM for MVS configuration file.......................... 77

What you need to know........................................................... 79Task 2: Configure Replication Server ............................................ 80

What you need to know........................................................... 81Creating the RS user on Replication Server ........................... 82Granting connect source permission....................................... 82Creating a connection to Replication Server ........................... 83

Task 3: Test your server connections with PINGRS ...................... 85Correcting PINGRS errors....................................................... 85

Task 4: Start Replication Agent...................................................... 86What’s next .................................................................................... 87

APPENDIX A LTM for MVS Configuration Parameters..................................... 89Understanding the LTM for MVS configuration file ........................ 89

Sample LTM for MVS configuration file................................... 89Understanding the LTM for MVS configuration parameters........... 94

API_com_test .......................................................................... 96API_QID_request_interval....................................................... 98batch_ltl_cmds ........................................................................ 99Char_conv_err_log................................................................ 100Codepage.............................................................................. 100Communications_Protocol .................................................... 103Creator .................................................................................. 103Date_conv_default ................................................................ 104Date_in_char ......................................................................... 105

Contents

vi Replication Agent for DB2 UDB for OS/390

DateTime_conv_err............................................................... 106LE_oper_com........................................................................ 107Log_extractor ........................................................................ 107Log_identifier......................................................................... 108Long_varchar ........................................................................ 109Low_activity_latency ............................................................. 110LTL_table_col_case .............................................................. 110LTL_test_only........................................................................ 111LTM_admin_pw..................................................................... 112LTM_admin_user .................................................................. 112LTM_process_maint_uid_trans ............................................. 113Maximum_connect_retries .................................................... 114Minimal_cols.......................................................................... 114Minimum_year....................................................................... 115Packet_size ........................................................................... 116replace_null_in_char ............................................................. 117retry ....................................................................................... 118RS ......................................................................................... 118RS_ccsid ............................................................................... 119RS_source_db....................................................................... 121RS_source_ds....................................................................... 122RS_pw................................................................................... 123RS_user ................................................................................ 123RSSD_database.................................................................... 124RSSD_pw.............................................................................. 125RSSD_server ........................................................................ 125RSSD_user ........................................................................... 126Stop_on_error ....................................................................... 126Support_DB2_comp_rec ....................................................... 128Suppress_col_names............................................................ 129Time_conv_default ................................................................ 130Time_in_char......................................................................... 131Timestamp_in_char............................................................... 132trace=1,4 ............................................................................... 133trace=1,11 ............................................................................. 133trace=1,23 ............................................................................. 134trace=1,31 ............................................................................. 135Transaction_name................................................................. 136Use_repdef............................................................................ 136User_exit ............................................................................... 138

APPENDIX B Replication Extract Configuration Parameters ......................... 139PARMLIB data set members........................................................ 139

Replication Extract members and parameter conventions.... 140

Replication Agent for DB2 UDB for OS/390 Installation Guide vii

SETUP00 member contents and parameters........................ 140PLANS00 member contents .................................................. 141PDR member contents and parameters ................................ 142

APPENDIX C Replication Agent Data Sets ...................................................... 151Replication Agent data sets.......................................................... 151

DBRMLIB contents ................................................................ 151DOCS contents...................................................................... 152ISPF contents ........................................................................ 152JCL contents.......................................................................... 153MACLIB contents................................................................... 154PDR.PARMLIB contents........................................................ 155RA.LINKLIB contents............................................................. 155LTMLOC ................................................................................ 155SAS.LINKLIB ......................................................................... 155Additional data sets ............................................................... 156

APPENDIX D Upgrading Your Replication Agent Software ........................... 157Migrating to Replication Agent for DB2 UDB 12.5 software ......... 157Additional migration considerations.............................................. 160

New LTI version..................................................................... 160FLOAT data rounding change ............................................... 160

Understanding the LTM Locator format........................................ 161Replication Agent LTM Locator formats ................................ 161

APPENDIX E Running Multiple Replication Agents........................................ 163Running multiple Log Transfer Managers .................................... 163

JCLLIB (LTMCNFG) .............................................................. 164PDR.PARMLIB ...................................................................... 165RA.LINKLIB ........................................................................... 165creator.LTMOBJECTS........................................................... 166

Glossary...................................................................................................................................... 167

Index............................................................................................................................................ 185

viii Replication Agent for DB2 UDB for OS/390

Replication Agent for DB2 UDB for OS/390 Installation Guide ix

About This Book

Sybase provides Replication Agent™ for DB2 UDB for OS/390 (hereafter referred to as Replication Agent) to enable you to replicate transaction operations from IBM DB2 UDB on OS/390 to replicate databases through Sybase Replication Server®.

Before you begin Read the Replication Agent for DB2 UDB Release Bulletin for OS/390 version 12.5 for important information about this Sybase software release that becomes available after this guide was printed.

Audience Use this document if you are responsible for any of these tasks:

• Administering Replication Server systems

• Administering your MVS (OS/390) system

• Administering your DB2 database

• Installing Replication Agent

How to use this book Use this document to accomplish the following:

• Understand basic replication concepts, including the relationship between replication components in a Sybase replication system

• Understand Replication Agent installation requirements

• Install the LTM for MVS and Replication Extract components of Replication Agent

• Verify your Replication Agent installation

Use this document to accomplish the following:

• Understand basic replication concepts, including the relationship between replication components in a Sybase replication system.

• Understand Replication Agent installation requirements.

Contents of this book See “Replication Agent task and documentation topics overview” on page 19 for a list of topics and chapters in this book. The glossary contains definitions of technical terms.

Contents of Replication Agent

Replication Agent includes the following components:

About This Book

x Replication Agent for DB2 UDB for OS/390

• Replication Agent for DB2 UDB for OS/390 product software, product #19319-33-1250, which includes the following components:

• Log Transfer Manager (LTM for MVS)

• Replication Extract, the log extract component of Replication Agent

• Tracing utilities, to assist with debugging and troubleshooting Replication Agent

• Replication Agent for DB2 UDB for OS/390 product documentation, including:

• Replication Agent for DB2 UDB Release Bulletin for OS/390, document #71014-01-1250

• Replication Agent for DB2 UDB Installation Guide for OS/390 (this document), document #34256-01-1250

• Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390, document #32005-01-1250

Related documents Obtain documentation for the following Sybase products from your site’s designated Sybase representative:

• Replication Server

• Adaptive Server Enterprise

Obtain the appropriate IBM DB2 documents concerning messages and codes, commands and utilities, SQL, administration and application programming.

Obtain documentation for the TCP/IP connectivity protocol as needed.

Other sources of information

Use the Sybase Technical Library CD and the Technical Library Product Manuals Web site to learn more about your product:

• The Technical Library CD contains product manuals and is included with your software. The DynaText browser (downloadable from Product Manuals at http://www.sybase.com/detail/1,6904,1010663,00.html) allows you to access technical information about your product in an easy-to-use format.

Refer to the Technical Library Installation Guide in your documentation package for instructions on installing and starting the Technical Library.

About This Book

Replication Agent for DB2 UDB for OS/390 Installation Guide xi

• The Technical Library Product Manuals Web site is an HTML version of the Technical Library CD that you can access using a standard Web browser. In addition to product manuals, you will find links to the Technical Documents Web site (formerly known as Tech Info Library), the Solved Cases page, and Sybase/Powersoft newsgroups.

To access the Technical Library Product Manuals Web site, go to Product Manuals at http://www.sybase.com/support/manuals/.

Sybase certifications on the Web

Technical documentation at the Sybase Web site is updated frequently.

❖ For the latest information on product certifications

1 Point your Web browser to Technical Documents at http://www.sybase.com/support/techdocs/.

2 Select Products from the navigation bar on the left.

3 Select a product name from the product list.

4 Select the Certification Report filter, specify a time frame, and click Go.

5 Click a Certification Report title to display the report.

❖ For the latest information on EBFs and Updates


2 Select EBFs/Updates. Enter user name and password information, if prompted (for existing Web accounts) or create a new account (a free service).

3 Specify a time frame and click Go.

4 Select a product.

5 Click an EBF/Update title to display the report.

❖ To create a personalized view of the Sybase Web site (including support pages)

Set up a MySybase profile. MySybase is a free service that allows you to create a personalized view of Sybase Web pages.


2 Click MySybase and create a MySybase profile.

About This Book

xii Replication Agent for DB2 UDB for OS/390

Style conventions Table 1 shows some of the style conventions used in the documentation for this product.

Table 1: Style conventions

Syntax conventions The following example illustrates some of the syntax conventions used in this guide:

COMMAND [object_name, [ {TRUE | FALSE} ] ]

Table 2 explains the syntax conventions used in this guide.

Text Explanation Example

Bold • Programs

• Utilities

• Procedures

• Commands

create connection

Italics • File names

• Directory names

• Properties

PDR.PARMLIB

Code • Code examples

• Screen text

Replication Agent for DB2 UDB for OS/390/12.5

Bold code • User input

• Command line input

/F [job_name],C, trace=1,11

Italics Variables (replace these with the appropriate values for your site)

host_name

Code italics

Variables in code you type (replace these with the appropriate values for your site)

maintenance_user_ID

About This Book

Replication Agent for DB2 UDB for OS/390 Installation Guide xiii

Table 2: Syntax conventions

If you need help Each Sybase installation that has purchased a support contract has one or more designated people who are authorized to contact Sybase Technical Support. If you cannot resolve a problem using the manuals or online help, please have the designated person contact Sybase Technical Support or the Sybase subsidiary in your area.

Gathering information for Sybase Technical Support

Sybase Technical Support may ask for some of the information in Table 3. Be sure to have information about the items marked with an asterisk (*).

Symbol Explanation Example

( ) Include parentheses as part of the command.

START DATABASE (database_name)

| A vertical bar indicates that you can select only one of the options shown. Do not type the bar in your command.

{red|yellow|blue}

, A comma indicates that you can choose one or more of the options shown. Separate each choice by using a comma as part of the command.

{rice,potatoes,beans}

{ } Braces indicate that you must choose at least one of the enclosed options. Do not type the braces when you enter the option.

Select only one: {red|yellow|blue}

Select at least one: {rice,potatoes,beans}

[ ] Brackets indicate that you can choose one or more of the enclosed options, or none. Do not type the brackets when you enter the options.

[anchovies]

... An ellipsis indicates that you can repeat the previous item as many times as necessary.

{rice,potatoes}...

About This Book

xiv Replication Agent for DB2 UDB for OS/390

Table 3: Information to gather for Sybase Technical Support

System component Information Output type

MVS MVS version and release

MVS maintenance level

Version and level of SAS/C run-time library

DFP/SFSMS level

MVS SYGWHOST macro (in XCPHPING member)

File contents

MVS dump

Warning! You must not use Abend-AID for Replication Agent dumps. Since Abend-AID removes dump information necessary to properly troubleshoot Replication Extract problems, make sure your batch job or started task JCL prevents Abend-AID from affecting abend output.

Output

Record of all console messages Output

DB2 Version

DSNJU004 utility listing of BSDS

If running in data-sharing mode:

• Number of members

• DSNJU004 utility listing of BSDS (for each member of data-sharing group, if running in data-sharing mode)

• LISTCAT of DB2 system logs

• Group attach name

Replication Server *Replication Server platform

*Replication Server release

Target port (Replication Server port number)

Replication Server machine interfaces file File contents

Replication Server subscriptions and replication definitions

File contents

*Replication Server log Output

About This Book

Replication Agent for DB2 UDB for OS/390 Installation Guide xv

Replication Agent *Replication Agent release number

*Replication Agent configuration file File contents

*Replication Agent log files Output

Adaptive Server Adaptive Server platform

Adaptive Server release number

TCP/IP connectivity Vendor, version, and release

Maintenance level

Data set prefix name

Address space name

*TSO PING command (if run) Output

*PINGRS job including JCL listing (if run) Output

JES SYSLOG during the period that PINGRS runs (if run)

Copy

NETSTAT ALL commands Output

TESTSITE command (if run) Output

TRACERTE (MVS) or traceroute (UNIX) command

Output

TRACE ALL and MORETRACE SOCKETS commands

Output

Troubleshooting All troubleshooting procedures Output

System component Information Output type

About This Book

xvi Replication Agent for DB2 UDB for OS/390

Replication Agent for DB2 UDB for OS/390 Installation Guide 1

C H A P T E R 1 Understanding Replication Agent

This chapter provides an overview of Replication Agent for DB2 UDB for OS/390 version 12.5 (hereafter referred to as Replication Agent), including the following topics:

If you are completely familiar with replication concepts, your MVS environment, and Replication Server, turn now to “Understanding the role of Replication Agent” on page 10.

Note The material in this chapter also appears in the Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390.

Understanding basic concepts of replication systemsTransaction replication maintains data in separate databases called replicate databases. Replicate databases contain accurate, current copies or subsets of data from the primary database.

Replication of data allows slower, process-intensive decision support queries to run against the same data without slowing mission-critical, on-line transaction processing (OLTP) applications.

Figure 1-1 on page 2 shows a generic replication system and its components.

Topic PageUnderstanding basic concepts of replication systems 1

Understanding the role of Replication Agent 10

Understanding connectivity in a replication system 14

Replication Agent users 15

Understanding replication in a data-sharing environment 17

Replication Agent task and documentation topics overview 19

What’s next 21

Understanding basic concepts of replication systems

2 Replication Agent for DB2 UDB for OS/390

Figure 1-1: Replication system overview

The following sections introduce the basic concepts of transaction replication and describe the following elements of a typical replication system:

• Primary database

• Primary database log

• Replication Extract

• Log Transfer Manager for MVS

• Replication Server

Primary databaseThe primary database, DB2, contains your source data.

Primary database logThe DB2 log contains information about updates, deletes, and inserts on DB2 tables. The DB2 log contains information about additional changes and events; this additional information is not currently replicated.

OS/390

PrimaryDatabase

DatabaseLog

Replication Agent

LogExtract

LTM forMVS

LAN

ReplicationServer System

Database (RSSD)

Adaptive Server

Replication Server

ReplicateDatabase

TCP/IP Connection

CHAPTER 1 Understanding Replication Agent


DB2 logs changes to rows in DB2 tables as they occur. The information written to the log includes copies of the data before and after the changes. In DB2, these records are known as “undo” and “redo” records.

Control records are written for commits and aborts. These records are translated to commits and rollbacks.

The DB2 log is composed of a series of data sets. Replication Extract uses these log data sets to identify DB2 data changes. The DB2 log consists of three types of data sets:

• Active log data sets reside on a direct access storage device (DASD). As changes occur, they are first recorded in an active log data set. Eventually, the active log fills and DB2 copies the log to an archive log.

• Archive log data sets reside on DASD or tape.

• The bootstrap data set (BSDS) contains information about all of the active and archive data sets that make up the log records.

Since DB2 writes change records to the active log as they occur, Replication Extract can process the log records immediately after they are entered.

Typically, DB2 writes two copies of the logs for redundancy in the event of log data set corruption.

See “DB2 log capacity” on page 37 for more information on the DB2 log.

DB2 log changes

Replication requires an entire “before” and “after” image of the row that has been changed by an update. When you mark a table for replication using the Replication Agent interface dialog panels, the table is altered with the DATA CAPTURE CHANGES clause. As the number of DB2 tables marked for replication increases, so do the DASD space requirements for the DB2 active log data sets.

There are no increases in the amount of data written to the log for deletes or inserts, because for deletes and inserts, the entire “before” image and “after” image is captured in the log.

Tables that receive updates to fixed-length rows write additional data to the DB2 log, specifically, the complete before image and after image of the changed row.

The additional DB2 log usage can be significant if the row size is large or if the number of updates is large.



Tables that receive updates to variable-length rows write additional data in the log, specifically, the data from the beginning of the row to the point of the change.

This information is not normally written to DB2 logs. The effect of this change is minimal if the number of updates is small, if the row size is small, or if the updates are normally applied near the beginning of the row.

DB2 does not log transactions in which the value of an updated DB2 column is identical to the value of that column before the update. Replication Agent does not replicate transactions of this nature because the transactions do not appear in the DB2 logs.

Note There are no “begin” records for DB2. “Begin” records are generated from the first record in a transaction operation.

DB2 active and archive logs

Be sure to protect DB2 active and archive logs against loss or corruption.

To optimize Replication Agent performance, be sure that the DB2 active logs are large enough to contain the number of log entries for a 12-hour period of update activity before reusing the log data set. This allows you to resume replication using log data following network outages that might interrupt replication, without requiring the log extract to read log entries from tape.

Replication ExtractLog extracts read and transfer relevant database transactions recorded in the database logs to LTM for MVS. The log extract in Replication Agent is Replication Extract.

A DB2 table named LTMOBJECTS is created during the installation of Replication Agent. This table contains a row corresponding to each table that is marked for replication. Replication Extract uses the LTMOBJECTS table to identify the data marked for replication.

To capture DB2 data changes, Replication Extract scans the DB2 active and archive logs for inserts, updates, and deletes on tables marked for replication. Replication Extract formats the extracted changes and passes them to LTM for MVS, which then transmits the changes to Replication Server.



Replication Extract and LTM for MVS run simultaneously within a single MVS address space as an LTM for MVS started task, continuously reading the DB2 logs.

When data sharing is enabled in DB2 version 5 or later, you can replicate transactions from multiple members of a data-sharing group with a single Replication Agent started task. Replication Extract merges the logs from each member within a data-sharing group.

In a non-data-sharing environment, replicating transactions from multiple DB2 subsystems requires one Replication Agent started task for each DB2 subsystem. Each Replication Agent started task processes the log of a single DB2 subsystem.

See “Understanding replication in a data-sharing environment” on page 17 for more information on data sharing.

Replication Extract processing flow

The following figure shows the processing flow between DB2, Replication Extract, LTM for MVS, and Replication Server:

Figure 1-2: Replication Extract processing flow

The processing flow for Replication Extract includes the following actions:

1 The MVS START command, which you issue from the MVS console, starts the LTM for MVS started task. (Replication Agent can also be started as a batch job.)

OS/390

DB2

DB2Logs

Replication Agent for DB2 UDB

ReplicationExtract

LTM forMVS

DB2 Catalog

Replication Server



a LTM for MVS processes the configuration file and retrieves information about Replication Server, Replication Extract, user exits, defaults, DB2, traces, and DB2 subsystems.

b LTM for MVS opens a connection to Replication Server.

If the connection to Replication Server fails, LTM for MVS retries the connection (according to the value of the retry and Maximum_connect_retries configuration parameters).

2 LTM for MVS starts the Replication Extract task using the MVS ATTACH command.

3 Replication Extract processes the hlq.PDR.PARMLIB data set allocated to the PTIPARM DD name. The hlq.PDR.PARMLIB data set contains information about DB2 subsystem load libraries, plans, defaults, and traces. The hlq.PDR.PARMLIB data set also contains parameters that you can use to control the execution of Replication Extract.

For information about the PDR.PARMLIB data set, see “Task 1: Edit the PARMLIB library members” on page 79.

4 Replication Extract connects to the DB2 subsystem using the DB2 CONNECT command. The DB2 subsystem must be active for the entire time the Replication Agent started task is active.

5 Replication Extract queries the LTMOBJECTS system table to identify the tables marked for replication.

6 Replication Extract queries the DB2 catalog to retrieve the definitions of all the tables recorded in the LTMOBJECTS table. These definitions are required to format the changes described in the DB2 log.

7 Replication Extract queries LTM for MVS for the origin queue ID (QID) of the last update that was successfully received by Replication Server, and writes a copy of the QID to the hlq.TRUNCPT data set.

This QID is called the LTM Locator, and is stored in the Replication Server database, in the rs_locater table. From this QID, Replication Extract derives the point within the log from which processing is to resume.

If the QID that LTM for MVS passes to Replication Extract and the QID in the TRUNCPT data set contain all binary zeros, Replication Extract begins processing from the end of the active log.

8 Replication Extract allocates and reads the BSDS to determine the names of all the active and archive log data sets.



9 Replication Extract resumes processing at the point derived from the LTM Locator and begins scanning the log (or logs, if Replication Agent is running in data-sharing mode) for changes to DB2 tables.

10 Using the log records that describe inserts, updates, and deletes to primary tables, Replication Extract constructs a full-row “after” image for inserts, a full-row “before” image for deletes, and full “before” and “after” images for updates for each affected row.

The individual column values are converted from DB2 internal format to their external format. Replication Extract then passes the converted transaction operation information to LTM for MVS.

Log Transfer Manager for MVSLog Transfer Manager receives relevant database transactions from log extracts. LTM for MVS translates this information into Log Transfer Language (LTL), and sends these LTL statements through a connection to Replication Server.

LTM for MVS contains the following interfaces:

• Replication API (Replication Application Program Interface)

• Log Transfer Interface (LTI)

• Sybase Open ClientConnect™ routines that allow LTM for MVS to communicate with Replication Server



Figure 1-3: LTM for MVS components

LTM for MVS translates the transaction information received from Replication Extract into Log Transfer Language (LTL), and sends these LTL statements to the primary Replication Server.

Replication Server holds the LTL statements in a stable queue, transforms these transactions (usually into SQL, according to user instructions), and passes the transformed transaction information to the replicate Replication Servers or replicate database(s) for processing.

LTM for MVS processing flow

LTM for MVS processes as follows:

1 Logs in to the primary Replication Server.

2 Sends a connect source command to identify the session as a log transfer source and to specify the database log to be transferred.

3 Obtains the maintenance user ID from Replication Server. LTM for MVS uses the Replication Server maintenance user ID to filter operations executed by the maintenance user.

4 Requests the origin queue ID from Replication Server. The origin queue ID contains the LTM Locator value.

Replication Extract uses the LTM Locator value to determine the point in the log at which LTM for MVS should begin transferring transaction operation records. Replication Server successfully received all log records up to this location.


ReplicationExtract

ReplicationAPI

Log TransferInterface

Open ClientLTM for MVS



5 Receives transaction operations from Replication Extract following the point in the log indicated by the LTM Locator value and formats them into LTL commands.

What you need to know

Replication ServerReplication Server transfers database transactions to the replicate database using a connection to the replicate database. Replication Server can replicate to a single database, multiple databases, or other Replication Servers.

Maintenance user ID The Replication Server get maintenance user command returns the Replication Server maintenance user ID.

Replication Server uses the maintenance user ID to update tables with replicated data in the database monitored by Replication Agent.

By default, Replication Agent does not pass transactions made by the maintenance user ID to Replication Server for replication. To replicate changes made by this user, set the value of the LTM for MVS LTM_process_maint_uid_trans configuration parameter to Y to specify that Replication Agent replicate all logged changes made by the Replication Server maintenance user.

LTM Locator and origin queue ID

The Replication Server get truncation command returns a value called the LTM Locator, which is the origin queue ID associated with the transaction operation last saved by Replication Server.

Replication Extract uses the LTM Locator value to determine the location in the log where replication should begin.

Replication Server has successfully saved all transactions up to this LTM Locator value in its stable queue; Replication Agent can safely ignore all transactions before this point in the log.

Understanding the role of Replication Agent


Replication Server holds the transaction operations in a stable queue and delivers them as soon as possible to other Replication Servers (replicate Replication Servers) or replicate databases. These transactions are transformed (usually into SQL) according to the instructions you provide to Replication Server and are sent to the replicate database for processing.

Replication Server guarantees transaction delivery: Every transaction successfully received from a LTM is guaranteed to be delivered to appropriately subscribing replicate databases.

Replication Server systems are administered through a LAN-based interface. The System Administrator creates subscriptions for replication definitions on Replication Server.

The subscriptions and replication definitions define the columns and rows that Replication Server manages at the replicate sites. The System Administrator also defines destinations and routes to manage network traffic.

MaterializationMaterialization is the process of initially populating the replicate database with a copy of the data from the primary database. Replication Agent requires that you set up and populate each replicate database so that it is in a state consistent with that of the primary database.

Replication Server then replicates incremental changes to the primary data from the primary database to the replicate database.

Understanding the role of Replication AgentReplication Agent is a component of a replication system that moves primary database transactions from DB2 through Replication Server to replicate databases.

Replication Agent fits into the generic replication system, illustrated in Figure 1-4, with the following differences:

• With Replication Agent, the primary database is DB2, which runs as a subsystem in MVS. The database logs are DB2 logs.



• Replication Agent provides a log extract, called Replication Extract, that reads the DB2 logs and retrieves the relevant DB2 active and archive log entries for tables marked for replication.

• LTM for MVS receives the data marked for replication from Replication Extract and transfers this data to Replication Server using the TCP/IP communications protocol.

• Replication Server then applies the changes to the replicate databases.

Figure 1-4: Replication Agent data flow

See also • Replication Server Administration Guide and Replication Server Design Guide for information about additional replication system topics

Replication Agent data flowThe Replication Agent data flow consists of four primary steps:

Step 1: Replication Extract reads log data.

Step 2: Replication API translates information.

Step 3: The LTI delivers information.

Step 4: Replication Server replicates information.

DB2DB2 Logs


ReplicationExtract

LTM forMVS

ReplicationServer

Replication System: Primary Side

Understanding the role of Replication Agent


Step 1: Replication Extract reads log data

Replication Extract reads the DB2 active and archive log data sets for changes to DB2 tables marked for replication. It retrieves all the relevant information and delivers it to the Replication API, a component of LTM for MVS.

Figure 1-5 illustrates this process.

Figure 1-5: Replication Extract reads log data

Step 2: Replication API translates information

The Replication API receives information from Replication Extract, translates the command structures received from the log extract into Log Transfer Language (LTL) statements, places the LTL in a buffer, and delivers the buffer to the LTI.

Figure 1-6 illustrates this process.

DB2DB2 Logs


ReplicationExtract

OS/390

ReplicationAPI





Figure 1-6: Replication API translates information

Step 3: The LTI delivers information

The LTI delivers the buffer to the Open ClientConnect for MVS routines embedded in LTM for MVS, as shown in Figure 1-7.

Figure 1-7: LTI translates information for Open Client


ReplicationExtract

ReplicationAPI




ReplicationExtract

ReplicationAPI



Understanding connectivity in a replication system


Step 4: Replication Server replicates information

LTM for MVS delivers LTL to Replication Server over the network. Replication Server translates the LTL statements into transactions that replicate the primary database changes to the replicate databases, as shown in Figure 1-8.

Figure 1-8: Replication Server receives transactions for replication

See also • “Understanding connectivity in a replication system” for information on Replication Agent-to-Replication Server connectivity

• Replication Server Administration Guide and the Replication Server Design Guide for more information about Replication Server functionality

Understanding connectivity in a replication systemReplicating transaction operations from MVS to Replication Server requires communication between different operating systems. Each site has two sets of connectivity options:

DB2DB2 Logs


ReplicationExtract

OS/390

ReplicationAPI



ReplicationServer

LTL



• Replication Agent-to-Replication Server connectivity

• Replication Server-to-DB2 connectivity

Replication Agent-to-Replication Server connectivityReplication Agent communicates with Replication Server using the MVS TCP/IP protocol.

Replication Server-to-DB2 connectivityReplication from Replication Server to DB2 replicate databases can use a variety of gateways. This connectivity, however, is required only when you plan to use automatic materialization (which Replication Agent does not support).

Three-tier architecture You can use Sybase DirectConnect™ for DB2 for gateway connectivity to allow Replication Server to issue selects, inserts, updates, or deletes against the tables stored in DB2.

Two-tier architecture You can also set up Replication Server-to-DB2 connectivity without a DirectConnect for DB2 gateway. For details on how to accomplish this, see the Replication Server Heterogeneous Replication Guide.

See also • Chapter 3, “Understanding Replication Agent operational considerations” for information about connectivity options for replication into DB2

• Chapter 3, “Preparing for Replication” in the Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390 for information for information on bulk materialization.

Replication Agent usersSeveral user identifiers are required for working with Replication Agent. The following table describes each one and its requirements.

Replication Agent users


Table 1-1: User IDs associated with Replication Agent

User ID Description Restrictions

LTMADMIN user Sybase recommends that you create the LTMADMIN user ID, a TSO user optionally named LTMADMIN, to perform the following tasks:

• Install, start, and stop Replication Agent

• Manage the Replication Agent system tables on DB2

• Bind the log extract plan

This identifier can be a TSO user ID or a group identifier. MVS user ID restrictions apply to this identifier (eight characters maximum, all uppercase).

This user ID should not be identical to the Replication Server maintenance user ID.

Replication Server maintenance user

The maintenance user is the Replication Server user in the create connection command used to create a connection from Replication Agent to Replication Server.

Any updates applied to the primary database by the maintenance user are ignored for replication unless the value of the LTM_process_maint_uid_trans LTM for MVS configuration parameter has a value of Y.

The Replication Server get maintenance user command returns the Replication Server maintenance user ID.

Any updates applied to the primary database by the maintenance user are ignored for replication unless the value of the LTM for MVS LTM_process_maint_uid_trans configuration parameter has a value of Y.

Because this user ID is intended to compare against a user ID that can perform updates on DB2, it must conform to MVS user ID restrictions (eight characters maximum, all uppercase).

Note To avoid cyclic replication, this user ID should not be identical to the value of the LTM for MVS RS_user configuration parameter (the RS user).

RS user The RS user is the user ID specified in the value of the RS_user configuration parameter.

This is the user ID that Replication Agent uses to connect to the primary Replication Server.

This user ID can be a maximum of 30 characters.

Note This user ID should not be identical to the Replication Server maintenance user ID.

RSSD user The RSSD user is the user ID specified in the value of the RSSD_user configuration parameter.

This is the user name for the Adaptive Server user who has permissions to perform selects against the primary Replication Server’s RSSD.

This user ID can be a maximum of 30 characters.



Understanding replication in a data-sharing environment

When you are using DB2 with data sharing enabled, you can replicate transactions from one or more DB2 subsystems within a data-sharing group.

This chapter contains the following tasks:

• Understanding data-sharing environment characteristics

• Replicating transactions in a data-sharing environment

Understanding data-sharing environment characteristics DB2 installations can have multiple MVS sysplexes. Each sysplex can contain multiple DB2 data-sharing groups. A DB2 data-sharing group is an MVS Cross-system Coupling Facility (XCF) group.

Each member of a DB2 data-sharing group is a DB2 subsystem, also called a member. The members within a single DB2 data-sharing group can share data. DB2 data sharing does not function across groups. The Sysplex Timer synchronizes timestamps between all DB2 subsystems in a data-sharing group.

The members of a DB2 data-sharing group can reside on the same or different MVS systems. Therefore, a DB2 data-sharing group can either span several MVS systems or reside on a single MVS system.

Each DB2 subsystem maintains its own recovery logs and boot-strap data set (BSDS). The BSDS for every DB2 member in a data-sharing group contains information about the other group members’ BSDSs. The shared communications area (SCA) in the coupling facility (XCF) for a given data-sharing group contains information about all BSDSs and all logs for DB2 subsystems within the group.

Understanding replication in a data-sharing environment


Figure 1-9: Illustration of data-sharing group components

Each log record header contains a log record sequence number (LRSN). The LRSN is a 6-byte value derived from the Store Clock timestamp. The LRSN is equal to or greater than the timestamp value truncated to 6 bytes. This value also exists in the header page of the tablespace. In the data-sharing environment, the LRSN replaces the relative byte address (RBA), although each subsystem continues to use the RBA for its own logs and BSDS.

Replicating transactions in a data-sharing environmentWhen data sharing is enabled in DB2 version 6 or later, you can replicate transactions from multiple members of a data-sharing group with a single Replication Agent started task. Replication Extract merges the logs from each member within a data-sharing group.

To replicate transactions when using DB2’s data-sharing environment, you must supply specific parameter values in the following:

• The LTM for MVS Log_identifier configuration parameter

DB2Subsystem

DB2Subsystem

DB2Subsystem

SharedCommunications

Area

DB2 Data-Sharing Group

SysplexTimer

OS/390 System 1 OS/390 System 2

Sysplex



• The SETUP00 and PDR members in the hlq.PDR.PARMLIB data set

Note The SETUP00 member was named SETUP in previous releases.

• The PDRBIND member in the hlq.JCL data set (you edit and submit the PDRBIND job when binding the log extract plan)

See also • Chapter 6, “Configuring Replication Extract” for information about editing the hlq.PDR.PARMLIB data set members and binding the log extract plan

• Appendix A, “LTM for MVS Configuration Parameters” for detailed information about the Log_identifier parameter

Replication Agent task and documentation topics overview

Table 1-2 lists the locations in the Replication Agent documentation of the tasks involved in installing, using, and troubleshooting Replication Agent. Each of the guides listed in this table includes a preface, this overview chapter, and a glossary of technical terms.

Table 1-2: Where to find Replication Agent documentation topics

Replication Agent for DB2 UDB Installation Guide for OS/390

Plan your Replication Agent installation

Includes information about installation preparation, including software requirements, operational considerations, and filling out the Replication Agent Installation Worksheet:

• Go to Chapter 2, “Understanding Replication Agent Installation Requirements”

• Go to Chapter 3, “Understanding Replication Agent Operational Considerations”

• Go to Chapter 4, “Gathering Installation Information”

Install Replication Agent

Includes instructions for installing the Replication Agent software, granting permissions, and configuring Replication Extract.

• Go to Chapter 5, “Installing Replication Agent”

• Go to Chapter 6, “Configuring Replication Extract”

Replication Agent task and documentation topics overview


Set up communications

Includes information about setting up TCP/IP communications between Replication Agent and Replication Server:

• Go to Chapter 7, “Configuring TCP/IP for Replication Agent”

Verify your installation

Includes information about setting required configuration parameter values, and test connections with the PING and PINGRS utilities:

• Go to Chapter 8, “Completing and Verifying Your Replication Agent Installation”

Reference Information

• Appendix A, “LTM for MVS Configuration Parameters”

• Appendix B, “Replication Extract Configuration Parameters,”

• Appendix C, “Replication Agent Data Sets”

• Appendix D, “Upgrading Your Replication Agent Software”

• Appendix E, “Running Multiple Replication Agents”

Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390

Start and stop Replication Agent

Includes information about starting, stopping, and troubleshooting Replication Agent using trace commands:

• Chapter 2, “Managing Replication Agent”

Prepare for replication

Includes information about preparing your replication environment for Replication Agent operations, including Replication Server setup, materializing replicate tables, and marking source data for replication:

• Chapter 3, “Preparing for replication”

• Chapter 4, “Replicating source tables”

Work with Replication Agent system tables

Includes information about using the Replication Agent system tables on DB2 to coordinate bulk materialization and mark tables for replication:

• Chapter 5, “Working with Replication Agent system tables”

Work with datatype conversions

Includes information about LTM for MVS datatypes, Adaptive Server datatypes, and Replication Agent datatype conversion handling:

• Chapter 6, “Working with datatype conversions”



What’s nextBefore installing Replication Agent, be sure your site meets the installation requirements. Go to Chapter 2, “Understanding Replication Agent Installation Requirements”.

Troubleshoot Replication Agent

Includes information about basic troubleshooting procedures, startup problems, restrictions, and failure and recovery:

• Chapter 7, “Basic troubleshooting procedures”

• Chapter 8, “Troubleshooting Replication Extract problems”

• Chapter 9, “Understanding known issues and restrictions”

• Chapter 10, “Troubleshooting Replication Agent start-up problems”

• Chapter 11, “Understanding error conditions”

• Chapter 12, “Recovering from Replication System errors”

Understand Replication Agent messages

Includes information, error, and warning messages written to log files and to the MVS operator console, accompanied by recommendations for user responses:

• Chapter 13, “Replication Extract messages”

• Chapter 14, “LTM for MVS messages”

• Chapter 15, “MVS console messages”

Reference

• Appendix A, “LTM for MVS configuration parameters”

• Appendix B, “Replication Extract configuration parameters”

• Appendix C, “Replication Extract commands”

• Appendix D, “Creating user exits”

What’s next



C H A P T E R 2 Understanding Replication Agent Installation Requirements

Before you install Replication Agent, ensure that your site meets the requirements listed in this chapter. This chapter includes the following information:

Understanding team skill requirementsYou need team members with the skills described in Table 2-1 to install Replication Agent successfully. For your site, identify each person or team responsible for the skill set.

Table 2-1: Team skill requirements

Topic PageUnderstanding team skill requirements 23

Understanding software requirements 24

Team skill Skill set

Coordination • Effective communication skills

• Understanding of the MVS operating system

Communications administration

• Understanding of connectivity products used at your site (SNA, VTAM, and TCP/IP)

• Ability to design, establish, test, and troubleshoot remote physical communications between Replication Agent and Replication Server

OS/390 systems programming

• Knowledge of the standards and conventions at the installation site

• Knowledge of job naming and accounting standards, data set naming conventions, and library management and authorization techniques

• Ability to create started tasks

Understanding software requirements


Understanding software requirements This section describes the software requirements for Replication Agent, including the following:

• Mainframe software requirements

• LAN software requirements

Mainframe software requirementsTable 2-2 describes the mainframe software requirements for Replication Agent.

Check each item when it is verified by the appropriate team member. Your Replication Agent installation can fail if you do not meet the prerequisites described in this section.

Data source administration • Understanding of the DB2 relational database management system (RDBMS), its authorization scheme, and its backup and recovery utilities

• Understanding of active and archive logs

• Ability to manage permissions

Replication Server administration

• Ability to design and administer the Replication Server environment

• Ability to determine appropriate methods for materialization and synchronization of primary and replicate tables

• Ability to administer Adaptive Server databases

• Ability to manage permissions needed for replication

Team skill Skill set

CHAPTER 2 Understanding Replication Agent Installation Requirements


Table 2-2: Replication Agent mainframe software requirements

LAN software requirementsThis section lists the requirements and restrictions for running Replication Server on the LAN with Replication Agent.

Replication Server version

Replication Agent for DB2 UDB for OS/390 version 12.5 is compatible with all currently supported versions of Replication Server.

See also • Replication Server Design Guide for information about capacity planning and other Replication Server requirements. Be sure to meet all the requirements listed in that chapter.

• Replication Server Administration Guide

Mainframe Software Supported Versions

MVS If you are using TCP/IP connectivity, you must use OS/390 version 2.8 or later.

SAS/C runtime environment

6.0 runtime libraries (supplied on Replication Agent software distribution tape)

Note The SAS/C runtime environment requirement replaces the IBM C/370 and PL/I requirements in earlier versions of Replication Agent.

DB2 database 6.1 or 7.1

Note Replication Agent for DB2 UDB for OS/390 12.5 includes DB2 7.1 tolerance, exploits some new features in DB2 6.1, and is expected to workwith DB2 5.x.

ISPF 3.5 or later

What’s next


What’s nextProceed to Chapter 3, “Understanding Replication Agent Operational Considerations”.


C H A P T E R 3 Understanding Replication Agent Operational Considerations

When using Replication Agent, you must consider the effects of its interactions with Replication Server and with your DB2 database and logs. Replication Agent connectivity and permissions requirements can also affect your replication environment. This chapter includes the following information about these considerations:

Before you begin • Be sure your site meets the requirements listed in Chapter 2, “Understanding Replication Agent Installation Requirements”

Understanding Sybase server operational considerations

This section contains information about the following Sybase server considerations:

• Heterogeneous datatype support (HDS)

• Replication Server-to-DB2 connectivity

Heterogeneous datatype support (HDS)For more information on setting up Replication Server and the HDS feature, see the Replication Server Configuration Guide and the Replication Server Heterogeneous Replication Guide.

Topic PageUnderstanding Sybase server operational considerations 27

Understanding DB2 database considerations 28

Understanding permissions requirements 30

Understanding DB2 database considerations


Replication Server-to-DB2 connectivityConnectivity from Replication Server to DB2 replicate databases can be accomplished using a variety of gateways. However, this connectivity is required only under the following conditions:

• You are replicating data into your DB2 database.

• You are using automatic materialization to populate your replicate database.

The gateway connectivity that allows Replication Server to issue select, insert, update, or delete statements against the tables stored in DB2 can be configured in many ways. For details on the range of available connectivity options between Replication Server and DB2, see the Replication Server Heterogeneous Replication Guide.

If you set up connectivity at your site, be sure that the Replication Agent-to-Replication Server communication at your site functions correctly, and ensure that your site is prepared for the possibility of additional work involved in maintaining a Replication Server-to-DB2 communications path. Sites without connectivity between Replication Server and DB2 require bulk materialization.

See also • http://www.sybase.com/Partners/certification/index.html on the World Wide Web for information about replication into DB2

• “Preparing for Replication” in the Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390 for detailed information about bulk materialization

Understanding DB2 database considerationsThis section details the following DB2 database restrictions you must consider when using Replication Agent:

• Support for DB2 features

• DB2 log capacity

• DB2 table size limit in Replication Server

• DB2 utilities

CHAPTER 3 Understanding Replication Agent Operational Considerations


See also • “Replicating Source Tables” in Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390 for information about considerations when using Replication Agent and DB2

Support for DB2 featuresReplication Agent version 12.5 supports some additional features for DB2 version 6. Although Replication Extract for Replication Agent version 12.5 reads logs created by DB2 version 7, Replication Agent version 12.5 will not exploit any new capabilities added by DB2 version 7.

DB2 log capacityReplication Agent increases the amount of information stored in DB2 logs. The amount depends on the size of tables being replicated and on the nature of transactions being performed on the primary database.

For optimal recovery, your DB2 active logs need the capacity for at least the number of records accumulated in a 12-hour period.

See also • IBM DB2 Administration Guide for information on allocating and managing DB2 data sets

DB2 table size limit in Replication ServerReplication Server has a 16KB stable queue buffer limit; therefore, a single transaction operation (insert, update, or delete) cannot be replicated if it exceeds 16KB.

DB2 utilitiesUsing some DB2 utilities on primary tables can jeopardize replicate databases, which may necessitate rematerializing your data.

LOAD

You may now use the DB2 LOAD LOG=YES utility to assist in replicate materialization.

Understanding permissions requirements


See also • “Restrictions on DB2 Utilities” in the Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390

Understanding permissions requirementsDB2 and Replication Server both have permission requirements to access their data and system tables.

• Replication Agent requires permission to read DB2 logs.

• Replication Agent requires permission to log in to Replication Server as a Log Transfer Manager.

The LTMADMIN user ID creates Replication Agent system tables on DB2, and requires the permissions to:

• Alter tables, for all primary DB2 tables marked for replication

• Bind and add the log extract plan, for Replication Extract operation

See also • “Task 8: Grant LTMADMIN user ID permissions”

What’s nextGo to Chapter 4, “Gathering Installation Information”


C H A P T E R 4 Gathering Installation Information

This chapter describes the information you must gather to complete the Replication Agent Installation Worksheet before installing Replication Agent.

Use the information in this section as you supply the following information on the Replication Agent Installation Worksheet:

Keep a copy of the completed worksheet for your records. You may want to refer to it during future installations or upgrades.

Before you begin • Review the system hardware and software prerequisites described in Chapter 2, “Understanding Replication Agent installation requirements”.

• If you are unfamiliar with Replication Server, read the following manuals before you install Replication Agent:

• Replication Server Administration Guide

• Replication Server Design Guide

• Verify that you have the following:

• Software distribution tape

• Network configuration and machine names

• Make a copy of the “Replication Agent Installation Worksheet” on page 68.

Topic PageSection 1: Recording user IDs 32

Section 2: Recording the LTM for MVS start-up procedure name 33

Section 3: Recording Replication Agent installation information 34

Section 4: Recording Replication Extract installation information 34

Section 5: Recording TCP/IP configuration information 36

Section 6: Recording TCP/IP information for Adaptive Server 37

Section 7: Recording required configuration information 39

Section 1: Recording user IDs


Section 1: Recording user IDsSybase recommends that you create the following users:

• The LTMADMIN user. This is a TSO user, optionally named LTMADMIN, who installs, starts, and stops Replication Agent, manages the Replication Agent system tables on DB2, and binds the log extract plan. This identifier can be a TSO login ID or a group identifier. MVS user ID restrictions apply to this identifier.

• The Replication Server maintenance user. This is the Replication Server user ID specified in the create connection command when creating a connection to Replication Server. (If you plan to replicate into DB2, to prevent cyclic replication, the maintenance user ID should not be identical to the RS user.)

• The RS user. This is a Replication Server user ID that LTM for MVS uses to log in to the primary Replication Server. This user must have connect source permission on Replication Server. This is the user ID specified in the value of the LTM for MVS RS_user configuration parameter.

• The RSSD user. This is the identifier that Replication Agent uses to log on to the Adaptive Server that contains the primary Replication Server RSSD. This user must have permission to perform selects against the Adaptive Server. This is the user ID specified in the value of the LTM for MVS RSSD_user configuration parameter.

See Table 1-1 on page 16 for detailed information about these user IDs.

❖ Recording user IDs

1 Record the LTMADMIN user ID in the following sections of the Replication Agent Installation Worksheet:

• Section 1a, “LTMADMIN User ID”

• Section 7g, “Creator”

2 Record the Replication Server maintenance user ID in section 1b, “Replication Server maintenance user ID.”

Note The Replication Server maintenance user ID should not be identical to the RS user.

3 Record the user ID that Replication Agent uses to log on to the primary Replication Server in the following sections of the Replication Agent Installation Worksheet:

CHAPTER 4 Gathering Installation Information


• Section 1c, “RS user”

• Section 7c, “RS_user”

Note The RS user should not be identical to the Replication Server maintenance user ID.

4 Record the user ID that Replication Agent uses to log on to the Adaptive Server that contains the primary Replication Server RSSD in the following sections of the Replication Agent Installation Worksheet:

• Section 1d, “RSSD user”

• Section 6f, “Adaptive Server User ID”

Section 2: Recording the LTM for MVS start-up procedure name

In this section you record the started task or batch procedure name that you use when starting and stopping Replication Agent.

Note In the JCL examples throughout the Replication Agent documentation, the variable “LTMxxxxx” represents the started task or batch procedure name that you select and record in this step.

❖ Recording the LTM for MVS start-up PROC name

1 Record the LTM for MVS start-up PROC name in section 2a of the Replication Agent Installation Worksheet.

Sybase recommends that the LTM for MVS PROC name consist of the prefix “LTM” plus a suffix of up to 5 characters.

2 (Optional) If you plan to run more than one instance of LTM for MVS, record a unique suffix for each LTM for MVS PROC corresponding to a subsystem in section 2b of the Replication Agent Installation Worksheet.

Section 3: Recording Replication Agent installation information


Section 3: Recording Replication Agent installation information

In this section, you select and record additional values to use when installing Replication Agent.

❖ Recording the Replication Agent installation information

1 Record valid job card information for your site in section 3a of the Replication Agent Installation Worksheet.

2 Select and record your high-level qualifier in section 3b of the Replication Agent Installation Worksheet.

• Optional step: If this is a new qualifier, enter an ALIAS entry in the MVS master catalog.

Note In the Replication Agent documentation, the hlq variable represents the high-level qualifier you record in this step.

3 Record the Unit specification for temporary datasets used in this installation in section 3d of the Replication Agent Installation Worksheet.

4 Record the Unit specification for catalog datasets used in this installation in section 3e of the Replication Agent Installation Worksheet.

5 Record the disk volume for the disk on which the permanent data sets will reside in section 3c of the Replication Agent Installation Worksheet.

Example value: RAD125.

Section 4: Recording Replication Extract installation information

This section explains how to record the following information, which you need to run the Replication Extract component of Replication Agent:

• DB2 subsystem ID

• Log extract plan name

• DB2 SDSNEXIT library name

• DB2 SDSNLOAD library name



• DB2 RUNLIB library name

• DB2 DBRMLIB library name

• DB2 version

Specifying DB2 system libraries for multi-member datasharingIf you are running a multi-member datasharing system, the DB2 system libraries listed here can be the libraries of any member involved in your data-sharing system. However, Sybase recommends that these libraries be those of member 0.

❖ Recording Replication Extract installation panel information:

1 Record the DB2 subsystem ID in section 4a, “DB2 subsystem ID (db2ssid),” on the Replication Agent Installation Worksheet.

If you are running DB2 in nondata-sharing mode, the DB2 subsystem ID should identify the subsystem ID of the member from which you are replicating transaction information.

If you are running DB2 in data-sharing mode, the DB2 subsystem ID should identify either the DB2 group attach name or member 0 of the data-sharing group.

2 Record the log extract plan name in section 4b, “Log extract plan name,” on the Replication Agent Installation Worksheet. The default value is REPAGENT.

If you are upgrading from an earlier version of Replication Agent that you are installing on the same DB2 subsystem as an older version, select a different plan name to prevent overlaying the old plan.

Note If you change the name of the log extract plan, you must also change the plan name in the PLANS00 member of the hlq.PDR.PARMLIB library and in the PDRBIND member of the hlq.JCL library. See Chapter 6, “Configuring Replication Extract” for details about working with these members.

3 Obtain the DB2 SDSNEXIT library name from your systems programmer. Record this name in section 4c of the Replication Agent Installation Worksheet.

Section 5: Recording TCP/IP configuration information


4 Obtain the DB2 SDSNLOAD library name from your systems programmer. Record this name in section 4d of the Replication Agent Installation Worksheet.

5 Obtain the DB2 RUNLIB library name from your systems programmer. Record this name in section 4e of the Replication Agent Installation Worksheet.

6 Obtain the DBRMLIB library name from your systems programmer. This is the DB2 utility DBRMLIB library. Record this name in section 4f of the Replication Agent Installation Worksheet.

7 Record the version of DB2 UDB you are using with Replication Agent in section 4g of the Replication Agent Installation Worksheet.

See also • Chapter 2, “Configuring Replication Extract” for detailed information about configuring Replication Extract

Section 5: Recording TCP/IP configuration informationTo support a TCP/IP connection between Replication Agent and the servers in your replication system, you must provide your MVS system with Sybase server names and TCP/IP host addresses.

Use the information in this section as you record these values on the Replication Agent Installation Worksheet.

Note The SYGWHOST macro replaces the mainframe interfaces file required in earlier versions of Replication Agent.

Recording TCP/IP information for Replication ServerEach XCPHPING member can contain multiple SYGWHOST TYPE=ENTRY macro entries. For each primary Replication Server in your replication system, add a SYGWHOST macro entry to the XCPHPING member of the hlq.JCL data set.



❖ Recording TCP/IP information for Replication Server

1 Record the name of the primary Replication Server in the following locations on the Replication Agent Installation Worksheet:

a Section 5a, “SERVERNAME”

You can contact your Replication Server Administrator for the primary Replication Server name.

This name must match the value specified for the RS parameter in the Replication Agent configuration file, and it is restricted to 30 characters maximum.

b Section 7b, “RS.”

2 Record the IP address of the machine on which Replication Server runs in section 5b, “IPADDR,” on the Replication Agent Installation Worksheet.

Contact your Replication Server Administrator for the IP address if necessary.

3 Record the listen port of the machine on which Replication Server runs in section 5c, “LSTNPORT,” on the Replication Agent Installation Worksheet.

Contact your Replication Server Administrator for the port number.

4 Record the name of the IBM TCP/IP address space in section 5d, “IBMTCPADDRSPACE,” on the Replication Agent Installation Worksheet.

Section 6: Recording TCP/IP information for Adaptive Server

If you plan to set the value of the Use_repdef parameter to Y, you must do the following:

• Create a SYGWHOST TYPE=ENTRY macro entry in the XCPHPING member of the hlq.JCL data set to provide information about the Adaptive Server that contains the RSSD for the primary Replication Server.

• Supply specific LTM for MVS configuration parameter values.

Use the information in this section as you record these values on the Replication Agent Installation Worksheet.

Section 6: Recording TCP/IP information for Adaptive Server


❖ Recording TCP/IP information for Adaptive Server

1 Record the name of the Adaptive Server that contains the primary Replication Server RSSD in both of the following locations on the Replication Agent Installation Worksheet:

a Section 6a, “SERVERNAME”

Contact your Replication Server Administrator for this value.

b Section 6d, “RSSD_server”

2 Record the IP address of the machine on which the Adaptive Server containing the Replication Server RSSD runs in section 6b, “IPADDR,” on the Replication Agent Installation Worksheet.

Contact your Adaptive Server Administrator for this IP address.

3 Record the listen port of the machine on which Adaptive Server runs in section 6c, “LSTNPORT,” on the Replication Agent Installation Worksheet.

Contact your Adaptive Server Administrator for this port number.

❖ Recording the Adaptive Server configuration parameter values

1 Record the Adaptive Server database name in section 6e on the Replication Agent Installation Worksheet.

2 The Adaptive Server User ID should have been recorded in section 6f on the Replication Agent Installation Worksheet (see “Section 1: Recording user IDs” on page 58 for details).

Replication Agent uses this ID to log on to the Adaptive Server that contains the primary Replication Server RSSD.

3 Specify the Adaptive Server password in section 6g on the Replication Agent Installation Worksheet.

See also • Chapter 7, “Configuring TCP/IP for Replication Agent” for detailed information about the SYGWHOST TYPE=ENTRY macro

• Appendix A, “LTM for MVS Configuration Parameters” for detailed information about the RSSD configuration parameters



Section 7: Recording required configuration information

This section describes how to select and record the configuration file name and the values of several required configuration parameters. You provided some of these configuration parameter values in earlier steps in this chapter.

See also • Appendix A, “LTM for MVS Configuration Parameters” for detailed information about configuration parameters

❖ Recording the configuration file information

1 On the Replication Agent Installation Worksheet, record the name of the configuration file in section 7a, “Configuration file name.”

Note If you are upgrading your Replication Agent software from an earlier version, review the configuration parameter values from the configuration file you used previously. Use values for the parameters in the Replication Agent Version 12.5 configuration file that match the values you used in the most recent version of Replication Agent.

2 Verify that the value recorded for the RS parameter in section 7b, “RS,” meets the following condition:

The value you specify for the RS configuration parameter must match the value of the TCP/IP SERVERNAME variable in the XCPHPING file.

You provided this value in section 5a, “SERVERNAME,” on the Replication Agent Installation Worksheet.

3 The user ID that Replication Agent uses to log on to the primary Replication Server should have been recorded in section 7c, “RS_user,” on the Replication Agent Installation Worksheet.

4 Record the password for the user ID identified in section 7d, “RS_pw,” on the Replication Agent Installation Worksheet. This value can have a maximum of 30 characters.

5 Record the RS_source_ds parameter value in section 7e, “RS_source_ds,” on the Replication Agent Installation Worksheet.

Note Be sure that the name you supply for the RS_source_ds parameter matches the value you specify for the data_server variable in the create connection command used to connect Replication Agent to the primary Replication Server.

Section 7: Recording required configuration information


6 Record the RS_source_db parameter value in section 7f, “RS_source_db,” on the Replication Agent Installation Worksheet.

Note Be sure that the value you supply for the RS_source_db parameter matches the value you specify for the database variable in the create connection command used to connect Replication Agent to the primary Replication Server.

7 Verify that the value recorded in section 7g for the Creator configuration parameter matches the value for the LTMADMIN user ID in section 1a, “LTMADMIN User ID.”

The value of the Creator parameter identifies the creator of the LTMOBJECTS table.

8 Verify that the value for the Log_identifier parameter in section 7h, “Log_identifier,” on the Replication Agent Installation Worksheet, exactly matches the DB2 subsystem or group attach name (depending on whether you are running DB2 in data-sharing mode) from which you are replicating transaction information and installing Replication Extract.

If you are running DB2 in data-sharing mode: The value of the Log_identifier parameter must contain the DB2 group attach name.

If you are running DB2 in nondata-sharing mode: The value of the Log_identifier parameter must exactly match the following values:

• The value you provided for the DB2 subsystem ID (db2ssid) in section 4a of the Replication Agent Installation Worksheet.

• The value you supply for the db2ssid variable in the PDRBIND member of the hlq.JCL data set. You edit and submit the PDRBIND job when binding the log extract plan.

• The value of the SSID parameter in the SETUP00 member of the hlq.PDR.PARMLIB data set.

Note The SETUP00 member was named SETUP in previous releases.

See also Appendix A, “LTM for MVS Configuration Parameters”



Replication Agent Installation WorksheetUse the following worksheet when you install Replication Agent.

Make a photocopy of this worksheet and enter the information before you proceed through the tasks in Chapter 5, “Installing Replication Agent”.

Keep the completed worksheet. You will need this information when you install and use Replication Agent, or when you call Technical Support.

Provide the following information on this worksheet:

1. User IDs2. LTM for MVS start-up procedure name3. Replication Agent installation panel information4. Replication Extract installation panel information5. TCP/IP information for Replication Server (if applicable)6. TCP/IP information for Adaptive Server (if you plan to set the value of the Use_repdef configuration parameter to Y)7. LTM for MVS configuration informationSee “Section 7: Recording required configuration information” on page 39 for details about these values.

Replication Agent Installation Worksheet


1. User IDsSee “Section 1: Recording user IDs” on page 32 for details about the user identifiers you must select and record in this section.

a. LTMADMIN user ID:

Sybase recommends that you create a TSO user named LTMADMIN. This user installs, starts, and stops Replication Agent, manages the DB2 system tables, and binds the log extract plan.

MVS restrictions apply to this user ID. This value must exactly match the value of the LTM for MVS Creator configuration parameter (see section 7g of this worksheet).

b. Replication Server maintenance user ID:

This is the Replication Server user ID specified in the create connection command when creating a connection to Replication Server. (If you plan to replicate into DB2, to prevent cyclic replication, the maintenance user ID should not be identical to the RS user.)

c. RS user:

This is a Replication Server user ID that LTM for MVS uses to log into the primary Replication Server.

d. RSSD user:

This is the identifier that Replication Agent uses to log on to the Adaptive Server that contains the primary Replication Server RSSD.



2. LTM for MVS start-up procedure nameSee “Section 2: Recording the LTM for MVS start-up procedure name” on page 33 for details about this procedure name.

a. LTM for MVS start-up PROC name (LTMxxxxx):

The LTM for MVS PROC name becomes the LTM for MVS started task name when you start Replication Agent. Sybase recommends naming this procedure with the prefix “LTM” plus a suffix of 5 characters maximum.

b. (Optional) If you are running additional Replication Agents, provide a unique LTM PROC name for each one:

LTM _ _ _ _ _

LTM _ _ _ _ _

LTM _ _ _ _ _

LTM _ _ _ _ _



3. Replication Agent installationSee “Section 3: Recording Replication Agent installation information” on page 34 for details about these panel options.

a. Job card information:

Supply valid job card information for your site. See your systems programmer if you need assistance.

b. High-level qualifier (hlq):

Identifies the data sets created during installation. This replaces the hlq variable in the JCL and library names throughout this documentation. Example value: DWM.RA.TEST

c. Disk volume (VOL=SER):

Obtain this value from the software distribution label. Example value: RAD125.

d. Unit specification for temporary data sets:

Use the name assigned by your systems programmer. 8 characters maximum. Example value: SYSDA.

e. Unit specification for catalog data set sets:

Example value: 3390.



4. Replication Extract installation panel informationSee “Section 4: Recording Replication Extract installation information” on page 34 for details about these panel options.

a. DB2 subsystem ID (db2ssid):

Identifies the DB2 subsystem ID from which you will replicate transaction information. If you are running DB2 in data-sharing mode, Sybase recommends that you specify the subsystem ID for member 0 of the data-sharing group. Record this value in section 7i.Example value: DMW5

b. Log extract plan name:

Default value: REPAGENT (see “Section 4: Recording Replication Extract installation information” on page 61 for information about selecting a different plan name)

c. DB2 SDSNEXIT library name:

Obtain this library name from your systems programmer.

d. DB2 SDSNLOAD library name:


e. DB2 RUNLIB library name:


f. DB2 DBRMLIB library name:

Obtain the DBRMLIB library name from your systems programmer. This is the DB2 utility DBRMLIB library.

g. DB2 version:

This is the version of DB2 you are using with Replication Agent.



5. TCP/IP information for Replication ServerSee “Section 5: Recording TCP/IP configuration information” on page 36 for details about these values.

If you have more than one Replication Server in your replication system, before filling out this portion of the worksheet, make a copy of this page for each additional Replication Server in your replication system.

For each Replication Server in your system, add one SYGWHOST TYPE=ENTRY macro entry to your XCPHPING member.

a.Replication Server name (SERVERNAME):

Identifies the name of the primary Replication Server to which Replication Agent connects. Restricted to 30 characters maximum.

This value must match the value of the RS configuration parameter. See section 7b of this worksheet.

b. IP address (IPADDR):

This is the IP address of the machine on which Replication Server runs.

c. Listen port (LSTNPORT):

This identifies the listen port of the machine on which Replication Server runs.

d. TCP address space (IBMTCPADDRSPACE):

Supply the IBM TCP/IP address space name as this parameter value only if you are using IBM TCP/IP. All characters must be uppercase.



6. TCP/IP information for Adaptive ServerSee“Section 6: Recording TCP/IP information for Adaptive Server” on page 37 for details about these values.

If you have more than one Adaptive Server containing a primary Replication Server RSSD in your replication system, make a copy of this page for each additional Adaptive Server in your replication system.

For each Adaptive Server containing a primary Replication Server RSSD, add one SYGWHOST TYPE=ENTRY macro entry to your XCPHPING member.

a. Adaptive Server name (SERVERNAME):

Identifies the name of the Adaptive Server that contains the Replication Server System Database (RSSD). This name consists of a maximum of 30 characters.

This value must match the value of the RSSD_server configuration parameter. See section 6d of this worksheet.

b. Adaptive Server IP address (IPADDR):

This is the IP address of the machine on which the RSSD Adaptive Server runs.

c. Adaptive Server listen port (LSTNPORT):

This is the listen port of the machine on which the RSSD Adaptive Server runs.

d. RSSD_server:

The RSSD_server value must match the value of the SERVERNAME variable in the SYGWHOST macro entry for the Adaptive Server containing the primary Replication Server RSSD. Use the same value you record in section 6a of this worksheet.

e. Adaptive Server database:

This is the Adaptive Server that contains the primary Replication Server RSSD.

f. Adaptive Server User ID:

This is the identifier that Replication Agent uses to log on to the Adaptive Server that contains the primary Replication Server RSSD.

g. Adaptive Server password:

This is the password that Replication Agent uses to log on to the Adaptive Server that contains the primary Replication Server RSSD.

What’s next


7. LTM for MVS configuration informationSee “Section 7: Recording required configuration information” on page 39 for details about these values.

What’s nextYou are now ready to install Replication Agent. Go to Chapter 5, “Installing Replication Agent”.

a. Configuration file name (LTMCNFG):

b. RS:

This value must match the value of the SERVERNAME variable in section 5a of this worksheet.

c. RS_user:

This identifies the user name that Replication Agent uses to log on to the primary Replication Server. Maximum of 30 characters.

Note The value of the RS_user parameter should not be identical to the user identified by the LTMADMIN user ID.

d. RS_pw:

This is the password for the user ID identified in the value of RS_user. Maximum of 30 characters.

e. RS_source_ds:

Must match the data server name in the Replication Server create connection command that Replication Agent issues to connect to Replication Server.

f. RS_source_db:

Must match the database name in the Replication Server create connection command that Replication Agent issues to connect to Replication Server.

g. Creator:

Identifies the creator of the DB2 system tables (LTMOBJECTS, LTMMARKER, and LTMLASTCOMMIT). The value you specify for Creator must match the user ID you specified in section 1.

h. Log_identifier:

Identifies the DB2 subsystem ID from which you are replicating transaction information or, if you are running DB2 in data-sharing mode, the DB2 group attach name.


C H A P T E R 5 Installing Replication Agent

This chapter describes how to install Replication Agent, which includes the following tasks:

Note Read this entire chapter before installing your Replication Agent software.

If you are upgrading to Replication Agent for DB2 UDB for OS/390 version 12.5, complete the tasks in this chapter, and proceed to Appendix D, “Upgrading Your Replication Agent Software” for additional instructions.

Before you begin • Be sure you completed the tasks in Chapter 4, “Gathering Installation Information”.

• Have a Replication Agent Installation Worksheet in front of you while you work through this chapter.

• Make sure that only the LTMADMIN user ID performs the Replication Agent installation. This user ID, which you record in section 1 on the Replication Agent Installation Worksheet, must keep the authorizations or permissions granted regardless of personnel changes.

See also • Chapter 4, “Gathering Installation Information”

Topic PageTask 1: Gather installation information 50

Task 2: Start the installation program 50

Task 3: Customize the JCL 51

Task 4: Transfer the data sets 52

Task 5: Unpack LINKLIB data sets 53

Task 6: Perform systems programmer installation tasks 54

Task 7: Create the Replication Agent system tables 54

Task 8: Grant LTMADMIN user ID permissions 55

Task 9: Install the Replication Agent interface 58

Task 10: Define the LTM start-up procedure 59

Task 1: Gather installation information


• “Replication Agent Installation Worksheet” on page 41

Task 1: Gather installation informationComplete the Installation Worksheet from Chapter 4, “Gathering Installation Information”.

Task 2: Start the installation programThis section describes how to start the Replication Agent for DB2 UDB installation program and set the path of the temporary work directory, where the installer places its temporary files.

❖ Starting the Replication Agent for DB2 UDB installation program

• Perform the following, based on your operating system.

• On Windows NT or Windows 2000: At the windows task bar, click on Start/Run and open x:\setup.bat, where 'x' indicates the drive containing the installation CD.

• On Solaris: Change to the root directory of your CD device and run setup, which is a csh script.

• On HP-UX: Change to the root directory of your CD device and run the setuphp script.

• On AIX: Change to the root directory of your CD device and run the setupaix script.

The Work Directory dialog box prompts you for the path of a temporary work directory.

❖ Setting the path of the temporary work directory

The temporary work directory is used to hold the customized JCL that is to be transferred to the mainframe. After installing Replication Agent for DB2 UDB for OS/390, you can delete this directory.

CHAPTER 5 Installing Replication Agent


1 Provide the path for the temporary work directory. You can use either the default directory for your operating system or provide a different directory name.

• To use the default directory: Choose the default for your operating system.

• To provide a directory name: Enter the path for the directory, or browse and select a path using the '...' button.

2 Click Set.

The directory path is created if it does not exist, and the Installation Data Entry dialog box appears.

Task 3: Customize the JCL❖ Customizing the JCL

1 At the Installation Data Entry dialog box, complete the following fields.

Operating system Default value

Windows NT and Windows 2000

C:\Documents and Settings\useridI\RAP’

UNIX ~userid/RAP

In this field Enter

JCL Line 1, Line 2, and Line 3

Job card information you recorded in section 3a of the Installation Worksheet.

Rep Agent HLQ High-level qualifier you recorded in section 3b of the Installation Worksheet.

Volume Serial The disk volume you recorded in section 3c of the Installation Worksheet.

Unit (work/data set) Unit specifications for temporary and catalog data sets you recorded in sections 3d and 3e of the Installation Worksheet.

DB2 Subsystem ID Subsystem ID you recorded in section 4a of the Installation Worksheet.

DB2 SDSNLOAD DSN SDSNLOAD library name you recorded in section 4d of the Installation Worksheet.

DB2 Runlib DSN RUNLIB library name you recorded in section 4e of the Installation Worksheet.

Task 4: Transfer the data sets


2 Click Tailor the JCL.

The generated JCL is written to the temporary work directory. You can rerun the customizing process any number of times. Each time, the contents of the temporary directory are deleted and overwritten.

The Installation Data Entry dialog box remains active, allowing you to transfer the data sets.

Task 4: Transfer the data setsAfter you have customized the JCL, transfer all data sets to the mainframe by selecting the FTP to Mainframe button of the Data Entry Window.

DB2 Exitlib DSN SDSNEXIT library name you recorded in section 4c of the Installation Worksheet.

DB2 Planname Log extract plan name you recorded in section 4b of the Installation Worksheet.

Note Do not specify a plan already in use at your installation. The R+ep Agent bind replaces all contents of an existing plan.

DB2 Version DB2 version you recorded in section 4g of the Installation Worksheet.

LTMADMIN User ID The user ID you recorded in section 1a of the Installation Worksheet.

Rep Server Name, IP, Port Values you recorded for sections 5a, 5b, and 5c, respectively.

Rep Server User ID/Password

Values you recorded for sections 7c and 7d of the Installation Worksheet.

ASE Name, IP, Port Values you recorded for sections 6a, 6b, and 6c, respectively.

ASE User ID/Password Values you recorded for sections 6f and 6g of the Installation Worksheet.

ASE Database Name The name you recorded in section 6e of the Installation Worksheet.

In this field Enter



All data sets are cataloged under the high level qualifier (hlq) specified in the Rep Agent HLQ field of the Data Entry Window and must be a valid catalog alias. There should be no preexisting data sets under hlq. If you need to restart or rerun the transfer, delete the data sets previously transferred.

❖ Transferring the data sets

1 In the Mainframe Host Name field, enter the DNS host name or IP address of your mainframe.

2 In the Mainframe Userid field, enter the TSO user ID to be used by FTP.

3 In the Mainframe Password field, enter the password associated with the user ID entered in the previous step.

Note The user ID is saved in the temporary working directory, but the password is not saved.

4 At FTP Allocation Defaults:

5 Select Go to start the FTP transfer.

Task 5: Unpack LINKLIB data setsReview the JCL in the RECEIVE and ALLOC members of the hlq.JCL data set. The RECEIVE job unpacks the Replication Agent and SAS/C runtime loadlibs into standard loadlibs. The ALLOC job allocates permanent Replication Agent data sets and defines generation data groups for Replication Agent logs.

Execute the RECEIVE and ALLOC jobs from the TSO command prompt.

Select this: To do this:

Mainframe FTP System Defaults

The volumes that are defined for default allocations in your mainframe’s FTP configuration.

Rep Agent ‘Tailored’ Settings

The same volume and unit defined on the ‘Common’ tab of the ‘Data Entry Window’.

Specific Volume/Unit A specific Volume and Unit.

Task 6: Perform systems programmer installation tasks


Task 6: Perform systems programmer installation tasks

Your systems programmer must perform several tasks to enable you to install and use Replication Agent. Have your systems programmer use this section to complete these tasks.

Note Do not concatenate non-APF authorized libraries on the same STEPLIB with the LINKLIB file.

❖ Performing systems programmer installation tasks

1 Authorize libraries.

Your systems programmer must grant APF authorization to the following libraries:

• Replication Agent LINKLIB library (hlq.LINKLIB)

• SAS/C run-time library (hlq.SAS.LINKLIB)

2 Configure your started tasks.

If needed, have your systems programmer add your started tasks to the IPL (initial program load) procedure for each LTM for MVS instance you defined.



Task 7: Create the Replication Agent system tables

Note If you are upgrading Replication Agent from an earlier release, you do not need to create the Replication Agent system tables on DB2. Go to “Task 10: Define the LTM start-up procedure” on page 59.

This step describes how to modify the sample JCL contained in the SQLINIT member in the hlq.JCL library to create and initialize the Replication Agent system tables on DB2.

Executing the SQLINIT job does the following:



• Creates the LTMOBJECTS and LTMMARKER Replication Agent system tables in DB2

• Grants SELECT permission on the Replication Agent LTMOBJECTS and LTMMARKER tables to PUBLIC

• Grants UPDATE permission on the Replication Agent LTMOBJECTS table to PUBLIC

Warning! Do not change the Replication Agent system table names.

❖ Creating the Replication Agent system tables

1 Log on to OS/390 as the LTMADMIN user. You recorded this user name in section 1a on the Replication Agent Installation Worksheet.

2 If you need to limit permissions, edit the SQLINIT member to replace PUBLIC with a subset of users who need these permissions.

Note If the system tables share a tablespace or database with your primary tables, Replication Extract can hold locks that prevent updates to the primary table.

3 Use the SPUFI utility to execute the SQLINIT member.

4 Most sites maintain a list of tables to be copied when you use the COPY utility to image copy the DB2 catalogs. Add the LTMOBJECTS and LTMMARKER table names to this list. Contact your DB2 database administrator for assistance with this task.

Task 8: Grant LTMADMIN user ID permissionsThe LTMADMIN user ID requires the appropriate permissions for managing the Replication Agent system tables on DB2, binding and executing the log extract plan, and executing traces on DB2.

In this section, you grant the LTMADMIN user ID the permissions to:

• Use the LTMADMIN user ID to bind and add the log extract plan

Task 8: Grant LTMADMIN user ID permissions


• Execute TRACE and MONITOR2 commands in DB2

Note You must grant permissions if the LTMADMIN user did not create the tables specified in each of the steps.

❖ Granting permissions to the LTMADMIN user

1 Grant the LTMADMIN user the permission to alter all primary DB2 tables that you mark for replication, using the following syntax:

GRANT ALTER ON TABLE table_name TO

LTMADMIN_user_ID

This grant allows the LTMADMIN user to execute an ALTER TABLE DATA CAPTURE CHANGES command on primary tables when replication is turned on.

2 Grant the LTMADMIN user permission to make inserts and updates in the LTMOBJECTS Replication Agent system table on DB2. Use the following syntax:

GRANT ALL (ERROR_CODE,QID) ON TABLE creator_name.LTMOBJECTS TO

LTMADMIN_user_ID

where creator_name is the user ID of the creator of the Replication Agent system tables and LTMADMIN_user_ID is the LTMADMIN user ID you recorded in section 1a on the Replication Agent Installation Worksheet.

3 Grant the LTMADMIN user ID select permission on the following DB2 catalog tables:

• SYSTABLES

• SYSTABLESPACE

• SYSTABLEPART

• SYSCOLUMNS

• SYSFIELDS

• SYSCOPY

4 Using the following syntax, grant DB2 TRACE permission to the LTMADMIN user ID:

GRANT TRACE to LTMADMIN_user_ID



where LTMADMIN_user_ID is the LTMADMIN user ID name you recorded in section 1a on the Replication Agent Installation Worksheet.

Note The DB2 TRACE facility must be active while Replication Agent is running.

If this permission is not granted, Replication Extract operation terminates and causes Replication Agent to stop.

Note To issue the MONITOR2 grant, you cannot be logged on as the LTMADMIN user ID.

5 Using the following syntax, grant DB2 DISPLAY permission to the LTMADMIN user ID:

GRANT DISPLAY to LTMADMIN_user_ID


Note To issue this grant, you cannot be logged on as the LTMADMIN user ID.

If this permission is not granted, Replication Extract operation terminates and causes Replication Agent to stop.

6 If you are using Replication Agent in a data-sharing environment, grant the LTMADMIN user ID permission to execute DB2 MONITOR2 commands, using the following example syntax:

GRANT MONITOR2 to LTMADMIN_user_ID


Note To issue this grant, you cannot be logged on as the LTMADMIN user ID.

See also “Working with Replication Agent System Tables” in the Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390 for information about working with the DB2 system tables

Task 9: Install the Replication Agent interface


Task 9: Install the Replication Agent interfaceThe Replication Agent interface consists of ISPF dialog panels. You use the Replication Agent interface dialog panels to mark tables for replication, and to activate and validate subscriptions.

❖ Installing the Replication Agent interface

1 In the hlq.ISPF data set:

• Verify that the JCL in the LTMSSET member is correct for your site.

2 Verify that the Replication Agent interface ISPF dialog panels are installed and functioning correctly by performing the following steps:

a Execute LTMCSET from the command line of any ISPF menu or type TSO EXEC ‘hlq.ISPF (LTMCSET)’ from the TSO command prompt.

The system displays the Replication Agent Main Menu.

b On the Replication Agent Main Menu, type 1 in the SELECTION field and press Enter.

The system displays the Activate and Deactivate Replication dialog.

3 To set replication on for an existing table, type 1 in the SELECTION field and complete the following required fields for the table:

• Table Creator ID - the ID of the table owner

• Table Name - the name of the existing table

• LTMOBJECTS Qualify field - default is NO

• LTMOBJECTS Creator ID - usually the LTMADMIN user

• DB2 Subsystem ID - the subsystem where you created the system tables in “Task 7: Create the Replication Agent system tables”.

4 Press Enter to save the changes.

5 Press F3 to exit from the Replication Agent interface dialog.

6 Verify that the activation job executed successfully.

See also “Replicating Source Tables” in the Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390 for information about using the Replication Agent interface



Task 10: Define the LTM start-up procedureThis section describes how to define the LTM start-up procedure for your site.

The LTM start-up procedure runs Replication Agent. The sample JCL for the LTM start-up procedure is contained in the LTMPROC member of the hlq.JCL library.

❖ Defining the LTM start-up procedure

1 Verify that the JCL in the LTMPROC member in the hlq.JCL library is correct for your site.

2 Save the LTMPROC member as the LTM for MVS procedure name you recorded on the Replication Agent Installation Worksheet in section 2, “LTM for MVS start-up Procedure Name.” This name is represented by “LTMxxxxx” in the Replication Agent documentation.

3 Depending on whether you want to run Replication Agent as a started task or batch job, perform one of the following procedures:

a Running Replication Agent as a started task

If you run Replication Agent as a started task, you must associate the LTMADMIN user ID with the LTM for MVS start-up procedure in the security started procedure table.

If you do not add the LTMADMIN user ID to the security package started procedure table, attempts to run Replication Agent as a started task can fail with an error similar to the following:

USER IS NOT AUTHORIZED TO EXECUTE PLAN REPAGENT

where REPAGENT is the name of the log extract plan.

To run Replication Agent as a started task

1 Copy the LTMxxxxx to one of the procedure libraries in the JES PROCLIB concatenation used for started tasks.

Note If you run Replication Agent as a started task, your systems programmer can modify the IPL procedure to start the task automatically.

2 Have the OS/390 systems programmer associate the LTMADMIN user ID with the LTM for MVS procedure by adding them to the security system started task authorization table. These names were recorded on the Replication Agent Installation Worksheet.

What’s next


b Running Replication Agent as a batch job

1 Copy the LTMxxxxx PROC to one of the procedure libraries in the JES PROCLIB concatenation or to any valid user procedure library used for batch jobs.

2 Verify that the execution JCL in the RUNLTM member in the hlq.ISPF library complies with your site’s standards for job card and accounting information.

You should also verify that the EXEC statement in the JCL for the RUNLTM member refers to the LTM for MVS start-up Procedure Name you recorded on the Replication Agent Installation Worksheet.

What’s nextIf you are installing Replication Agent for the first time, proceed to Chapter 6, “Configuring Replication Extract”.

If you are upgrading Replication Agent from an earlier release, proceed to Appendix D, “Upgrading Your Replication Agent Software”.


C H A P T E R 6 Configuring Replication Extract

This chapter describes the following steps required to configure Replication Extract:

Before you begin • Be sure you have completed the tasks in Chapter 5, “Installing Replication Agent”

See also • Appendix B, “Replication Extract Configuration Parameters”

• “Replication Extract Commands” in the Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390

Task 1: Edit the PARMLIB library membersThe PARMLIB (parameter library) members contain the parameters that enable you to configure the execution of Replication Extract. You can find the SETUP00, PDR, and PLANS00 members in the hlq.PDR.PARMLIB data set. This is the data set pointed to by the PTIPARM DD name in the LTMPROC JCL.

Note The SETUP00 and PLANS00 members were named SETUP and PLANS, respectively, in previous releases.

Topic PageTask 1: Edit the PARMLIB library members 61

Task 2: Bind the log extract plan 67

Task 1: Edit the PARMLIB library members


Each parameter in the SETUP00, PDR, and PLANS00 members consists of a parameter name, followed by the parameter value, enclosed in parentheses. If you add comments to any PARMLIB data set member, make sure that each set of opening comment characters (/*) has a corresponding set of closing comment characters (*/). Omitting any of these characters can result in errors during the PARMLIB data set processing.

Note If you are upgrading your Replication Agent software from an earlier version, review the configuration parameter values from the configuration file you used previously. Use values for the parameters in the SETUP00 and PDR members in the hlq.PDR.PARMLIB data set that match the values you used in the most recent version of Replication Agent.

You can edit the SETUP00 and PDR members to allow Replication Agent to process one or more members in a DB2 data-sharing environment.

Note The installation tasks in Chapter 5, “Installing Replication Agent” effect basic customization of the PLANS00, SETUP00, and PDR members for a non-datasharing environment.

If you need to configure Replication Agent to run in a datasharing environment, continue with Task 1a: Edit the PLANS00 member. Otherwise, skip to Task 2: Bind the log extract plan.

Task 1a: Edit the PLANS00 memberThe PLANS00 member of the hlq.PDR.PARMLIB data set contains the PDRPLANS variable, which contains the log extract plan name. The following example shows a sample PLANS00 member:

PDRPLN01 = REPAGENT /*PLATINUM REPLICATION EXTRACT PLAN*/

❖ To edit the PLANS00 member

Supply a name for the log extract plan. REPAGENT is the default name for the log extract plan.

If you are upgrading from an earlier version of Replication Agent and you plan to run both versions from the same DB2 subsystem: Be sure to select a unique name for the log extract plan to prevent overlaying the older version of the plan with the newer plan.

CHAPTER 6 Configuring Replication Extract


If you do not use the default name for the log extract plan: Make the following changes:

1 Change the value of the PDRPLANS variable from “REPAGENT” to the name you recorded in section 4b on the Replication Agent Installation Worksheet.

2 Change the name of the plan in the sample JCL supplied in the PDRBIND member of the hlq.JCL data set. See “Task 2: Bind the log extract plan” on page 67.

If you need to set up Replication Agent in a data-sharing environment, continue with Task 1b: Edit the SETUP00 member. Otherwise, skip to Task 1c: Edit the PDR member.

Task 1b: Edit the SETUP00 memberThe SETUP00 member of the hlq.PDR.PARMLIB data set contains the SSID and LOADLIBS parameters, which provide information about the DB2 subsystem on which you are installing Replication Extract.

The following example shows a SETUP00 member:

Example SSID (db2ssid) /* DB2 SUBSYSTEM ID */ LOADLIBS ( /* -- DB2 LOAD LIBRARIES -- */ DSN.V510.SDSNEXIT /* EXITS (EDIT & FIELD PROCS */ DSN.V510.SDSNLOAD /* DB2 SOFTWARE LIBRARY */ )

❖ To edit the SETUP00 member

1 Supply a value for the SSID parameter by replacing the db2ssid variable in the example shown with the value you recorded in section 4a on the Replication Agent Installation Worksheet.

If you are running DB2 in data-sharing mode, for each DB2 subsystem that runs a Replication Agent started task, include a line containing a SSID entry for each data-sharing member and data-sharing group attach name.

2 Supply values for the LOADLIBS parameter as follows:

a Replace the DB2 SDSNEXIT library name with the name you recorded in section 4c on the Replication Agent Installation Worksheet.



b Replace the DB2 SDSNLOAD library name with the name you recorded in section 4d on the Replication Agent Installation Worksheet.

3 Save the SETUP00 member.

The SETUP00 member and DB2 data sharing

If you are replicating from multiple members using DB2’s data-sharing environment, the SETUP00 member can include multiple SSID and LOADLIBS parameters that identify DB2 subsystems from which you are replicating transactions. The only requirement for the multiple entries in the SETUP00 member is that one of the SSID parameter values in the SETUP00 member must match the value of the LTM for MVS Log_identifier configuration parameter.

The following example shows a SETUP00 member that contains multiple SSID and LOADLIBS parameters:

Example

SSID (MVSA) /* DB2 SUBSYSTEM ID */LOADLIBS ( /* -- DB2 LOAD LIBRARIES -- */

DSN.V510.SDSNEXIT /* EXITS (EDIT & FIELD PROCS*/ DSN.V510.SDSNLOAD /* DB2 SOFTWARE LIBRARY */ )

SSID (MVSB) /* DB2 SUBSYSTEM ID */LOADLIBS ( /* -- DB2 LOAD LIBRARIES -- */

DSN.V510.SDSNEXIT /* EXITS (EDIT & FIELD PROCS*/ DSN.V510.SDSNLOAD /* DB2 SOFTWARE LIBRARY */ SSID (MVSC) /* DB2 SUBSYSTEM ID */ LOADLIBS ( /* -- DB2 LOAD LIBRARIES -- */ DSN.V510.SDSNEXIT /* EXITS (EDIT & FIELD PROCS*/ DSN.V510.SDSNLOAD /* DB2 SOFTWARE LIBRARY */

If you intend to use data sharing with the single-member only (SMO) option, continue with Task 1c: Edit the PDR member. Otherwise, skip to Task 2: Bind the log extract plan.



Task 1c: Edit the PDR memberThe PDR member of the hlq.PDR.PARMLIB data set enables you to specify values for several parameters required for the installation and execution of Replication Extract.

The following example shows the contents of a sample PDR member.

Example/*------------------------------------------------------------------*//* ---- P L A T I N U M T E C H N O L O G Y I N C. ---- *//* *//* PLATINUM DATA REPLICATOR DEFAULT PARMLIB OPTIONS *//*------------------------------------------------------------------*/REPL_ERROR (TERM) /* REPLICATION ERROR CONDITIONS: */ /* (TERM) OR (MSG) */ /* */ /* */POLL_INTVL (00.00.20.00) /* AMOUNT OF TIME TO SLEEP BEFORE */ /* REPOLLING THE HIGH WRITTEN RBA */ /* AFTER REACHING END OF ACTIVE LOG */ /* (HH.MM.SS.TT) */ /* */CI_COUNT (000) /* MINIMUM NUMBER OF CIS TO ALLOW */ /* DB2 TO WRITE BEFORE ISSUING EXCP */ /* AFTER REACHING END OF ACTIVE LOG */ /* */ARCHIVE (B) /* ARCHIVE LOG ACCESS METHOD */ /* (E) EXCP OR (B) BSAM */ /* */BUFFERS (25) /* NUMBER OF BUFFERS TO USE WHEN */ /* READING DB2 LOG (01 - 50) */ /* */LOGCOPY2 (N) /* USE COPY2 BEFORE COPY1 OF DB2 */ /* ACTIVE/ARCHIVE LOGS (Y) OR (N) */ /* */TRACE (Y) /* TRACE FOR DIAGNOSTIC MESSAGES */ /* (Y) OR (N) */ /* */ /* */GENID (0) /* GENERATION ID */ /* */ /* */SET_TRUNC (47000) /* FREQUENCY WITH WHICH TO FORCE */ /* THE REP SERVER TO SAVE A NEW */



/* TRUNCATION POINT 47000 */ /* */ /* SINGLE MEMBER DATA SHARING OPTION */ /* READER_TYPE (SMO) */ /* READER_NAME (SSID) */ /* */

The PDR member and DB2 data sharing

Only one PDR member is required for data sharing. This member name must be PDR or PDRssid, where ssid represents the DB2 group attach name (recommended) or the identifier of one of the subsystem names in the data-sharing group.

If all of the updates you plan to replicate occur within a single member of a data-sharing group, you can improve Replication Agent performance by setting the value of the Replication Extract READER_TYPE parameter to single-member only (SMO). Adding this parameter and value instructs Replication Agent to process only a single log and can improve Replication Agent performance.

Use the following procedure for configuring Replication Agent to replicate from a single member of a data-sharing group:

❖ To replicate from a single member in a data-sharing environment

• In the PDR member of the hlq.PDR.PARMLIB data set, uncomment the READER_TYPE and READER_NAME parameters as shown in the following example:

READER_TYPE (SMO) /* */READER_NAME (MVSA) /* */

The value of the READER_TYPE parameter is always SMO.

Supply a value for the READER_NAME parameter by replacing the member_name variable with the name of the data-sharing group member that contains the updates you plan to replicate.

Note The READER_NAME parameter value can differ from the subsystem ID of the data-sharing group member from which you are replicating. To verify whether the member name is the same as the subsystem ID, use the DB2 -DISPLAY GROUP command to display the member name and subsystem ID.



Task 2: Bind the log extract planThe log extract plan supplies DB2 with the SQL statements that Replication Extract uses to access the DB2 catalog and the Replication Agent system tables on DB2. This section explains how to bind the log extract plan.

The PDRBIND member of the hlq.JCL data set contains the JCL that you edit and submit to bind the log extract plan.

The following example shows the sample JCL contained in the PDRBIND member.

Example//PTIBIND EXEC PGM=IKJEFT01//STEPLIB DD DISP=SHR,DSN=db2lib//DBRMLIB DD DISP=SHR,DSN=hlq.DBRMLIB//SYSTSPRT DD SYSOUT=*//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSOUT DD SYSOUT=*//REPORT DD SYSOUT=*//SYSTSIN DD * DSN SYSTEM(db2ssid) BIND PLAN (REPAGENT) - MEMBER(DRA@LTMR - DRA@LTMS - DRA@LTMU - LAA@COLC - LAA@COPY - LAA@FLDC - LAA@TBC2 - LAA@TSPT - LAA@TS01) - VALIDATE (RUN) - ISOLATION(CS) - ACQUIRE (USE) - FLAG (I) - RELEASE (COMMIT) - EXPLAIN (NO) - ACTION (REPLACE) - RETAIN ;/*

Task 2: Bind the log extract plan


Table 6-1 describes the variables in the PDRBIND JCL.

Table 6-1: PDRBIND variable values

❖ To bind the log extract plan:

1 Verify that the PDRBIND JCL contains the values appropriate for your site, according to the information in Table 6-1.

2 Verify that the DBRMLIB DD statement contains the high-level qualifier that you recorded in section 3b of the Replication Agent Installation Worksheet.

Note This DBRMLIB is distributed on the Replication Agent software tape. It contains the SQL statements that Replication Extract uses to access DB2 catalog information about the primary tables being replicated.

The following shows an example of the edited DBRMLIB DD statement:

Variable Value

db2lib This is the fully qualified name of the DB2 software load library.

hlq This is the high-level qualifier that you recorded in section 3a of the Replication Agent Installation Worksheet.

db2ssid This identifies the DB2 subsystem from which you will replicate transaction information and where the log extract plan is to be bound.

If you are running DB2 in data-sharing mode, Sybase recommends that you specify the subsystem ID for member 0 of the data-sharing group.

Replace this variable with either of the following:

• If using DB2 in nondata-sharing mode, provide the DB2 subsystem ID that you recorded in section 4a on the Replication Agent Installation Worksheet.

• If using DB2 in data-sharing mode, provide the subsystem for member 0 of the data-sharing group from which you are replicating transaction information.

ACTION You can either specify REPLACE or ADD as the value of the ACTION parameter.

Note Be aware that if you specify REPLACE, you can overlay an existing plan by running the PDRBIND job.



//DBRMLIB DD DISP=SHR,DSN=LTM.TEST.R1250.DBRMLIB

3 Submit the PDRBIND job for execution.

The bind condition codes you receive after executing the bind job depend on the version of DB2 you are running.

• For DB2 version 5.1: The bind operation ends with condition code 4.



Note You must grant the following permission if the LTMADMIN user ID did not bind the log extract plan.

4 Grant the LTMADMIN user ID the permission to bind and add the log extract plan, using the following syntax:

GRANT BIND,EXECUTE ON PLAN REPAGENT TO LTMADMIN_user_ID

where:

• REPAGENT is the log extract plan name you recorded in section 4b

• LTMADMIN_user_ID is the LTMADMIN user ID name you recorded in section 1a on the Replication Agent Installation Worksheet

What’s nextProceed to Chapter 7, “Configuring TCP/IP for Replication Agent”.

What’s next



C H A P T E R 7 Configuring TCP/IP for Replication Agent

This chapter describes how to set up communications between Replication Agent and Replication Server using IBM TCP/IP.

This chapter includes the following sections:

Note The installation tasks in Chapter 5, “Installing Replication Agent” effect basic connectivity configuration. To skip these additional configuration tasks, proceed to Chapter 8, “Completing and Verifying Your Replication Agent Installation”.

Before you begin • Verify that you successfully completed the tasks described in Chapter 4, “Gathering Installation Information”

• Make sure you complete the Replication Agent Installation Worksheet. Keep the completed worksheet in front of you as you proceed through this chapter.

• Be sure you chose and recorded a value for the Communications_Protocol configuration parameter. You should have selected this value when completing the Replication Agent Installation Worksheet.

See also • “Replication Agent Installation Worksheet” on page 41

• Appendix A, “LTM for MVS Configuration Parameters”

Topic PageTask 1: Verify TCP/IP connectivity 72

Understanding the SYGWHOST macro 73

Task 2: Assemble and link the SYGWXCPH module 75

Task 1: Verify TCP/IP connectivity


Task 1: Verify TCP/IP connectivityUse TSOPING to verify TCP/IP connectivity to the machine containing one of the following servers:

• Primary Replication Server

• Adaptive Server that contains the RSSD for the primary Replication Server

Note Use TSOPING to verify TCP/IP connectivity to the Adaptive Server RSSD only if you plan to set the value of the LTM for MVS Use_repdef configuration parameter to Y.

❖ To verify TCP/IP connectivity

1 Verify connectivity to the primary Replication Server in your replication system using the following syntax:

TSO ping [IPADDR]

where IPADDR is the IP address of the machine where the primary Replication Server resides. See section 5b of the Replication Agent Installation Worksheet for the primary Replication Server IPADDR value.

2 If you plan to set the value of the Use_repdef parameter to Y, verify connectivity to the Adaptive Server that contains the RSSD for the primary Replication Server using the following syntax:

TSO ping [IPADDR]

where IPADDR is IP address of the machine where the Adaptive Server that contains the RSSD for the primary Replication Server resides. See section 6b of the Replication Agent Installation Worksheet for the RSSD server IPADDR value.

TSOPING writes output to the OS/390 console to indicate success or failure.

3 If the connection between TCP/IP and the server succeeds, the console displays a message similar to the following:

TSO ping [host_name]Ping V#R1: Pinging host[host_name](555.111.22.33) Use ATTN to interrupt. ping: Ping #1 response took 0.447 seconds. Successes so far 1.

CHAPTER 7 Configuring TCP/IP for Replication Agent


If the console messages indicate a successful connection, proceed to “Task 2: Assemble and link the SYGWXCPH module” on page 75.

If messages indicate failure, proceed to step 4.

4 If the OS/390 console displays a message that indicates the connection between TCP/IP and the server failed, do the following before proceeding to “Task 2: Assemble and link the SYGWXCPH module” on page 75:

a Contact your TCP/IP systems administrator to verify that TCP/IP is functioning properly.

b Contact your LAN administrator to verify that the Replication Server (and the Adaptive Server, if applicable) is running.

See also • Appendix A, “LTM for MVS Configuration Parameters” for detailed information about the Use_repdef configuration parameter

Understanding the SYGWHOST macroTo support a TCP/IP connection between Replication Agent and Replication Server, you must provide your OS/390 system with information about the Sybase servers and TCP/IP host addresses in your replication system.

You provide this information by editing the SYGWHOST TYPE=ENTRY macro, located in the XCPHPING member of the hlq.JCL library.

Note The SYGWHOST macro replaces the mainframe interfaces file required in earlier versions of Replication Agent.

The SYGWHOST TYPE=ENTRY macro performs the following functions:

• Serves as a directory containing network addresses and other information that controls how Replication Agent connects to other servers.

• Configures the Open Client component of LTM for MVS to use either IBM TCP/IP or Interlink TCPaccess protocol for a TCP/IP connection between Replication Agent and Replication Server.

The Replication Agent TCP/IP installation requires a SYGWHOST TYPE=ENTRY macro entry for each primary Replication Server in your replication system. You can define any number of Replication Server entries in the SYGWHOST macro.

Understanding the SYGWHOST macro


If you plan to set the value of the LTM for MVS Use_repdef configuration parameter to Y, uncomment and provide valid values for the Adaptive Server SYGWHOST TYPE=ENTRY macro entry for each Adaptive Server that contains an RSSD for a primary Replication Server. The number of Adaptive Server entries in the SYGWHOST macro should be equal to the number of Replication Server entries in the macro.

SyntaxSYGWHOST TYPE=ENTRY, * SERVERNAME=SERVER, * IPADDR=999.999.999.999, * LSTNPORT=9999, * IBMTCPADDRSPACE=XXXXXXXX,| INTRSUBSYSNAME=XXXX, * LISTENER=LAN *

ContentsThe SYGWHOST TYPE=ENTRY macro contains the six parameters shown in the following table. See Section 5: Recording TCP/IP configuration information and Section 6: Recording TCP/IP information for Adaptive Server in Chapter 4, “Gathering Installation Information” for information about providing the values for your site.

Parameter Definition

SERVERNAME The name of a Sybase server (30 characters maximum).

IPADDR The host IP address of the machine on which the LAN Sybase server runs.

LSTNPORT The listen port of the machine on which the server specified by SERVERNAME runs.

Contact your Replication Server or Adaptive Server Administrator for this value.

IBMTCPADDRSPACE

Note Enter a value for this parameter only if you are using IBM TCP/IP.

The name of the address space where IBM TCP/IP runs (8 characters maximum, all uppercase).

Contact your Systems Programmer for this value.

CHAPTER 7 Configuring TCP/IP for Replication Agent


Task 2: Assemble and link the SYGWXCPH moduleSubmit the XCPHping job to assemble and link-edit the SYGWXCPH module.

A return code of 4 indicates success.

What’s nextYou are ready to verify your Replication Agent software installation. Go to Chapter 8, “Completing and Verifying Your Replication Agent Installation”.

INTRSUBSYSNAME

Note Enter a value for this parameter only if you are using Interlink TCPaccess.

The name of the subsystem on which Interlink TCPaccess runs (4 characters maximum, all uppercase).

Contact your Systems Programmer for this value.

LISTENER This value is always LAN.

Parameter Definition

What’s next



C H A P T E R 8 Completing and Verifying Your Replication Agent Installation

To complete and verify your Replication Agent installation, complete the following tasks:

Note The installation tasks in Chapter 5, “Installing Replication Agent” accomplish basic configuration tasks. This chapter describes additional tasks.

Before you begin • Make sure you complete the Replication Agent Installation Worksheet. Keep the completed worksheet in front of you as you proceed through this chapter.

• Verify that TCP/IP connectivity has been established with Replication Server.

• Make sure you successfully complete the tasks described in Chapter 5, “Installing Replication Agent”.

See also • “Replication Agent Installation Worksheet” on page 41

Task 1: Verify the LTM for MVS configuration fileThe LTM for MVS configuration file can be a sequential file or a member of the partitioned data set (PDS) that contains system information used by Replication Agent. The LTM for MVS configuration file contains information about:

Topic PageTask 1: Verify the LTM for MVS configuration file 77

Task 2: Configure Replication Server 80

Task 3: Test your server connections with PINGRS 85

Task 1: Verify the LTM for MVS configuration file


• Replication Server connectivity

• Replication Agent behavior

• Data conversion actions and defaults

• Testing and debugging

• Replication Extract

Before you can verify your LTM for MVS installation, you must provide values for several required configuration parameters by editing the LTMCNFG member, which is located in the hlq.JCL library.

❖ To edit the LTM for MVS configuration file

1 In the Replication Agent Installation Worksheet, turn to section 7, “LTM for MVS Configuration Information.”

2 Locate the values you recorded for the following required configuration parameters:

• Codepage

• RS

• RS_ccsid

• RS_user

• RS_pw

• RS_source_ds

• RS_source_db

• Transaction_name

• Creator

• Log_identifier

If you are using TCP/IP connectivity and set the value of the Use_repdef configuration parameter to Y, you must also locate the values you recorded for the following required configuration parameters:

• RSSD_server

• RSSD_database

• RSSD_user

CHAPTER 8 Completing and Verifying Your Replication Agent Installation


• RSSD_pw

Note If you are upgrading your Replication Agent software from an earlier version, review the configuration parameter values from the configuration file you used previously. Use values for the parameters in the Replication Agent for DB2 UDB for OS/390 version 12.5 configuration file that match the values you used in the most recent version of Replication Agent.

3 Use your site’s text editor to verify or insert the values for the required configuration parameters listed in the preceding step in the sample configuration file (located in the LTMCNFG member, in the hlq.JCL library).

Note Be sure your text editor allows you to enter values in mixed case. The configuration file is case sensitive.

Use the following syntax:

parameter_name=parameter_value

For example, to set the value of the RS_user parameter to LTMADMIN, edit the RS_user parameter value as follows:

RS_user=LTMADMIN

4 Save the LTM for MVS configuration file.


Case sensitivity The LTM for MVS configuration file is case sensitive.

Verifying configuration parameter values

You can verify whether LTM for MVS accepted the correct values from the configuration file by examining the LTM for MVS log file, LTMLOG, after restarting and stopping Replication Agent.

LTMLOG records configuration parameters and values, and configuration errors, if applicable.

Task 2: Configure Replication Server




• Appendix A, “LTM for MVS Configuration Parameters” for descriptions of the configuration parameters required for installation

Task 2: Configure Replication ServerHave your Replication Server Administrator perform the tasks in this section using Replication Command Language (RCL) commands.

This section includes the following tasks:

• Creating the RS user on Replication Server

• Granting connect source permission

• Creating a connection to Replication Server

Warning! This section assumes that you have one Replication Server in your replication system. If you have more than one Replication Server in your replication system, you must create routes between them. See the Replication Server Commands Reference for information on the create route command.

See also • Replication Server Commands Reference and Replication Server Administration Guide for information on RCL commands.

• Replication Server Installation Guide for detailed instructions on how to configure Replication Servers.

Configuration errors Before you initialize any changes to the LTM for MVS configuration file, check this list for potential errors:

• Beginning a line with a blank causes syntax errors.

• Do not delete lines containing unused parameters. Your site might need those parameters in the future.



These instructions are standard Replication Server setup procedures and are appropriate for any type of Replication Agent.


RS_source_ds The value of the RS_source_ds LTM for MVS configuration parameter identifies a unique name for the OS/390 system that contains the primary data source.

Make sure that the OS/390 system name you supply in the create connection command matches the value you specified for the RS_source_ds parameter in the LTM for MVS configuration file.

RS_source_db The value of the RS_source_db LTM for MVS configuration parameter identifies a unique instance of the Log Transfer Manager (LTM) you are running. It is the name of the database that contains the primary data source to be replicated.

Make sure that the database name you supply in the create connection command matches the value you specified for the RS_source_db parameter in the LTM for MVS configuration file.

maintenance_user_ID The value of the maintenance_user_ID identifies the Replication Server user specified in the create connection command. This user ID must be granted all necessary permissions to update replicate tables. This user ID should not match the value of the RS_user configuration parameter.

maintenance_ password The value of the maintenance_password identifies the password for the Replication Server maintenance_user_ID. This password is restricted to 30 characters maximum.



Creating the RS user on Replication ServerWhen you replicate from your data source to Replication Server, the connection from Replication Agent to Replication Server requires a valid Replication Server user ID.

You must issue the create user command to create the Replication Server user. Use the values of the RS_user and RS_pw LTM for MVS configuration parameters as the user ID and password.

Note Have your Replication Server System Administrator perform the following task.

❖ To create the Replication Server user

1 Obtain the value of the RS_user configuration parameter, which you recorded during installation in section 7c, “RS_user,” on the Replication Agent Installation Worksheet.

2 Obtain the value of the RS_pw configuration parameter, which you recorded during installation in section 7d, “RS_pw,” on the Replication Agent Installation Worksheet.

3 Log in to the primary Replication Server as the System Administrator (sa) and enter the following command:

create user RS_userset password RS_pw

where RS_user and RS_pw are the Replication Server user ID and password you located in steps 1 and 2.

Granting connect source permissionAfter you create the Replication Server user, you must grant connect source permission to this Replication Server user ID.

Note Have your Replication Server Administrator perform the following task.

❖ To grant connect source permission

1 Locate the Replication Server user ID you just created, which should match the value of the RS_user configuration parameter in the LTM for MVS configuration file.



2 Log in to the primary Replication Server as the system administrator (sa) and execute the Replication Server grant connect source command using the following example syntax:

grant connect source to RS_user

where RS_user is the Replication Server user ID you recorded in section 7c on the Replication Agent Installation Worksheet.

See also • Replication Server Commands Reference for information on Replication Server commands

Creating a connection to Replication ServerA connection is a message stream from a Replication Agent to a Replication Server. Connections allow the primary data sources identified on this connection to participate in replication.

You create a connection from the primary data source to the primary Replication Server using the create connection command with the dsi_suspended option. This option starts the connection with the DSI thread suspended. This option is especially useful when you create a connection to a non-Sybase data server that does not support Replication Server connections.

Be sure that the Replication Server maintenance_user_ID that you specify in the create connection command is not identical to the LTMADMIN user name (which you recorded in section 1a, “LTMADMIN User ID,” on the Replication Agent Installation Worksheet).

Note Have your Replication Server Administrator perform the following task.

❖ To create a connection to the primary Replication Server

1 Log in to the primary Replication Server as the System Administrator (sa) using isql:

isql -Usa -Psa_password -Sservername

2 Create the connection using the following syntax:

1> create connection to RS_source_ds.RS_source_db2> set error class error_class3> set function string class function_class4> set username maintenance_user_ID5> set password maintenance_password



6> with log transfer on, dsi_suspended7> go

Example

This example creates a connection for the DMW5 DB2 subsystem in the MVSA data server. Replication Server uses the default rs_sqlserver_error_class error class to handle errors for the database.

In addition, Replication Server uses the function strings in the default rs_sqlserver_function_class function string class for data manipulation operations.

Note In this example, the Replication Server ID DB2MAINT should not be identical to the value of the RS_user parameter, which you recorded in section 7c, “RS_user,” on the Replication Agent Installation Worksheet.

create connection to MVSA.DMW5 set error class rs_sqlserver_error_class set function string class rs_sqlserver_function_class set username DB2MAINT set password DB2MPSWD with log transfer on, dsi_suspended go

See also • Appendix A, “LTM for MVS Configuration Parameters” for information on filtering maintenance user ID transactions using the LTM_process_maint_uid_trans LTM for MVS configuration parameter

• Replication Server Commands Reference for information on the create connection command

To check the connectivity and the configuration settings for the LTMCNFG member, continue with the optional Task 3: Test your server connections with PINGRS. Otherwise, skip to Task 4: Start Replication Agent.



Task 3: Test your server connections with PINGRSReplication Agent provides the PINGRS utility to test the complete connection path from OS/390 to Replication Server. To verify connectivity, PINGRS attempts to log in to Replication Server and execute a CONNECT SOURCE LTI command.

The PINGRS utility is provided in the PINGRS member in the hlq.JCL library.

❖ To test your server connections with the PINGRS utility

1 Verify that the sample JCL in the PINGRS member is correct for your site and contains a pointer to your configuration file name.

2 Submit the PINGRS job.

This job step results in a return code of 00 regardless of whether PINGRS succeeds or fails.

3 View the SYSPRINT output to determine whether PINGRS succeeded.

If the connection between Replication Agent and Replication Server succeeds, PINGRS writes output to SYSPRINT indicating a return code of -1. The last message in SYSPRINT reads as follows:

CONNECT SOURCE LTI "database_name"."server_name" succeeded!

If the connection between Replication Agent and Replication Server fails, the OS/390 console displays either a return code of -2 or no code. See “Correcting PINGRS errors” on page 85.

Note If you set the value of the LTM for MVS Use_repdef configuration parameter to Y, the console displays all replication definitions and columns for which you have subscriptions in the SYSPRINT file.

See also • Chapter 7, “Configuring TCP/IP for Replication Agent”

• Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390

Correcting PINGRS errorsThe following types of errors can occur if the connection between TCP/IP and Replication Server is invalid.

Task 4: Start Replication Agent


For TCP/IP:

• PINGRS indicates a failure to connect to Replication Server. In this case, locate the sources of connectivity problems and correct any errors.

• PINGRS indicates a successful connection to Replication Server but the CONNECT SOURCE LTI command fails. Be sure that you granted connect source authority to the Replication Server maintenance user ID.

• Verify that Replication Server is running.

See also • “Granting connect source permission” on page 82 of this chapter

• Chapter 4, “Gathering Installation Information”

• Chapter 7, “Configuring TCP/IP for Replication Agent”

Task 4: Start Replication AgentYou can now start Replication Agent, either as a started task or as a batch job.

❖ Starting LTM for MVS as a started task

1 Start Replication Server according to the instructions in the Replication Server Installation Guide.

2 Issue the START (S) command on the OS/390 operator console:

S LTMxxxxx

where LTMxxxxx is the LTM start-up procedure name you defined at installation.

3 Check the LTMLOG log data set to verify that the system wrote the configuration file parameter values to the LTMLOG log data set. (You can find the log name by checking the LTMLOG DD name in the LTMxxxxx procedure.) This indicates that you successfully started LTM for MVS.

❖ Starting LTM for MVS as a batch job

1 Start Replication Server.

2 Submit the LTMxxxxx procedure.



3 Check the LTMLOG log data set to verify that the system wrote the configuration file parameter values to the LTMLOG log data set. (You can find the log name by checking the LTMLOG DD name in the LTMxxxxx procedure.) This indicates that you successfully started LTM for MVS.

What’s nextIf you are upgrading to a new version of Replication Agent, go to Appendix D, “Upgrading Your Replication Agent Software”.

If you are installing Replication Agent for the first time, go to the Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390.

What’s next



A P P E N D I X A LTM for MVS Configuration Parameters

This chapter contains information about the LTM for MVS configuration file and the parameters that control the behavior of the LTM for MVS component of Replication Agent.

This chapter includes the following tasks:

Understanding the LTM for MVS configuration fileWhen LTM for MVS starts, it reads the LTM for MVS configuration file, which contains parameters that control the behavior of the LTM for MVS component of Replication Agent.

The configuration file contains parameters and their associated values. Each line containing a configuration parameter is followed by the = (equals) character, followed by the value. LTM for MVS ignores blank lines and lines beginning with the # character.

Sample LTM for MVS configuration fileThe following example shows the contents of the sample configuration file, located in the LTMCNFG member in the hlq.JCL data set.

Example

#-----------------------------------------------------------# Configuration File for

Topic PageUnderstanding the LTM for MVS configuration file 89

Understanding the LTM for MVS configuration parameters 94

Understanding the LTM for MVS configuration file


# Replication Agent for DB2 Release 12.5## The general format for a configuration parameter is:# config_keyword=config_value## Comments are indicated by a "#" in column 1.## Comments related to specific configuration parameters# follow that parameter in the configuration file.## NOTE: Configuration parameter keywords and values# are *case sensitive* except where noted.# The values of the following configuration parameters are converted# to upper case regardless of the input value:# Log_identifier# Creator# Log_extractor##-----------------------------------------------------------## Replication Server Connectivity Parameters##-----------------------------------------------------------RS=LTMIDRS1RS_user=ltmdevrsRS_pw=ltmdevrs_pwRS_source_ds=MVSARS_source_db=DSNATransaction_name=netgwCommunications_Protocol=IBMTCPCodepage=CP500RS_ccsid=819#User_exit=Use_repdef=N# You must specify minimal_cols=Y and specify# values for the RSSD_server and# RSSD_database parameters to use the Use_repdef# parameter.#RSSD_server=ASE_server_name# Specify Adaptive Server name used in the SYGWHOST macro in# the XCPHPING member. If Use_repdef=Y, you must specify a# value for the RSSD_server parameter.#RSSD_database=rssd_name# Specify the name of the Adaptive Server database that contains the

APPENDIX A LTM for MVS Configuration Parameters


# RSSD for the primary Replication Server.# You must set Use_repdef=Y to use the RSSD_database# parameter.#RSSD_user=ASE_server_user# Specify the Adaptive Server user who has permissions to# perform selects against the Adaptive Server RSSD.#RSSD_pw=password# Specify the password for the Adaptive Server user.#Suppress_col_names=N# To use the Suppress_col_names parameter, you MUST set# the value of the Minimal_cols parameter to Y and the# value of the Use_repdef parameter to Y.#Support_DB2_comp_rec=N# Set Support_DB2_comp_rec=Y if you experience# problems with replication of DB2 compensation records.##-----------------------------------------------------------## LTM/MVS Configuration Parameters##-----------------------------------------------------------# General configurationLTM_admin_user=noneyet# The LTM_admin_user parameter is required but not used# in this release.LTM_admin_pw=noneyet# The LTM_admin_pw parameter is required but not used# in this release.retry=10Maximum_connect_retries=10batch_ltl_cmds=onAPI_QID_request_interval=1000Minimal_cols=YLTM_process_maint_uid_trans=NStop_on_error=N# LE_oper_com=N#-----------------------------------------------------------## New parameters##-----------------------------------------------------------Long_varchar=N

Understanding the LTM for MVS configuration file


Low_activity_latency=10LTL_table_col_case=asisDateTime_conv_err=Default#-----------------------------------------------------------## Conversion actions and defaults##-----------------------------------------------------------Minimum_year=0000DateTime_conv_err=DefaultDate_conv_default=1900-01-01Time_conv_default=00:00:00Date_in_char=NTime_in_char=NTimestamp_in_char=N#replace_null_in_char=Null#-----------------------------------------------------------## Testing/Debugging Aids##-----------------------------------------------------------#trace=1,11#trace=1,31#trace=1,23#LTL_test_only=N#API_com_test=N#-----------------------------------------------------------## Log Extract Configuration Parameters##-----------------------------------------------------------Log_extractor=DRL@INIMLog_identifier=Packet_size=16KCreator=LTMADMIN# Identifies the user ID of the creator of the LTMOBJECTS# and LTMMARKER tables.




Case sensitivity The keywords in the LTM for MVS configuration file are case sensitive.

You can verify whether LTM for MVS accepted the correct values from the configuration file by examining the LTMLOG1 file. After you restart Replication Agent, LTMLOG1 displays the configuration parameters and values, and configuration errors, if applicable.

One line per configuration parameter

Each configuration parameter entry must be on its own line; therefore, the LTM for MVS configuration file has no line continuation character.

Duplicate parameter entries

LTM for MVS processes duplicate entries for a single parameter in the configuration file inconsistently. In most cases, the second entry overrides the first entry. Sybase recommends that you avoid using multiple entries for single parameters in the configuration file.

Optional parameters For optional configuration parameters you do not want to use, comment out the line in the LTM for MVS configuration file by inserting the “#” (pound) symbol in the first column of the line.

Required parameters Do not delete or comment out any required configuration parameters.

LTM for MVS supplies default values for most configuration parameters. Change the values for these parameters for your site as needed.

Understanding the LTM for MVS configuration parameters



This section lists the LTM for MVS configuration parameters in alphabetical order with their valid values. Parameter descriptions include information about performance and tuning considerations where appropriate.

Note Be sure to read the information in this section before you change configuration parameter values so that you understand the consequences of the changes.

The default values for most of the parameters in the LTM for MVS configuration file enable the operation of most replication systems.

You can change parameter values to accommodate unusual environments or situations. For example, you can adjust parameter values if an error message indicates that your system has run out of configurable resource.

Configuration errors After modifying configuration parameters and before starting LTM for MVS, check this list for potential errors:

• Beginning a line with a blank causes syntax errors.

• Provide valid values for all optional configuration parameters that are not commented out of the configuration file. Leaving a parameter name in an active state without an appropriate value causes syntax errors.

• If a parameter is set to insert a null in a replicate column, make sure that column allows nulls.

• Do not delete lines containing unused parameters. Your site may need those parameters in the future.

Adaptive Server LTM configuration parameters

LTM for MVS configuration parameters differ from Adaptive Server LTM configuration parameters.



Table A-1 lists the configuration parameters described in this section according to their function.

Table A-1: LTM for MVS configuration parameters

Configuration parameter type Parameter name and location

Required parameters “Log_extractor” on page 107

“RS” on page 118

“RS_source_db” on page 121

“RS_source_ds” on page 122

“RS_user” on page 123

“RS_pw” on page 123

“LTM_admin_pw” on page 112

“LTM_admin_user” on page 112

“Communications_Protocol” on page 103

“Transaction_name” on page 136

Performance parameters “Low_activity_latency” on page 110

“RSSD_database” on page 124

“RSSD_pw” on page 125

“RSSD_server” on page 125

“RSSD_user” on page 126

“Minimal_cols” on page 114

“Suppress_col_names” on page 129

“Use_repdef” on page 136

“Support_DB2_comp_rec” on page 128

“API_QID_request_interval” on page 98

“Packet_size” on page 116

“trace=1,31” on page 135

“RS_ccsid” on page 119

“batch_ltl_cmds” on page 99

Numeric and data conversion parameters

“replace_null_in_char” on page 117

“Codepage” on page 100



API_com_testAssists with debugging log extract or user exit applications you create. The API_com_test parameter is optional.

Date and time conversion parameters

“Date_in_char” on page 105

“Time_in_char” on page 131

“Timestamp_in_char” on page 132

“DateTime_conv_err” on page 106

“Date_conv_default” on page 104

“Long_varchar” on page 109

“Time_conv_default” on page 130

“Minimum_year” on page 115

Processing parameters “Stop_on_error” on page 126

“User_exit” on page 138

“LTL_table_col_case” on page 110

Log extract parameters “Creator” on page 103

“Log_identifier” on page 108

Communication parameters “LTM_process_maint_uid_trans” on page 113

“retry” on page 118

“Transaction_name” on page 136

“Maximum_connect_retries” on page 114

Testing and debugging parameters

“API_com_test” on page 96

“LTL_test_only” on page 111

“LE_oper_com” on page 107




Configuration parameter type Parameter name and location



Example syntaxAPI_com_test=N

Default value

• N

Valid values

• N

• Allows LTM for MVS to connect to Replication Server

• Does not create APICOM nor UELECMD files

• Y

• Allows LTM for MVS to connect to Replication Server

• Sends Replication API call structures to APICOM file

• If a user exit is loaded, sends Replication API call structures to UELECMD file after the user exit is invoked

• O

• Sends Replication API call structures to APICOM file

• If a user exit is loaded, sends Replication API call structures to UELECMD file

• Reads LTMTRUNC file for the LTM Locator value

• Sets the maintenance user ID FREDDY## (where the # sign represents a space)

• Prevents LTM for MVS from creating LTL

• Prevents LTM for MVS from connecting to Replication Server

Comments

Use the output in the APICOM file to monitor Replication Extract’s calls to the Replication API in the following cases:

• When a user exit is not installed

• When a user exit is installed, but before it is invoked



Use the UELECMD file to examine the manner in which the user exit altered the LE Command structure.

Set the value of API_com_test to Y or O, depending on whether you want to process transaction operations while debugging. Use the output in the APICOM file to monitor Replication Extract’s calls to the Replication API without a user exit installed or before it invokes, if a user exit is installed. Use the UELECMD file to examine Replication Extract’s calls to the Replication API after the user exit is invoked.

When you set the value of the API_com_test to N, Replication Agent does not write output to the APICOM or UELECMD files, but it allows Replication Agent to connect to Replication Server.

When the API_com_test parameter is set to Y, memory allocations and file input and output result. Sybase recommends that you set the API_com_test parameter to N for normal operation. The correct space allocation depends on the amount of data involved.

If you set the value of API_com_test to Y or O, uncomment the APICOM DD statement in the JCL that starts the LTM for MVS started task on MVS:

//APICOM DD DSN=hlq.APICOM,DISP=(,CATLG),// UNIT=SYSDA,DCB=(LRECL=4096,RECFM=VB),// SPACE=(CYL,(1,1))

Uncomment the UELECMD DD statement only if you installed a user exit in the JCL that starts the LTM for MVS task on MVS:

//UELECMD DD DSN=hlq.UELECMD,DISP=(,CATLG),// UNIT=SYSDA,DCB=(LRECL=4092,RECFM=VB),// SPACE=(CYL,(1,1))

See “Creating User Exits” in the Replication Agent for DB2 UBD User’s and Troubleshooting Guide for OS/390 for information about using a user exit to replace binary zeros.

API_QID_request_intervalControls the number of messages Replication API sends to the LTI before requesting a new LTM Locator from Replication Server.

The API_QID_request_interval parameter is optional.



Example syntaxAPI_QID_request_interval=1000

Default value

• 1000

Valid values

• Any integer from 1 to 10000

Note In Replication Agent for DB2 UDB for OS/390 version 12.5, the default value of the API_QID_request_interval parameter changes from 200 to 1000. The maximum value is currently 10000; formerly it was 1000.

Comments

The API_QID_request_interval configuration parameter controls the number of messages LTM for MVS sends to Replication Server before issuing a get truncation command to request a new LTM Locator value from Replication Server.

Issuing a get truncation command forces Replication Server to update rs_locater with the current LTM Locator for the primary database. This prevents Replication Extract from unnecessarily reprocessing transactions upon restart.

See the Replication Server Commands Reference for information about the rs_locater Replication Server system table.

batch_ltl_cmdsControls whether LTM for MVS collects transactions (including inserts, updates, and deletes) in a 16K buffer and either ships them to Replication Server when the buffer is full, or sends the transactions one at a time.

The batch_ltl_cmds parameter is required.

Example syntaxbatch_ltl_cmds=on



Default value

• on

Valid values

• on

Batches transactions in a 16K buffer and ships to Replication Server when buffer is full.

• off

Places a single transaction in each 16K buffer it sends to Replication Server.

Performance and tuning considerations

Set the value of batch_ltl_cmds to on to reduce network traffic and increase throughput.

Char_conv_err_logThis parameter is obsolete. It is used only in Replication Agent for DB2 UDB for OS/390 versions earlier than 11.5.

CodepageIdentifies the name of the code page that DB2 is currently using. To identify the code page DB2 is using, check the value of the CCSID initialization parameter in DB2.



The Codepage parameter is optional.

Warning! If you change the DB2 CCSID setting in the DSNTIPF panel, you must also do the following to ensure LTM resumes processing at the end of the DB2 log using the proper CCSID:

1 Change the values for the Replication Agent Codepage and RS_ccsid parameters in the LTMCNFG member of the hlq.JCL data set to reflect the new CCSID value.

2 Reset the truncation point and rs_locater values to zero. See “Basic Replication Agent Troubleshooting Tips” in Chapter 7, “Basic Troubleshooting Procedures” of the Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390 for instructions.

Options

The force option for the Codepage configuration parameter forces Replication Agent to use the code page value provided in the Codepage configuration parameter instead of the CCSID value provided from DB2.

Note Replication Agent now supports all valid DB2 CCSIDs, including ASCII and double-byte CCSIDs, in addition to single-byte character sets.

Example syntaxCodepage=CP500,force

Default value

• CP500

Valid values

To determine the appropriate value for the Codepage parameter, see the table provided in the CODEPAGE member of the hlq.DOCS library. Here is an excerpt of the CODEPAGE member:

|-------------------------------------------------------|| This table lists the values to use for the Rep Agent || Codepage= and RS-ccsid= parameters. The ’DB2 CCSID’ |



| column lists the settings used on the DB2 installation|| panel ’DSNTIPF’. This is usually the same as the || CCSID for the user database in which the primary table|| was created. The Rep Server/ASE column lists || character set values. The RS_ccsid value should || reflect the setting of Replication Server’s RS_charset|| configuration parameter. ||-------------------------------------------------------|| | Rep Server/ASE | Rep Agent | Rep Agent || DB2 CCSID | ---------------| Codepage= | RS_ccsid= || | character set | | ||-----------|----------------|------------|-------------|| 37 | cp437 | 37 | 437 ||-----------|----------------|------------|-------------|| 37 | iso_1 | 37 | 819 ||... ... ... ... ... ... ... ... ... ... ... ... ... ...||-----------|----------------|------------|-------------|| 5026 | cp932 | 5026 | 932 ||-----------|----------------|------------|-------------|| 5035 | cp932 | 5035 | 932 ||-----------|----------------|------------|-------------|| 5348 | cp437 | 5348 | 437 ||-----------|----------------|------------|-------------|| 5348 | iso_1 | 5348 | 819 ||-----------|----------------|------------|-------------|| 5348 | cp1252 | 5348 | 1252 ||-----------|----------------|------------|-------------|

This table matches DB2 CCSIDs with their appropriate Replication Agent Codepage and RS_ccsid configuration parameter values.

Comments

You can verify the CCSID setting for a database by executing the following query:

SELECT * FROM SYSIBM.SYSDATABASE WHERE NAME = ’database_name’

where database_name is the name of the database for which you are verifying the CCSID setting. You can also verify the CCSID settings for translation tables used by the LTM in character data conversions by executing the following query:

SELECT * FROM SYSIBM.SYSSTRINGS WHERE INCCSID = inccsid AND

OUTCCSID = outccsid



Character translation errors can occur when the value of the Codepage parameter value does not match the code page that DB2 is currently using.

See the IBM Character Data Representation Architecture Reference and Registry, document #SC09-2190-00, for the Character Data Representation Architecture conversion tables.

Communications_ProtocolTells Replication Agent which protocol option your system is using:

• IBM TCP/IP

The Communications_Protocol parameter is required.

Example syntaxCommunications_Protocol=IBMTCP

Valid values

• IBMTCP

CreatorIdentifies the creator name for the LTMOBJECTS, LTMMARKER, and LTMLASTCOMMIT tables, which are created on DB2 by the LTMADMIN user ID during installation.

Note Replication Agent does not use the LTMMARKER table, which will be removed entirely from subsequent versions.

The Creator parameter is required.

Example syntaxCreator=LTMADMIN



Default value

• LTMADMIN

Valid values

• Maximum of 8 characters

Note Obtain your site’s value for the Creator parameter from the Replication Agent Installation Worksheet in the Replication Agent for DB2 UDB Installation Guide for OS/390. This value should have been recorded on the worksheet during installation.

Date_conv_defaultCan perform three functions:

• If the value of the DateTime_conv_err parameter is set to Default, this parameter supplies the value that LTM for MVS inserts in columns that encounter date conversion errors.

• Supplies date values during conversion of LTM for MVS date data to Adaptive Server datetime format.

• If your data contains year values less than the value of the Minimum_year parameter, then LTM for MVS inserts the value of the Date_conv_default parameter in the data you are replicating.

The Date_conv_default parameter is optional.

Example syntaxDate_conv_default=2000-12-31

Default value

• 1900-01-01

Valid values

• Any valid ISO date format value (YYYY-MM-DD, where YYYY=year, MM=month, and DD=day of the month)



See Chapter 6, “Working with datatype conversions” in the Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390 for examples of valid date, time, and timestamp formats.

Date_in_charControls whether LTM for MVS sends date columns as char(10) fields or converts them to Adaptive Server datetime format.

The Date_in_char parameter is optional.

Example syntaxDate_in_char=N

Default value

• N

Valid values

• N

LTM for MVS converts LTM for MVS date datatype columns to Adaptive Server datetime.

• Y

When you set Date_in_char to Y, LTM for MVS converts dates that are out of range for the replicate table to a char(10) column.

LTM for MVS sends LTM for MVS date datatype columns as char(10) fields (ISO format: CCYY-MM-DD) instead of converting them to Adaptive Server datetime format.




DateTime_conv_errControls the action LTM for MVS takes when it encounters conversion errors during conversion of LTM for MVS date, time, or timestamp data to Adaptive Server datetime.

The DateTime_conv_err parameter is optional.

Example syntaxDateTime_conv_err=Default

Default value

• Default

Valid values

• Default

If the error is a date error, LTM for MVS places the value stored in the Date_conv_default parameter in the column encountering the error.

• Null

LTM for MVS places a null in the column encountering the error.

• Datetime

If the error is a date error, LTM for MVS places the value stored in the Date_conv_default and Time_conv_default parameters in the column encountering the error.

Note If you set the value of DateTime_conv_err to null, be sure the affected replicate columns allow nulls.




LE_oper_comControls whether Replication Extract or LTM for MVS handles all messages from the MVS operator console.

Controls the handling of messages from the MVS operator console.

The LE_oper_com parameter is optional.

Example syntaxLE_oper_com=N

Default value

• N

Valid values

Note If you do not comment out the LE_oper_com parameter, you must set its value to N.

• N

LTM for MVS handles messages from the MVS operator console.

Log_extractorProvides LTM for MVS with the name of the Replication Extract load module to be attached at start-up.

The Log_extractor parameter is required.

Example syntaxLog_extractor=DRL@INIM

Default value

• DRL@INIM



Valid value

• DRL@INIM

Warning! Do not change the default value of the Log_extractor parameter; doing so causes program failure.

Log_identifierProvides LTM for MVS with the identifier of the subsystem containing the primary tables on DB2. This is also the subsystem on which the Replication Extract component of Replication Agent is running.

The Log_identifier parameter is required.

Example syntaxLog_identifier=DSNA

Default value

• none

Valid values

• A DB2 subsystem ID or group attach name (see “The Log_identifier parameter and data sharing” on page 109 for additional details)

• Maximum of 8 characters

Note Obtain your site’s value for the Log_identifier parameter from the Replication Agent Installation Worksheet in the Replication Agent for DB2 UDB Installation Guide for OS/390. This value should have been recorded on the worksheet during installation.



Comments

When changing the value of the Log_identifier parameter, Replication Agent should have processed all records up to the end of the DB2 log. Changing the value causes Replication Extract to process transactions on a different DB2 subsystem. When Replication Extract stops processing the log for the subsystem you originally specified, open transactions on that subsystem may never reach the replicate database.

The Log_identifier parameter and data sharing

Replication Extract uses the value of the Log_identifier parameter to connect to DB2. The Log_identifier value identifies either the DB2 group attach name or a single DB2 subsystem (Sybase recommends using the group attach name as data sources for replication.

In DB2, the group attach name functions as an alias for a group of transaction identifiers. Replication Agent can use the group attach name to replicate transactions from multiple members of a data-sharing group.

Long_varcharSpecifies size limits for char and varchar datatypes.

The Long_varchar parameter is required.

Example syntaxLong_varchar=Y

Default value

• N

Valid values

• Y

Replication Agent limits char field lengths at 254 bytes and varchar fields at 32,704 bytes.

• N



Replication Agent uses old char and varchar field limits.

Low_activity_latencyControls the length of time Replication Agent is quiescent during a low-activity period. This parameter can be used to conserve resources when the demand on Replication Agent is low.

The Low_activity_latency parameter is optional.

Example syntaxLow_activity_latency=5

Default value

• 10

Valid values

• Any integer from 1 to 99.

LTL_table_col_caseSpecifies the case of replicate table and column names.

The LTL_table_col_case parameter is optional.

Example syntaxLTL_table_col_case=asis

Default value

• asis

Valid values

Values for this parameter must be entered in lowercase.



• asis

The replicate table name is the same as the primary table name.

• upper

The replicate table name is uppercase.

• lower

The replicate table name is lowercase.

Note The table names produced as a result of this parameter setting must match the table names in the replication definition and in the target database. Table and column names must be of the same case if this parameter is used.

LTL_test_onlyControls whether LTM for MVS connects to Replication Server and sends transaction operations for replication.

The LTL_test_only parameter is optional.

Example syntaxLTL_test_only=N

Default value

• N

Valid values

• N

Allows LTM for MVS to connect to Replication Server and send transaction operations for replication, in normal production mode.

• Y

Setting the value of LTL_test_only to Y results in the following actions:

• Prevents LTM for MVS from connecting to Replication Server

• Sends LTL to the LTLOUT file (in EBCDIC format)



• Obtains the LTM Locator value from LTMTRUNC file

• Sets the maintenance user ID to FREDDY## (the # symbol represents a space)

• A

Causes Replication Agent to write data to the LTLOUT file in ASCII format instead of in EBCDIC format. This value is otherwise the same as a value of Y.

Comments

Set the value of LTL_test_only to Y only when debugging Replication Agent.

LTM_admin_pwThe LTM_admin_pw parameter is required but not used in this software release.

Although this parameter is not used, you must provide a value. Do not comment out or delete.

Example syntaxLTM_admin_pw=noneyet

Valid value

• Any value

LTM_admin_userThe LTM_admin_user parameter is required but not used in this software release.

Although this parameter is not used, you must provide a value. Do not comment out or delete.

Example syntaxLTM_admin_user=noneyet



Valid value

• Any value

LTM_process_maint_uid_transControls whether LTM for MVS forwards transactions performed by the Replication Server maintenance user to Replication Server.

The LTM_process_maint_uid_trans parameter is optional.

Example syntaxLTM_process_maint_uid_trans=N

Default value

• N

Valid values

• N

Transactions performed by the Replication Server maintenance user are not sent to Replication Server.

• Y

Transactions performed by the maintenance user are sent to Replication Server for replication.

Comments

Most replication installations do not need to replicate transactions performed by the Replication Server maintenance user.

Set the value of this parameter to Y only if you are certain you need to replicate maintenance user transactions.



Maximum_connect_retriesControls the number of times LTM for MVS attempts to restore a failed connection to Replication Server.

The Maximum_connect_retries parameter is optional.

Example syntaxMaximum_connect_retries=10

Default value

• 10

Valid values

• Integers from 0 (none) to 9999 (infinite). A blank value will be accepted and set to 0.

Comments

• If the LTM for MVS message queue does not contain messages to send, LTM for MVS does not attempt to restore the connection to Replication Server.

Minimal_colsControls whether transaction operation records for updates include the entire before image of a row and only those columns in the after image that change as a result of the update.

The Minimal_cols parameter is optional.

Example syntaxMinimal_cols=Y

Default value

• Y



Valid values

• Y

Causes transaction operation records for updates to include the entire before image of a row but only those columns in the after image that change as a result of the update.

• N

Allows transaction operation records for updates to include the entire before image of a row and the entire after image of the row.


Setting the value of Minimal_cols to Y can reduce network traffic, especially at sites with tables containing a high volume of columns.

Note Replication Agent limits char and varchar field lengths to 254 bytes and long varchar field lengths to 32704 bytes when Minimal_cols=N. When Minimal_cols=Y, Replication Agent limits char and varchar fields to 250 bytes and long varchar fields to 32700 bytes. Replication Agent allows a maximum of 126 double-byte characters when Minimal_cols=N and 124 double-byte characters when Minimal_cols=Y.

Minimum_yearThe value you supply is the minimum year value that Replication Agent can accept.

The Minimum_year parameter is optional.

Example syntaxMinimum_year=1753

Default value

• 0000



Valid values

• Any four-digit integer

Comments

If a date or timestamp in the source data marked for replication contains a year below the value you specify in the Minimum_year configuration parameter, then LTM for MVS inserts the value of the Date_conv_default parameter in the data you are replicating.

Updated data can fail (and Adaptive Server can fail, depending on the settings of the Adaptive Server parameters that control error behavior) under the following conditions:

• The source data contains dates before 1753.

• You specify a Minimum_year value of less than 1753.

See “Date_conv_default” on page 104 for information on the Date_conv_default parameter.

Packet_size• Sets the size of packets in bytes used by TCP/IP in sending data from

Replication Agent to Replication Server

• Sets the size of the buffers used by Replication Agent

The Packet_size parameter is optional.

Example syntaxPacket_size=16k

Default value

• 16K

Valid values

• Multiples of 512 from 512 to 1024000 bytes. A value in this range ending with the letter k or K is also valid.



replace_null_in_charSpecifies the value that replaces binary zero (x’00’) characters in LTM for MVS char or varchar data columns, except when the value of replace_null_in_char is blank or the parameter is commented out of the configuration file.

The replace_null_in_char parameter is optional.

Note This parameter is commented out of your LTM for MVS configuration file. Leave it commented out unless you know you have binary zeros in LTM for MVS char or varchar columns.

Example syntaxreplace_null_in_char= blank

Default value

• Null

Valid values

• Any value except x’00’

• To replace the null characters with blanks, set this parameter value as follows:

replace_null_in_char=#blank

where the # symbol represents a space.

Comments

To make this parameter active, uncomment the parameter in the LTM for MVS configuration file.

When uncommented, this parameter can impair performance. It forces LTM for MVS to scan each char or varchar field and replace each binary zero. You can use a user exit to perform this function more efficiently.

See Appendix D, “Creating user exits” in the Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390 for information about using a user exit to replace binary zeros.



retryControls the number of seconds LTM for MVS waits before attempting to restore a failed connection to Replication Server.

The retry parameter is optional.

Example syntaxretry=10

Default value

• 10

Valid values

• Integers between 1 (one second) and 86400 (one day)

Comments

If the LTM for MVS message queue does not contain messages to send, LTM for MVS does not attempt to restore the connection to Replication Server.


If the value of this parameter is too low, your CPU usage can be unnecessarily high during network outages. If this value is too high, delays in replication can occur following network outages.

RSName of the machine where the primary Replication Server resides.

The RS parameter is required. The maximum length for this parameter is 30 alphanumeric characters.

Example syntaxRS=LTMIDRS1



Valid values

The value of the RS parameter for your site must exactly match the value of the SERVERNAME parameter in the SYGWHOST macro entry for Replication Server.

The value of the RS parameter must contain a maximum of 30 alphanumeric characters.

Note Obtain your site’s value for the RS parameter from the Replication Agent Installation Worksheet in the Replication Agent for DB2 UDB Installation Guide for OS/390. This value should have been recorded on the worksheet during installation.

RS_ccsidIndicates the Coded Character Set Identifier (CCSID) used by the Replication Server to which Replication Agent is connected.

The RS_ccsid parameter is optional.

Warning! If you change the DB2 CCSID setting in the DSNTIPF panel, you must also do the following to ensure LTM resumes processing at the end of the DB2 log using the proper CCSID:

1 Change the values for the Replication Agent Codepage and RS_ccsid parameters in the LTMCNFG member of the hlq.JCL data set to reflect the new CCSID value.

2 Reset the truncation point and rs_locater values to zero. See “Basic Replication Agent Troubleshooting Tips” in Chapter 7, “Basic Troubleshooting Procedures” of the Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390 for instructions.

Example syntaxRS_ccsid=819

Default value

• 819



Valid values

• The range of valid values for the RS_ccsid parameter is between 0 and 64534 inclusive. A value in this range starting with the prefix cp or CP is also valid. For example, the user may enter 1258 or CP1258 to indicate the code page value for Vietnamese.

Note Replication Agent has until now supported only the single-byte, European character sets. Replication Agent version 12.5 supports all valid DB2 CCSIDs, including ASCII and double-byte CCSIDs.

To determine the appropriate value for the RS_ccsid parameter, see the table provided in the CODEPAGE member of the hlq.DOCS library. Here is an excerpt of the CODEPAGE member:

|-------------------------------------------------------|| This table lists the values to use for the Rep Agent || Codepage= and RS-ccsid= parameters. The ’DB2 CCSID’ || column lists the settings used on the DB2 installation|| panel ’DSNTIPF’. This is usually the same as the || CCSID for the user database in which the primary table|| was created. The Rep Server/ASE column lists || character set values. The RS_ccsid value should || reflect the setting of Replication Server’s RS_charset|| configuration parameter. ||-------------------------------------------------------|| | Rep Server/ASE | Rep Agent | Rep Agent || DB2 CCSID | ---------------| Codepage= | RS_ccsid= || | character set | | ||-----------|----------------|------------|-------------|| 37 | cp437 | 37 | 437 ||-----------|----------------|------------|-------------|| 37 | iso_1 | 37 | 819 ||... ... ... ... ... ... ... ... ... ... ... ... ... ...||-----------|----------------|------------|-------------|| 5026 | cp932 | 5026 | 932 ||-----------|----------------|------------|-------------|| 5035 | cp932 | 5035 | 932 ||-----------|----------------|------------|-------------|| 5348 | cp437 | 5348 | 437 ||-----------|----------------|------------|-------------|| 5348 | iso_1 | 5348 | 819 ||-----------|----------------|------------|-------------|| 5348 | cp1252 | 5348 | 1252 ||-----------|----------------|------------|-------------|



This table matches DB2 CCSIDs with their appropriate Replication Agent Codepage and RS_ccsid configuration parameter values.

Comments

You can verify the CCSID setting for a database by executing the following query:

SELECT * FROM SYSIBM.SYSDATABASE WHERE NAME = ’database_name’

where database_name is the name of the database for which you are verifying the CCSID setting. You can also verify the CCSID settings for translation tables used by the LTM in character data conversions by executing the following query:

SELECT * FROM SYSIBM.SYSSTRINGS WHERE INCCSID = inccsid AND

OUTCCSID = outccsid

RS_source_dbThe value of the RS_source_db parameter represents a logical database name for the tables being replicated. Sybase recommends using the DB2 subsystem or group name (for example, DSNA).

You must select a name to represent the DB2 database, and use it consistently to represent the DB2 database.

Make sure that value you supply for the RS_source_db parameter matches the value you specify for the database variable in the create connection command used to connect Replication Agent to the primary Replication Server.

The RS_source_db parameter is required.

Example syntaxRS_source_db=DSNA



Valid values

• The value of the RS_source_db parameter must match the primary database name in the Replication Server create connection command that LTM for MVS issues to connect the primary database to Replication Server.

Note Obtain your site’s value for the RS_source_db parameter from the Replication Agent Installation Worksheet in the Replication Agent for DB2 UDB Installation Guide for OS/390. This value should have been recorded on the worksheet during installation.

See the “Replication Agent Installation Worksheet” on page 41 for further details.

RS_source_ds Identifies the MVS system that contains the DB2 source database. You can choose this parameter value arbitrarily, as long as you use it consistently to represent the DB2 data server.

Be sure that the value you supply for the RS_source_ds parameter matches the value you specify for the data_server variable in the create connection command used to connect Replication Agent to the primary Replication Server.

The RS_source_ds parameter is required.

Example syntaxRS_source_ds=MVSA

Valid value

• The value of the RS_source_ds parameter must match the name of the primary data server in the Replication Server create connection command that LTM for MVS issues to connect the database containing the primary data to Replication Server.



• Maximum length: 30 characters.

Note Obtain your site’s value for the RS_source_ds parameter from the Replication Agent Installation Worksheet in the Replication Agent for DB2 UDB Installation Guide for OS/390. This value was recorded on the worksheet during installation.

RS_pwProvides the password for RS_user, which is the user ID that LTM for MVS uses to log into the primary Replication Server.

The RS_pw parameter is required.

Example syntaxRS_pw=ltmdevrs_pw

Valid values

• # (blank space)

Setting this value to a blank space inserts a null password.

• Change this value for your site.

• Maximum length: 30 characters.

Note Obtain your site’s value for the RS_pw parameter from the Replication Agent Installation Worksheet in the Replication Agent for DB2 UDB Installation Guide for OS/390. This value should have been recorded on the worksheet during installation.

RS_userIdentifies the Replication Server user ID that LTM for MVS uses to log into the primary Replication Server. This user must have connect source permission on Replication Server.

The RS_user parameter is required.



Example syntaxRS_user=ltmdevrs

Valid value

• A valid Replication Server user ID

• Maximum length: 30 characters

Note Obtain your site’s value for the RS_user parameter from the Replication Agent Installation Worksheet in the Replication Agent for DB2 UDB Installation Guide for OS/390. This value should have been recorded on the worksheet during installation.

RSSD_databaseProvides the name of the database within the Adaptive Server that contains the Replication Server System Database (RSSD) for the primary Replication Server.

The RSSD_database parameter is required if you set the value of the Use_repdef parameter to Y.

LTM for MVS ignores the value of the RSSD_database parameter if you set the value of the Use_repdef parameter to N.

Example syntaxRSSD_database=rssd_name

Valid values

• The name of the Adaptive Server that contains the primary Replication Server’s RSSD

Comments

You must set the value of the Use_repdef parameter to Y to use the RSSD_database parameter.



RSSD_pwProvides the password for the Adaptive Server user ID specified in the RSSD_user parameter value.

The RSSD_pw parameter is required if you set the value of the Use_repdef parameter to Y.

LTM for MVS ignores the value of the RSSD_pw parameter if you set the value of the Use_repdef parameter to N.

Example syntaxRSSD_pw=password

Valid values

• Password of the Adaptive Server user ID specified in the RS_user parameter value

• # (blank space)

Setting this value to a blank space inserts a null password.

RSSD_serverProvides the name of the Adaptive Server that contains the primary Replication Server’s RSSD.

The RSSD_server parameter is required if you set the value of the Use_repdef parameter to Y.

LTM for MVS ignores the value of the RSSD_server parameter if you set the value of the Use_repdef parameter to N.

Example syntaxRSSD_server=sql_server_name

Valid value

• The value of the SERVERNAME variable in the SYGWHOST macro entry for the Adaptive Server that contains the primary Replication Server’s RSSD.



Comments

If the value of the Use_repdef parameter is set to Y, you must specify a value for the RSSD_server parameter.

Note Obtain your site’s value for the RSSD_server parameter from the Replication Agent Installation Worksheet in the Replication Agent for DB2 UDB Installation Guide for OS/390. This value should have been recorded on the worksheet during installation.

RSSD_userProvides the identifier that Replication Agent uses to log on to the Adaptive Server that contains the primary Replication Server RSSD. This user must have permission to perform selects against the Adaptive Server.

The RSSD_user parameter is required if you set the value of the Use_repdef parameter to Y.

LTM for MVS ignores the value of the RSSD_user parameter if you set the value of the Use_repdef parameter to N.

Example syntaxRSSD_user=sql_server_user

Valid value

• The user ID of the Adaptive Server user who has permission to perform selects against the Adaptive Server RSSD.

Stop_on_errorControls whether the detection of specific errors shuts down LTM for MVS.

The Stop_on_error parameter is optional.

Example syntaxStop_on_error=N



Default value

• N

Valid values

• N

LTM for MVS continues processing despite detection of specific errors. LTM for MVS logs errors in the LTMLOG file.

• Y

• Shuts down LTM for MVS upon detection of specific errors.

• LTL is sent to LTLOUT without passing data to Replication Server.

Comments

Use this parameter to troubleshoot specific errors, including invalid replication definitions. Set the value of this parameter to Y to assist in troubleshooting Replication Extract or a user exit application you created.

Table A-2 shows the behavior of LTM for MVS when it detects specific error conditions.



Table A-2: Error conditions that shut down LTM for MVS

Upon detecting other errors, LTM for MVS continuously attempts to retry the connection to Replication Server.

Support_DB2_comp_recWith the value of the Support_DB2_comp_rec parameter set to Y, Replication Agent suppresses DB2 delete compensation records from the transaction operation information sent to Replication Server.

Message number Condition

How Stop_on_error value affects LTM for MVS

14021 Invalid login.

Note This message appears only when using Replication Server 11.x.

LTM for MVS shuts down regardless of Stop_on_error value.

14025 LTM for RS_source_ds. RS_source_db is not configured to connect.


14027 LTM for RS_source_ds. RS_source_db is already connected.

LTM for MVS shuts down regardless of Stop_on_error value. LTM for MVS retries the connection once.

14039 Log Transfer for LTM for RS_source_ds. RS_source_db is suspended. The connect source is refused because Log Transfer is suspended.


20014 Invalid login. LTM for MVS shuts down regardless of Stop_on_error value.

32020 Table table_name is not defined.

LTM for MVS does not shut down; retries connection regardless of Stop_on_error value.

32032 Replication definition does not exist for table table_name.

LTM for MVS shuts down only when Stop_on_error=Y.



Default value

• N

Valid values

• N

LTM for MVS passes DB2 delete compensation records to Replication Server.

• Y

LTM for MVS ignores DB2 delete compensation records. Delete compensation records are not passed to Replication Server.

Suppress_col_namesThe Suppress_col_name parameter determines whether LTM for MVS suppresses column names from the LTL that is sent to Replication Server. You can use this parameter to reduce network traffic.

The Suppress_col_name parameter is optional.

Example syntaxSuppress_col_names=N

Default value

• N

Valid values

• N

Includes column names in the LTL that LTM for MVS sends to Replication Server.

• Y



Suppresses column names from the LTL that LTM for MVS sends to Replication Server.

Warning! If you set the value of Suppress_col_names to Y, be sure that the order of the columns in your replication definition exactly matches the order of your DB2 columns. Failure to do so can result in a mismatch between your source and replicate data.

Comments

If you set the value of Suppress_col_names to Y, you must set the values of the following parameters as follows:

• Minimal_cols=Y

• Use_repdef=Y


Setting the value of Suppress_col_names to Y, with Minimal_cols set to Y and Use_repdef set to Y, can dramatically increase throughput.

Time_conv_defaultPerforms two functions:

• Controls the value DateTime_conv_err supplies in columns that encounter date conversion errors when the DateTime_conv_err parameter is set to Datetime.

• Supplies time values during conversion of LTM for MVS date to Adaptive Server datetime format.

The Time_conv_default parameter is optional.

Example syntaxTime_conv_default=00:00:00

Default value

• 00:00:00



Valid values

• Any valid ISO time format value (HH:MM:SS, where HH=hour, MM=minute, and SS=second)

See “Working with Datatype Conversions” in the Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390 for examples of valid date, time, and timestamp formats.

Time_in_charControls whether LTM for MVS time columns are sent as char(8) fields or converted to Adaptive Server datetime format.

The Time_in_char parameter is optional.

Example syntaxTime_in_char=N

Default value

• N

Valid values

• N

Causes LTM for MVS to convert LTM for MVS time columns to Adaptive Server datetime format.

• Y

Causes LTM for MVS to send unmodified time columns as char(8) fields (format: HH:MM:SS) instead of converting them to Adaptive Server datetime format.




Timestamp_in_charControls whether unmodified timestamp columns are sent as char(26) fields or converted to Adaptive Server datetime format.

The Timestamp_in_char parameter is optional.

Example syntaxTimestamp_in_char=N

Default value

• N

Valid values

• N

LTM for MVS converts LTM for MVS timestamp columns to Adaptive Server datetime format. The datetime format contains only milliseconds, whereas timestamp contains microseconds.

• Y

LTM for MVS sends timestamp columns as char(26) fields (example: 1994-01-01-10.02.30.006123) instead of being converted to Adaptive Server datetime format.

Comments

LTM for MVS timestamp data has 6 digits of precision. Set the value of Timestamp_in_char to Y to prevent precision loss during conversion of LTM for MVS timestamp data to Adaptive Server datetime format. Use when LTM for MVS timestamp data needs to be replicated and to remain unique.




trace=1,4Traces Replication Extract’s calls to the Replication API and sends the output to the SYSPRINT file. Run this trace only on the advice of Sybase Technical Support.

The trace=1,4 parameter is optional.

Example syntax

To enable this facility, insert the statement trace=1,4 in the LTM for MVS configuration file.

Note Be sure to comment out trace statements in the configuration file after you obtain the desired information. Traces require significant MVS resources and can seriously impair LTM for MVS performance.

Comments

This facility can also be turned on and off dynamically from the MVS console.

1 Start this trace on a job by entering the following command from the MVS operator console:

F job_name,C,trace=1,4

2 End this trace by entering the following command from the MVS operator console:

F job_name,C,notrace=1,4

See also • Chapter 2, “Managing Replication Agent”

trace=1,11Writes Log Transfer Language (LTL) that is passed to Replication Server to the LTLOUT trace file.

The trace=1,11 parameter differs from the trace=1,31 parameter in that it translates the LTLOUT file data into EBCDIC, while trace=1,31 translates the LTLOUT file data into ASCII.




Example syntax

To enable this trace facility, insert the statement trace=1,11 in the LTM for MVS configuration file.

Note Be sure to comment out trace statements in the configuration file after you obtain the desired information. Traces require significant MVS resources and can seriously impair LTM for MVS performance.

Comments

This trace facility can also be turned on and off dynamically from the MVS console.





See also • Chapter 2, “Managing Replication Agent”

trace=1,23This facility writes processing time information in the LTMTRACE file.


Example syntax




Comments

After running LTM for MVS with the trace=1,23 statement inserted in the configuration file, the LTMTRACE file contains various messages about processing.

You can use the information provided in these messages to identify the source of processing delays, if applicable. The following are sample messages printed to the LTMTRACE file:

Network (QID) snd/rec completed in 0.004200 secLTM build/send 16Kb buffer in 0.114700 seconds (139.494333 Kb/sec)LTM build/send avg: 145.222459Kb per second

Note Be sure to comment out trace statements in the configuration file after you obtain the desired information. Traces require significant MVS resources and can impair LTM for MVS performance.

This trace facility can also be turned on and off dynamically from the MVS console.





trace=1,31Starts a trace that sends data passed to Replication Server to the LTLOUT file. The user can then determine whether LTM for MVS is functioning properly by examining the LTLOUT file.

The trace=1,31 parameter differs from the trace=1,11 parameter in that it translates the LTLOUT file data into ASCII, while trace=1,11 translates the LTLOUT file data into EBCDIC.




Example syntax


Transaction_nameThis configuration parameter, which was intended for use with APPC connectivity, is now obsolete. Replication Agent version 12.5 does not support APPC connectivity.

For TCP/IP connectivity, the value of Transaction_name is required but ignored.

Example syntaxTransaction_name=netgw

Valid values

• Any value is valid

Use_repdefWith TCP/IP connectivity, allows LTM for MVS to send LTL to Replication Server that contains only the columns specified in the replication definition.

The Use_repdef parameter is optional.

Example syntaxUse_repdef=N

Default value

• N

Valid values

• N



LTM for MVS sends LTL to Replication Server that contains all DB2 columns defined in your primary table.

• Y

With TCP/IP connectivity, LTM for MVS logs in to the Adaptive Server that contains the RSSD for the primary Replication Server. LTM for MVS then obtains the replication definition and includes only the columns specified in the replication definition in the LTL it sends to Replication Server.

Note Because LTM for MVS logs in to the Adaptive Server that contains the RSSD for the primary Replication Server, the Adaptive Server user ID used by LTM for MVS must have permissions to perform selects against the Adaptive Server RSSD. This Adaptive Server user ID, specified by the value of the RSSD_user parameter, must have a minimum of SELECT privileges.

If you set the value of Use_repdef to Y and use TCP/IP, you must do the following:

• Set the value of Minimal_cols to Y.

• Add a SYGWHOST macro entry for the Adaptive Server that contains the RSSD for the primary Replication Server. The SYGWHOST macro entry must contain valid values for this Adaptive Server in the SERVERNAME, IPADDR, and LSTNPORT parameters.

• Provide valid values for each of the following configuration parameters:

RSSD_database

RSSD_pw

RSSD_server

RSSD_user


If you specify only a subset of the tables in the replication definition, and the tables have long column names, setting the value of Use_repdef to Y can help reduce network traffic and can therefore improve performance when you use TCP/IP.



User_exitSupplies the name of your user exit to Replication Agent upon start-up.

The User_exit parameter is optional.

Example syntaxUser_exit=RADAEX1

Default value

• Null

Valid values

• The value of the User_exit parameter must be identical to the name of your user exit module and is restricted to the following:

• Must be a maximum of 8 characters, all uppercase

Note When processing the configuration file, Replication Agent automatically changes the case of the User_exit parameter value to upper case.

• Must begin with an alphabetic character

• Must be a valid module name on MVS

• Must be the name of the user exit module located in your LINKLIB

Comments

If you have a user exit, you must specify the name in the User_exit configuration parameter; otherwise the system will not load it.


A P P E N D I X B Replication Extract Configuration Parameters

This chapter describes the Replication Extract parameters contained in the PARMLIB (Replication Extract parameter data set) member.

See also • Appendix C, “Replication Extract commands” in the Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390

PARMLIB data set membersThe SETUP00, PLANS00, and PDR members in the hlq.PDR.PARMLIB data set that is contained on the Replication Agent distribution tape contain the parameters that enable you to customize the execution of Replication Extract.


This section contains the following information:

• Replication Extract members and parameter conventions

• SETUP00 member contents and parameters

• PLANS00 member contents

• PDR member contents and parameters

PARMLIB data set members


Replication Extract members and parameter conventions Each parameter in the SETUP00, PLANS00, and PDR members consists of a parameter name, followed by the parameter value. If you add comments to any hlq.PDR.PARMLIB data set member, make sure that each set of opening comment characters (/*) has a corresponding set of closing comment characters (*/). Omitting any of these characters can result in errors during the hlq.PDR.PARMLIB data set processing.

SETUP00 member contents and parametersThe SETUP00 member in the hlq.PDR.PARMLIB data set contains parameters that provide information about the DB2 subsystem on which you are installing Replication Extract.

The following example shows a sample SETUP00 member.

ExampleSSID (db2ssid) /* DB2 SUBSYSTEM ID */LOADLIBS ( /* -- DB2 LOAD LIBRARIES -- */ DSN.V510.SDSNEXIT /* EXITS (EDIT & FIELD PROCS*/ DSN.V510.SDSNLOAD /* DB2 SOFTWARE LIBRARY */

)

The SETUP00 member contains two parameters:

• SSID

• LOADLIBS

SSID

The value of this parameter identifies the DB2 subsystem on which you install Replication Extract.

For each DB2 subsystem that runs a Replication Agent started task, include a line containing a SSID entry for each data-sharing member.

If you are running DB2 in data-sharing mode, the SSID parameter value should contain the DB2 group attach name or the subsystem ID for member 1 of the data-sharing group from which you are replicating transaction information.

APPENDIX B Replication Extract Configuration Parameters


SSID entries coded in the SETUP00 member need not be unique, but there must be an entry for the value of the LTM for MVS Log_identifier parameter, which Replication Extract uses to connect to DB2. The SETUP00 member can also contain SSIDs in the datasharing group other than the one specified in Log_identifier.

The SETUP00 member can optionally include the DB2 group attach name, which can serve as an alias for SSIDs and can be used as the value in both the LTM for MVS Log_identifier parameter and the Replication Extract SSID parameter. For the sake of simplicity, you may want to use the DB2 group attach name for the values of both parameters.

Replication Agent searches the SSID entries in the SETUP00 member for matches with the value of the LTM for MVS Log_identifier parameter. Once a match is found, the remaining SSIDs are ignored. The order of the SSIDs does not matter. If a match is not found, the LTM abends with a return code of 8 and delivers an error message like the following:

LAE0006E DB2 SSID ssid is not defined in the Platinum PARMLIB

where ssid is the subsystem ID for which Replication Agent is searching in the SETUP00 member.

Incorrect syntax will also result in an LTM abend with return code of 8, but will result in a different error message like the following:

LAE0006E LOAD OF MODULE DSNALI FAILED

LOADLIBS

The value of this parameter represents the DB2 load library names for this subsystem. These libraries contain information specific to the user environment, such as the DSNZPARMS member and editprocs and fieldprocs.

PLANS00 member contentsThe PLANS00 member of the PARMLIB data set contains the name of the log extract plan name as the value of the PDRPLANS parameter.

The following example shows sample PLANS00 member contents.



ExamplePDRPLN01=REPAGENT PLATINUM REPLICATION EXTRACT

where the value of the PDRPLANS parameter is REPAGENT, which is the name of the log extract plan. This variable value must be enclosed in parentheses.

PDRPLANS

Specifies the name of the log extract plan name.

Note If you change the default name of the log extract plan, you must change the name of the plan in the sample JCL supplied in the PDRBIND member of the hlq.JCL data set.

PDR member contents and parametersThe PDR member of the hlq.PDR.PARMLIB data set enables you to specify values for several parameters required for the installation and execution of Replication Extract.

Note Only one PDR member is required for data sharing. This member name must be PDR or PDRxxxx, where xxxx represents the identifier of one of the DB2 subsystem names in the data-sharing group.

Example

The following example shows sample PDR member contents:

/*------------------------------------------------------------------*//* ---- P L A T I N U M T E C H N O L O G Y I N C. ---- *//* *//* PLATINUM DATA REPLICATOR DEFAULT PARMLIB OPTIONS *//*------------------------------------------------------------------*/REPL_ERROR (TERM) /* REPLICATION ERROR CONDITIONS: */ /* (TERM) OR (MSG) */ /* */ /* */POLL_INTVL (00.00.20.00) /* AMOUNT OF TIME TO SLEEP BEFORE */ /* REPOLLING THE HIGH WRITTEN RBA */ /* AFTER REACHING END OF ACTIVE LOG */



/* (HH.MM.SS.TT) */ /* */CI_COUNT (000) /* MINIMUM NUMBER OF CIS TO ALLOW */ /* DB2 TO WRITE BEFORE ISSUING EXCP */ /* AFTER REACHING END OF ACTIVE LOG */ /* */ARCHIVE (B) /* ARCHIVE LOG ACCESS METHOD */ /* (E) EXCP OR (B) BSAM */ /* */BUFFERS (25) /* NUMBER OF BUFFERS TO USE WHEN */ /* READING DB2 LOG (01 - 50) */ /* */LOGCOPY2 (N) /* USE COPY2 BEFORE COPY1 OF DB2 */ /* ACTIVE/ARCHIVE LOGS (Y) OR (N) */ /* */TRACE (Y) /* TRACE FOR DIAGNOSTIC MESSAGES */ /* (Y) OR (N) */ /* */ /* */GENID (0) /* GENERATION ID */ /* */ /* */SET_TRUNC (47000) /* FREQUENCY WITH WHICH TO FORCE */ /* THE REP SERVER TO SAVE A NEW */ /* TRUNCATION POINT 47000 */ /* */ /* SINGLE MEMBER DATA SHARING OPTION */ /* READER_TYPE (SMO) */ /* READER_NAME (SSID) */ /* */

The PDR member contains the following parameters.

REPL_ERROR

Indicates whether to continue processing the log if replication errors occur. Such conditions occur whenever Replication Extract is unable to process a log record that describes a change to a table marked for replication. A replication error can occur if, for example, a replicate table was not defined with the DATA CAPTURE CHANGES clause.

Specify one of the following values for REPL_ERROR:

• TERM terminates the started task if a replication error condition occurs.



• MSG issues a message to the operator console indicating that a replication error occurred. Replication stops for the table on which the error occurred. Replication Extract continues processing the log and replicating changes made to any other tables marked for replication.

Note Sybase recommends that you set the value of the Replication Extract REPL_ERROR configuration parameter to TERM instead of MSG. This ensures that logically connected replicate tables remain synchronized.

POLL_INTVL

Controls the amount of time Replication Extract waits before repolling DB2’s high-written log relative byte address (RBA) after reaching the end of the active log.

The format of this parameter is HH.MM.SS.TH, where:

• HH represents hours.

• MM represents minutes.

• SS represents seconds

• TH represents hundredths of a second.

Separate each number by a period.

For example, assume the value for POLL_INTVL is 00.00.20.00. When Replication Extract starts, it determines the log RBA of the last record DB2 wrote to the log. Replication Extract then scans the log until it reaches this end point (the RBA represents the end of the current active log). Replication Extract enters a wait state for 20 seconds, as indicated by the value in POLL_INTVL. When the 20 seconds pass, Replication Extract dispatches and again determines where the active log ends. When the new end point is reached, the cycle repeats.


A high POLL_INTVL value decreases the amount of CPU time used and the number of I/O operations Replication Extract performs. It also increases the latency time, a measure of the time passed from the point when your DB2 data is updated to the point when Replication Agent distributes the update to Replication Server.



A low POLL_INTVL value increases CPU use and the number of I/O operations Replication Extract performs, but decreases the latency time.

For a low latency time, specify a POLL_INTVL value of 00.00.02.00.

Note The default polling interval is 20 seconds. You must not set the polling interval to a value less than 20 in a data-sharing environment.

CI_COUNT

Controls the minimum number of log Control Interval (CI) operations that DB2 writes to the log before Replication Extract issues I/O operations to retrieve new data from the log. Enter a numeric value between 0 and 999.

The effect of the CI_COUNT parameter is similar to the POLL_INTVL parameter.

• A low CI_COUNT value increases the number of I/O operations issued but reduces the latency period.

• A high CI_COUNT value decreases the number of I/O operations issued.

Sybase recommends that you specify a CI_COUNT value of 0 (zero), and use the POLL_INTVL parameter to control CPU usage, I/O operations issued, and latency time.

GENID

Controls the value of the high-order 2 bytes of the origin queue ID (QID).



Every update that passes to Replication Server contains a unique identifier known as a QID. Replication Extract constructs the QID as a continuously increasing value. The QID of each update is guaranteed to be greater than the QID of all lower updates. The QID consists of a series of DB2 log RBAs that identify the log record that describes the update. Replication Server tracks the highest QID that successfully replicated and ignores any passed updates having a lower QID. This prevents a single update from being incorrectly replicated repeatedly to the same server. It also prevents the reprocessing of a portion of the log that already successfully replicated. Using the GENID parameter, you can circumvent this action.

Note GENID controls whether you can reprocess a portion of the log. You may need to reprocess a portion of the DB2 log that already successfully replicated if, for example, a hardware failure causes the loss of data at a replicated database. In this case, you might decide to restore the data at the server from a local backup and then reapply a portion of the DB2 log.

The specified GENID must be a number from 0 to 65535. The default value of 0 causes the first 2 bytes of the QID to be set to null (x’00’). Incrementing the GENID value by 1, such as from GENID(0) to GENID(1), forces all QIDs generated from the new value to be greater than any previously-generated QIDs. This makes it possible to reprocess a portion of the log and ensures that Replication server does not discard the reprocessed update.

When you update the GENID parameter, the new value must be larger than the old value. If it is not, Replication Server ignores all subsequently passed updates.

Warning! Changes to the GENID parameter must be synchronized with changes to other configuration parameters and can corrupt replicate data if used incorrectly. Contact Sybase Technical Support before making any changes to this parameter.

See also Appendix D, “Upgrading Your Replication Agent Software”

ARCHIVE

Specifies the access method for reading archive logs.

Specify one of the following values for ARCHIVE:



• B (the default) for BSAM, which is used for accessing an archive log that is compressed using third-party compression software

• E for EXCP

BUFFERS

Specifies the number of buffers for the log reader.

The number of buffers ranges from 1 to 50. The default is 50.

LOGCOPY2

Specifies whether to use COPY2 rather than COPY1 of the archive log.

Specify one of the following values for LOGCOPY2:

• N (the default) uses COPY1 before COPY2.

• Y uses COPY2 before COPY1.

COPY1 and COPY2 each consist of active and archive data sets. When Replication Agent is reading the active data sets, it always uses the LOGCOPY1 parameter, unless an error is detected. When Replication Agent is reading the archive data sets, it follows the setting for the LOGCOPY2 parameter. Replication Agent will read archive data sets only during start-up or when recovering from an error.

TRACE

Controls the Replication Extract messaging level.

Specify one of the following values for TRACE:

• N (the default) means that the messaging level is not traced.

• Y means that the messaging level flow is traced.

SET_TRUNC

The value of the SET_TRUNC parameter controls the number of DB2 log Control Intervals (CIs) to process before updating the LTM Locator maintained by the Replication Server.



The LTM Locator value represents a unique position within the DB2 log. When Replication Agent starts and establishes communication with Replication Server, it receives the current LTM Locator value. Replication Extract then uses the LTM Locator value to derive the point from which to resume processing the DB2 log.

Specify a value that causes the LTM Locator to update twice during the processing of each active log data set. Use the following formulas to calculate this value:

If your active log resides on a 3390:

value = C x 180 / 2

or,

value = T x 12 / 2

If your active log resides on a 3380:

value = C x 150 / 2

or,

value = T x 10 / 2

where:

• C is the size of your smallest active log data set in cylinders

• T is the size of your smallest active log data set in tracks

In a data-sharing environment, Replication Extract resumes processing the DB2 log when any member of the data-sharing group reaches the derived threshold; However, Replication Extract only updates the truncation point of the member that reached the threshold.

READER_TYPE

This parameter is commented out unless you are replicating from a single member in a DB2 data-sharing environment.

If you are replicating from a single member in DB2 data-sharing mode, the value of the READER_TYPE parameter is always SMO.

READER_NAME

This parameter is commented out unless you are replicating from a single member in a DB2 data-sharing environment.



If you are replicating from a single member in DB2 data-sharing mode, the value of the READER_NAME parameter should be the name of the data-sharing group member that contains the updates you plan to replicate.

Note The READER_NAME parameter value can differ from the subsystem ID of the data-sharing group member from which you are replicating. To verify whether the member name is the same as the subsystem ID, use the DB2 -DISPLAY GROUP command to display the member name and subsystem ID.


A P P E N D I X C Replication Agent Data Sets

Replication Agent for DB2 UDB for OS/390 version 12.5, which includes the LTM for MVS and Replication Extract components, is supplied on the Replication Agent distribution CD. This appendix describes the characteristics and contents of the Replication Agent data sets that result on the mainframe after the installation process.

Replication Agent data setsThis section contains information about Replication Agent data sets and data set members.

DBRMLIB contentsThe hlq.DBRMLIB file contains Replication Extract database request modules necessary for the DB2 plan.

Replication Agent data sets


DOCS contentsThe following table shows the contents of the hlq.DOCS data set.

Table C-1: DOCS library contents

ISPF contentsThe following table shows the contents of the hlq.ISPF data set.

Table C-2: ISPF library contents

Member name Contents

AMBLIST Sample JCL for utility. Use as directed by Sybase Technical Support.

CODEPAGE Contains a table listing values to use for the Replication Agent Codepage and RS_ccsid parameters.

DSNJU004 Job to print the contents of the bootstrap data sets.

RADAEX1 Example user exit.

SETRPERR Sample SPUFI input for updating the ERROR_CODE column of the LTMOBJECTS Replication Agent system table with an error code of 20.


LTMCSET CLIST for Replication Agent ISPF interface dialogs.

LTMSSET Skeleton JCL for Replication Agent ISPF interface dialogs.

RADAEX1 Sample Assembler user exit.

RADH0000 ISPF dialog panels.



RADP0000 ISPF dialog panels.



RATH0000 ISPF dialog panels.



APPENDIX C Replication Agent Data Sets


JCL contentsThe following table shows the contents of the hlq.JCL data set.

Table C-3: JCL library contents














RATPLOGO ISPF dialog panels.

RATP0000 ISPF dialog panels.

RATP0010 ISPF dialog panels.

RATS0000 Extra JCL procedure for running Replication Agent.



ALLOC Job to allocate permanent Replication Agent data sets and define generation data groups for Replication Agent logs.

CVTQID Use only as directed by Sybase Technical Support.

GRANT Grants BIND and EXECUTE permissions to LTMADMIN user ID for the log extract plan.

LTMCNFG Sample LTM for MVS configuration file.



MACLIB contentsThe following table shows the contents of the hlq.MACLIB data set.

Table C-4: MACLIB library contents

LTMPROC Sample JCL procedure for running Replication Agent.

PDRBIND Sample JCL for binding the log extract plan.

PINGRS Sample JCL to run PINGRS to test connectivity between Replication Agent and Replication Server.

RECEIVE Job to unpack the Replication Agent and SAS/C runtime loadlibs into standard loadlibs.

RUNLTM Sample JCL to run LTMPROC.

SQLINIT Sample SPUFI input to create and grant permissions to LTMOBJECTS..

XCPHPING Sample JCL to assemble and link SYGWXCPH.



APIXITCA API exit communications area for RADAEX1.

LECMDEXT LECMD copybook for sample user exit (RADAEX1).

SYGWDRIV Assembler macro required for XCPHPING macro. Do not update.

SYGWHOST Assembler macro required for XCPHPING macro. Do not update.

SYGWMCST Assembler macro required for XCPHPING macro. Do not update.

SYGWMCXL Assembler macro required for XCPHPING macro. Do not update.

SYGW1 Assembler macro required for XCPHPING macro. Do not update.



APPENDIX C Replication Agent Data Sets


PDR.PARMLIB contentsUse the PDR, PLANS00, and SETUP00 members of the hlq.PDR.PARMLIB data set to edit Replication Extract configuration parameters.


The following table shows the contents of the hlq.PDR.PARMLIB data set.

Table C-5: PDR.PARMLIB library contents

RA.LINKLIB contentsThe hlq.LINKLIB contains all of the executable modules for Replication Agent for DB2 UDB for OS/390 version 12.5.

LTMLOCThe hlq.LTMLOC file contains error messages in U.S. English that you can translate into the language used at the installation site.

SAS.LINKLIBThe hlq.SAS.LINKLIB data set contains the SAS/C link libraries. This is the runtime environment required for use with Replication Agent for DB2 UDB for OS/390 version 12.5.

Note The SAS/C runtime environment replaces the IBM C/370 runtime environment and PL/I libraries required in earlier versions of Replication Agent for DB2 UDB for OS/390.


PDR Log extract configuration options.

PLANS00 Log extract configuration options.

SETUP00 Log extract configuration options.



Additional data setsThe following table shows additional data sets installed with Replication Agent.

Table C-6: Additional data sets

Data set Contents

TRUNCPT Contains the origin queue ID of the last update successfully received by Replication Server.

LTMLOG Replication Agent messages and errors.

LTMLOG2 Replication Agent messages and errors.


A P P E N D I X D Upgrading Your Replication Agent Software

This appendix contains the following tasks and topics:

For assistance with restoring earlier versions of Replication Agent software, contact Sybase Technical Support.

Before you begin • Verify that you have successfully installed Replication Agent for DB2 UDB for OS/390 version 12.5.

• Make sure you have a completed Replication Agent Installation Worksheet in front of you as you work through this chapter.

See also • The Replication Agent for DB2 UDB Release Bulletin for OS/390

• “Replication Agent Installation Worksheet” in Chapter 4, “Gathering Installation Information”

• Chapter 5, “Installing Replication Agent”

Migrating to Replication Agent for DB2 UDB 12.5 software

Follow the procedure in this section when upgrading from Replication Agents earlier than Replication Agent for DB2 UDB for OS/390 version 12.5. Sybase recommends that you perform this procedure during a period of low activity.

Topic PageMigrating to Replication Agent for DB2 UDB 12.5 software 157

Additional migration considerations 160

Understanding the LTM Locator format 161

Migrating to Replication Agent for DB2 UDB 12.5 software


If you have not installed and used earlier versions of Replication Agent software before, do not use this procedure.

Warning! You must perform the tasks contained in this section AFTER you complete your installation of Replication Agent for DB2 UDB for OS/390 version 12.5 but BEFORE you start Replication Agent in your production environment.

❖ To upgrade Replication Agent software to version 12.5

1 To prevent updates to the DB2 primary tables, use the following syntax:

START DATABASE (database_name) SPACENAM (space_name) ACCESS (RO)

2 Allow the currently installed Replication Agent to process to the end of the log.

To determine whether processing has reached the end of the log, issue the XSTATUS command from the MVS operator console. This command displays Replication Extract’s current hlq.PDR.PARMLIB parameter values.

Use the following information to evaluate the values of the following parameters:

• HI extracted RBA. The relative byte address (RBA) of the last DB2 log record processed by Replication Extract. It uniquely identifies the position at which Replication Extract is processing the DB2 log.

• DB2 HI written RBA. The RBA of the last record that DB2 wrote to the log. Compare this value with the high-extracted RBA to determine where Replication Extract is in relationship to the end of the DB2 log.

3 Stop the currently installed Replication Agent using the instructions in the Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390.

4 Shut down Replication Server.

5 On the Adaptive Server containing the RSSD for the primary Replication Server, issue the rs_zeroltm stored procedure using the following syntax:

rs_zeroltm RS_source_ds,RS_source_db

where the values for RS_source_ds and RS_source_db match the values you recorded in sections 8e and 8f of the Replication Agent Installation Worksheet.

APPENDIX D Upgrading Your Replication Agent Software


6 Use ISPF to edit the hlq.TRUNCPT data set. Edit columns 1 through 36 to contain only binary zeros.

7 Review the configuration parameter values from the version of Replication Agent that you used most recently.

a Change the values of the parameters in the Replication Agent for DB2 UDB for OS/390 version 12.5 configuration file, located in the LTMCNFG member of the hlq.JCL library, to match the values you used in the most recent version of Replication Agent.

b Change the values of the Replication Extract configuration parameters, located in the SETUP00, PDR, and PLANS00 members in the hlq.PDR.PARMLIB data set, to match the values you used in the most recent version of Replication Agent.


c Increase the value of the GENID parameter by 1 in the PDR member of the hlq.PDR.PARMLIB data set to prevent QID sequence errors. (See “GENID” on page 145 for details about this parameter.)

8 Start Replication Server.

9 Start the 12.5 version of Replication Agent using the instructions in the Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390.

10 Resume updates to the primary tables on DB2.

You can use the following example syntax:

START DATABASE (database_name) SPACENAM (space_name) ACCESS (RW)

This command restores read and write access to the DB2 database.

Replication Agent begins processing the log at the point where it stopped processing.

See also • “Replication Agent Installation Worksheet” in Chapter 4, “Gathering Installation Information”

• Appendix B, “Replication Extract Configuration Parameters” for information about editing the PDR member

• Replication Server Commands Reference for information about the rs_zeroltm stored procedure

Additional migration considerations


Additional migration considerationsThis section addresses the following considerations that can affect migration from earlier versions of Replication Agent:

• New LTI version

• FLOAT data rounding change

New LTI versionReplication Agent for DB2 UDB 12.5 for OS/390 supports extensible limits through use of the new Long_varchar configuration parameter for replication to Replication Server 12.5. If you attempt to replicate to a Replication Server 12.0 or earlier using Long_varchar=Y, you might receive the following LTM for MVS error message:

01133: “Long_varchar forced to ‘N’ - Rep Server does not

support Long_varchar.”

❖ If you encounter this error message

1 On the Adaptive Server containing the primary Replication Server RSSD, execute the rs_del_locater stored procedure using the following example syntax:

rs_del_locater RS_source_ds, RS_source_db

where the values for RS_source_ds and RS_source_db match the values you recorded on the Replication Agent Installation Worksheet.

The rs_del_locater stored procedure deletes some rows from the rs_locater table for the specified database connection. For more information on this and other stored procedures, see the Replication Server Reference Manual.

2 Reboot your Replication Server.

FLOAT data rounding changeIn all versions of Replication Agent for DB2 UDB for OS/390, a precision of only 15 digits is guaranteed for FLOAT data. In Replication Agent for DB2 UDB for OS/390 version 12.5, the rounding of double-precision FLOAT data beyond the 15th decimal place differs slightly from the rounding of this data in Replication Agent for DB2 UDB for OS/390 version 11.2 and earlier.

APPENDIX D Upgrading Your Replication Agent Software


Understanding the LTM Locator formatThe LTM Locator is the origin queue ID (QID) of the most recent transaction operation that Replication Server successfully saved in its inbound queue.

Replication Server provides the LTM Locator to Replication Agent when Replication Agent issues a get truncation command to Replication Server.

Replication Agent issues a get truncation command to update its LTM Locator value during the following events:

• Start-up

• Recovery processing

• When the number of messages sent to the Replication API for processing exceeds the number of messages specified in the value of the API_QID_request_interval configuration parameter

• When Replication Extract requests that LTM for MVS obtain a new LTM Locator value

Replication Agent maintains a copy of the LTM Locator in the data set pointed to by the LTMTRUNC DD name in the Replication Agent execution JCL.

Replication Agent LTM Locator formatsUse the tables in this section to verify that your LTM Locator format is correct after you upgrade to Replication Agent for DB2 UDB for OS/390 version 12.5.

Following is an example of the QID received from Replication Server upon start-up:

0001B0C79D60B86600000001B0C79D60B2B30001000010C8AC0C00

Table D-1 shows the format of the LTM Locator in the current version of Replication Agent.

Understanding the LTM Locator format


Table D-1: LTM Locator format in current version of Replication Agent

See also • Appendix A, “LTM for MVS Configuration Parameters” for more information about the API_QID_request_interval parameter

Length (bytes) Field description

2 Database generation ID

6 • RBA or LRSN of the current non-utility transaction

• RBA or LRSN of the beginning of the next transaction in a utility operation

2 • Counter in a data-sharing environment (used to avoid duplication in the sysplex)

• Counter for utility transactions

• Hexadecimal zeros (x’00’) any other time

2 • Member identifier used in a data-sharing environment


6 URID* of the oldest open operation

2 • Member identifier associated with the oldest open operation in a data-sharing environment


6 URID* identifying the beginning of the current operation

1 Type of record:

• (x’00’) operation control record

• (x’01’) insert, update, or delete transaction

• (x’02’) set truncation point

• (x’11’) insert, update, or delete compensation transaction

9 Reserved for future use

*The URID is an RBA value. See the Glossary for a definition.


A P P E N D I X E Running Multiple Replication Agents

This chapter describes how to run multiple Replication Agents in your replication system.

Running multiple Log Transfer ManagersYou can run multiple LTM for MVS instances in your replication system to obtain the following:

• Improved performance of your replication system if you are replicating large volumes of transaction information

• Access to multiple DB2 subsystems

• Access to multiple DB2 data-sharing groups

For each LTM for MVS instance in your replication system, you must have uniquely named versions of some, but not all, data sets. The following tables shows which data sets must be unique, and which can be unique or shared:

Running multiple Log Transfer Managers


Table E-1: Unique data sets required for each LTM for MVS

Table E-2: Data sets required for each LTM for MVS, shared or unique

JCLLIB (LTMCNFG)The following parameters in the LTMCNFG data set should be reviewed:

• RS

• RS_user

• RS_pw

• RSSD_database

• RSSD_user

• RSSD_pw

• RS_source_ds

• RS_source_db

• log_identifier

• creator

Data set description Data set name

LTM for MVS configuration data set

hlq.JCL(LTMCNFG)

Truncation point data set hlq.ssid.TRUNCPT

RA message data set hlq.ssid.LTMLOG

RA message data set hlq.ssidLTMLOG2

Data set description Data set name

RA DB2 load library hlq.RA.LINKLIB

Replication extract parameter library

hlq.PDR.PARMLIB

Contains the SAS/C link libraries

hlq.SAS.LINKLIB

DB2 table specifying which tables to replicate

creator.LTMOBJECTS

APPENDIX E Running Multiple Replication Agents


See Task 1: Verify the LTM for MVS configuration file in Chapter 8, “Completing and Verifying Your Replication Agent Installation” and Appendix A, “LTM for MVS Configuration Parameters” for more information about LTMCNFG parameters.

PDR.PARMLIBSee Task 1: Edit the PARMLIB library members in Chapter 6, “Configuring Replication Extract” and Appendix B, “Replication Extract Configuration Parameters” for more information about PDR.PARMLIB parameters.

SETUP00

The parameter ssid and DB2 library names in the SETUP00 member should be reviewed.

See Task 1b: Edit the SETUP00 member in Chapter 8, “Completing and Verifying Your Replication Agent Installation” for more information about SETUP00 parameters.

PLANS00

The parameter PDRPLN01 in the PLANS00 member should be reviewed.

See Task 1a: Edit the PLANS00 member in Chapter 8, “Completing and Verifying Your Replication Agent Installation” for more information about PLANS00 parameters.

PDR

The parameter LOGCOPY2 in the PDR member should be reviewed.

See Task 1c: Edit the PDR member in Chapter 8, “Completing and Verifying Your Replication Agent Installation” for more information about PDR parameters.

RA.LINKLIBThe member SYGWXCPH in the hlq.RA.LINKLIB data set can be changed. SYGWXCPH contains entries for Replication Server and ASE. You can use a single SYGWXCPH for multiple RA DB2s.

Running multiple Log Transfer Managers


See Chapter 7, “Configuring TCP/IP for Replication Agent” for more information about hlq.RA.LINKLIB parameters.

creator.LTMOBJECTSIn DB2, the table LTMOBJECTS contains the specifications for all the tables to be replicated by a RA DB2. You can use the same creator.LTMOBJECTS for multiple RA DB2s if the replication specification is the same. If the specification differs, create another LTMOBJECTS with a different DB2 owner, and specify the new owner in the creator parameter in the hlq.JCL (LTMCNFG). The DB2 table must be named LTMOBJECTS.

See Task 7: Create the Replication Agent system tables and Task 9: Install the Replication Agent interface in Chapter 5, “Installing Replication Agent” of this guide and “Marking tables for replication” in Chapter 4, “Replicating source tables” of the Replication Agent for DB2 UDB User’s and Troubleshooting Guide for OS/390 for more information about creator.LTMOBJECTS parameters.

167

Glossary

This glossary includes terms and definitions either used or paraphrased from the following sources:

• The IBM Dictionary of Computing

• The American National Dictionary for Information Systems

• The Information Technology Vocabulary, developed by Subcommittee 1, Joint Technical Committee 1, of the International Organization for Standardization and the International Electrotechnical Commission (ISO/IEC JTC1/SC1). Sybase also used definitions from draft international standards, committee drafts, and working papers being developed by ISO/IEC JTC1/SC1.

This glossary uses the following references are used:

• Contrast with refers to a term that has an opposite or different meaning.

• Compare with refers to a term that has a similar meaning.

• See also refers to terms that have a related meaning.

Words containing these references are highlighted.

active log The part of the DB2 log where log records are written as they are generated. The active log always contains the most recent log records. The archive log holds older records that no longer fit on the active log. See also Database 2. Contrast with archive log.

Adaptive Server Enterprise

The server in the Sybase Client-Server architecture. It manages multiple databases and multiple users, tracks the actual location of data on disks, maintains mapping of logical data description to physical data storage, and maintains data and procedure caches in memory.

address An identifying number (often hexadecimal or binary) that describes a location in computer memory where information is stored.

after image The complete contents of a row after an update or insert. See also image. Contrast with before image.

Glossary

168

APF See authorized program facility.

API See application program interface.

application program interface (API)

A predefined functional interface, supplied by an operating system or other licensed program, that allows an application program written in a high-level language to use specific data or functions of the operating system or the licensed program.

Replication Agent for DB2 UDB for OS/390 includes the Replication API, an open API to which application developers can write Replication Extract programs. See also Log Transfer Manager for MVS, Replication API, and Replication Extract.

archive log The part of the DB2 log that contains log records that no longer fit in the active log. See also Database 2. Contrast with active log.

ASE See Adaptive Server Enterprise.

atomic materialization

The process of populating a replicate database using Replication Server commands that prevents client applications from executing transactions against the primary database while the subscription data is unloaded.

authorization The process of granting a user either complete or restricted permission to access an object, resource, or function.

authorized program facility (APF)

A facility that recognizes the programs authorized to use restricted functions.

automatic materialization

The process of populating a replicate database using Replication Server commands. After the replicate database is populated with a copy of the primary data, this command automatically activates your transaction replication subscriptions. Replication Server supports automatic materialization only from primary databases to which it has a connection (through a gateway, if necessary) and that can process SQL.

BCP See bulk copy transfer.

before image The complete contents of a row before an update or delete. See also image. Contrast with after image.

bootstrap data set (BSDS)

A VSAM data set that contains name and status information for DB2 and RBA range specifications for all active and archive log data sets. See also relative byte address and Virtual Storage Access Method.

BSAM Basic Sequence Access Method.

BSDS See bootstrap data set.

Glossary

169

bulk copy transfer (BCP)

A transfer method wherein multiple rows of data are inserted into a table in the target database.

bulk materialization A method of initializing subscription data outside the replication system. This is also a process of populating replicate transactions into a remote database management system before receiving distribution of changes from the Replication Server. See also materialization and Replication Server.

CCSID Coded Character Set Identifier.

CICS See Customer Information Control System.

Client-Library A library of routines that is part of Open ClientConnect. Open ClientConnect’s Client-Library comprises a subset of the Open ClientConnect Client-Library routines.

commit An instruction to DB2 to make permanent the changes requested in a transaction. See also transaction. Contrast with rollback.

compensatory operation

A transaction operation used to negate the effects of another operation with a lower origin queue ID in the same transaction. Replication Server reconciles compensatory operations and their counterparts so that neither are applied in the replicate database. See also origin queue ID.

configure To define to a system the devices, optional features, and programs installed on the system.

connectivity The capability to attach a variety of functional units without modifying them.

Customer Information Control System (CICS)

An IBM product that provides an environment for building, using, processing, and maintaining databases in the MVS and VSE environments for online transaction processing (OLTP). See also online transaction processing.

database A set of related data tables and other database objects that are organized and presented to serve a specific purpose.

database management system (DBMS)

A computer-based system for defining, creating, manipulating, controlling, managing, and using databases. The software for using a database can be part of the database management system, or it can be a stand-alone database system. Contrast with relational database management system.

Database 2 (DB2) A relational database management system for the IBM MVS operating system. See also Multiple Virtual System.

data definition name (DD name)

The name of a JCL DD statement (also called “file name”) that identifies one or more input/output data sets. See also data definition statement.

Glossary

170

data definition statement (DD statement)

A statement required in an MVS job to describe an input or output file and associated data sets. See also job control language.

data distribution The process of partitioning data to more than one location. Data distribution is distinct from data replication. Distributed data is partitioned among different sites in the distributed system as a single image and is not necessarily replicated data. See also data replication.

Data Facility Product (DFP)

A program that isolates applications from storage devices, storage management, and storage device hierarchy management.

data replication The process of copying data to remote locations. The copied (replicated) data is then kept synchronized with the primary data. Data replication is distinct from data distribution. Replicated data is stored copies of data in particular sites throughout a system and is not necessarily distributed data. See also data distribution and transaction replication.

data server A database management system program that responds to client requests. See also local area network.

data server interface (DSI)

A thread from Replication Server into the replicate database used to transfer messages from Replication Server to the replicate data server.

datatype A keyword that identifies the characteristics of stored information on a computer. Some common datatypes are char, int, smallint, date, time, numeric, and float. Different databases support different datatypes.

Data Warehousing The process of turning the data contained in operational systems into data that can be used by analysts and management to make business decisions. This typically involves:

• Moving the data to new servers, both to avoid overloading operational systems with analysis queries and to take advantage of database engines more efficient for decision support

• Transforming, summarizing, and reconciling the data gathered from disparate operational systems into formats more suitable to decision support

DB2 See Database 2.

DBMS See database management system.

DD name See data definition name.

DD statement See data definition statement.

Glossary

171

decision support application

A database application characterized by ad hoc queries, reports, calculations, and few data-update transactions.

Decision Support System (DSS)

In contrast to online transaction processing (OLTP), processing that is characterized by fewer, more complex, longer-running transactions from fewer users. Transactions are typically queries only and may reference data from many tables. Database systems designed and tuned for DSS are commonly used to hold Data Warehouse data gathered from operational systems. Contrast with online transaction processing.

default The value, option, or behavior used when a property is not explicitly specified.

DFP See Data Facility Product.

DirectConnect A Sybase Open Server application that provides access management for non-Sybase databases, copy management (transfer), and remote systems management. Each DirectConnect consists of a server and one or more service libraries to provide access to a specific data source. DirectConnect replaces the products “MDI Database Gateway” and “OmniSQL Access Module.” Contrast with EnterpriseConnect.

DLL See dynamic link library.

DSI See data server interface.

DSI thread An outbound queue connection to the target or replicate database.

DSNTIAD A DB2 sample program written in Assembler language that uses dynamic SQL. DSNTIAD is used to issue all SQL statements except SELECT in batch mode.

DSNTEP2 A DB2 sample program written in PL/I. It runs SQL statements in batch mode.

DSS See Decision Support System.

dynamic link library (DLL)

A file containing executable code and data bound to a program at load time or runtime, rather than during linking. The code and data in a dynamic link library can be shared by several applications simultaneously.

exception channel program (EXCP)

A program that allows direct reading of disk and tape files.

EXCP See exception channel program.

file transfer protocol (FTP)

A TCP/IP utility that moves files efficiently between machines.

FTP See file transfer protocol.

Glossary

172

function A unit of functional capability expressed by an individual command in an application program interface. See also application program interface.

gateway Connectivity software that allows communication between two or more computer systems with different network architectures.

group attach name The name of the DB2 data-sharing group.

guaranteed transaction delivery

A LTM for MVS subsystem that ensures the transactions entered into the replication system are properly distributed, even following an interruption caused by the failure of one or more replication system components. See also Replication Agent for DB2 UDB for OS/390.

IEBCOPY An IBM MVS system utility that performs copy operations including backup copying, unloading, reloading, and compressing partitioned data sets; and merging partitioned data sets to create new partitioned data sets. See also Multiple Virtual Storage.

image The complete contents of a row at a particular time. See also after image and before image.

index A set of pointers that are logically ordered by the values of a key. Indexes are used to provide rapid access to data and can enforce uniqueness on the rows in a table.

initial program load (IPL)

A process for loading system programs and preparing a system to run jobs.

Interactive System Productivity Facility (ISPF)

An IBM licensed program that serves as a full-screen editor and dialog manager. Used for writing application programs, ISPF provides a means of generating standard screen panels and interactive dialogues between the application programmer and terminal user.

interfaces file A file containing information that Sybase Open Server/Open ClientConnect applications (including Replication Server and Adaptive Server) use to establish TCP/IP connections to other Open Server/Open ClientConnect applications. Sybase interfaces file names differ across platforms: interfaces for UNIX platforms, sql.ini for Windows NT, and win.ini for Windows. See also SYGWHOST macro and TCP/IP.

IP address The internet protocol address at which TCP/IP expects to find the defined device. See also TCP/IP.

IPL See initial program load.

ISPF See Interactive System Productivity Facility.

Glossary

173

isql An interactive SQL client application to Sybase Adaptive Server.

JCL See job control language.

job A collection of related programs, identified by appropriate job control statements.

job control language (JCL)

In MVS, a control language used to identify a job and describe its requirements to an operating system. See also Multiple Virtual Storage.

K (kilobyte) A measurement of storage equal to 1024 bytes (210).

local area network (LAN)

A computer network located on the user’s premises and covering a limited geographical area. Communication within a local area network is not subject to external regulations; however, communication across the LAN boundary can be subject to some form of regulation.

LE Command structure

The definition of memory allocation and usage for areas containing the commands and data passed from the Replication Extract to the Replication API. See also Replication API and Replication Extract.

log A written record of operations performed, normally used for recovery. See also active log, archive log, or transaction log.

log extract A subset of Replication Agent for DB2 UDB for OS/390 that interacts with data sources to replicate logged transactions marked for replication. Replication Extract is the log extract supplied with Replication Agent for DB2 UDB for OS/390. Replication Extract uses the Replication Application Program Interface (API) to convey the transactions to the Log Transfer Interface (LTI), which transforms them into Log Transfer Language (LTL) and sends them to a Replication Server. Replication Server then replicates the data changes to replicate databases. See also Log Transfer Interface, Log Transfer Language, Log Transfer Manager for MVS, Replication API, and Replication Server.

logical unit 6.2 (LU 6.2)

An IBM communications protocol that allows mainframe and non-mainframe computers to communicate on a peer-to-peer basis.

LOGMODE A keyword in the VTAM mode table that specifies the logon mode name needed for dependent LUs to request VTAM sessions. See also logon mode and Virtual Telecommunications Access Method.

logon mode Contains the parameters and protocols that determine a session’s characteristics. Logon modes are defined in SYS1.VTAMLIB, VTAM’s mode table. See also Virtual Telecommunications Access Method.

Glossary

174

log record sequence number (LRSN)

A 6-byte value that DB2 generates and associates with each log record. The LRSN is contained in the DB2 log record header and tablespace header page. The LRSN replaces the RBA in a data-sharing environment, although each member continues to use the RBA for its own logs and BSDS. A number that DB2 generates and associates with each log record. DB2 also uses the LRSN for page versioning. The LRSNs generated by a given DB2 data-sharing group form a strictly increasing sequence for each DB2 log and a strictly increasing sequence for each page across the DB2 group. See also relative byte address.

Log Transfer Interface (LTI)

A component of the Log Transfer Manager that provides the session between any MVS-based Log Transfer Manager for MVS and a Replication Server. The LTI receives MVS data changes in Sybase Adaptive Server datatype values and transforms the changes into Log Transfer Language transactions, which are then sent to the Replication Server. See also Log Transfer Language, Log Transfer Manager for MVS, and Replication Server.

Log Transfer Language (LTL)

The subset of the Replication Command Language that Log Transfer Manager for MVS uses for submitting the information retrieved from the primary database transaction logs to Replication Server. See also primary database, Replication Agent for DB2 UDB for OS/390, Replication Server, and transaction log.

Log Transfer Manager (LTM)

An application that communicates updates made at a primary data server to Replication Server. Examples include the Log Transfer Manager for Sybase Adaptive Server, and Replication Agent for DB2 UDB for OS/390, which consists of Sybase’s LTM for MVS and Replication Extract. See also Database 2, LTM, Replication Agent for DB2 UDB for OS/390, Replication Extract, and Replication Server.

Log Transfer Manager for MVS (LTM for MVS)

Log Transfer Manager for MVS is an application that communicates transactions identified by a Replication Extract to Replication Server. See also Replication Agent for DB2 UDB for OS/390, Replication Extract, and Replication Server.

LTI See Log Transfer Interface.

LTL See Log Transfer Language.

LTM See Log Transfer Manager.

LTM for MVS See Log Transfer Manager for MVS.

Glossary

175

LTM for MVS configuration file

A file that contains the configuration parameters needed to operate LTM for MVS. A sample file is shipped in the hlq.JCL data set as the LTMCNFG member. See also Log Transfer Manager for MVS.

LTM Locator An origin queue ID that identifies the last transaction operation successfully saved in Replication Server’s inbound queue. Replication Extract uses the LTM Locator to identify the location in the log to begin scanning during start-up and restart. See also origin queue ID and Replication Extract.

LTMOBJECTS table See replication registration table.

LU6.2 See logical unit 6.2.

mainframe An IBM or IBM-compatible computer that conforms to the System/370 or System/390 architecture and supports MVS. Sometimes referred to as a host. See also Multiple Virtual Storage.

maintenance user ID An identifier defined in the replicate database that is used by Replication Server to identify the Replication Server maintenance user. See also Replication Server.

materialization The method or process by which data is placed into a replicate table in preparation for replication. See also replicate table.

module A program unit that is discrete and identifiable with respect to compiling, combining with other units, and loading; for example, the input to or output from an assembler, compiler, linkage editor, or executive routine.

Multiple Virtual Storage (MVS)

An IBM operating system that runs on most IBM mainframes. MVS provides “kernel” services (paging, device I/O, dispatching, and so on) for the application programs and application subsystems that run on MVS.

MVS See Multiple Virtual Storage.

NCP See Network Control Program.

network A configuration of data processing devices and software connected for information exchange.

Network Control Program (NCP)

An IBM-licensed program that provides communication controller support for network operations.

nonatomic materialization

The process of populating a replicate database using Replication Server commands that allows client applications to execute transactions against the primary database while the subscription data is unloaded.

OLTP See online transaction processing.

Glossary

176

online transaction processing (OLTP)

A system that is characterized by many small, simple, short-duration transactions from many users. These transactions tend to be oriented toward data manipulation (insert, update, delete), and to only reference one or a few tables.

Open ClientConnect application

An application written using Sybase Open ClientConnect libraries.

Open ClientConnect A Sybase product that provides customer applications, third-party products, and other Sybase products with the interfaces required to communicate with Open ClientConnect and Open ServerConnect applications. Open ClientConnect allows Open Client-style communication between DB2 and Replication Server.

Open Client/Server Architecture

The combination of Open ClientConnect and Open ServerConnect, which provide the connectivity backbone for Sybase’s distributed client-server architecture.

Open Server A Sybase product that provides the tools and interfaces required to create a custom server. Clients can route requests to DirectConnect through an Open Server that they configured to meet specific needs, such as the preprocessing of SQL statements or decision making about routing RPCs to Transaction Router Service for DB2 or to other servers.

Open Server application

A custom server built with Sybase Open Server.

operating system A group of programs that translates commands to the computer, helping to perform such tasks as creating files, running programs, and printing documents.

origin queue ID An identifier built by Replication Extract that uniquely identifies each transaction operation transmitted to Log Transfer Manager (LTM) for MVS. Replication Server maintains the origin queue ID of the last update that was successfully stored in the Replication Server stable queue during a given connection. LTM for MVS requests this identifier from Replication Server upon start-up and restart. See also Log Transfer Manager for MVS, LTM Locator, Replication Agent for DB2 UDB for OS/390, Replication Extract, and Replication Server.

packer routine A routine that converts a primary database log record into a LTL record, which is then sent to Replication Server. See also Log Transfer Language and Replication Server.

parallel sessions Multiple sessions running simultaneously between two LUs across a single LU 6.2 conversation. See also session.

Glossary

177

permission The level of access to an object, resource, or function.

ping A method used to create a connection to determine the availability of a process or data source.

ping interval The period of time between pings. See also ping.

primary data The version of a set of data in a replicated data system from which replication occurs. With Replication Agent for DB2 UDB for OS/390, primary data is stored in DB2. See also Database 2, Replication Agent for DB2 UDB for OS/390, and Replication Server.

primary database The database that contains the transactions to be replicated or processed. See also primary data.

primary table A DB2 table used as a source for replication or processing. See also Database 2, primary data, and primary database.

program temporary fix (PTF)

A temporary solution or by-pass of a problem to resolve a defect in a current unaltered release of a program.

protocol A set of standards that govern the behavior of computers communicating on a network.

PTF See program temporary fix.

QID See queue ID.

queue A list constructed and maintained so that the next data element to be retrieved is the one stored first.

queue ID (QID) The DB2 relative byte address of the log record associated with the insert, update, or delete that Replication Agent for DB2 UDB for OS/390 sends to Replication Server. Replication Server maintains the QID of the last update that was successfully stored in the Replication Server stable queue for this connection. Requesting this QID is part of the initial conversation that occurs between Replication Agent for DB2 UDB for OS/390 and Replication Server (analogous to the get truncation point in Log Transfer Manager for Sybase Adaptive Server). See relative byte address.

RACF See Resource Access Control Facility.

RBA See relative byte address.

RCB See receive event control block.

RCL See Replication Command Language.

Glossary

178

RDBMS See relational database management system.

receive event control block (receive ECB)

The event control block passed to the Replication Extract at start-up that, when posted, indicates that there are messages for the Replication Extract. The Replication Extract can obtain the messages using the Replication API’s LTMSEND function call. See also Replication API and Replication Extract.

record A set of one or more related data items grouped for processing.

recovery The process of rebuilding one or more databases from database dumps or log dumps.

relational database A collection of data in which relationships between data items are explicitly specified as equally accessible attributes. The data is viewed as being stored in tables consisting of columns (data items) and rows (units of information). Relational databases can be accessed by SQL requests. See also Structured Query Language.

relational database management system (RDBMS)

The application that controls relational databases. See also relational database. Contrast with database management system.

relative byte address (RBA)

The address of a byte in the DB2 log. The address is the byte’s offset from the beginning of the log.

replicate database The database to which Replication Server is replicating transactions. There can be more than one replicate database for each Replication Server. See also primary database and Replication Server.

replicate table A database management system table maintained by Replication Server. See also Replication Server.

replicate transactions

Information copied from a primary database using Replication Server and stored in a replicate table. See also replicate table and Replication Server.

replicated data system

A data-processing system in which data is replicated in multiple databases to provide remote users with the benefit of local data access.

replication See transaction replication.

Replication Agent See Replication Agent for DB2 UDB for OS/390.

Replication Agent for DB2 UDB for OS/390

The Sybase application consisting of LTM for MVS and Replication Extract. Replication Agent for DB2 UDB for OS/390 allows the replication of transactions from a primary database to replicate databases through Sybase’s Replication Server. See also Log Transfer Manager for MVS, Replication Extract, and Replication Server.

Glossary

179

Replication API An interface for LTM for MVS used by Replication Extracts to communicate transactions to Sybase’s replication system. See also application program interface, Log Transfer Manager for MVS, and Replication Extract.

Replication Command Language (RCL)

The command language used with Replication Server.

replication definition A description of a table for which subscriptions can be created. The definition, maintained by Replication Server, includes information about the columns in the table, the location of the primary version of the table, and some options that specify how the table can be used. See also Replication Server and subscription.

Replication Extract A log extract that is a component of Replication Agent for DB2 UDB for OS/390. Replication Extract interacts with primary data servers to capture updates of transactions marked for replication. See also log extract and Replication Agent for DB2 UDB for OS/390.

replication registration table

A DB2 table named LTMOBJECTS that controls the replication of DB2 data and each row of which identifies a primary DB2 table that has been registered by the user. See also Database 2.

Replication Server A Sybase Open Server application that maintains replicate transactions received from a data source, which can be either the source data server or another Replication Server. See also Adaptive Server Enterprise.

Replication Server Interface (RSI)

A thread from a primary Replication Server into a replicate Replication Server used to transfer commands from the RSI outbound stable queue to the replicate Replication Server. There is one RSI thread for each replicate Replication Server that is a recipient of commands from the primary Replication Server. See also Replication Server and stable queue.

Replication Server System Database (RSSD)

The system database in which Replication Server stores its system information. The tables reside in a Sybase Adaptive Server database. See also Database 2, Replication Server, and Adaptive Server Enterprise.

Replication Toolkit A programming guide for the Replication API and sample log extract programs to allow a customer or third-party vendor to develop a Log Extract program that interfaces with the Log Transfer Manager.

request One or more database operations the application sends as one unit to the database. During a request, the application gives up control to the DBMS and waits for its response. Depending on the response, the application commits or rolls back the request. One or more requests can be grouped into a single unit of work.

Glossary

180

resource Any facility of a computing system or operating system required by a job or task, including main storage, input/output devices, processing unit, data sets, and control or processing programs.

Resource Access Control Facility (RACF)

A security package for IBM mainframes.

rollback A transaction operation instructing the DBMS to ignore the changes requested in a transaction. See also transaction. Contrast with commit.

route A connection from a primary Replication Server to a replicate Replication Server. See also Replication Server.

RPL Request parameter list.

RSI See Replication Server interface.

RSSD See Replication Server System Database.

source The primary database or the database that contains the data to be replicated or processed.

SPUFI See SQL Processor Using File Input.

SQL See Structured Query Language.

sqledit A utility for creating and editing sql.ini files and file entries.

SQL Processor Using File Input (SPUFI)

A DB2 facility that enables users to execute SQL statements without embedding them in an application program.

SQL Server See Adaptive Server Enterprise.

SSID See subsystem identifier.

stable queue A store-and-forward queue in which Replication Server messages destined for a route or database connection are stored. Messages written into the stable queue remain there until they can be delivered to the replicate Replication Server or replicate database. See also Replication Server.

statement In programming languages, a language construct that represents a step in a sequence of actions or a set of declarations.

storage group A named set of direct access storage device (DASD) volumes. DB2 data can be stored in storage groups. See also Database 2.

Glossary

181

Structured Query Language (SQL)

A language developed by IBM to process data in a relational database. SQL is an industry standard.

subscription A request for Replication Server to maintain either a replicated copy of a table or a set of rows from a table in a database at a specified site. See also Replication Server.

subsystem In IBM MVS/CICS, a single instance of a relational database.

subsystem identifier (SSID)

The name of a DB2 subsystem.

SYGWHOST macro The SYGWHOST TYPE=ENTRY macro, distributed in the XCPHPING member of the hlq.JCL data set, serves as a directory containing network addresses and other information that controls how Replication Agent for DB2 UDB for OS/390 connects to other servers, and configures the Open ClientConnect component of LTM for MVS to use IBM TCP/IP for a TCP/IP connection between Replication Agent for DB2 UDB for OS/390 and Replication Server. The SYGWHOST TYPE=ENTRY macro can be a member of a Partitioned Data Set (PDS) or a sequential file.

The Replication Agent for DB2 UDB for OS/390 TCP/IP installation requires a SYGWHOST TYPE=ENTRY macro entry for each primary Replication Server in your replication system. You can define any number of Replication Server entries in the SYGWHOST macro.

The SYGWHOST TYPE=ENTRY macro replaces the interfaces file required in earlier versions of the Replication Agent for DB2 UDB for OS/390 software. See also interfaces file and TCP/IP.

synchronization The method that ensures primary and replicate tables are equivalent. For example, if transaction number 100 is successful in the primary database, the 100th transaction in the replicate database should also be successful.

systems management

The process of initiating, configuring, monitoring, and adjusting applications on a system.

sysplex A set of MVS systems communicating and cooperating with each other through certain multisystem hardware components and software services that protect customer workloads.

system administrator

The person at a computer installation who designs, controls, and manages the use of the computer system.

table In a relational database management system, a two-dimensional array of data or a named data object that contains a specific number of unordered rows composed of a grouping of columns specific for the table.

Glossary

182

tablespace In MVS, a page set that stores the records in one or more tables. See also MVS/CICS.

target The database receiving the replicate data in a replication environment. Also known as a destination.

task control block (TCB)

An MVS control block used to communicate information about tasks within an address space. There is one TCB per task in an address space. An address space can support one or more tasks, but any task may reside in only one address space. See also Database 2 and Multiple Virtual Storage.

TCB See task control block.

TCP/IP See Transmission Control Protocol/Internet Protocol.

trace The process of recording the sequence in which the statements in a program are executed and, optionally, the values of the program variables used in the statements.

transaction A group that can include zero, one, or many database transaction operations (including inserts, updates, and deletes) that are applied or rejected as a whole.

transactional consistency

A condition in which all transactions in the primary database are applied in the replicate database in the same order that they were applied in the primary database.

transaction log The log of transactions kept by a database server. Replication Extract reads these logs to identify the changes to primary databases. See also log extract, Replication Agent for DB2 UDB for OS/390, and Replication Extract.

transaction program A program that processes transactions. There are two kinds of transaction programs: application transaction programs and service transaction programs.

transaction replication

The process of copying transaction operations (updates, inserts, and deletes) to remote locations. The replicated transactions are then kept consistent with the primary transaction. See also data duplication and data replication.

Transact-SQL A Sybase Adaptive Server SQL extension that allows procedural programming within a DBMS to access and manipulate data. See also Adaptive Server Enterprise and Structured Query Language.

Transmission Control Protocol/Internet Protocol (TCP/IP)

A computer network communications protocol designed by the Department of Defense Advanced Research Projects Agency. Contrast with advanced program-to-program communications.

Glossary

183

truncation point The location in a DBMS transaction log that separates the part of the log verifiably received by Replication Server from the part that has not yet been verifiably received. In Adaptive Server, the transaction log entries that precede the truncation point have already entered the replication system, so that portion of the log can be safely truncated. See also database management system, LTM Locator, origin queue ID, Replication Server, Adaptive Server Enterprise, and transaction log.

UNIX An operating system developed by Bell Laboratories that allows multiple programs to run and multiple users to work concurrently.

URID See UR identifier.

UR identifier The log RBA of the beginning of a recovery unit. The UR identifier is the earliest relative byte address required to process the UR during restart. See also relative byte address.

user-defined function

A user-defined, custom-built, Replication Server function whose name and parameters exactly match the name and parameters of a replicated stored procedure.

user exit A user-written transaction program that can be given control at a determined point in a program.

In Replication Agent for DB2 UDB for OS/390, a program called by the Replication API’s LTMSEND function call to alter transaction operations before sending them to Replication Server. See also Replication API.

view An alternative representation of data from one or more tables. A view can include all or some of the columns in a table. Refer to Sybase Adaptive Server or IBM DB2 documentation for more information about Adaptive Server views. See also Database 2 and Adaptive Server Enterprise.

Virtual Storage Access Method (VSAM)

An IBM-licensed program that controls reading and writing data to and from a disk.

VSAM See Virtual Storage Access Method.

VTAM See Virtual Telecommunications Access Method.

WAN See wide area network.

wide area network (WAN)

A network that provides communication services to a geographic area larger than that served by a LAN. Contrast with local area network.

Glossary

184

Windows NT (Windows New Technology)

A multitasking operating system from Microsoft Corporation.

185

AActive log

data set 3description 4

Adaptive Serverinformation for Technical Support xvLTM configuration parameters 94name 125SYGWHOST macro 47, 137user 16, 32, 33, 38, 47, 126user password 125

Address spaceMVS 5

After imagecreated for inserts and updates 7

ALIAS entry 34ALTER TABLE DATA CAPTURE CHANGES

command 56API

Replication 7, 12API_com_test configuration parameter

description 96API_QID_request_interval

configuration parameter changes 99API_QID_request_interval configuration parameter

161APPC/MVS

testing connectivity with PINGRS 85Applications

OLTP 1Archive log

data set 3description 4

ARCHIVE PDR parameter 146ATTACH command 6Authority

connect source for Replication Server maintenance user ID 86

Authorization table

started task 59Authorizations. See Permissions 59

BBasic concepts

connectivity 14database logs 2log extracts 7Log Transfer Managers 7materialization 10replication in data sharing environment 17, 19role of Replication Agent for DB2 10transaction replication 1

Batch jobstarting LTM for MVS 86

batch_ltl_cmds configuration parameterdescription 99

Before imagecreated for deletes and updates 7

Begin recordsand DB2 4

Binary zeroand QID 6

Bindcondition codes 69DB2 operation 69JCL 63, 142PLATINUM plan 19, 40, 67Replication Extract plan 67sample JCL for PLATINUM plan 154

Bootstrap data set. See BSDS 3BSDS

in data sharing environment 17information recorded in 3reading active and archive log data sets 6

BUFFERS PDR parameter 147Bulk materialization

and connectivity 28

Index

Index

186

CCapacity

DB2 log 29Case

sensitivity in configuration file 79, 93Catalog

DB2 5MVS master 34

Changes to DB2 log 3CHAR datatype

and Date_in_char configuration parameter 105and replace_null_in_char configuration parameter 117and Timestamp_in_char configuration parameter 132

Char_conv_err_logconfiguration parameter changes 100obsolete configuration parameter 100

Character translationerrors 102, 121

CI_COUNT Replication Extract parameterdescription 145

ClausesDATA CAPTURE CHANGES. See DATA CAPTURE

CHANGES clause 143Codepage

DB2 usage 100Codepage configuration parameter

description 100editing the configuration file 78

CommandsALTER TABLE DATA CAPTURE 56ATTACH 6CONNECT 6CONNECT SOURCE LTI 85create connection 81, 83, 84, 122create user 82get maintenance user 9, 16get truncation 9, 99, 161grant connect source 83isql 83MONITOR2 57MORETRACE SOCKETS xvNETSTAT ALL xvPING xvPINGRS xv, 85START 5, 86TESTSITE xv

TRACE ALL xvtrace=1,11 134trace=1,23 134, 135trace=1,4 133TRACERTE xvXSTATUS 158

Commentsin configuration file 94in Replication Extract code 140

Communicationadministration 23configuring LTM for MVS 103

Communications_Protocol configuration parameterdescription 103editing the configuration file 78

Compensation recordssupport for DB2 128

Condition codesbind 69

ConfigurationReplication Server 80running multiple LTMs 164sample file 89, 153

Configuration filecase sensitivity 79, 93comments 94editing 78error 94recording information for worksheet 39

Configuration parameter changesAPI_QID_request_interval 99Char_conv_err_log 100

Configuration parametersAdaptive Server LTM 94API_com_test 96API_QID_request_interval 161batch_ltl_cmds 99Codepage 78, 100Communications_Protocol 78, 103Creator 40, 78Log_extractor 107Log_identifier 18, 78, 108, 109Long_varchar 109Low_activity_latency 110Ltl_table_col_case 110LTL_test_only 111

Index

187

LTM_admin_pw 112LTM_admin_user 112LTM_process_maint_uid_trans 9, 113Minimal_cols 114Minimum_year 115Numeric_conv_default 116optional 93Packet_size 116replace_null_in_char 117Replication Extract 139, 140, 141, 142required 93RS 37, 39, 48, 78, 118RS_ccsid 119RS_codepage 78RS_pw 48, 78, 82RS_source_db 40, 48, 78, 81, 121, 158RS_source_ds 39, 40, 78, 81, 122, 158RS_user 48, 78, 82RSSD_database 47, 78RSSD_pw 47, 78, 124RSSD_server 47, 78, 125RSSD_user 47, 78Stop_on_error 126Support_DB2_comp_rec 128Suppress_col_names 129Time_conv_default 130Time_in_char 131Timestamp_in_char 132trace=1,11 133trace=1,23 134trace=1,31 135trace=1,4 133Transaction_name 78understanding 94User_exit 138

Configuring Replication Extract 6, 139CONNECT command 6CONNECT SOURCE LTI command

failure 86testing the server connection 85

Connect source permissionReplication Server user ID 82

Connectioncreating to Replication Server 83

ConnectivityAPPC/MVS 85

information for Technical Support xvReplication Agent to Replication Server 15requirements 14TCP/IP errors 85

Considerationsperformance 100, 118

ConventionsReplication Extract parameters 139

Coordination, team skills 23Counter

in QID 162CP037 (United States/Canada) codepage 101create connection command

and RS_source_db configuration parameter 16, 32, 40, 42, 81, 121

and RS_source_ds configuration parameter 39, 81, 122

connecting to Replication Server 83reference to 84

create user command 82Creating

replication definitions 10Replication Server user ID 82

Creator configuration parameterediting the configuration file 78value 40

Current transactionbegin RBA 162LRSN 162RBA 162

DData

flow 11reading log 12

DATA CAPTURE CHANGES clauseand REPL_ERROR parameter 143DB2 log changes 3

Data setsactive log 3archive log 3PARMLIB 6TRUNCPT 6

Data sharing

Index

188

counter 162DB2 and Log_identifier parameter 40, 109DB2 and SSID parameter 140DB2 subsystem ID 35, 63editing the PDR member 66editing the SETUP member 64Log_identifier configuration parameter 109LTMADMIN user ID permission required 57member identifier 162replication environment concepts 17, 19

DatabaseDB2 requirement 28generation ID in QID 162logs 2

DatatypesCHAR 105, 117, 132DATE 105, 130TIME 104, 131TIMESTAMP 132VARCHAR 117

DATE datatypeand Date_in_char configuration parameter 105and Time_conv_default configuration parameter 130

DateTime_conv_err configuration parametereffect on Date_conv_default configuration parameter

104effect on the Time_conv_default configuration

parameter 130DB2

active logs 4archive logs 4codepage usage 100compensation records, delete 128data sharing and Log_identifier parameter 40, 109data sharing and SSID parameter 140data sharing requirement 57database requirement 28DBRMLIB name 36, 45DISPLAY GROUP command 66, 149DISPLAY permissions for LTMADMIN user 57group attach name in DB2 subsystem ID field 35group attach name in Log_identifier parameter 40, 48,

108, 109group attach name in SSID parameter 140high-extracted RBA 158high-written RBA 158

MONITOR2 commands 57PDR member parameters for data sharing 19processing flow 5Replication Agent system tables 54, 56, 67requirement 25SCCSID 100SETUP member parameters for data sharing 19subsystem ID 35, 63table size requirement 29TRACE permissions for LTMADMIN user 56utility plan name 35, 45

DB2 catalogprocessing flow 5retrieving table definitions 6tables 56

DB2 DBRMLIB library namerecording 35

DB2 logcapacity requirement 29changes 3

DB2 RUNLIB library nameobtaining 36recording 34

DB2 SDSNEXIT library name 34DB2 SDSNLOAD library name

obtaining 36recording 34

DB2 subsystem ID 35in PDRBIND member 40on Replication Agent Installation Worksheet 40recording 34

DB2 versionsbind condition codes 69versions 4.1 69

db2ssid valueDB2 subsystem name 34replicating transactions 40

DBRMLIBDB2 library name 35obtaining name for DB2 utility library 36, 45Replication Extract 68

Deactivateconfiguration parameters 93

Decision support queries 1Definitions, replication 10Delete compensation records 128

Index

189

Deletesin DB2 log 3

DISPLAYDB2 permission 57

DISPLAY GROUPDB2 command 66, 149

DOCS library 152Dynamic tracing 133, 134, 135

EEntry

ALIAS 34Errors

character translation 102, 121configuration 94correcting TCP/IP connectivity 85LTM for MVS configuration 80rs_sqlserver_error_class 84that shut down Replication Agent 128

Execution JCLmodifying Replication Agent 59RUNLTM member 60

FFailure and recovery

Replication Agent started task 59Features

running multiple Log Transfer Managers 163Files

configuration 89, 164LTLOUT 164LTMLOG 86, 87LTMTRUNC 112truncation point. See Truncation point file 164

FLOAT rounding changemigration considerations 160

Flow of data 11Format

current LTM Locator 161Functions

rs_sqlserver_function_class 84

GGeneration ID

in QID 162GENID PDR parameter

description 145, 146get maintenance user command 9, 16get truncation command 9, 99, 161Group attach name

DB2 35, 40, 48, 108, 109, 140

HHardware prerequisites 31High-extracted RBA

description 158High-level qualifier 34, 44High-written RBA 158HLQ 34, 44

IIBM C/370 run-time requirement

replaced by SAS/C 25IBM TCP/IP

Communications_Protocol configuration parameter value 103

IBMTCPADDRSPACEvariable in SYGWHOST macro 46

IDsLTMADMIN user 32, 55, 59maintenance user 81, 83, 84RS_user configuration parameter 82user 82

Informationrecording JCL 34recording Replication Extract 34translation by Replication API 12

Information for Technical SupportAdaptive Server xvMVS xivReplication Server xivTCP/IP xvtroubleshooting xv

Inserts

Index

190

in DB2 log 3Installation

completing the installation worksheet 31preparing 31, 48prerequisites for 71, 77recording configuration file information 39recording Replication Agent panel information 34recording TCP/IP configuration information 36, 38Replication Agent 49, 59

Installation requirements 23, 25communications administration skill set 23coordination skill set 23DB2 database 28DB2 log capacity 29DB2 table size 29log capacity 29MVS systems programming skill set 23team skills 23

Instancesrunning multiple LTM for MVS 33

Interfaces filereplaced by SYGWHOST macro 36Replication Server xiv

IPADDR variablein SYGWHOST macro for Adaptive Server 47in SYGWHOST macro for Replication Server 46

ISPFrequirement 25

ISPF library 152isql command 83

JJCL

execution 59, 60information 34PDRBIND member 19, 40

JCL library 153Job

batch 86

LLatency time 144

LibrariesDOCS 152ISPF 152JCL 153MACLIB 154PDR.PARMLIB 155recording DB2 DBRMLIB name 35SAS.LINKLIB 155

LibrariesLINKLIB 155LINKLIB library 155Load libraries

obtaining DB2 SDSNLOAD name 36recording DB2 SDSNEXIT name 34recording DB2 SDSNLOAD name 34

LOADLIBSSETUP member parameter 141

Locator, LTM. See LTM Locator 8Log Control Interval

and SET_TRUNC PDR parameter 147Log Extract

basic concepts 4Log record sequence number

description 18Log Transfer Interface

basic concepts 7delivering information 13

Log Transfer Languagebasic concepts 7data flow 13description 8

Log Transfer Managerbasic concepts 7description 7

Log_extractor configuration parameterdescription 107

Log_identifier configuration parameterdescription 108editing the configuration file 78replicating transactions 18, 109

LOGCOPY2 PDR parameter 147Logs

active 4archive 4capacity requirement 29changes to DB2 3database 2

Index

191

DB2 148DB2 active 4DB2 archive 4DB2 capacity 29DB2 changes 3processing from the end of the DB2 active log 6reading data 12requirements for replication 3

Long_varchar configuration parameterdescription 109

Low_activity_latency configuration parameterdescription 110

LRSNdescription 18in QID 162

LSTNPORT variablein SYGWHOST macro for Adaptive Server 47in SYGWHOST macro for Replication Server 46

LTI. See Log Transfer Interface 7LTL. See Log Transfer Language 7Ltl_table_col_case configuration parameter

description 110LTL_test_only configuration parameter

description 111LTLOUT file

running multiple LTMs 164LTM for MVS

configuration file errors 80editing the configuration file 78log file contents 79, 93PROC name 43processing flow 5running multiple instances 33, 163sample configuration file 153started task name 33, 43started task name and LTMPROC member 59starting 86startup PROC 59

LTM Locator 99and API_QID_request_interval configuration

parameter 98and origin queue ID 8, 9and QID 6and SET_TRUNC PDR parameter 147counter 162current format 161

database generation ID 162description 161LRSN 162member identifier 162RBA 162

LTM PROC name 43LTM. See Log Transfer Manager 7LTM.R1150.PDR.PARMLIBx09 file 155LTM_admin_pw configuration parameter

description 112LTM_admin_user configuration parameter

description 112LTM_process_maint_uid_trans configuration parameter

and the maintenance user ID 9description 113

LTMADMIN user 16and started task 59associating ID with started task 59granting permissions 55ID restrictions 48permissions 69recording ID 32Replication Agent system table creator 103restrictions 16

LTMADMIN user IDpermission for data sharing 57permissions 56permissions for binding and executing the

PLATINUM plan 55, 69permissions for managing Replication Agent system

tables 55selecting 32, 40

LTMCNFG memberediting 78testing server connections 85

LTMLOG file 86, 87LTMLOG1 file contents 79, 93LTMOBJECTS table

granting permissions 56Replication Extract queries 6SQL for updating 152

LTMPROC memberLTM for MVS started task 59

LTMTRUNC file 112LTMxxxxx

LTM for MVS started task name 59

Index

192

LTMxxxxx PROC 59

MMACLIB library 154Macros

SYGWHOST xiv, 73Mainframe interfaces file, replaced by SYGWHOST macro

36Maintenance password 81Maintenance user ID

and LTM for MVS processing flow 8create connection command 83, 84filtering transactions 113granting connect source authority 86Replication Server 16, 32, 42, 81

Master catalogMVS 34

Materializationbasic concepts 10bulk 28

max_messagesobsolete configuration parameter 113

Member identifierin QID 162

MembersLTMCNFG 85PARMLIB 6, 61PINGRS 85

Messageshandling 107

Migrationadditional considerations 160FLOAT rounding change 160

Minimal_cols configuration parameterdescription 114

Minimum_year configuration parameterdescription 115

MONITOR2 commandspermission 57

MORETRACE SOCKETS commandoutput xv

MSG value 144Multiple

LTM for MVS instances 163

LTM for MVS instances, running 33Multiple Replication Agent instances

and SSID parameter 140MVS

address space 5handling operator console messages 107information for Technical Support xivinterfaces file, replaced by SYGWHOST macro 36master catalog 34requirement 25SYGWHOST macro xivsystems programming team skills requirement 23

NNames

Adaptive Server 125DB2 utility plan 35, 45high-level qualifier 44LTM PROC 43PLATINUM plan 34PLATINUM plan restrictions 63

NETSTAT ALL command xvNumeric_conv_default configuration parameter

description 116

OObsolete configuration parameters

Char_conv_err_log 100max_messages 113

Oldest open transactionLRSN 162RBA 162

OLTP applications 1Online transaction processing applications 1Open Client

and Log Transfer Manager 7Operator commands

trace 133, 134, 135Origin queue ID. See QID 8Overview

replication system 2

Index

193

PPacket_size configuration parameter

description 116Panels

recording installation information 34Parameters

DB2 initialization 100library 61PARMLIB 158Replication Extract. See Replication Extract

configuration parameters 143PARMLIB member

description 61processing 6

PARMLIB parameter 158PARMLIBx09 member 155Passwords

Adaptive Server user 125maintenance 81

PDR member 155CI_COUNT parameter 145description 63GENID parameter 145parameters for data sharing 19POLL_INTVL parameter 144READER_NAME parameter 66, 148, 149READER_TYPE parameter 66, 148REPL_ERROR parameter 143sample contents 140, 142SET_TRUNC parameter 147

PDR.PARMLIB data set 19PDR.PARMLIB library 155PDR0110

changing default PLATINUM plan name 35permission failure 59

PDRBIND member 67JCL 19, 40sample JCL for binding the PLATINUM plan

154PDRPLANS parameter

in PLANS member 141Replication Extract parameter 142

Performance considerationsbatch_ltl_cmds configuration parameter 100retry configuration parameter 118

Permissions

binding and executing the PLATINUM plan 55, 69

connect source 82executing plan PDR0110 59granting connect source to Replication Server user

ID 82LTMADMIN user 55, 69LTMADMIN user and DB2 DISPLAY permissions

57LTMADMIN user and DB2 MONITOR2 commands

57LTMADMIN user and DB2 TRACE permissions

56LTMADMIN user ID 56managing Replication Agent system tables 55PDR0110 failure 59Replication Agent system tables on DB2 55required for data sharing 57select 56

PING commandinformation for Technical Support xv

PINGRS commandoutput xvtesting the server connection 85using 85

PINGRS member 85PL/I run-time requirement

replaced by SAS/C 25Plan

binding PLATINUM 67DB2 utility name 35, 45PLATINUM 19, 40PLATINUM name 34, 62PLATINUM name in PLANS member 141, 142PLATINUM name restrictions 63

PLANS memberdescription 155editing 62PDRPLANS parameter 141, 142sample contents 141

PLATINUMplan name 62

PLATINUM planbinding 19, 40, 67changing default plan name 35description 67

Index

194

name in PLANS member 142name restrictions 63permission failure 59permissions 59recording name 34sample JCL for binding 154

Preparingfor installation 31, 48

Prerequisitessoftware 31system hardware 31

PROC name, LTM for 43PROC name, LTM for MVS

on worksheet 43recording 33

Processingfrom the end of the DB2 active log 6

Protocolconfiguring LTM for MVS 103

QQID

and GENID parameter 146and LTM Locator 8, 9binary zeros 6counter 162current LTM Locator format 161database generation ID 162description 161LRSN 162LTM for MVS processing flow 8LTM Locator 6LTM Locator value 99member identifier 162RBA 162Replication Extract queries 6TRUNCPT data set 6

Qualifierhigh-level 34, 44

Queries, decision support 1Queue

stable 8

RRBAs

data-sharing environment 18high-extracted 158high-written 158in QID 162

READER_NAME parameterin PDR member 66, 148, 149

READER_TYPE parameterdata sharing 66in PDR member 66, 148

RecordingLTM for MVS started task name 33

Relative byte addresses. See RBAs 158REPL_ERROR PDR parameter

description 143value recommendation 144

replace_null_in_char configuration parameterdescription 117

Replicationand Replication Server 14basic concepts 10definitions and Replication Server 10system architecture 14transaction 1

Replication Agentconnectivity requirements 14creating system tables on DB2 54current LTM Locator format 161data flow 11differences from a generic replication system 10errors that cause shutdown 128installation 49, 59installation panel 34interface dialogs 3LTMADMIN user 16operational considerations 27, 28preparing to install 31, 48prerequisites for installation 71, 77restoring earlier versions 157role of 10started task 59startup procedure 59system tables 67understanding concepts 1, 15upgrading 60

Index

195

user interface and ALTER TABLE authority 58Replication Agent execution JCL

modifying 59RUNLTM member 60

Replication Agent system tablesLTMADMIN user ID permissions 55LTMOBJECTS 56permissions 55

Replication APIand Log Transfer Manager 7translating information 12

Replication definitionscreating 10troubleshooting 127

Replication Extractbasic concepts 4binding plan 67comments in code 140DBRMLIB 68member conventions 139parameters 155, 158processing flow 5reading log data 12recording information 34XSTATUS command 158

Replication Extract configuration parameters 139ARCHIVE 146BUFFERS 147CI_COUNT 145conventions 139GENID 145, 146in PDR member 142in PLANS member 141in SETUP member 140LOGCOPY2 147processing 6REPL_ERROR 143SET_TRUNC 147TRACE 147value recommendation for REPL_ERROR 144

Replication Serverconfiguring 80create connection command 16creating connection 83familiarization with 31information for Technical Support xiv

interfaces file xivmaintenance user ID 16, 32, 42, 81, 83, 84, 86replicating information 14rs_locater table 6SERVERNAME parameter 119SYGWHOST macro 46SYGWHOST macro entry 119TCP/IP connectivity 15user ID 82, 124user ID and RS_user configuration parameter 82

Replication Server commandscreate user 82grant connect source 83

Replication systembasic concepts 1overview 2

Required configuration parameters 93Requirements

DB2 versions 25installation 23, 25ISPF version 25MVS version 25run-time environments 25SAS/C run-time libraries 25

Restartand API_QID_request_interval configuration

parameter 99Restoring Replication Agent software 157Restrictions

LTMADMIN user ID 16PLATINUM plan name 63

RS configuration parameterand SERVER TCP/IP variable 39description 118editing the configuration file 78on worksheet 48recording 37recording the value 39

RS user ID 16RS_ccsid configuration parameter

description 119RS_codepage configuration parameter

editing the configuration file 78rs_locater, QID in Replication Server table 6RS_pw configuration parameter

and create user command 82

Index

196

editing the configuration file 78on worksheet 48

RS_source_db configuration parameterand create connection command 81and rs_zeroltm procedure 158description 121editing the configuration file 78on worksheet 48recording the value 121recording value 40Replication Server connection 81

RS_source_ds configuration parameter 39and create connection command 81and rs_zeroltm procedure 158description 122editing the configuration file 78recording 39recording the value 39Replication Server connection 81

rs_sqlserver_error_class error class 84rs_sqlserver_function_class function 84RS_user configuration parameter

and create user command 82and grant connect source command 82and RS user 16editing the configuration file 78on worksheet 48user ID specified in 48

rs_zeroltm stored procedure 158RSSD user ID 16RSSD_database configuration parameter

editing the configuration file 78on worksheet 47

RSSD_pw configuration parameterdescription 124editing the configuration file 78on worksheet 47

RSSD_server configuration parameterdescription 125editing the configuration file 78on worksheet 47

RSSD_user configuration parameterediting the configuration file 78on worksheet 47

Run libraries and DB2 RUNLIB namerecording 34

RUNLTM member 60Running multiple LTM for MVS instances 33

SSample

configuration file 89JCL in PLANS member 62

SAS.LINKLIB file 155SAS/C

requirement 25SCCSID

DB2 initialization parameter 100Security started task authorization table

LTMADMIN user IDLTMADMIN user ID 59Select permission 56SERVERNAME parameter

in SYGWHOST macro 46, 47, 119SET_TRUNC PDR parameter 147SETUP member 155

description 63, 140LOADLIBS parameter 141parameters for data sharing 19sample 140SSID parameter 140SSID value 40

Shutting down Replication Agenterrors 128

SMOvalue of READER_TYPE parameter for data sharing

66Software

prerequisites 31SQL

LTL translation 8SQLINIT

effects of executing 54SSID SETUP parameter 140Stable queue 8START command 5, 86Started tasks

associating with LTMADMIN user ID 59LTM for MVS 86LTM for MVS name 33, 43Replication Agent 59

Index

197

StartingLTM for MVS as a batch job 86LTM for MVS as a started task 86

Startup proceduredefining Replication Agent 59LTM for MVS task name 33

Stop_on_error configuration parameterdescription 126

Stored proceduresrs_zeroltm 158

Subscriptionsreplication definitions 10

Subsystem IDDB2 35, 63recording DB2 34

Support queries 1Support_DB2_comp_rec configuration parameter

description 128Suppress_col_names configuration parameter

description 129SYGWHOST macro xiv

Adaptive Server 47entry for Adaptive Server 137entry for Replication Server 119providing information xivreplacing interfaces file 36Replication Server 46understanding 73

SYSCOLUMNS table 56SYSCOPY table 56SYSFIELDS table 56SYSTABLEPART table 56SYSTABLES 56SYSTABLES table 56SYSTABLESPACE table 56System hardware prerequisites 31System tables

creator 103LTMOBJECTS 6, 152Replication Agent 56, 67

Systemsreplication 1

TTables

DB2 catalog 56DB2 size requirement 29LTMLASTCOMMIT 55LTMMARKER 55LTMOBJECTS 55Replication Agent system table permissions 55SYSCOLUMNS 56SYSCOPY 56SYSFIELDS 56SYSTABLEPART 56SYSTABLES 56SYSTABLESPACE 56

TasksLTMxxxxx PROC 59started, LTM for MVS 43starting LTM for MVS 86startup procedure name 33

TCP/IPCommunications_Protocol configuration parameter

value 103connectivity 15information for Technical Support xvrecording configuration information 36, 38

TCP/IP variablesIBMTCPADDRSPACE 46IPADDR 46, 47LSTNPORT 46, 47SERVERNAME 46, 47

Team skillscommunications administration 23coordination 23installation requirements 23MVS system programming 23

TERM value 143, 147TESTSITE command xvTIME datatype

and Date_conv_default configuration parameter 104

and Time_in_char configuration parameter 131Time_conv_default configuration parameter

description 130Time_in_char configuration parameter

description 131TIMESTAMP datatype

Index

198

and Timestamp_in_char configuration parameter 132Timestamp_in_char configuration parameter

description 132TRACE

DB2 permission 56TRACE ALL command xvTRACE parameter 147trace=1,11 configuration parameter

description 133trace=1,11 utility 134trace=1,23 configuration parameter

description 134trace=1,23 utility 134, 135trace=1,31 configuration parameter

description 135trace=1,4 configuration parameter

description 133trace=1,4 utility 133TRACERTE command xvTraces

trace=1,11 configuration parameter 133trace=1,23 configuration parameter 134trace=1,31 configuration parameter 135trace=1,4 configuration parameter 133

Transactionreplication 1

Transaction_name configuration parameterediting the configuration file 78

Transaction_name parameterworksheet 48

Troubleshootinginformation for Technical Support xvusing LTM for MVS trace parameters 133, 134

Truncation pointrunning multiple LTMs 164See LTM Locator 147

TRUNCPT data set and QID 6Tuning considerations

batch_ltl_cmds configuration parameter 100retry configuration parameter 118

UUnited States/Canada codepage

CP037 101

User IDsAdaptive Server 16, 32, 33, 38, 47, 126connect source permission 82creating Replication Server 82LTMADMIN 16, 32, 40, 103maintenance 81, 83, 84maintenance user ID 16Replication Server 82, 124restrictions 48RS user 16RSSD user 16

User_exit configuration parameterdescription 138

UtilitiesPINGRS 85

UtilityDB2 plan name 45

VVARCHAR datatype

and replace_null_in_char configuration parameter 117

VariablesHLQ 34

WWorksheet

completing installation 31

XXSTATUS command

upgrading Replication Agent 158

Installation Guide

Documents

Transcript of Installation Guide