用 InforSphere Classic Replication Server 实现 CICS 数据之间的复制

核心提示：简介经典复制 (Classic Replication) 是高容量地等待时间的复制解决方案，它将改变的数据从大机上的非关系数据源转移到目标数据存储中，用 InforSphere Classic Replication Server 实现 CICS 数据之间的复制，目标数据存储可以是关系数据库，也可以是源数据库或源文件的

简介

经典复制 (Classic Replication) 是高容量地等待时间的复制解决方案，它将改变的数据从大机上的非关系数据源转移到目标数据存储中。目标数据存储可以是关系数据库，也可以是源数据库或源文件的非关系型拷贝。

对于到非关系型目标的复制，例如 VSAM(Virtual Storage Access Method) 文件到 VSAM 文件的复制，经典复制将数据修改直接写到非关系型目标数据存储的拷贝中。对于到关系型目标的复制，经典复制采用一种 Q 复制形式，Q 复制使用 WebSphere MQ 消息队列将数据修改传递到 DB2 服务器上的 Q Apply 程序。

不管修改的数据是传到关系型目标还是非关系型目标，数据源的改变都是被经典 捕获组件捕捉到。经典捕获组件是由更改捕获代理程序 CCA(Change Capture Agent)，关联服务 CS(Correlation Service)，分发服务 DS(Distribution Service) 和发布服务 PS(Publication Service) 组成。

更改捕获代理程序在非关系源数据库上运行，监视非关系源数据库上的数据集，捕获更改并将已经更改的数据发送至关联服务。根据数据源的不同类型，代理程序会有所不同。本文的着重介绍 CICS VSAM 数据之间的复制。

CICS 其全称是 Customer Information Control System，即客户信息控制系统，它是一系列为 IBM 和非 IBM 平台上的应用提供联机事务处理和事务管理的产品，其功能是为商业应用提供一个事务处理环境。CICS VSAM 是指 CICS 管理的 VSAM 文件。

项目背景

在一个比较复杂的生产环境中，数据源往往分布在不同的系统中。也就是说我们必须将 Classic Replication Server 的组件分布式装载到不同的机器上，各组件之间以 TCP/IP 通讯。我们经常碰到的一种方式就是将改捕获代理和关联服务组件放在源数据库端，而把分发服务组件和发布服务组件放在目的数据库端。Classic Replication Server 可以帮我们实现各种经典数据源之间的数据实时复制。Classic Replication Server 将数据源中的源数据实时的复制到目标数据库中去，可以用作系统容灾，系统迁移，系统集成，数据仓库的数据抽取等用途。

图 1 中所示的系统是一个应用 Classic Replication Server 实现 CICS 数据源之间复制的系统。本系统中采用 VSAM 专有 CCA —— Native VSAM Agent (NVA) 更改捕获代理程序捕捉 Source VSAM 数据源的变化并将更改信息传送给关联服务 CS，后者则将 NVA 传来的信息加以整理并通过 TCP/IP 传送给另一 LPAR(Logical PARtition) 的分发服务 DS，分发服务再将接收到的信息传送给 MQ 加以保存，而发布服务 PS 则读取 MQ 保存的更改信息并对目的数据库做一致性更改。

图 1. 复制系统

查看原图（大图）

复制原理解析

我们以典型的 CICS VSAM 到 CICS VSAM 的复制为例来具体阐释一下这个复制系统的原理，也为接下来的服务器部署做一个铺垫。下面我们按照整个实际复制过程中涉及组件的顺序来介绍各个组件的功能以及相互之间的联系。

名称服务器 CNS(Common Name Service) data server

CNS data server 即名称服务，该服务为单个 z/OS LPAR 上的所有关联服务 CS 和更改捕获代理程序 CCA 提供一个公共接口，以便控制访问控制表 (Control Table) 和过滤表 (Filter Table)。它相当于一个注册机，所有该 LPAR 上的控制表和过滤表都在该注册机上注册才能被关联服务和更改捕获代理程序使用。

过滤表所包含的信息主要是用于确定更改是针对数据库对象还是文件。控制表则纪录每个更改捕获代理程序的恢复信息。不管是更改捕获代理程序还是关联服务，都可以访问过滤表和关联表。尤其是控制表，像是一条纽带联系着更改捕获代理程序与关联服务。更改捕获代理程序只将捕获的更改信息传送给配置了相同控制表的关联服务。

