...

WebSphere Classic Replication Server for z/OS (Release 9.1) – VSAM capture

by user

on
Category: Documents
78

views

Report

Comments

Transcript

WebSphere Classic Replication Server for z/OS (Release 9.1) – VSAM capture
March 2007
WebSphere Classic Replication Server
for z/OS (Release 9.1) –
An end-to-end scenario using native
VSAM capture
Tom Wabinski, Anil Varkhedi, Thomas Atwood
WebSphere II Classic Products Development
IBM Silicon Valley Laboratory
San Jose, California, U.S.A.
Configuring WebSphere Classic Replication for z/OS
Page 1
Contents
1 Introduction
2 A business case
3 Configure the name service
4 Configure the data server
5 Start the data server
6 Generate control table
mappings
7 Define user table mappings
8 Create WebSphere MQ
objects
9 Create Q Apply control tables
10 Define MQ capture
parameters
1 Introduction
This article describes an end-to-end data replication scenario from
native Virtual Storage Access Method (VSAM) files to IBM® DB2®
Universal Database™ (DB2 UDB) for z/OS® using IBM
WebSphere® Classic Replication Server for z/OS, IBM
WebSphere Replication Server for z/OS, and IBM WebSphere
MQ® for z/OS. It leads you through the configuration tasks
required to implement the scenario. Data replication can be used
for many business functions, such as migration, workload
balancing, and monitoring. This document describes an end-to-end
scenario using a single business case as an example, and does
not cover the installation of the products. It is assumed that IBM
WebSphere Classic Replication Server for z/OS, IBM WebSphere
Replication Server for z/OS, IBM WebSphere MQ for z/OS, and
Classic Data Architect (CDA) are already installed. CDA is a
remote administration tool for IBM WebSphere Classic Replication
Server for z/OS and can be run from Windows® or Linux®
workstations. You will also need an IBM DB2 Connect™ or regular
DB2 UDB installation on a Windows, Linux or UNIX® workstation.
This installation includes the ASNCLP utility that is required to
perform administration tasks for the DB2 UDB instance on the
z/OS system. This scenario covers Q replication and Classic to run
on the same logical partition (LPAR).
13 Configure the native VSAM
change-capture agent
The article is a supplement to the documentation. Many alternative
approaches exist for the setup tasks described here. This paper
focuses on providing a single approach, so that you can see
results right away without dealing with confusing options. See the
documentation for descriptions of alternative approaches. You can
visit the IBM website and the Classic information center to find
topics, white papers, and tutorials that provide conceptual
overviews and different business cases.
14 Run replication
Conventions
11 Create subscriptions
12 Configure the Q Apply
program and load
15 Conclusion
This document provides numerous sample configuration files and
sample Job Control Language (JCL). The samples are shipped as
part of the server package, and you must modify them to fit your
environment. Changes and sections subject to modification are
highlighted in blue. Original comments in the sample files are
removed to keep the examples short.
This document uses italics to denote user-defined names that can
differ for the setup at your site, such as the high-level qualifier
(HLQ), query processor name, and queue names. Bold is used to
denote menu navigation.
Configuring WebSphere Classic Replication for z/OS
Page 2
2 A business case
JK Enterprises (JKE) is expanding, and adding new employees at a very high rate. The company
has problems with employee attrition. JKE wants to provide better tools to help employees interact
with management, so that the company can better manage salary, performance bonuses, and
awards. The JKE human resources management system currently runs on a mainframe, using
legacy HR applications written in COBOL that interface with a VSAM data store. The customer’s
newer, Web-based applications run on the same LPAR, but use a DB2 database. JKE wants to
replicate the data in real time between the VSAM clusters and DB2 tables, because the company
will continue to use the legacy applications in the short term, and cannot replace them. The
company is creating a prototype of a solution that uses the IBM WebSphere Replication suite of
products. Figure 1 shows the proposed migration strategy.
Figure 1. Business case example
For the prototype, the customer has chosen a VSAM cluster that contains basic employee
information. The name of that cluster is USRT001.VSAM.EMPLOYEE. The description of the data in
the COBOL copybook definition file is as shown in Figure 2:
Configuring WebSphere Classic Replication for z/OS
Page 3
Figure 2. Sample COBOL copybook
***************************************************************
*
* SAMPLE - EMPLOYEE COPYBOOK
*
***************************************************************
*
01 EMPLOYEE.
05 ENAME
PIC X(20).
05 PHONE
PIC 9(9) COMP.
05 FILLER
PIC X.
05 MAILID
PIC X(6).
05 SALARY
PIC S9(5)V99 COMP-3.
05 JOBID
COMP-1.
05 EMPID
PIC 9(9) COMP.
05 DEPTID
PIC 9(4) COMP.
05 FILLER
PIC X(2).
05 DEPARTMENT
PIC X(15).
In this scenario, you replicate the USRT001.VSAM.EMPLOYEE VSAM file to a DB2 table that you
define.
Here is an overview of the configuration steps necessary to implement this scenario. You specify a
high-level qualifier during installation, and specify it again repeatedly as part of the configuration
steps. This article uses USRT001 as the high-level qualifier.
Here is an overview of the configuration steps:
1. Configure the name service (NS).
The NS is responsible for sequencing and filtering the captured changes. You configure this
service to run in a separate job.
2. Configure the data server by setting up a data source.
This step enables you to use the Classic Data Architect and the command line program
ASNCLP. You also configure the data server to run the required services that correlate,
stage, sequence, format, and put the changes on the WebSphere MQ queues.
3. Map the control tables.
The mappings are stored in the metadata catalogs. The empty metadata catalogs are
created automatically with the high-level qualifier you specified during installation. The
product uses the information in these tables to capture and propagate change data.
4. Map the data description for the source VSAM cluster as a table in the metadata catalogs.
The layout definition is stored in a COBOL copybook. Use CDA to create the table mapping
for the VSAM file using the COBOL copybook as input, and mark the table for change
capture.
5. Set up the required WebSphere MQ queues.
Configuring WebSphere Classic Replication for z/OS
Page 4
The queues serve as a transport mechanism between IBM WebSphere Classic Replication
Server and Q Apply. Queues are also used for storing restart information and staging
purposes.
6. Create the Q Apply control tables.
The Q Apply control tables contain information about the receive queues that Q Apply
browses for changed data, and the subscriptions that contain information that Q Apply
needs to populate the target tables.
7. Define capture parameters used by the data server.
These are global parameters that mainly name WebSphere MQ objects.
8. Set up subscriptions.
Subscriptions define the user tables and the target WebSphere MQ queues (send queues)
to the data server. They also define the target tables and receive queues to Q Apply.
9. Set up the Q Apply program.
Q Apply browses the receive queues for changes and applies them to the target table. You
configure Q Apply to perform an automatic and internal full refresh of the target tables, also
referred to as load.
10. Set up the native VSAM change-capture agent (CCA).
The CCA is part of the first tier in IBM WebSphere Classic Replication. After customizing
one of the assembler modules by relating the target correlation service (CS) to the CCA,
you create the load module for the CCA. You then load the CCA and enable it. At this point
the CCA is ready to capture changes made to the VSAM file. Figure 3 summarizes the
steps:
Configuring WebSphere Classic Replication for z/OS
Page 5
Figure 3. Summary of configuration steps
3 Configure the name service
The NS is a central component for retrieving and publishing CCA filtering information and
processing restart information. The name service maintains two internal user-defined tables: a
control table and a filter table. The control table stores the recovery status of the agent, and the filter
table stores information about VSAM files. You define names for both of them.
Run the NS as a separate job, despite the fact that you can configure the NS to run as a task within
a data server. This approach avoids problems when recycling a data server, because the NS tracks
the status of the CCA — information that is lost if the server comes down. The sample configuration
file is CACCNSCF, a member of the SCACCONF partitioned data set (PDS).
To configure the NS:
1. Specify the control table name.
The control table name must match the name of the correlation service you assign to it. You
configure the CS in the “Configuring the data server” section, and give it the same name
you specify for this control table.
Configuring WebSphere Classic Replication for z/OS
Page 6
2. Specify the filter table name.
The control table name for the correlation service in this scenario is USRT01CT, and the filter table
name is USRT01F. Modify CACCNSCF as shown in Figure 4:
Figure 4. Sample configuration file CACCNSCF for the name service
**********************************************************************
*
*
*
CLASSIC NAME SERVICE CONFIGURATION
*
*
*
**********************************************************************
*
* THE FOLLOWING 2 SERVICE INFO ENTRIES ARE REQUIRED.
SERVICE INFO ENTRY = CACCNTL CNTL 0 1 1 100 4 5M 5M NO_DATA
SERVICE INFO ENTRY = CACLOG LOG 1 1 1 100 1 5M 5M DISPLAY
*SERVICE INFO ENTRY = CACOPER OPER 2 1 1 100 4 5M 5M NO_DATA
*
* MISC REQUIRED PARAMETERS
*
MESSAGE POOL SIZE = 4194304
*
NL = US ENGLISH
NL CAT = DD:ENGCAT
*
CONTROL TABLE NAME = USRT01CT/32
FILTER TABLE NAME = USRT01F/100
4 Configure the data server
You configure the data server by modifying a configuration file, CACCSCF of SCACCONF PDS,
which serves as input to the JCL that starts the data server. To configure the data server for Classic
replication, you need to set up several tasks defined with the keywords SERVICE INFO ENTRY.
The required tasks are the:
•
•
•
•
•
Correlation service (CS)
Distribution service (DS)
Publication service (PS)
Query processor (QP)
Connection handler
You also enable the VSAM service. See Figure 3 for a summary of the stages in the setup process.
The CCA communicates with the CS using a cross memory (XM) queue owned by the CS. Figure 5
shows the communication between the CCA and the CS. You configure the XM queue by entering a
protocol string in the configuration file. You repeat the same step later when you map the VSAM
user employee table for change capture (Figure 26).
Configuring WebSphere Classic Replication for z/OS
Page 7
Figure 5. Communication between the CCA and CS
The CS reads the metadata (system catalogs and control data) and forwards changes that were
made to the subscribed datasets or database objects to the DS. The CS also filters the amount of
data pushed to the DS. Figure 6 illustrates the communication between the CS and DS. You can
change the IP address, but any time you use 0.0.0.0, the system interprets this as the IP address of
the current image. For all services that you configure for TCP/IP, you need to specify a TCP port
number that is not in use. You might need to get that TCP port number from the system
administrator.
Figure 6. Communication between the CS and DS
The DS is mainly responsible for sequencing incoming messages before forwarding them to the PS.
The PS is responsible for putting messages on WebSphere MQ queues in the appropriate format,
based on subscription information in the VSAM control files. The DS and PS also use cross memory
services as a data transport mechanism.
Connection handler and QP define a classic data source in the data server accessed by
ODBC/CLI/JDBC applications. The connection handler is responsible for routing requests to the
appropriate QPs configured in the data server. CDA connects to the data source with the supplied
JDBC driver. Components of the data server itself connect to the data source using CLI and require
appropriate CLI configuration parameters when performing administration tasks, such as creating
subscriptions.
Configuring WebSphere Classic Replication for z/OS
Page 8
To configure the data server:
1. Enable the DS and PS. You configure both services using the service info entry for
CACDSRD. The components of the DS service info entry are shown in Figure 7.
Figure 7. DS service info entry
a. Set the DS name USRT001DIST after the module name CACDSRD.
b. Set the DS protocol string to establish a TCP/IP connection between the CS and the
DS. Use the following format:
<communication protocol>/<IP address>/<port number>
The example protocol string is SKT/0.0.0.0/6201. The SKT identifier indicates that you
are using TCP/IP protocol.
c.
Set the PS protocol string for the data queue used to transfer data from the DS to the
PS.
Set the communication protocol XM1, followed by a data space name, a queue name,
and the queue size in megabytes. The data space and queue name must be four
characters in length, and unique across the LPAR. A unique name is required because
the system uses the first three characters of the data space name to generate a systemlevel name. Use the following format:
<communication protocol>/<data space name>/<queue name>/<size in megabytes>
The example protocol string is XM1/T1D1/T1Q1/4.
d. Set the PS protocol string for the control queue used to transfer status and error
information from the PS to the DS, using the same format you used to set the data
queue. The same restrictions of length and uniqueness apply.
The example protocol string is XM1/T1C1/T1Q1/4.
2. Edit the service info entry and parameters for the CS. The components of the CS service
info entry are shown in Figure 8.
Configuring WebSphere Classic Replication for z/OS
Page 9
Figure 8. CS Service Info Entry
a. Set the protocol string XM1/CCM1/CCQ1/512 in field two for the cross memory queue
(CCA XM queue) that the CCA uses to communicate with the CS. Use the same format
you used earlier to set the PS protocol strings for the DS service info entry.
b. Set the DS protocol string for TCP/IP in field 10 for the DS that the CS will connect to.
The values must match the IP address and port number you set for the TCP/IP
connection between the CCA and the CS.
c.
Specify the CS name.
You used this name for the control table when you set up the NS in section 3.
3. Make sure the QP service is enabled. The QP service is required to run Data Definition
Language (DDL) and SQL queries which will be issued by the administrative tool CDA. We
named the QP TRAINSAMP.
4. Enable the connection handler task CACINIT. Specify a port number, and make sure that
this port number is not in already in use.
You can change the 0.0.0.0 entry to point to a particular IP address.
5. Edit the CLI configuration parameters.
The configuration parameters are DATASOURCE, DEFLOC, USERID and
USERPASSWORD. In this scenario, the parameters point to the QP TRAINSAMP that you
configured earlier.
6. Enable the VSAM service CACVSMS. This step improves performance when creating
control information, such as subscriptions.
7. Specify the common filter table name used by this CS, USRT01F. You specified this name
when you configured the name service in the “Configure the name service” section.
When you follow the preceding steps, you have a configuration file CACCSCF as shown in Figure 9.
Configuring WebSphere Classic Replication for z/OS
Page 10
Figure 9. Sample configuration file CACCSCF with data server configuration, including the CS, DS, PS,
connection handler, QP, and CLI
**********************************************************************
*
*
*
CORRELATION SERVICE CONFIGURATION
*
*
*
**********************************************************************
*
* THE FOLLOWING 2 SERVICE INFO ENTRIES ARE REQUIRED.
SERVICE INFO ENTRY = CACCNTL CNTL 0 1 1 100 4 5M 5M NO_DATA
SERVICE INFO ENTRY = CACLOG LOG 1 1 1 100 1 5M 5M DISPLAY
*SERVICE INFO ENTRY = CACOPER OPER 2 1 1 100 4 5M 5M NO_DATA
*
**************************************************************
*
* DISTRIBUTION SERVICE CONFIGURATION
SERVICE INFO ENTRY = CACDSRD USRT01DIST 2 1 1 1 4 5M 5M \
SKT/0.0.0.0/6201,XM1/T1D1/T1Q1/16,XM1/T1C1/T1Q1/4
*
* CORRELATION SERVICE
SERVICE INFO ENTRY = CACECA2 XM1/CCM1/CCQ1/512 2 1 1 16 4 5M 5M \
SKT/0.0.0.0/6201,CSA=1K,CSARLSE=3,INT=1, \
COLDSTART,NAME=USRT01CT
*
* VSAM SERVICE CONFIGURATION
SERVICE INFO ENTRY = CACVSMS VSAMSRV 2 1 1 50 4 5M 5M CLOSE_ON_IDLE
**************************************************************
*
* VSAM CHANGE CAPTURE AGENT
*SERVICE INFO ENTRY = CACECA1V VSAMECA 2 1 1 1 4 5M 5S \
* APPLID=APPLID STARTUP APPLID.CICSAPPL.DFHLOG \
* APPLID.CICSAPPL.DFHJ01 APPLID.CICSAPPL.DFHJ02 \
* APPLID.CICSVR.DFHLGLOG
*
* QUERY PROCESSOR SERVICE INFO ENTRY
*
THE LAST SUBPARAMETER POINTS TO A QP SERVICE CONFIGURATION FILE
SERVICE INFO ENTRY = CACQP TRAINSAMP 2 5 10 20 4 5M 5M CACQPCF
*
*
**************************************************************
*
* TCP/IP CONNECTION HANDLER
* REFER TO DOCUMENTATION FOR DETAILED INFORMATION ON LAST SUBPARAMETER
SERVICE INFO ENTRY = CACINIT TCPIP 2 1 1 100 4 5M 5M \
TCP/0.0.0.0/6400
*
**************************************************************
* ADMINSTRATION STORED PROCEDURE PARAMETERS
*
DEFLOC = TRAINSAMP
DATASOURCE = TRAINSAMP TCP/0.0.0.0/6400
USERID = USRT001
USERPASSWORD = usrt001p
**************************************************************
* CLASSIC NAME SERVICES (CNS) PARAMETERS
Configuring WebSphere Classic Replication for z/OS
Page 11
*
COMMON FILTER TABLE NAME = USRT01F
*
**************************************************************
* OPTIONAL PARAMETERS WHEN RUNNING CNS IN THE SAME SERVER
* NOTE: THESE PARAMETERS NEED TO BE REMOVED WHEN CNS IS
*
RUN IN A SEPARATE ADDRESS SPACE
*
*** CONTROL TABLE NAME = (NONAME)/32
*** FILTER TABLE NAME = FILTER_TABLE/100
*
**************************************************************
* MISC REQUIRED PARAMETERS
*
MESSAGE POOL SIZE = 16777216
*
NL = US ENGLISH
NL CAT = DD:ENGCAT
*
LD TEMP SPACE = HIPERSPACE,INIT=16M,MAX=2048M,EXTEND=16M
*
SERVER CODEPAGE = 37
5 Start the data server
You have now configured the data server with all the services required to generate table mappings
and subscription control information, and run the data server with change capture. The next step is
to start the data server. See Figure 3 for a summary of the stages in the setup process.
The sample JCL to start the data server is CACCS of SCACSAMP PDS, found in the server
package. Make the following modifications:
1. Revise the job card.
2. Revise the high-level qualifier and data set names based on this scenario.
3. Revise the disk volume name.
4. Revise the region size.
After making your modifications, you will have a sample JCL CACCS as shown in Figure 10 below:
Figure 10. Sample JCL CACCS to bring up the data server
//USRT01CS JOB (3WCA,376),'QA ID',CLASS=A,MSGCLASS=X,
//
MSGLEVEL=(1,1),NOTIFY=&SYSUID,REGION=0M
//********************************************************************
//*
*
//*
NAME: CACCS
*
//*
SAMPLE CORRELATION SERVER JCL
*
//********************************************************************
//CACCS
PROC CAC='USRT001',
INSTALLED HIGH LEVEL QUALIFIER
//
CONFIG=CACCSCF,
CORRELATION SERVER CONFIGURATION
//*
ADA='ADABAS',
ADABAS HIGH LEVEL QUALIFIER
Configuring WebSphere Classic Replication for z/OS
Page 12
//*
DB2='DSN',
DB2 HIGH LEVEL QUALIFIER
//*
DC='DCOM',
DATACOM HIGH LEVEL QUALIFIER
//*
IDMS='IDMS',
IDMS HIGH LEVEL QUALIFIER
//*
IMS='IMS',
IMS HIGH LEVEL QUALIFIER
//*
MQS='MQS',
MQ-SERIES HIGH LEVEL QUALIFIER
//
DISKU=SYSDA,
DASD UNIT
//
DISKVOL=DEMO01,
DASD VOLSER
//
SOUT='*',
SYSOUT CLASS
//
RGN=32M
REGION SIZE
//*
//IEFPROC EXEC PGM=CACCNTL,TIME=1440,REGION=&RGN
//STEPLIB DD DISP=SHR,DSN=&CAC..V9R1M00.SCACLOAD
//*
DD DISP=SHR,DSN=&ADA..LOAD
//*
DD DISP=SHR,DSN=&DB2..SDSNLOAD
//*
DD DISP=SHR,DSN=&DC..CAILIB
//*
DD DISP=SHR,DSN=&DC..DATACOM.CHLQ.CUSLIB
//*
DD DISP=SHR,DSN=&DC..DATACOM.THLQ.CAILIB
//*
DD DISP=SHR,DSN=&IDMS..LOADLIB
//*
DD DISP=SHR,DSN=&IMS..RESLIB
//*
DD DISP=SHR,DSN=&MQS..SCSQANLE
//*
DD DISP=SHR,DSN=&MQS..SCSQAUTH
//VHSCONF DD DISP=SHR,DSN=&CAC..V9R1M00.SCACCONF(&CONFIG)
//CTRANS
DD DISP=SHR,DSN=&CAC..V9R1M00.SCACSASC
//*
//* META DATA CATALOGS
//CACCAT
DD DISP=SHR,DSN=&CAC..V9R1M00.CATALOG
//CACINDX DD DISP=SHR,DSN=&CAC..V9R1M00.CATINDX
//*
//* VSAM CONTROL TABLES
//SUBSCR
DD DISP=SHR,DSN=&CAC..V9R1M00.ASN.SUBS
//COLSCR
DD DISP=SHR,DSN=&CAC..V9R1M00.ASN.SRCCOLS
//PRMSCR
DD DISP=SHR,DSN=&CAC..V9R1M00.ASN.CAPPARMS
//SQUECR
DD DISP=SHR,DSN=&CAC..V9R1M00.ASN.SQUEUES
//SQUECRI DD DISP=SHR,DSN=&CAC..V9R1M00.ASN.SQUEUES.AIXSQ1.PATH
//*
//* RECOVERY DATASETS
//CACRCVD DD DISP=SHR,DSN=&CAC..V9R1M00.CACRCVD
//CACRCVX DD DISP=SHR,DSN=&CAC..V9R1M00.CACRCVX
//*
//* ADABAS ENVIRONMENT
//*DDCARD DD DISP=SHR,DSN=&CAC..V9R1M00.SCACSAMP(CACADADD)
//*
//* DATACOM SECURITY
//*DDIDENT DD DISP=SHR,DSN=&CAC..V9R1M00.SCACSAMP(CACDCID)
//*
//* IDMS ENVIRONMENT
//*SYSCTL DD DISP=SHR,DSN=&IDMS..SYSCTL
//*
//* IMS DBD LIBRARY
//*DBDLIB DD DISP=SHR,DSN=&IMS..DBDLIB
//*
//SYSOUT
DD SYSOUT=&SOUT
//SYSTERM DD SYSOUT=&SOUT
//SYSPRINT DD SYSOUT=&SOUT
//SYSMDUMP DD DUMMY
//CACLOG
DD DISP=(NEW,PASS,KEEP),DSN=&&LOG,
Configuring WebSphere Classic Replication for z/OS
Page 13
//
UNIT=&DISKU,SPACE=(TRK,(60,30))
//*
//* PRINT OUT THE LOG SUMMARY
//*
//LOGSUM
EXEC PGM=CACPRTLG,PARM='SUMMARY=Y',COND=EVEN
//STEPLIB DD DISP=SHR,DSN=&CAC..V9R1M00.SCACLOAD
//VHSCONF DD DISP=SHR,DSN=&CAC..V9R1M00.SCACCONF(&CONFIG)
//ENGCAT
DD DISP=SHR,DSN=&CAC..V9R1M00.SCACMENU
//CTRANS
DD DISP=SHR,DSN=&CAC..V9R1M00.SCACSASC
//CACLOG
DD DISP=(OLD,PASS),DSN=&&LOG
//SYSTERM DD SYSOUT=&SOUT
//SYSPRINT DD SYSOUT=&SOUT
//SYSIN
DD DUMMY
//*
//* PRINT OUT THE LOG
//*
//LOGPRINT EXEC PGM=CACPRTLG,PARM='SUMMARY=N',COND=EVEN
//STEPLIB DD DISP=SHR,DSN=&CAC..V9R1M00.SCACLOAD
//VHSCONF DD DISP=SHR,DSN=&CAC..V9R1M00.SCACCONF(&CONFIG)
//ENGCAT
DD DISP=SHR,DSN=&CAC..V9R1M00.SCACMENU
//CTRANS
DD DISP=SHR,DSN=&CAC..V9R1M00.SCACSASC
//CACLOG
DD DISP=(OLD,DELETE),DSN=&&LOG
//SYSTERM DD SYSOUT=&SOUT
//SYSPRINT DD SYSOUT=&SOUT
//SYSIN
DD DUMMY
//
PEND
//CACCS
EXEC CACCS
6 Generate control table mappings
The next step is to use the administration tools to create the control table mappings. You use CDA
to apply the data definition language (DDL) found in the sample member CACREPSP of
SCACSAMP PDS, found in the server package. See Figure 3 for a summary of the stages in the
setup process.
To generate control table mappings:
1. Download the CACREPSP file from the SCACSAMP dataset using FTP to your Windows or
Linux workstation. You can do this from a command prompt using the following commands:
ftp 0.0.0.0
cd USRT001.V9R1M00.SCACSAMP
get CACREPSP
Change the “0.0.0.0” IP address to point to the IP address of the z/OS LPAR hosting the
data server.
2. Using CDA, create a connection to the data source. The data source was configured in the
“Configure the data server” section, when you set up a query processor and connection
handler.
a) Start CDA to open the initial workspace.
b) Right-click Connection in the Database Explorer in the lower left region, and choose
New Connection (Figure 11). The New Connection window appears.
Configuring WebSphere Classic Replication for z/OS
Page 14
If you cannot see the Database Explorer view, make sure you are in the Classic
Integration perspective. The perspective name appears on the tab in the upper righthand corner. If you are in the Classic Integration Perspective, select Window > Reset
Perspective to restore the layout. If you are not in the Classic Integration perspective,
select Window > Open Perspective > Other, select Classic Integration from the
dialog, and click OK.
Figure 11. CDA Database Explorer - New Connection
\
c) In the New Connection window (Figure 12):
i. Expand Classic Integration and select V9.
ii. Provide the connection information, including the data source name (the query
processor TRAINSAMP in this scenario), the IP address of the LPAR, and the port
number the connection handler is listening on. In this scenario, the connection
handler is listening on port 6400.
iii. Click Finish. The connection will be automatically established.
Configuring WebSphere Classic Replication for z/OS
Page 15
Figure 12. CDA - New Connection window
3. Execute the DDL contained in the file CACREPSP you previously downloaded from
SCACSAMP.
a) Open a SQL editor by clicking the SQL icon on the toolbar (Figure 13).
Configuring WebSphere Classic Replication for z/OS
Page 16
Figure 13. Database Explorer – SQL editor
b) Paste the contents of CACREPSP into the editor window, right-click in the window, and
choose Run SQL from the menu (Figure 14).
Figure 14. New SQL statement window
c) Select the connection TRAINSAMP, as shown in Figure 15.
Configuring WebSphere Classic Replication for z/OS
Page 17
Figure 15. Connection Selection window
d) Verify the task execution in the data output window of the CDA (Figure 16).
You can click on the objects in the left pane to see detailed messages. You might see
errors, such as those shown in Figure 16. If the errors are about initial drop statements
for non-existing mappings, as shown in Figure 16, you can ignore them. You can also
ignore the 0x00740702 warning generated when creating
“ASN.IBMQREP_SRC_COLS.”
Configuring WebSphere Classic Replication for z/OS
Page 18
Figure 16. CDA Data Output window
7 Define user table mappings
In this section, you use CDA to map a VSAM source cluster to relational user tables in the metadata
catalogs. See Figure 3 for a summary of the stages in the setup process. You map the VSAM
cluster USRT001.VSAM.EMPLOYEE to create the source table for replication.
Classic Data Architect
CDA is a program that provides a graphical user interface on a Windows or Linux workstation that
you can use to manage the relational data model of your entire business.
You can use CDA to create data design projects and physical data models. A data design project
enables you to manage SQL statements and one-to-many physical data models. A physical data
model contains relational objects, such as tables, views, indexes, keys, and stored procedures. You
can also create physical data models for other database management systems, such as DB2 UDB.
You can manage multiple data design projects.
User table mappings
Because this scenario uses an HR database, you create the data project HR_PROJECT and the
physical data model HR_MODEL Your data model contains a source table definition with the name
USRT001.EMPLOYEE. You use a COBOL copybook to import the source table definition into the
data model, generate DDL for the source table, and run the DDL on the data server.
After you create the relational table mappings, you specify a primary key. The Q Apply program
might fail if you do not define and map the primary key correctly. Even though VSAM enforces
uniqueness for key fields that were defined when the VSAM cluster was created, you also define a
primary key for the relational table mapping. The data server forwards this key information to Q
Apply.
To define user table mappings:
1. Create a design project using CDA.
Configuring WebSphere Classic Replication for z/OS
Page 19
a. From the main menu, go to File > New > Data Design Project, as shown in Figure 17.
Figure 17. Create new Data Design Project
b. Specify the project name HR_PROJECT, and click Finish, as shown in Figure 18.
Figure 18. New Data Design Project window
2. Create a physical data model:
a. In the Main Menu, go to File > New > Physical Data Model, as shown in Figure 19.
Configuring WebSphere Classic Replication for z/OS
Page 20
Figure 19. New Physical Data Model
b. In the window that appears (Figure 20), specify the destination folder HR_MODEL,
version V9, and activate the radio button Create from template. CDA creates an empty
model.
Configuring WebSphere Classic Replication for z/OS
Page 21
Figure 20. New Physical Data Model window
3. Import the COBOL copybook CACEMPFD of SCACSAMP.
a. From the main menu, go to File > Import, as shown in Figure 21.
Configuring WebSphere Classic Replication for z/OS
Page 22
Figure 21. Invoke Import
b. Expand the folder Classic Data Architect, and select Classic Data Architect
References in the Import window, as shown in Figure 22.
Configuring WebSphere Classic Replication for z/OS
Page 23
Figure 22. Import window
c.
In the Import Data Definitions window, provide the connection information of the remote
z/OS host, and specify the data set name and member name of the COBOL copybook
file (CACEMPFD of SCACSAMP), as shown in Figure 23. Click Finish to import the
copybook.
Configuring WebSphere Classic Replication for z/OS
Page 24
Figure 23. Import Data Definitions window
4. Create a VSAM table in the data model
a. In the Data Project Explorer, expand the data model and right-click SCHEMA. Select
Add Classic Object from the menu, then VSAM Table, as shown in Figure 24.
Configuring WebSphere Classic Replication for z/OS
Page 25
Figure 24. Add VSAM table
b. Specify the copybook CACEMPFD and type the schema name USRT001, as shown in
Figure 25. In the Select Table Usage field, check both the Query and Change capture
options. Click Next to proceed.
Configuring WebSphere Classic Replication for z/OS
Page 26
Figure 25. New VSAM Table I
c.
In the next window (Figure 26), specify the table name EMPLOYEE, the cross memory
URL, and the data set name of the source VSAM cluster USRT001.VSAM.EMPLOYEE.
The CCAs use the XM URL. The URL must match the XM queue name that you
specified in the CS service info entry CACECA2 when you configured the data server.
See Figure 9.
Configuring WebSphere Classic Replication for z/OS
Page 27
Figure 26. New VSAM Table II
d. In the next window, select the elements you want to map as columns, and click Finish.
The new table appears in the Data Project Explorer.
In this scenario, you enable all the elements, as shown in Figure 27.
Configuring WebSphere Classic Replication for z/OS
Page 28
Figure 27. New VSAM Table III
e. Define a primary key for the relational table mapping.
In this scenario, the original VSAM cluster USRT001.V910.VSAM.EMPLOYEE was
defined with a key for the first 20 bytes of a record, as shown in red highlighting in
Figure 28. You mapped this field as the column ENAME in your relational table mapping
earlier, and this is the column for which you define a primary key.
Make sure that you see the properties view in your workspace. If you cannot see this
window, activate it by going to Window > Show View > Properties, from the main
menu
In the Data Project Explorer, click the table object EMPLOYEE, as shown in Figure 29.
The table properties appear in the Properties window. Under the columns tab, select
ENAME as the primary key Figure 30).
Configuring WebSphere Classic Replication for z/OS
Page 29
Figure 28. VSAM cluster definition JCL
//USRT01A2 JOB (3WCA,376),'QA ID',CLASS=A,MSGCLASS=X,
//
MSGLEVEL=(1,1),NOTIFY=&SYSUID,REGION=0M
//*
//CACEMP1 EXEC PGM=IDCAMS
//CACEDATA DD DISP=SHR,DSN=USRT001.V910.SCACSAMP(CACEDATA)
//SYSPRINT DD SYSOUT=*
//SYSIN
DD *
SET MAXCC = 8
DELETE USRT001.V910.VSAM.EMPLOYEE
SET MAXCC = 0
DEFINE CLUSTER (NAME
(USRT001.V910.VSAM.EMPLOYEE) KEYS
(20 0) TRACKS
(1 1) RECORDSIZE (80 80) FREESPACE (40 40)) DATA
(NAME
(USRT001.V910.VSAM.EMPLOYEE.DATA) VOLUMES
(DEM001)) INDEX
(NAME
(USRT001.V910.VSAM.EMPLOYEE.INDEX) VOLUMES
(DEM001))
REPRO INFILE (CACEDATA) OUTDATASET (USRT001.V910.VSAM.EMPLOYEE)
Figure 29. Data Project Explorer
Configuring WebSphere Classic Replication for z/OS
Page 30
Figure 30. Properties window - Table properties
5. Generate and run the DDL.
a. In the Data Project Explorer, right-click the table EMPLOYEE, and choose Generate
DDL from the menu, as shown in Figure 31.
Figure 31. Invoke Generate DDL
Configuring WebSphere Classic Replication for z/OS
Page 31
b. In the Generate DDL window, specify the model objects. Click Next to continue.
In this scenario you activate all the options, as shown in Figure 32.
Figure 32. Generate DDL
c.
In the Generate DDL window, specify the model objects. Activate tables and indexes, as
shown in Figure 33. Click Next to continue.
Figure 33. Generate DDL II
Configuring WebSphere Classic Replication for z/OS
Page 32
d. Specify the run options. Check the option to run the DDL on the data server (Figure 34).
Click Next to continue.
Figure 34. Generate DDL III
e. Specify the connection information. Choose the existing connection TRAINSAMP, and
click Next, as shown in Figure 35. You might be prompted for your ID and password,
and a summary of your selected options will appear. Click Finish to run the DDL. You
can verify the run in the data output window.
Configuring WebSphere Classic Replication for z/OS
Page 33
Figure 35. Generate DDL IV
8 Create WebSphere MQ objects
In this section, you set up WebSphere MQ objects for replication. See Figure 3 for a summary of the
stages in the setup process.
When you configure WebSphere MQ for replication, the following objects are available for your use:
•
•
•
•
•
•
•
Queue manager
WebSphere MQ channels
Listeners
Send queues
Receive queues
Restart queue
Administration queue
Many configuration scenarios are possible when you use WebSphere MQ with Q replication. One
determining factor is whether replication occurs on the same system, between different systems, or
between different LPARs on the same Sysplex. This scenario uses a local replication scenario,
where you replicate data from a VSAM cluster to a DB2 target table on the same z/OS LPAR. In this
scenario, you only need to configure one queue manager and local queue definitions. For this
Configuring WebSphere Classic Replication for z/OS
Page 34
reason, you do not need to create channels and listeners to link different queue managers. For
information about more complex MQ configurations, see the IBM WebSphere Information
Integration Replication and Event Publishing Guide and Reference, document number SC19-102900. The WebSphere MQ objects, and the names used in this scenario, are highlighted in red in
Figure 36.
Figure 36. WebSphere MQ object configuration
WebSphere MQ
Queue Manager: CSQ1
Compact
Format
Publication
Service
Send/Receive Queue:
ASN.USRT001.REPL1
Spill Queue:
IBMQREP.SPILL.MODELQ
Q Apply
Administration Queue:
ASN.USRT001.ADMINQ
Restart Queue:
ASN.USRT001.RESTARTQ
This scenario assumes that your system administrator has already created the queue manager
CSQ1. On the z/OS platform, creating a queue manager typically requires additional tasks other
than running a Create command, as you would do on the Windows, UNIX, or Linux platforms. For
more information on how to create a queue manager on z/OS, refer to the WebSphere MQ System
Setup Guide.
Define the required WebSphere MQ objects by issuing the appropriate commands using the System
Display and Search Facility (SDSF).
To create WebSphere MQ objects:
1. Type a forward slash (/) to bring up the command extension panel (Figure 37). The
command syntax is:
<Command Prefix String> <Command>
Contact your system administrator if you do not know the command prefix string, which is
defined in SYS1.PARMLIB. In this scenario, the command prefix string is the percent sign
(%) and the queue manager name is CSQ1.
2. Create an administration queue.
Define the administration queue as SHARED. The administration queue acts locally as both
a send and receive queue, and multiple applications open it.
3. Create a restart queue.
Configuring WebSphere Classic Replication for z/OS
Page 35
4. Create a spill model queue.
Give the spill model queue the default name IBMQREP.SPILL.MODELQ. Q Apply
dynamically creates spill queues during a load based on this template.
5. Create a data queue.
Define the data queue as SHARED. The data queue acts locally as both a send and receive
queue, and multiple applications open it.
Refer to Figure 38, Figure 39, Figure 40, and Figure 41 for examples of WebSphere MQ object
definitions.
Figure 37. SDSF main menu
Display Filter View Print Options Help
------------------------------------------------------------------------------HQX7708 ----------------- SDSF PRIMARY OPTION MENU -------------------------COMMAND INPUT ===> /
SCROLL ===> PAGE
DA
I
O
H
ST
Active users
Input queue
Output queue
Held output queue
Status of jobs
LOG
SR
MAS
JC
SE
RES
ENC
System log
System requests
Members in the MAS
Job classes
Scheduling environments
WLM resources
Enclaves
F1=HELP
F7=UP
F2=SPLIT
F8=DOWN
F3=END
F9=SWAP
INIT
PR
PUN
RDR
LINE
NODE
SO
Initiators
Printers
Punches
Readers
Lines
Nodes
Spool offload
ULOG
User session log
F4=RETURN
F10=LEFT
F5=IFIND
F11=RIGHT
F6=BOOK
F12=RETRIEVE
Figure 38. Create the administration queue
System Command Extension
Type or complete typing a system command, then press Enter.
===> %CSQ1 DEFINE QLOCAL(ASN.USRT001.ADMINQ) DEFPSIST(YES)
===> PUT(ENABLED) GET(ENABLED) DEFSOPT(SHARED) INDXTYPE(GROUPID)
Figure 39. Create the restart queue
System Command Extension
Type or complete typing a system command, then press Enter.
Configuring WebSphere Classic Replication for z/OS
Page 36
===> %CSQ1 DEFINE QLOCAL(ASN.USRT001.RESTARTQ) DEFPSIST(YES)
===> PUT(ENABLED) GET(ENABLED) DEFSOPT(SHARED) INDXTYPE(GROUPID)
Figure 40. Create the spill model queue
System Command Extension
Type or complete typing a system command, then press Enter.
===> %CSQ1 DEFINE QMODEL(IBMQREP.SPILL.MODELQ) DEFSOPT(SHARED)
===> MAXDEPTH(500000) MSGDLVSQ(FIFO) DEFTYPE(PERMDYN)
Figure 41. Create a data queue for replication
System Command Extension
Type or complete typing a system command, then press Enter.
===> %CSQ1 DEFINE QLOCAL(ASN.USRT001.REPL1) DEFPSIST(YES)
===> PUT(ENABLED) GET(ENABLED) INDXTYPE(MSGID) DEFSOPT(SHARED)SHARE
If you have a scenario that uses many WebSphere MQ objects, consider creating a batch job that
invokes these commands. For sample JCL, refer to the command section of the WebSphere MQ for
z/OS System Administration Guide.
9 Create Q Apply control tables
This section describes how to create control tables that are used by Q Apply in the target DB2
database. See Figure 3 for a summary of the stages in the setup process. The DB2 subsystem
holds the apply control tables and the target table. This scenario uses the subsystem name DSN1.
This document does not cover the definition and configuration of the DB2 subsystem. For details,
refer to the DB2 UDB for z/OS Installation guide.
Use ASNCLP to create the apply control tables. You invoke ASNCLP from a DB2 installation on a
Windows workstation. DB2 Connect is the minimum requirement if you do not have DB2 for
Windows installed.
To create Q Apply control tables:
1. Using CDA, create a database and table spaces within the target DB2 for zSeries®
subsystem.
a. Add a connection to DSN1 in your workspace.
Click New Connection In the New Connection window (Figure 42), select DB2 UDB
zSeries as the database manager, select V8 (New-Function Mode), and provide the
connection details. Deactivate the retrieve objects created by this user-only checkbox,
so you can see all the objects on that subsystem.
Configuring WebSphere Classic Replication for z/OS
Page 37
Figure 42. Creating a DB2 UDB for zSeries connection
b. Create the database and table spaces for the Q apply control tables.
Type the following DDL in the SQL Editor window of CDA for the DSN1 connection you
just created:
CREATE DATABASE USRT1HR BUFFERPOOL BP0 STOGROUP IICF;
CREATE TABLESPACE USRT1TSA IN USRT1HR SEGSIZE 4 LOCKSIZE PAGE
CCSID EBCDIC;
CREATE TABLESPACE USRT1TSB IN USRT1HR SEGSIZE 4 LOCKSIZE ROW
CCSID EBCDIC;
Right-click in the Editor window, and choose Run SQL to create the database and table
spaces.
If you want to verify your created objects by using CDA to query the system tables, be
aware that the number of result rows retrieved might be limited. To increase or disable
Configuring WebSphere Classic Replication for z/OS
Page 38
this limitation, go to Window > Preferences, from the main menu. Expand Data on the
tree in the left pane, select Output, and modify the result set preferences, as shown in
Figure 43. CDA uses JDBC to connect to data sources. Some JDBC drivers and
versions do not support restricting the number of result rows, and if this is the case with
your driver, setting these options has no effect and CDA issues no warning messages.
Figure 43. CDA Preferences window
2. Create the apply control tables. The steps below describe the procedure on the Windows
platform.
a. Open a DB2 command window (db2cmd.exe).
b. Add the DB2 UDB zSeries subsystem DSN1 to the catalog, and issue the following
commands from the DB2 command prompt:
CATALOG TCPIP NODE "TCP0001" REMOTE 0.0.0.0 SERVER 446 OSTYPE
MVS;
CATALOG DATABASE "DSN1" AT NODE "TCP0001" AUTHENTICATION DCS;
TERMINATE;
c.
Optional: If your Windows PATH environment variable is set to point to the correct
Java™ runtime required by ASNCLP, skip this step. Otherwise, run the following
commands in a command window:
set DB2PATH=C:\Program Files\IBM\SQLLIB
set PATH=%DB2PATH%\java\jdk\bin;%DB2PATH%\jdk\jre\bin;%PATH%
d. Create an ASNCLP input file usrt001_crtctrlapp.in
Include the commands shown in Figure 44 to set an apply schema, set a queue
manager and create the apply control tables. Optionally, you can save the DDL
statements into a file, such as ctrl_app.sql, to modify and run them at a later time.
Configuring WebSphere Classic Replication for z/OS
Page 39
Figure 44. ASNCLP commands of usrt001_crtctrlapp.in
ASNCLP SESSION SET TO Q REPLICATION;
SET OUTPUT TARGET SCRIPT "ctrl_app.sql";
SET LOG "qctrl.err";
SET SERVER TARGET TO DB "DSN1" ID "USRT001" PASSWORD "usrt001p";
SET APPLY SCHEMA "ASNUSRT001";
SET QMANAGER "CSQ1" FOR APPLY SCHEMA;
SET RUN SCRIPT NOW STOP ON SQL ERROR ON;
CREATE CONTROL TABLES FOR APPLY SERVER IN ZOS PAGE LOCK DB "USRT1HR"
"USRT1TSA" ROW LOCK DB "USRT1HR" "USRT1TSB";
QUIT;
e. Invoke ASNCLP from the command prompt, using the input file you just created.
C:\Program Files\IBM\SQLLIB\BIN>asnclp –f usrt001_crtctrlapp.in
The sample output is shown in Figure 45.
Figure 45. Sample ASNCLP output
C:\Program Files\IBM\SQLLIB\BIN>asnclp -f usrt001_crtctrlapp.in
====
CMD: ASNCLP SESSION SET TO Q REPLICATION;
====
====
CMD: SET OUTPUT TARGET SCRIPT "ctrl_app.sql";
====
====
CMD: SET LOG "qctrl.err";
====
====
CMD: SET SERVER TARGET TO DB DSN1 ID "USRT001" PASSWORD "usrt001p";
====
====
CMD: SET APPLY SCHEMA "ASNUSRT001";
====
====
CMD: SET QMANAGER "CSQ1" FOR APPLY SCHEMA;
Configuring WebSphere Classic Replication for z/OS
Page 40
====
====
CMD: SET RUN SCRIPT NOW STOP ON SQL ERROR ON;
====
====
CMD: CREATE CONTROL TABLES FOR APPLY SERVER IN ZOS PAGE LOCK DB
"USRT1HR" "USRT1TSA" ROW LOCK DB "USRT1HR" "USRT1TSB";
====
<ClpInfo2Log:: Preparing to run script.>
<ClpInfo2Log:: Now running SQL...>
<ClpInfo2Log:: The SQL command completed successfully.>
====
CMD: QUIT;
====
ASN1953I ASNCLP : Command completed.
10 Define WebSphere MQ capture parameters
The capture control tables you mapped earlier contain capture control information that is used by
several services. The capture control tables provide a common data store that is also used by IBM
WebSphere Classic Event Publisher for z/OS. Capture parameters name mainly WebSphere MQ
objects that are used globally. If you want to run replication exclusively, or in conjunction with event
publishing, use ASNCLP to create the capture parameters. The capture parameters are queue
manager name, administration queue name, and restart queue name. See Figure 3 for a summary
of the stages in the setup process.
Because the data server’s capture control tables are set up differently, you do not use a Create
command. Instead, use the ALTER CAPTURE PARAMETERS command to alter the existing tables
for Q Replication.
To define WebSphere MQ capture parameters:
1. Prepare ANSCLP for Classic replication by creating the file asnservers.ini, which contains
the connection information to a data source.
IBM has enhanced ASNCLP to support Classic replication. ASNCLP loads the supplied
JDBC driver (cacjdbc21.jar) installed under %DB2PATH%\sqllib\tools.
The data server alias information is specified in the SET SERVER command.
The sample content of asnservers.ini is shown in Figure 46. The information for the data
server in this scenario is marked blue.
Configuring WebSphere Classic Replication for z/OS
Page 41
Figure 46. Contents of asnservers.ini
[server1]
Data source=TWALOC
Type=CLASSIC
Host=1.1.1.1
Port=7029
[server2]
Type=CLASSIC
Data source=TRAINSAMP
Host=0.0.0.0
Port=6400
Codepage=Cp500
2. Place the SET SERVER and ALTER CAPTURE PARAMETERS commands in an ASNCLP
input file you create named usrt001_crtcapparms.in. The contents of the input file are shown
in Figure 47.
Figure 47. ASNCLP commands of usrt001_crtcapparms.in
ASNCLP SESSION SET TO Q REPLICATION;
#Setting classic server as source.
SET SERVER capture TO CONFIG SERVER "server2" FILE "C:\Program
Files\IBM\SQLLIB\bin\asnservers.ini" ID "USRT001" PASSWORD "usrt001p";
ALTER CAPTURE PARAMETERS QMGR "CSQ1" RESTARTQ "ASN.USRT001.RESTARTQ"
ADMINQ "ASN.USRT001.ADMINQ";
QUIT;
3. Invoke ASNCLP as follows:
C:\Program Files\IBM\SQLLIB\BIN>asnclp -f usrt001_crtcapparms.in
ASNCLP connects to the data server and inserts the information. ASNCLP does not support
the option to save the SQL scripts in a file to run later for other data servers. You can run
ALTER CAPTURE PARAMETERS for subsequent modification of existing capture
parameters.
11 Create subscriptions
In this section, you set up the source table and target table for replication by defining subscriptions
using ASNCLP. You create a subscription for the source table USRT001.EMPLOYEE and the target
table USRT001.EMPLOYEE _CPY. The target table is created by ASNCLP in the target DB2
database. In this scenario, the HR Web applications accesses the USRT001.EMPLOYEE_CPY
table later. See Figure 1 for a summary of the business case.
First, you set the log file and the target Q Apply server and create a replication queue map. The
subscriptions refer to the replication queue maps for information about the queues and message
size. See Figure 3 for a summary of the stages in the setup process.
To create subscriptions:
Configuring WebSphere Classic Replication for z/OS
Page 42
1. Create a table space for the target table using the CDA SQL editor and the connection with
the DSN1 subsystem you created previously. Issue the following command:
CREATE TABLESPACE "USRT1TSC" IN "USRT1HR" SEGSIZE 4 CCSID EBCDIC;
2. Create replication queue maps.
Create an input file usrt001_crtreplqmap.in for the ASNCLP commands. An example
containing the names used in this scenario is shown in Figure 48.
Figure 48. ASNCLP commands of usrt001_crtreplqmap.in
ASNCLP SESSION SET TO Q REPLICATION;
SET LOG "qsub.err";
SET SERVER TARGET TO DB "DSN1" ID "USRT001" PASSWORD "usrt001p";
SET SERVER CAPTURE TO CONFIG SERVER server2 FILE "C:\Program
Files\IBM\SQLLIB\bin\asnservers.ini" "USRT001" PASSWORD "usrt001p";
SET APPLY SCHEMA "ASNUSRT001";
CREATE REPLQMAP "REPLQMAPCLASSIC1" USING ADMINQ "ASN.USRT001.ADMINQ"
RECVQ "ASN.USRT001.REPL1" SENDQ "ASN.USRT001.REPL1" MAX MESSAGE SIZE
300;
QUIT;
Invoke ASNCLP and run the commands using usrt001_crtreplqmap.in as the input file:
C:\Program Files\IBM\SQLLIB\BIN>asnclp -f usrt001_crtreplqmap.in
3. Create subscriptions.
Create an input file usrt001_crtqsubs.in for the ASNCLP commands. An example containing
the names used in this scenario is shown in Figure 49.
Specify an ‘I’ (internal load) for the load phase, so that Q Apply initiates an automatic load of
the target table for this subscription. Specify LOAD TYPE 4 to indicate that replication tasks
initiate the load.
Specify the information required to create the target table (schema name, table name, data
base name and table space name).
Figure 49. ASNCLP commands of usrt001_crtqsubs.in
ASNCLP SESSION SET TO Q REPLICATION;
SET LOG "qsub.err";
SET SERVER TARGET TO DB "DSN1" ID "USRT001" PASSWORD "usrt001p";
SET SERVER CAPTURE TO CONFIG SERVER server2 FILE "C:\Program
Configuring WebSphere Classic Replication for z/OS
Page 43
Files\IBM\SQLLIB\bin\asnservers.ini" ID "USRT001" PASSWORD "usrt001p";
SET APPLY SCHEMA "ASNUSRT001";
#Use new target with automatic Classic Load.
CREATE QSUB USING REPLQMAP "REPLQMAPCLASSIC1" (SUBNAME "SUBSCLASSIC1"
"USRT001"."EMPLOYEE" OPTIONS HAS LOAD PHASE I TARGET NAME
"USRT001"."EMPLOYEE_CPY" IN DB "USRT1HR" "USRT1TSC" LOAD TYPE 4);
QUIT;
Invoke ASNCLP and run the commands using usrt001_crtqsubs.in as the input file:
C:\Program Files\IBM\SQLLIB\BIN>asnclp -f usrt001_crtqsubs.in
You cannot specify a capture schema other than ASN, which is the default schema name for nonrelational data sources. You cannot generate output DDL scripts for non-relational data sources.
Execution occurs immediately, and you cannot specify different options.
You can customize your approach by using a single input file for both steps. This is also true of
earlier steps that use ASNCLP input files. Choose the approach that best fits your need to isolate or
group commands for reuse or debugging.
This article does not cover commands to manipulate this control information, such as commands for
altering and dropping replication queue maps and subscriptions. See the Q replication
documentation for details.
12 Configure the Q Apply program and load
In this section, you configure Q Apply and load. See Figure 3 for a summary of the stages in the
setup process.
Configuration tasks typically performed by system programmers and database administrators as
part of product installation are prerequisite to running Q Apply. These tasks include configuring z/OS
for replication and configuring DB2 UDB for z/OS. What follows is a summary of the most important
prerequisites.
1. Ensure that the load libraries are APF authorized, especially the replication load libraries
that are in the dataset SASNLOAD.
2. Provide authorizations for the user IDs that operate the apply program, especially select,
insert, update, delete, and bind authorities.
3. Ensure that the replication packages and plans are bound to DB2 UDB for z/OS.
Sample JCL is in member ASNQBNDL of dataset SASNSAMP. Refer to the installation and
customization guide for details.
Configuring WebSphere Classic Replication for z/OS
Page 44
DSNUTILS setup
On zSeries, you can run Q Apply on native z/OS or USS, and each option has its own setup path.
This scenario configures Q Apply to run on native z/OS. This decision has no impact on
performance or other obvious advantages, so your choice is a matter of personal preference.
In this scenario, you set up a subscription so that Q Apply performs an automatic and internal load
from your data source. Q Apply invokes the DSNUTILS stored procedure to load records into the
target tables. An administrator configures DSNUTILS during the DB2 installation, and replication
requires that the administrator set up DSNUTILS to run in a workload management environment
(WLM). The following is a summary of the setup steps:
1. Create a PROC in PROCLIB that is named by the JES startup.
Sample JCL is shown in Figure 50. In the JCL, you revise the STEPLIB, the name of the
DB2 subsystem, and the name of the WLM application environment. The JCL also sets
NUMTCB to 1. NUMTCB 1 is a requirement for DSNUTILS to run.
2. Define a WLM application environment in the coupling facility data sets by using the WLM
panel. Name the newly-created PROC in this WLM application environment definition.
3. Run the CREATE command (subsequently ALTER) for the DSNUTILS stored procedure.
Provide the WLM application environment name in the commands.
4. Run the appropriate commands for refreshing and deploying.
For more information about the DSNUTILS configuration process, see z/OS MVS Planning:
Workload Management, the DB2 UDB for z/OS Utility Guide and Reference, and the DB2
UDB for z/OS Administration Guide.
Figure 50. WLM-managed stored procedure JCL
//*
JCL FOR RUNNING THE WLM-ESTABLISHED STORED PROCEDURES
//*
ADDRESS SPACE
//*
RGN
-- THE MVS REGION SIZE FOR THE ADDRESS SPACE.
//*
DB2SSN -- THE DB2 SUBSYSTEM NAME.
//*
APPLENV -- THE MVS WLM APPLICATION ENVIRONMENT
//*
SUPPORTED BY THIS JCL PROCEDURE.
//*
//*
IMPORTANT: You must use the value 1 in this EXEC card:
//*
IEFPROC EXEC PGM=DSNX9WLM,REGION=&RGN,TIME=NOLIMIT,
//*
PARM='&DB2SSN,1,&APPLENV'
//*
//*************************************************************
//DSNWLM
PROC RGN=0K,APPLENV=WLMENV1,DB2SSN=DSN1
//IEFPROC EXEC PGM=DSNX9WLM,REGION=&RGN,TIME=NOLIMIT,
//
PARM='&DB2SSN,1,&APPLENV'
//STEPLIB DD DISP=SHR,DSN=CEE.SCEERUN
//
DD DISP=SHR,DSN=DSN.DSN1.SDSNLOAD
//UTPRINT DD SYSOUT=*
//*RNPRIN01 DD SYSOUT=*
//DSSPRINT DD SYSOUT=*
//SYSIN
DD UNIT=SYSDA,SPACE=(4000,(20,20),,,ROUND)
//SYSPRINT DD UNIT=SYSDA,SPACE=(4000,(20,20),,,ROUND)
Configuring WebSphere Classic Replication for z/OS
Page 45
CLI driver setup
Q Apply uses a Call Level Interface (CLI) to retrieve data from your data sources during the load
process. Because this scenario uses Q Apply for native z/OS, Q Apply loads the supplied Classic
CLI driver for native z/OS. You specify configuration parameters for the CLI driver in a configuration
file, including connection information to the data source (TRAINSAMP in this scenario).
If you have the SAF EXIT enabled in the data server, you may have to turn it off, or the load utility
might not be able to connect to the data server. For more information about the SAF EXIT, see the
WebSphere Classic Federation Server for z/OS Administration Guide.
CACINIZ of SCACSAMP is a sample configuration file for the Classic CLI z/OS client. Set it up as
shown in Figure 51.
Figure 51. CACINIZ sample configuration file for the Classic CLI driver on z/OS
NL CAT = DD:ENGCAT
NL = US English
* default datasource location
DEFLOC = TRAINSAMP
DATASOURCE = TRAINSAMP tcp/0.0.0.0/6400
*DATASOURCE = CACSAMP2 XM1/CAC/CAC
* performance and memory parameters
FETCH BUFFER SIZE = 32000
MESSAGE POOL SIZE = 4000000
* tracing options
TRACE LEVEL = 4
SERVICE INFO ENTRY = CACLOG LOG 1 1 1 100 1 5M 5M DISPLAY
When your environment is configured properly, you can set up the JCL that starts the Q Apply
program. You can find the sample JCL in ASNQSTRA of SASNSAMP. Modify ASNQSTRA as
shown in Figure 52, which shows the configuration used in this scenario.
To configure the Q Apply JCL:
1. Revise the JOB card.
2. Revise the Q Apply program parameters.
3. Customize the STEPLIB card to point to the Q Apply load modules, DB2 UDB for z/OS load
modules, the WebSphere MQ load modules, and the data server load modules.
4. Customize the MSGS card to point to the Q Apply message catalog.
5. Specify the VHSCONF card in order to point to the Classic CLI for z/OS CACINIZ
configuration file, which is required for the load utility.
6. Optional: Set the CACLOG card to point to the trace output generated by the Classic CLI
driver during the load process.
You can also configure the Classic CLI driver for tracing. In addition to setting CACLOG, set
TRACE LEVEL to smaller than eight (for error message logging) or smaller than three (for
information message logging). The default and recommended trace level is four.
Configuring WebSphere Classic Replication for z/OS
Page 46
7. Set CTRANS to point to the SAS C runtime program for the Classic CLI driver on z/OS that
is required when running a load.
8. Optional: If your NL CAT system parameter points to a DD, set ENGCAT to point to the
message catalog. This is the case in our scenario.
9. Enable ASNFILES, which points to the data set name that holds the output generated by
the Q Apply load utility.
Figure 52. ASNQSTRA sample JCL
//USRT001A JOB NOTIFY=&SYSUID,
//
MSGCLASS=X,MSGLEVEL=(1,0),
//
REGION=0M
//********************************************************
//QAPP EXEC PGM=ASNQAPP,
// PARM='/APPLY_SCHEMA=ASNUSRT001 APPLY_PATH=/u/usrt001
//
APPLY_SERVER=DSN1 logstdout=y'
//STEPLIB DD DSN=USRT001.V9R1M00.DPROPR.SASNLOAD,DISP=SHR
//
DD DSN=DSN.DSN1.SDSNLOAD,DISP=SHR
//
DD DSN=MQS531.SCSQANLE,DISP=SHR
//
DD DSN=MQS531.SCSQAUTH,DISP=SHR
//
DD DSN=MQS531.SCSQLINK,DISP=SHR
//*
DD DSN=XML!!0.SIXMMOD1,DISP=SHR
//*
DD DSN=SYS!!0.SCEERUN,DISP=SHR
//*
DD DSN=SYS!!0.SCLBDLL,DISP=SHR
//*
//* Uncomment this statement if you choose Qapply internal load
//* to load target table and your source is Classic.
//*
//* This is the loadlib that contains all the load modules
//* necessary to run the CLI driver for Classic load.
//*
//
DD DSN=USRT001.V9R1M00.SCACLOAD,DISP=SHR
//*
//*TRCIN
DD DISP=SHR,DSN=USRT001.PARMLIB(TRCIN),
//*
VOL=SER=DRRSHR,UNIT=SYSDA
//MSGS
DD PATH='/u/usrt001/db2repl_09_01/msg/En_US/db2asn.cat'
//*
//* For classic load, uncomment these statements.
//*
//* VHSCONF DD is the configuration file for the Classic driver,
//* which contains the configuration information for the driver.
//* This file also is referred to as cac.ini file.
//* Copy this file from the SASNSAMP(CACINIZ) and customize for
//* your installation.
//*
//VHSCONF DD DISP=SHR,DSN=USRT001.V9R1M00.SCACSAMP(CACINIZ)
//*
//* CACLOG DD points to the logfile where trace messages
//* will be put when CLI tracing is enabled.
//* Please change the file name to point to a valid
//* dataset. You could have an existing dataset or it will
//* be created.
//*
//CACLOG
DD DSN=USRT001.TRCLOG,
Configuring WebSphere Classic Replication for z/OS
Page 47
//
DISP=(NEW,PASS,KEEP),UNIT=3390,SPACE=(TRK,(30,10))
//*
//* The CTRANS DD is required by SAS 'C' and this points to
//* the location of the SAS 'C' runtime libraries, These
//* libraries are shipped with Classic. Please change
//* DSN to point to the Classic library.
//*
//CTRANS
DD DISP=SHR,DSN=USRT001.V9R1M00.SCACSASC
//*
//* ENGCAT DD points to the message catalog, the value of the "NL CAT"
//* parameter in the CACINIZ (also refer to as cac.ini )determines
//* if this DD is required.
//* If the "NL CAT" points to a DD such as "NL CAT = DD:ENGCAT",
//* then you need to have this DD card.
//* If the NL CAT points to a DSN:<dataset name>, then you do not
//* need this DD statement. If the NL CAT points to an hfs file
//* as in hfs:/u/a/msgcat, you will also not need this DD card.
//*
//ENGCAT
DD DSN=USRT001.V9R1M00.SCACMENU,DISP=SHR
//*
//* ASNFILES DD points to the file where output of the unload
//* from classic source will be saved.
//* The ASNFILES DD card is a model DD statement that the user can modify
//* to point a UNIT where they would like the load data file to be created.
//* You can customize the Unit parameter for the DD card.
//* This example shows Unit=VIO.
//* The size of the file is determined by QApply by calculating the
//* number of rows in the source * maxrowsize.
//* The source parameter for SPACE and DCB for this DD card will
//* be ignored when Qapply create this file.
//* The format of the file is fixed with LRECL set to maxrowsize.
//* The DSN parameter of the DD card, if specified will
//* override the APPLY_PATH. If the file name specified in DSN exists
//* in the system, QApply will give an error and stop.
//*
//ASNFILES DD DSN=USRT001.ASN.TMP,
//
DISP=(NEW,DELETE,DELETE),
//
UNIT=3390,SPACE=(CYL,(10,10)),VOL=SER=DEMO01,
//
DCB=(RECFM=VB,BLKSIZE=6404))
//CEEDUMP DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD DUMMY
//*
The load process creates a data file that is automatically deleted after the load. You might have to
delete this file manually if the load fails. The load process creates a load trace file, and DSNUTILS
also generates a trace file. For more information about trace files, see the IBM WebSphere
Information Integration Replication and Event Publishing Guide and Reference, document number
SC19-1029-00.
13 Configure the native VSAM change-capture agent
The last configuration task before starting the replication environment is to configure the native
VSAM CCA. See Figure 3 for a summary of the stages in the setup process.
Configuring WebSphere Classic Replication for z/OS
Page 48
The native VSAM CCA uses SVC intercepts and JRNAD exit routines to intercept VSAM processing
and detect changes to subscribed data sets. It is written in assembler language, and you must build
a site-specific load module that defines site options, such as the correlation service name. You then
link the site-specific information into the load module. The setup process consists of assembling the
user options module, linking the agent with the user options module, and deploying the CCA.
To configure the native VSAM change-capture agent:
1. Modify CACE1NVA of SCACSAMP by specifying the correlation service name USRT01CT,
as shown in Figure 53. CACE1NVA invokes a supplied macro automatically in the following
step.
Figure 53. CACE1NVA Sample
**********************************************************************
*
*
* NAME:
CACE1NVA
*
*
*
* DESCRIPTION: CHANGE CAPTURE RECOVERY AGENT MESSAGES AND OPTIONS
*
*
*
*--------------------------------------------------------------------*
CACE1NVA CACEOPTM ,
SrvNam=USRT01CT,
FiltUser=,
FiltJbNm=,
PgmExcl=()
END
|
|
|
|
Server name
Username filter
Jobname filter
Program exclusion list
+
+
+
+
2. Invoke the HLASM assembler. Specify CACE1NVA as the input file in SYSIN and a DSN for
the output object file in SYSLIN. The sample JCL is shown in Figure 54.
Figure 54. JCL to assemble the native VSAM CCA
//USRT1AS JOB (3WCA,376),'INTEGRATION',CLASS=A,
//
MSGCLASS=X,NOTIFY=&SYSUID
//*
//* Using HLASM assembler
//*
//HLSM
EXEC PGM=ASMA90,
// PARM='NOLIST,NODECK,OBJECT,XREF(SHORT),RENT'
//STEPLIB DD DISP=SHR,DSN=ASM.SASMMOD1
//SYSLIB
DD DISP=SHR,DSN=SYS1.MACLIB
//
DD DISP=SHR,DSN=SYS1.MODGEN
//
DD DISP=SHR,DSN=USRT001.V9R1M00.MACLIB
//
DD DISP=SHR,DSN=SYS2.SASC.C650.MACLIBA
//SYSUT1
DD DSN=&SYSUT1,SPACE=(1024,(120,120),,,ROUND),UNIT=3390
//SYSPUNCH DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSIN
DD DSN=USRT001.V9R1M00.SCACSAMP(CACE1NVA),
//
DISP=SHR
//SYSLIN
DD DSN=USRT001.V9R1M00.OBJ(CACE1NVA),
//
DISP=OLD
Configuring WebSphere Classic Replication for z/OS
Page 49
//*
3. Use the object file CACE1NVA you just assembled as input to the link editor to create the
CCA load module. Invoke the linker by submitting the modified sample JCL CACNVALX of
SCACSAMP, as shown in Figure 55.
Figure 55. CACNVALX Sample JCL to link the native VSAM CCA
//USRT001L JOB (3WCA,376),'INTEGRATION',CLASS=A,
//
MSGCLASS=X,NOTIFY=&SYSUID
//********************************************************************
//*
*
//*
JOB CONTROL STATEMENTS TO LINK THE MODIFIED NVA OPTIONS TABLE *
//*
(CACE1NVA) WITH THE NVA ACTIVE CHANGE CAPTURE AGENT.
*
//*
*
//*
1) PROVIDE A JOB CARD THAT IS VALID FOR YOUR SITE
*
//*
2) CHANGE CAC PARM TO INSTALLED HIGH LEVEL QUALIFIER
*
//*
3) CHANGE &&OBJ TO IDENTIFY OBJECT LIBRARY WHERE CUSTOMIZED
*
//*
VERSION OF CACE1NVA EXISTS
*
//*
*
//********************************************************************
//LNKOPT PROC CAC='USRT001'
INSTALLED HIGH LEVEL QUALIFIER
//*
//LINK
EXEC PGM=IEWL,
//
PARM='MAP,LIST,AMODE=31,RENT,REUS,REFR'
//LOAD
DD DISP=SHR,DSN=&CAC..V9R1M00.SCACLOAD
//OBJ
DD DISP=SHR,DSN=&CAC..V9R1M00.OBJ
//SYSLMOD DD DISP=SHR,DSN=&CAC..V9R1M00.SCACLOAD
//SYSUT1
DD UNIT=3390,SPACE=(1024,(120,120),,,ROUND),DCB=BUFNO=1
//SYSPRINT DD SYSOUT=*
//
PEND
//LNKOPT EXEC LNKOPT
//SYSLIN
DD *
CHANGE
CACE1NVA(CACE1OPT)
INCLUDE OBJ(CACE1NVA)
INCLUDE LOAD(CACNVA00)
MODE
AMODE(31),RMODE(24)
SETCODE AC(1)
ENTRY
MSBAVLM0
NAME
CACNVA00(R)
//
4. Load the native VSAM CCA by modifying and submitting CACNVASM of SCACSAMP with
the SVCMGR LD function enabled, as shown in Figure 56.
a. Specify the load module name CACNVA00 that you linked in the previous step.
b. Un-comment the line for the LD function, and specify the data set name where the
load module resides.
Figure 56. Sample JCL CACNVASM that loads the native VSAM CCA
//USRTINSN JOB (3WCA,376),'INTEGRATION',CLASS=A,
Configuring WebSphere Classic Replication for z/OS
Page 50
//
MSGCLASS=X,NOTIFY=&SYSUID
//********************************************************************
//*
*
//*
JOB CONTROL STATEMENTS TO INVOKE SVC INSTALL MANAGER.
*
//*
*
//*
1) PROVIDE A JOB CARD THAT IS VALID FOR YOUR SITE
*
//*
2) CHANGE CAC PARM TO INSTALLED HIGH LEVEL QUALIFIER
*
//*
*
//*
NOTES:
*
//*
*
//*
- THE STEPLIB DATASET THAT CONTAINS THE CACNVAIN LOAD MODULE
*
//*
MUST BE AUTHORIZED.
*
//*
*
//*
- THE MODULE TO BE LOADED (CACNVA00) MUST EXIST IN LPA PRIOR
*
//*
TO INVOKING THE SVC INSTALL MANAGER.
*
//*
*
//*
- THE VARIABLES BELOW MUST BE SET TO THE CORRECT VALUES AND
*
//*
ALL PARMSTR SET STATEMENTS MUST BE COMMENTED OUT EXECPT THE *
//*
ONE TO BE USED FOR THE EXEC STATEMENT.
*
//*
*
//********************************************************************
//*
//*-------------------------------------------------------------------//* SVCMGR PROC
//*-------------------------------------------------------------------//*
//SVCMGR PROC CAC='USRT001'
INSTALLED HIGH LEVEL QUALIFIER
//*
//SVCMGR EXEC PGM=CACNVAIN,PARM=
//STEPLIB DD DISP=SHR,DSN=&CAC..V9R1M00.SCACLOAD
//SYSPRINT DD SYSOUT=*
//
PEND *
//*
//*============================================
//* VARIABLES
//*============================================
//*
//
SET MODNAME=CACNVA00
//
SET USRNAME=''
//
SET JOBNAME=''
//*
//*============================================
//* Run the SVC Manager
//*============================================
//*
//SVCMGR EXEC SVCMGR,PARM='LD,M=&MODNAME,DS=USRT001.V9R1M00.SCACLOAD'
//*SVCMGR EXEC SVCMGR,PARM='RM,M=&MODNAME'
//*SVCMGR EXEC SVCMGR,PARM='EN,M=&MODNAME,FL=A'
//*SVCMGR EXEC SVCMGR,PARM='DI,M=&MODNAME,FL=A'
//*SVCMGR EXEC SVCMGR,PARM='SF,M=&MODNAME,U=&USRNAME,J=&JOBNAME'
//*SVCMGR EXEC SVCMGR,PARM='QU,ALL'
//
Configuring WebSphere Classic Replication for z/OS
Page 51
14 Run replication
In this section, you start and run the replication environment. See Figure 3 for a summary of the
stages in the setup process.
To run replication:
1. Stop the data server.
The server was already running for the configuration tasks. Once you stop the server, you
can cold start the newly-configured environment.
Another reason this step is necessary is because the CAPPARMS are only exchanged
between the CS and DS on the initial connection, and they were not defined when the CS
and DS last connected. You need another start to ensure that the CAPPARMS information
is sent. Shut down the data server by issuing the following MTO command from SDSF:
/STOP <serverjobname>
In this scenario, the job name is USRT01CS and the command was issues as shown in
Figure 57.
Never cancel the server job directly from SDSF. The controlled shutdown that the STOP
command provides is necessary to bring down all services safely and to avoid problems
when restarting. This is especially important for restarting the CS.
Figure 57. MTO command to stop the data server
Display Filter View Print Options Help
-----------------------------------------------------------------------------SDSF STATUS DISPLAY ALL CLASSES
LINE 1-2 (2)
COMMAND INPUT ===> /STOP USRT01CS
SCROLL ===> HALF
NP
JOBNAME JobID
Owner
Prty Queue
C Pos SAff ASys Status
USRT01CS JOB07197 USRT001
6 EXECUTION A
SYE9
USRT001 TSU07083 USRT001
15 EXECUTION
SYE9 SYE9
F1=HELP
F7=UP
F2=SPLIT
F8=DOWN
F3=END
F9=SWAP
F4=RETURN
F10=LEFT
F5=IFIND
F11=RIGHT
F6=BOOK
F12=RETRIEVE
2. Start the NS.
The JCL is CACCNS of SCACSAMP. The JCL takes the NS configuration file CACCNSCF,
which you configured in the “Configure the name service” section, as input. Modify it as
shown in Figure 58.
Configuring WebSphere Classic Replication for z/OS
Page 52
If you recycle the replication environment later, you do not need to restart the NS.
Figure 58. Sample JCL CACCNS to start the name service
//USRT01NS JOB (3WCA,376),'QA ID',CLASS=A,MSGCLASS=X,
//
MSGLEVEL=(1,1),NOTIFY=&SYSUID,REGION=0M
//********************************************************************
//*
*
//*
NAME: CACCNS
*
//*
SAMPLE CLASSIC NAME SERVICES JCL
*
//*
*
//*
1) CHANGE CAC PARM TO INSTALLED HIGH LEVEL QUALIFIER
*
//*
2) CHANGE CONFIG PARM TO THE APPROPRIATE CONFIG MEMBER
*
//*
*
//********************************************************************
//CACCNS
PROC CAC='USRT001',
INSTALLED HIGH LEVEL QUALIFIER
//
CONFIG=CACCNSCF,
PCI SERVER CONFIGURATION
//
DISKU=SYSDA,
DASD UNIT
//*
DISKVOL=DEM001,
DASD VOLSER
//
SOUT='*',
SYSOUT CLASS
//
RGN=6M
REGION SIZE
//*
//IEFPROC EXEC PGM=CACCNTL,TIME=1440,REGION=&RGN
//STEPLIB DD DISP=SHR,DSN=&CAC..V9R1M00.SCACLOAD
//VHSCONF DD DISP=SHR,DSN=&CAC..V9R1M00.SCACCONF(&CONFIG)
//CTRANS
DD DISP=SHR,DSN=&CAC..V9R1M00.SCACSASC
//*
//SYSOUT
DD SYSOUT=&SOUT
//SYSTERM DD SYSOUT=&SOUT
//SYSPRINT DD SYSOUT=&SOUT
//SYSMDUMP DD DUMMY
//CACLOG
DD DISP=(NEW,PASS,KEEP),DSN=&&LOG,
//
UNIT=&DISKU,SPACE=(TRK,(60,30))
//*
//* PRINT OUT THE LOG SUMMARY
//*
//LOGSUM
EXEC PGM=CACPRTLG,PARM='SUMMARY=Y',COND=EVEN
//STEPLIB DD DISP=SHR,DSN=&CAC..V9R1M00.SCACLOAD
//VHSCONF DD DISP=SHR,DSN=&CAC..V9R1M00.SCACCONF(&CONFIG)
//ENGCAT
DD DISP=SHR,DSN=&CAC..V9R1M00.SCACMENU
//CTRANS
DD DISP=SHR,DSN=&CAC..V9R1M00.SCACSASC
//CACLOG
DD DISP=(OLD,PASS),DSN=&&LOG
//SYSTERM DD SYSOUT=&SOUT
//SYSPRINT DD SYSOUT=&SOUT
//SYSIN
DD DUMMY
//*
//* PRINT OUT THE LOG
//*
//LOGPRINT EXEC PGM=CACPRTLG,PARM='SUMMARY=N',COND=EVEN
//STEPLIB DD DISP=SHR,DSN=&CAC..V9R1M00.SCACLOAD
//VHSCONF DD DISP=SHR,DSN=&CAC..V9R1M00.SCACCONF(&CONFIG)
//ENGCAT
DD DISP=SHR,DSN=&CAC..V9R1M00.SCACMENU
//CTRANS
DD DISP=SHR,DSN=&CAC..V9R1M00.SCACSASC
//CACLOG
DD DISP=(OLD,DELETE),DSN=&&LOG
//SYSTERM DD SYSOUT=&SOUT
Configuring WebSphere Classic Replication for z/OS
Page 53
//SYSPRINT DD SYSOUT=&SOUT
//SYSIN
DD DUMMY
//
PEND
//CACCNS EXEC CACCNS
3. Enable the native VSAM CCA.
Modify CACNVASM of SCACSAMP PDS and submit the job. Comment out the LD function
you used earlier and activate the EN function to enable the agent. Revise the text
highlighted in blue in Figure 59.
Figure 59. CACNVASM sample JCL to start the native VSAM CCA
//USRTINSN JOB (3WCA,376),'INTEGRATION',CLASS=A,
//
MSGCLASS=X,NOTIFY=&SYSUID
//********************************************************************
//*
*
//*
JOB CONTROL STATEMENTS TO INVOKE SVC INSTALL MANAGER.
*
//*
*
//*
1) PROVIDE A JOB CARD THAT IS VALID FOR YOUR SITE
*
//*
2) CHANGE CAC PARM TO INSTALLED HIGH LEVEL QUALIFIER
*
//*
*
//*
NOTES:
*
//*
*
//*
- THE STEPLIB DATASET THAT CONTAINS THE CACNVAIN LOAD MODULE
*
//*
MUST BE AUTHORIZED.
*
//*
*
//*
- THE MODULE TO BE LOADED (CACNVA00) MUST EXIST IN LPA PRIOR
*
//*
TO INVOKING THE SVC INSTALL MANAGER.
*
//*
*
//*
- THE VARIABLES BELOW MUST BE SET TO THE CORRECT VALUES AND
*
//*
ALL PARMSTR SET STATEMENTS MUST BE COMMENTED OUT EXECPT THE *
//*
ONE TO BE USED FOR THE EXEC STATEMENT.
*
//*
*
//********************************************************************
//*
//*-------------------------------------------------------------------//* SVCMGR PROC
//*-------------------------------------------------------------------//*
//SVCMGR PROC CAC='USRT001'
INSTALLED HIGH LEVEL QUALIFIER
//*
//SVCMGR EXEC PGM=CACNVAIN,PARM=
//STEPLIB DD DISP=SHR,DSN=&CAC..V9R1M00.SCACLOAD
//SYSPRINT DD SYSOUT=*
//
PEND *
//*
//*============================================
//* VARIABLES
//*============================================
//*
//
SET MODNAME=CACNVA00
//
SET USRNAME=''
//
SET JOBNAME=''
Configuring WebSphere Classic Replication for z/OS
Page 54
//*
//*============================================
//* Run the SVC Manager
//*============================================
//*
//*SVCMGR EXEC SVCMGR,PARM='LD,M=&MODNAME,DS=USRT001.V9R1M00.SCACLOAD'
//*SVCMGR EXEC SVCMGR,PARM='RM,M=&MODNAME'
//SVCMGR EXEC SVCMGR,PARM='EN,M=&MODNAME,FL=A'
//*SVCMGR EXEC SVCMGR,PARM='DI,M=&MODNAME,FL=A'
//*SVCMGR EXEC SVCMGR,PARM='SF,M=&MODNAME,U=&USRNAME,J=&JOBNAME'
//*SVCMGR EXEC SVCMGR,PARM='QU,ALL'
//
4. Start the data server by submitting the already configured CACCS JCL.
5. Start Q Apply by submitting the already configured ASNQSTRA JCL.
The replication environment is now running. Since you are cold starting the CS, the
subscription SUBSCLASSIC1 you previously created activates automatically. The initial load
takes place automatically upon activation of the subscription. If the load completes
successfully, the subscription state changes to Active.
6. Verify the status of the subscription in the SYSTERM output of the data server job
(USRT01CS in this scenario).
Look in the job output for this activation confirmation for your subscription:
RECEIVED ACTIVATE CONFIRMATION FOR SUB <SUBSCLASSIC1>
7. Ensure that the load was successful.
For subscriptions set up for automatic load, you can verify the load by checking the job
output for LOADDONE message processing. Look for the following verification messages:
RECEIVED LOADDONE FOR SUB <SUBSCLASSIC1>
RECEIVED LOADDONE CONFIRMATION FOR SUB <SUBSCLASSIC1>
Use ASNCLP to deactivate subscriptions by running the appropriate deactivation command. You
can also use an MTO command. See the Q replication and Classic replication guide for details.
Any change that legacy applications make to the VSAM source cluster USRT001.VSAM.
EMPLOYEE changes the DB2 target table USRT001.EMPLOYEE_CPY accordingly. If your
production environment is offline and to verify your setup, there is another way to make changes
against the VSAM source. If you run SQL Data Manipulation Language (DML) against the mapped
USRT001.EMPLOYEE source table, the CCA captures the changes. Use the connection that you
created previously (TRAINSAMP in this scenario) to run your SQL statements from the CDA SQL
Editor. Figure 60 shows a sample statement. For information about using the SQL Editor, refer to
the “Generate control table mappings” section.
Configuring WebSphere Classic Replication for z/OS
Page 55
Figure 60. Sample insert statement
You can also use CDA to verify if changes are correctly applied to the target table. In the database
explorer, select and expand the DB2 UDB zSeries connection (DSN1 in this scenario). Expand the
list of schemas and look for your schema name (USRT001 in this scenario). Expand the schema
item, expand tables, and look for your target table (EMPLOYEE_CPY in this scenario). Right-click
on the target table, and click Data in the menu. Select Sample Contents in the submenu, as shown
in Figure 61.
Configuring WebSphere Classic Replication for z/OS
Page 56
Figure 61. Retrieve table content
The data output window appears in your workspace showing the results set with the newly inserted
row, as shown in Figure 62.
Configuring WebSphere Classic Replication for z/OS
Page 57
Figure 62. Sample result set
You can also use MTO commands to verify the replication setup and to monitor the production
environment while it is running. The following section shows some key examples. For the complete
list of administration options, refer to the Classic Event Publishing Guide and Reference, document
number GC19-1125-00.
Due to the length of the commands, it is recommended to bring up the command extension panel by
typing ‘/’ from SDSF before issuing them.
1. Issue the REPORT command against the CS in SDSF to display CS activity. The activity
report displays:
•
•
The number of active agents
The number of changes agents intercepted
The command syntax is:
F <data server job name>,CMD,<correlation service name>,’REPORT’
If you did not specify a correlation service name after CACECA2 in the CS service info
entry, use the name of the cross memory queue that is used for communication between the
native VSAM CCA and the CS.
Here is an example REPORT command for this scenario:
F USRT01CS,CMD,XM1/CCM1/CCQ1/512,’REPORT’
Configuring WebSphere Classic Replication for z/OS
Page 58
The JES2 output is shown in Figure 63.
Figure 63. Correlation service activity report
18.51.11
18.51.11
18.51.11
18.51.11
18.51.11
18.51.11
18.51.11
JOB09323
JOB09323
JOB09323
JOB09323
JOB09323
JOB09323
JOB09323
18.51.11 JOB09323
CAC00200I CMD, XM1/CCM1/CCQ1/512,’REPORT’
CACG150I CORRELATION SERVICE ACTIVITY REPORT
******** Transactions *********
Agent
Processed Sent
Pending
---------------- --------- --------- --------NVA_05_236297634 000000001 000000001 000000000
CACG151I END OF REPORT, AGENT TOTAL=1
State
-------Active
CACG152I PENDINGQ(0) MSGQ(0) UORS(0) MSGS(1)
2. Issue the REPORT command against the distribution service to display information about
subscriptions. The resulting activity report contains information about the number of
received change messages and their processing, and metrics for all subscriptions per
subscription. For data sources other than native VSAM this command also displays commit
information. The syntax is:
F <data server job name>,CMD,<distribution service name>,’REPORT,CMF’
Issue the following command from SDSF:
F USRT01CS,CMD,USRT01DIST,’REPORT,CMF’
The JES2 output is shown in Figure 64.
Figure 64. Distribution service activity report for subscriptions
18.57.29
18.57.29
18.57.29
18.57.29
18.57.29
18.57.29
18.57.29
18.57.29
18.57.29
18.57.29
18.57.29
18.57.29
18.57.29
18.57.29
18.57.29
18.57.29
JOB09323
JOB09323
JOB09323
JOB09323
JOB09323
JOB09323
JOB09323
JOB09323
JOB09323
JOB09323
JOB09323
JOB09323
JOB09323
JOB09323
JOB09323
JOB09323
CAC00200I CMD,USRT01DIST,’REPORT,CMF’
CACJ001I DISTRIBUTION SERVICE ACTIVITY REPORT
-------------------------------------------Change Message(s) Received = 1
Commit Message(s) Received = 0
Message(s) Sent = 1
Message(s) Staged = 0
Total Message(s) Staged = 0
-------------------------------------------CACJ028I DISPLAY CURRENT CMF WRITER INFORMATION
SUB NAME
TYPE STAT TABLE NAME
CHANGES INSERTS UPDATES DELETES
============= ==== ==== ================ ======= ======= ======= =======
SUBSCLASSIC1
CMF ACT USRT001.EMPLOYEE
1
1
0
0
TOTALS
CMF ---- ALL
1
1
0
0
============= ==== ==== ================ ======= ======= ======= =======
Displayed 1 of 1 apply entries
3. Issue the DISPLAY command against the distribution service to display metrics about a
specific subscription name you specify. The syntax of this command is:
F <data server job name>,CMD,<distribution service name>, ’DISPLAY,
SUB, NAME=<subscription name>’
Configuring WebSphere Classic Replication for z/OS
Page 59
Here is an example DISPLAY command for this scenario:
F USRT01CS,CMD,USRT01DIST,’DISPLAY,SUB,NAME=SUBSCLASSIC1’
The JES2 output is shown in Figure 65.
Figure 65: Subscription metrics
12.52.30
12.52.30
12.52.30
12.52.30
12.52.30
12.52.30
12.52.30
12.52.30
12.52.30
12.52.30
12.52.30
12.52.30
12.52.30
12.52.30
12.52.30
12.52.30
12.52.30
JOB09750
JOB09750
JOB09750
JOB09750
JOB09750
JOB09750
JOB09750
JOB09750
JOB09750
JOB09750
JOB09750
JOB09750
JOB09750
JOB09750
JOB09750
JOB09750
JOB09750
CAC00200I CMD,USRT01DIST,’DISPLAY,SUB,NAME=SUBSCLASSIC1’
***** Subscription Name (SUBSCLASSIC1) *****
Owner Name
= 'USRT001'
Table Name
= 'EMPLOYEE'
Sub Type
= 'U'
Topic Name
= '_'
Before Values
= 'N'
Changed Cols Only = 'Y'
Ord #
= 2
Seq #
= 0
Session Handle
= 1
INS(S)
= 1
UPD(S)
= 0
DEL(S)
= 0
COMMIT(S)
= 0
STATE
= 0
Total Number Of Sub(s) = 1
15 Conclusion
In this article, you learned how to use Classic Replication to replicate VSAM data to DB2 targets.
This technology can be used to replicate from Classic supported data sources to a relational
database management system (RDBMS) supported by Q Replication. This technology can be used
to populate and maintain data warehouses, maintain replicas of data for disaster recovery and data
migration. It can also be used to move legacy data to RDBMSs for Web application servers to
access the data using the SQL interfaces. This can also be achieved in a federated manner using a
sister product, Classic Federation.
Credits
We especially want to thank the following people for
their contributions in supporting this residency and/or
for their technical review:
Anuradha Iruku
Sameera Memon
Lakshmi Palaniappan
Sharon Roeder
Gregg Upton
Charles Weigel
Austin Willoughby
Thanks to the following people for their contributions to
this project by providing technical help and/or technical
review:
Michael Alper
Paul Cadarette
Andre Corbeil
R’Jane Fernandez
John Griffin
Donna Hodge
Gig Kirk
Craig Knutson
Bob Love
Ralph Rinke
Joseph Scully
© IBM Corporation 2005
IBM Corporation
Systems and Technology Group
Route 100
Somers, New York 10589
Produced in the United States of America
12 - 2005
All Rights Reserved
This document was developed for products and/or
services offered in the United States. IBM may not
offer the products, features, or services discussed in
this document in other countries.
The information may be subject to change without
notice. Consult your local IBM business contact for
information on the products, features and services
available in your area.
All statements regarding IBM future directions and
intent are subject to change or withdrawal without
notice and represent goals and objectives only.
IBM, the IBM logo, the e-business logo, z/OS, IMS,
CICS, and WebSphere are trademarks or registered
trademarks of International Business Machines
Corporation in the United States or other countries or
both. A full list of U.S. trademarks owned by IBM may
be found at:
http://www.ibm.com/legal/copytrade.shtml.
UNIX is a registered trademark of The Open Group in
the United States, other countries or both.
Linux is a trademark of Linus Torvalds in the United
States, other countries or both.
Microsoft, Windows, Windows NT and the Windows
logo are registered trademarks of the Microsoft
Corporation.
Java and all Java-based trademarks and logos are
trademarks of Sun Microsystems, Inc. In the United
States and/or other countries
Other company, product, and service names may be
trademarks or service marks of others.
Copying or downloading the images contained in this
document is expressly prohibited without the written
consent of IBM.
Information concerning non-IBM products was
obtained from the suppliers of these products or other
public sources. Questions on the capabilities of the
non-IBM products should be addressed with those
suppliers.
The IBM home page on the Internet can be found at:
http://www.ibm.com.
The IBM WebSphere home page on the Internet can
be found at:
http://www-306.ibm.com/software/websphere.
Fly UP