WebSphere Classic Replication Server for z/OS (Release 9.1) – VSAM capture
by user
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.