更改捕获代理 CCA

不同的数据源需要配置不同类型的 CCA。本文中讲述专用于 VSAM 的 CCA 即 NVA。图 2 就是一个典型的 NVA 实例。我们可以把 NVA 看成一个主进程，该进程与关联服务以控制表一一对应，而该进程则包含多个线程，用于与被监视的诸多 VSAM 文件一一对应。如图 3 所示，NVA_SLS**...**** 代表着各个 NVA 线程，VSM2VSM2.** 则是被监视是否被更改的 VSAM 文件。CCA 捕获到更改后，便将更改信息以非关系型描述的方式传送给关联服务 CS。

图 2. 典型的 NVA 实例

查看原图（大图）

图 3. 更改捕获代理与 VSAM 文件

查看原图（大图）

关联服务 CS

关联服务 CS 接收来自更改捕获代理 CCA 对于更改的非关系型描述，然后将该描述转为关系型描述，以便转发给分发服务 DS。图 4 就是一个典型的 CS 配置。一个 CS 与一个 CCA 以配置的控制表一一对应。如果有多个 NVA 实例从 VSAM 文件中捕获更改，则需要运行多个关联服务。这种并行性的主要优点是加快处理更改数据的速度。但必须注意这些关联服务需要配置不同的 RECSERVICENAME，不然很有可能接受到非对应 NVA 传送的更改信息。

如图 2 和图 4 所示，CS 与 NVA 以 SERVERNAME(SRVNAM) LJPVSAM1 一一对应。

图 4. CS 配置

查看原图（大图）

分发服务 DS

分发服务 DS 接收来自关联服务 CS 对于更改的关系型描述，并将这些描述信息排序，然后发送到 MQ。

如图 4 和图 5 所示，DS 与 CS 以 LISTENSTRING(DISTSERVICENAME) SKT/9.68.75.169/8336 一一对应。

图 5. DS 配置

查看原图（大图）

发布服务 PS

发布服务 PS 读取 MQ 保存的更改信息并对目的数据库做一致性更改。

生产环境准备

我们以典型的 CICS VSAM 到 CICS VSAM 的复制为例实现这个复制系统。整个生产环境包括两个 LPAR(IICF02: 9.68.74.46; IICF03: 9.68.75.169), 源 / 目的 CICS VSAM 文件，CNS Server, NVA, Classic Data Architect(CDA), MQ 以及 IBM Personal Communications(IBM PCOM)。并假定 Classic Replication Server 基于的 LOAD LIB（如下图 6）已经存在于源 / 目的 LPAR 上。

图 6. LOAD LIB

查看原图（大图）

软件准备

源 / 目的数据系统：CICS 3 for zOS V1R10

Classic Replication Server 客户端：CDA V95 for Windows XP SP2

目的端消息服务器：MQ7.0 for zOS V1R10

zOS 客户端：PCOM V5.9 for Windows XP SP2

安装 CICS 3, CDA V95, MQ 7.0 和 PCOM V5.9

在 zOS V1R10 上安装并启动 CICS3, MQ7.0，安装以及启动过程不再赘述，可以查阅相关文档。或者寻找专业 zOS Administrator 协助安装以及启动 CICS，MQ。本示例环境中源端 (IICF02) 安装 CICS 环境 CICSIIC2，目的端 (IICF03) 安装 CICS 环境 CICSIIC3 和 MQ 环境 MQ73。

在 Windows XP SP2 上安装 CDA V95 and PCOM V5.9. 具体安装过程比较简单，直接双击 Install Image 安装即可。具体安装过程也不再赘述。

定制目的端 CICS

所谓定制目的端 CICS，就是在 CICSIIC3 上定义 CICS VSAM Replication 需要的事务 (Transaction)，复制 (Replication) 程序，关闭 (Shut Down) 程序，异常处理 (Abend Handle) 程序，连接 (Connection) 以及会话 (Session)。由于复制的 Apply 过程在目的端完成，所以只需要在目的端定制。

CAC.V950.TEST.SKELETON(CACRCDEF) 提供了定制目的端 CICS 的一个范本，本示例使用 VSM2VSM3.JCLLIB(CACRCDEF)。我们只需要在 CICSIIC3 已经启动的情况下，执行该 JCL 即可。

可以看出 CACRCDEF 中关闭程序 CACWSDS1 定义了一个 SUFFIX S1, 这就需要我们在 PLT(Program List Table) 中去定义它。CICSTS32.CICSIIC3.JCLLIB(DFHPLTS1) 给出了创建 PLT S1 的一个范本。我们需要首先 Shut Down CICSIIC3，然后执行该范本 JCL，最后在 CICSIIC3 启动文件 CICSTS32.CICSIIC3.JCLLIB(CICSIIC3) 参数部分加入 PLTSD=S1，如下图 7 所示，再执行该启动文件，这样整个定制过程就成功完成了。

图 7. 定制目的端 CICS: PLTSD=S1

创建源 / 目的 CICS VSAM File

首先分别在源端 IICF02，目的端 IICF03 上建立并初始化 Native VSAM File : VSM2VSM2.CKF80.TEST 和 VSM2VSM3.CKF80.TEST。CAC.V950.TEST.SKELETON(CACEVSAM) 提供了创建并初始化 Native VSAM File 的一个范例。本示例环境分别使用 VSM2VSM2.CLUSTER(CKF80)& VSM2VSM2.JCLLIB(CKF80INT) 和 VSM2VSM3.CLUSTER(CKF80) & VSM2VSM3.JCLLIB(CKF80INT) 来创建并初始化。

接下来我们需要将建立的两个 Native VSAM File 分别部署到源 / 目的 CICS 中，使用 PCOM 分别登陆 CICSIIC2, CICSIIC3, 使用 CEDA DEFINE 定义基于这两个 Native VSAM File 的 File Control Table(FCT) ，如图 8 所示，该图只是 CEDA DEFINE 视图的一部分，需要指出的是 RECORDSize=00080( 见截图最后一行 ) ，Keylength=008、RECORDFormat=F、Add/Browse/Delete/READ/UPDATE 均为 Yes, RECOVery=Backoutonly，其他参数均保持默认，然后使用 CEDA INSTALL 安装 FCT，创建过程就算结束了。

图 8. 使用 CEDA DEFINE 定义 FCT

查看原图（大图）

最终建立的 CICS VSAM File 如下所示

Source		Target
Data Set Name	FCT	Data Set Name	FCT
VSM2VSM2.CKF80.TEST	CKF80802 On CICSIIC2	VSM2VSM3.CKF80.TEST	CKF803 On CICSIIC3

部署 CNS Server 和 NVA

部署 CNS Server 的时候，由于 NVA 和 CS 部署在源 LPAR 即 IICF02 上，也就是说我们只需要在 IICF02 上部署 CNS Server. 以 Control Table 为 LJPVSAM, Filter Table 为 GY 为例，执行以下命令即可 ( 假定 CNS Server DCCNS2 已经启动 )：

　F　DCCNS2,ADD,CONFIG,SERVICELIST=CONTROLTBLNAME,SERVICE=CNTL,VALUE=LJPVSAM1/32　
　F　DCCNS2,ADD,CONFIG,SERVICELIST=FILTERTBLNAME,SERVICE=CNTL,VALUE=GY/132　
　

接下来部署 NVA。部署 NVA 包括配置，编译，连接，装载，使能几步：

配置：CAC.V950.TEST.SAMPLIB 中提供了 NVA 实例的一个范本 CACE1NVA. 修改 SrvNam=LJPVSAM1( 如图 2 所示 ) 即可。

编译：CAC.V950.TEST.SKELETON(CACIDLDB) 中的 ASSEMBLE 部分提供了使用 ASAM90 来编译 NVA 实例的一个范本。

连接： CAC.V950.TEST.SKELETON(CACNVALX) 提供了使用 IEWL 来连接 NVA 编译文件的一个范本。

装载： CAC.V950.TEST.SKELETON(CACNVASM) 提供了装载 NVA 到 SVC 的一个范本。首次装在使用 SVCMGR EXEC SVCMGR,PARM='LD,M=&&MODNAME,DS=&&LOADLIB' ，否则使用 SVCMGR EXEC SVCMGR,PARM='LD,F=Y,M=&&MODNAME,DS=&&LOADLIB'。但原则上我们建议见使用首次装载模式。如果是 n 次装载，可以首先使用 SVCMGR EXEC SVCMGR,PARM='RM,M=&MODNAME' 删除已经存在的 NVA 实例。因为 SVC 是核心级模块，n 次装载比较容易造成内存泄漏和不可预见的问题。

使能：CAC.V950.TEST.SKELETON(CACNVASM) 也提供了使能 NVA 一个范本。使用 SVCMGR EXEC SVCMGR,PARM= 'EN,M=&&MODNAME' 即可。

本示例环境所用 NVA 实例是 IICF02：CSDL.V960.LICL1105.JCLLIB(CAC21NVA). 相关编译，连接，装载，使能 JCL 分别是 CSDL.V960.LICL1105.JCLLIB(ASMCNA21/CACNV21L/CNALD211/ NVAENA21)。

复制环境部署

如图 1 所示，复制系统的部署主要包括源端 CS 服务器部署，目的端 DS 服务器部署以及目的端 PS 服务部署。

源端 CS 服务器部署

部署 CS Server，按照顺序包括创建配置文件，创建目录文件，创建控制表文件，创建日志流，创建连接文件， 启动 CS 服务器以及映射数据到服务器。

创建配置文件：配置文件记录着 CS 服务器各个服务启动时的状态。CS 服务器并非只有关联服务一种服务，而是许多服务的合集，只不过关联服务是 CS 服务器众多服务中最为重要的一个服务而已。该过程包括三个部分：

创建空白配置文件：CAC.V950.TEST.SKELETON(CACCFGCS) 提供了创建 CS Server 空白配置文件的一个范本。本示例中使用 VSM2VSM2.JCLLIB(CACCFGDB) 来创建。

创建配置清单文件：CAC.V950.TEST.CONFIG(CACSVCS) 提供了一个配置清单文件的范本。本示例中为 VSM2VSM2.CONFIG(EXPCS21)。

导入配置清单文件到空白配置文件：CAC.V950.TEST.SKELETON(CACCFGUT) 提供了该范本。本示例中使用 VSM2VSM2.JCLLIB(CACCFGUT) 来导入。

创建目录文件：目录文件记录着 CS Server 包含的所有对象的简略信息，包括表，存储过程，Publication, Subscription 等等的信息。CAC.V950.TEST.SKELETON(CACCATLG) 提供了创建目录文件的一个范本。本示例中使用 VSM2VSM2.JCLLIB(CACCATLG) 来创建。

创建控制表文件：控制表文件存储着复制过程使用的 Publication, Subscription 的详细信息， CAC.V950.TEST.SKELETON(CACCSTRL) 提供了使用创建控制表文件的一个范本。本示例中使用 VSM2VSM2.JCLLIB(CACCTRL) 来创建。

创建日志流：从配置清单文件 VSM2VSM2.CONFIG(EXPCS21) 可以看出，我们需要创建两个日志流，即 STREAMNAME='LOGGER.CS21.LOG'以及 SLSPREFIX='CMNLOG.IICF02'，前者是为 CS 服务器专门制定的系统级 LOG，后者则用于部署 PS 服务。CAC.V950.TEST.SKELETON(CACDEFLS) 提供了日志流创建的范本，本示例使用 VSM2VSM2.JCLLIB(DEFLOGS)。

创建连接文件：连接文件允许客户端如 CDA 连接到服务器。CAC.V950.TEST.CONFIG(CACMUCON) 提供了连接文件的一个范本。本示例使用 VSM2VSM2.DDL(CACMUCON)。连接文件不需要执行，只用创建好放在特定的目录下就可以了。

启动 CS 服务器：现在我们就可以启动 CS 服务器了。只需要 Submit 相应的 JCL 即可，CAC.V950.TEST.SKELETON(CACCS) 提供了 CS JCL 的一个范本，本示例使用 VSM2VSM2.JCLLIB(V2VCS21)。

映射数据到服务器：对于 CICS VSAM Replication，我们最后还需要为服务器映射一些数据。该数据主要用于 PS 服务部署，不然 PS 是不可能部署成功的。CAC.V950.TEST.SKELETON(CACMETAU) 提供了数据映射的一个范本，本示例使用 VSM2VSM2.JCLLIB(CACMETAU)。需要指出的该 JCL 中用到 VSM2VSM2.DDL(CACREPSP) 其实就是 CAC.V950.TEST.SKELETON(CACREPSP)。只需要 Copy 后者为前者即可。

目的端 DS 服务器部署

和部署 CS Server 类似 , 目的端 DS 服务器部署按照顺序包括创建配置文件，创建目录文件，创建连接文件 , 启动 DS 服务器以及映射数据到服务器。

创建配置文件：和上述 CS 配置文件创建过程类似，只不过 VSM2VSM2.JCLLIB 需要改成目的端的 VSM2VSM3.JCLLIB。而 VSM2VSM2.CONFIG(EXPCS21) 则变成目的端 VSM2VSM3.CONFIG(EXPCS3)。

创建目录文件：和上述 CS 目录文件创建过程类似，只不过 VSM2VSM2.JCLLIB 需要改成目的端的 VSM2VSM3.JCLLIB。

创建连接文件：和上述 CS 连接文件创建过程类似，只不过 VSM2VSM2.JCLLIB 需要改成目的端的 VSM2VSM3.JCLLIB。

启动 DS 服务器：和上述 CS 启动过程类似，只不过 CACCS 变成 CACDS, VSM2VSM2.JCLLIB 变成目的端的 VSM2VSM3.JCLLIB，V2VCS21 变成 V2VDS3 即可。

映射数据到服务器：和上述 CS 映射过程类似，只不过 VSM2VSM2.JCLLIB 变成目的端的 VSM2VSM3.JCLLIB 即可。

目的端 PS 服务部署

目的端 PS 服务部署按照顺序包括创建 MQ，配置 Publishing Target，创建 Subscription。

创建 MQ ：

需要在 IICF03 上创建两个本地队列：发送队列和重新启动队列。前者用于放置分发服务传来的消息，后者用于 MQ 重启时备份消息。本示例使用 VSM2VSM3.JCLLIB(CSQUTIL1)。

配置 Publishing Target ：

如图 9 所示，我们需要启动源端 CS 服务器，利用 CDA 连接到该服务器（具体连接方法不再赘述）后再做配置。必须在源端而不是在目的端配置，而 CS 启动时会自动将配置信息传给 DS 服务器。

图 9. 配置 Publishing Target

查看原图（大图）

创建 Subscription：

Subscription 是源目的 CICS VSAM 文件复制的纽带。创建的时候我们需要指定源 / 目的端信息并使之有效性检验。

1. 指定源 / 目的端信息：如图 10 所示。以下为各参数的详细解释：

Schema name: 源 / 目的 CICS VSAM 映射表所在的模式。

XM URL: 源端关联服务的 RECSERVICENAME 参数，标示于 VSM2VSM2.CONFIG(EXPCS21)。

Log stream suffix: 源端日志流后缀，标示于 VSM2VSM2.JCLLIB(DEFLOGS)。

Classic server LUNAME: Logic Unit of CICSIIC3. 你可以使用”D NET,ID=CACCAPP3,E”来查看所有 CICSIIC3 的逻辑单元名。需要注意的是此参数不可与 VSM2VSM3.CONFIG(EXPDS3) 中指定的 CICSCONNECTION 参数第一字段值 CACVREPL 相同，以免造成 CICS 死锁。这里指定为 CACCICS3。

CICS APPLID: 也就是目的端 IICF03 上的 CICS 启动程序名。与 VSM2VSM3.CONFIG(EXPDS3) 中指定的 CICSCONNECTION 参数第二字段值相同。

Logmode: 登录模式。与 VSM2VSM3.CONFIG(EXPDS3) 中指定的 CICSCONNECTION 参数第三字段值相同。

Transaction ID: 交易名。可以在目的端 IICF03 使用” F CICSIIC3,CEMT I TRANS” 来查看所有的 TRANSACTION ID。不可与 VSM2VSM3.CONFIG(EXPDS3) 中指定的 CICSCONNECTION 参数第四字段值 VSM1 相同，以免造成交易冲突。这里指定为 EXV3。

图 10. 指定源 / 目的端信息

查看原图（大图）

2. 有效性检验：有效性是指所制定的表名，Subscription 名，FCT 名，是否具有唯一性。如图 11 所示。

图 11. 有效性检验

查看原图（大图）

总结

至此，这个分布式复制系统就完全部署好了，我们就会拥有完整的，可以重复利用的 CICS VSAM 复制系统框架。如果需要部署更多的文件复制，只需要创建相应文件的 FCT 以及 Subscription 就可以了。通过本文，读者可以了解使用 Classic Replication Server 进行数据复制的原理，以及部署一个复杂的复制环境，为读者提供一个初步了解和使用 Classic Replication Server 的机会。