Once the Event Replicator for Adabas has been installed, replication can be implemented and started. How replication is implemented varies greatly by site and situation, but this document describes some general implementation steps.
Replication definitions are used to customize the replication process. These definitions are specified in initialization parameters read from DDKARTE in the Event Replicator Server startup job or in the Replicator system file.
If you want to use Event Replicator initialization parameters to specify the replication definitions that will be read from DDKARTE in the Event Replicator Server startup job, read Event Replicator Server Initialization Parameters.
If you want to use the Adabas Event Replicator Subsystem to maintain the replication definitions in the Replicator system file, access it as described in Accessing the Adabas Event Replicator Subsystem. Be sure also to identify the Replicator system file you want to update as soon as you access the Adabas Event Replicator Subsystem. For information on identifying the Replicator system file using the Adabas Event Replicator Subsystem, read Identifying, Loading, and Unloading the Replicator System File. For information on maintaining definitions using the Adabas Event Replicator Subsystem, read Using the Adabas Event Replicator Subsystem
Once the Event Replicator for Adabas in installed, its replication processing is driven by definitions you specify. These definitions are described in the following table in order of importance to replication (required definitions are listed first).
Note:
You can run Event Replicator for Adabas in verify (test) mode, by turning on verification in
the VERIFYMODE replication definition. This is useful if you want to test the
definitions you have specified before you start using Event Replicator for Adabas in production mode.
For more information, read Running in Verify
Mode.
| Definition Type | Defines | How many definitions are required? |
|---|---|---|
| destination | The destination of the replicated data.
Destination definitions can be created for Adabas, File,
webMethods EntireX, WebSphere MQ, and Null destinations.
To maintain destination definitions using DDKARTE statements of the Event Replicator Server startup job, read Destination Parameter. To maintain destination definitions using the Adabas Event Replicator Subsystem, read Maintaining Destination Definitions. |
Required.
At least one destination definition is required for data replication to occur. Create one definition for every Event Replicator for Adabas destination you intend to use. |
| subscription | A set of specifications to be applied to
the replication of the data. These include (but are not limited to):
Subscription definitions identify SFILE definitions and resend buffer definitions that should be used. At least one SFILE definition is required. To maintain subscription definitions using DDKARTE statements of the Event Replicator Server startup job, read SUBSCRIPTION Parameter. To maintain subscription definitions using the Adabas Event Replicator Subsystem, read Maintaining Subscription Definitions. |
Required.
At least one subscription definition is required for data replication to occur. |
| SFILE | An Adabas file to be replicated and the
replication processing that should occur for that file. SFILE definitions are
sometimes referred to as subscription file definitions and are
referenced by subscription definitions.
An SFILE definition identifies (among other things):
To maintain SFILE definitions using DDKARTE statements of the Event Replicator Server startup job, read SUBSCRIPTION Parameter. To maintain SFILE definitions using the Adabas Event Replicator Subsystem, read Maintaining SFILE Definitions. |
Required.
At least one SFILE definition is required for data replication to occur. |
| initial-state | An initial-state request for data from
the target application. Initial-state definitions identify the subscription,
destination, and specific Adabas files to use in an Event Replicator for Adabas initial-state run.
To maintain initial-state definitions using DDKARTE statements of the Event Replicator Server startup job, read INITIALSTATE Parameter. To maintain initial-state definitions using the Adabas Event Replicator Subsystem, read Maintaining Initial-State Definitions. |
Not required.
If you want initial-state data produced in an Event Replicator for Adabas run, only one initial-state definition is required. Otherwise, no initial-state data definition is required. |
| IQUEUE | The input queue on which Event Replicator for Adabas should
listen for requests from webMethods EntireX and WebSphere MQ targets.
To maintain IQUEUE definitions using DDKARTE statements of the Event Replicator Server startup job, read IQUEUE Parameter. To maintain IQUEUE definitions using the Adabas Event Replicator Subsystem, read Maintaining Input Queue (IQUEUE) Definitions. |
Not required.
At least one IQUEUE definition is required for every EntireX Communicator or WebSphere MQ target you intend to use. If webMethods EntireX or WebSphere MQ are not used, no IQUEUE definition is required. |
| GFB |
A global format buffer (GFB) definition stored separately for use in SFILE definitions. You can specify GFBs manually or generate them using Predict file definitions. When you generate them, a field table is also generated. While a format buffer specification is required in a subscription's SFILE definition, a stored GFB definition does not need to be used. The SFILE definition could simply include the format buffer specifications it needs. To maintain GFB definitions using DDKARTE statements of the Event Replicator Server startup job, read GFORMAT Parameter. To maintain GFB definitions using the Adabas Event Replicator Subsystem, read Maintaining GFB Definitions. |
Not required.
No GFB definition is required. If a global format buffer is needed, at least one GFB definition is required. |
| resend buffer | A resend buffer that can be used by any
subscription to expedite the retransmission of a transaction.
To maintain resend buffer definitions using DDKARTE statements of the Event Replicator Server startup job, read RESENDBUFFER Parameter. To maintain resend buffer definitions using the Adabas Event Replicator Subsystem, read Maintaining Resend Buffer Definitions. |
Not required.
No resend buffer definition is required. If you elect to retransmit a transaction, at least one resend buffer definition is required. |
| transaction filter | A filter definition that can be used to
filter the records used for replication based on the values of fields in those
records.
To maintain transaction filter definitions using DDKARTE statements of the Event Replicator Server startup job, read FILTER Parameter. To maintain transaction filter definitions using the Adabas Event Replicator Subsystem, read Maintaining Transaction Filter Definitions. |
Not required.
No transaction filter definition is required. If you want to use a transaction filter to filter records used in replication, at least one transaction filter definition is required. |
The applicable definitions and the sequence in which they should be set up varies, depending on the destination. Five destinations are supported in the Event Replicator for Adabas: Adabas, webMethods EntireX, IBM WebSphere MQ, File, and Null. The following table describes each of these destination types and lists the definitions that apply to the destination in the order in which they should be defined.
| Destination Type | Description | Definition List and Order of Creation |
|---|---|---|
| Adabas | Data is replicated to one or more Adabas files. |
|
| webMethods EntireX | Replicated data is written to an output queue via webMethods EntireX. |
|
| File | Replicated data is written to the CLOG, using TLOG URBLTDOD records. |
|
| WebSphere MQ | Replicated data is written to an output queue via IBM WebSphere MQ. |
|
| Null | Data replication is tested without actually sending the data to a destination. |
|
Once the replication definitions have been defined for your Event Replicator Server, customize the startup JCL to identify where the replication definitions should be found for the Event Replicator Server run.
Change the setting for the ADARUN parameter RPLPARMS to "BOTH", "FILE", or "PARMS". The RPLPARMS parameter identifies where the replication definitions (initialization parameters) should be read from:
If you have specified and intend to maintain your replication definitions solely in DDKARTE statements of the Event Replicator Server startup job, specify the value of RPLPARMS as "PARMS".
If you have specified and intend to maintain your replication definitions solely in a Replicator system file associated with this Event Replicator Server, specify the value of RPLPARMS as "FILE".
If you have specified and intend to maintain your replication definitions in both DDKARTE statements of the Event Replicator Server startup job and a Replicator system file associated with the Event Replicator Server, specify the value of RPLPARMS as "BOTH".
Note:
In this case, the DDKARTE statements in the Event Replicator Server
startup job are read after the definitions in the Replicator system file.
Therefore the DDKARTE initialization parameter settings will override any
replication definitions in the Replicator system file.
Read Adabas Initialization (ADARUN) Parameters for further details.
If one or more WebSphere MQ queues will be used by the Event Replicator Server, ensure all load libraries in the Event Replicator Server STEPLIB or JOBLIB concatenation are APF-authorized.
If tracing is enabled for a destination class or user exit (using the TRACE keyword parameter of the DCLASSPARM parameter), be sure to include the following JCL statement in the startup JCL of the Event Replicator Server:
//DDTRACE1 DD SYSOUT=X
For more information about the DCLASSPARM parameter, which is valid only for webMethods EntireX or WebSphere MQ destinations, read DCLASSPARM.
If you choose to automate Replay Utility (ADARPL) processing by the Event Replicator Server for specific subscriptions, you need to add the DDJCLIN and DDJCLOUT JCL statements in the Event Replicator Server startup JCL. For complete information on the Event Replicator Server startup JCL updates required for automated ADARPL processing, read Automating Replay Processing.
If appropriate, modify the sample subscription user exit located in the ARFvrs.SRCE library and assemble. Ensure the subscription user exits are in the Event Replicator Server job STEPLIB concatenation. See ARFvrs.JOBS (z/OS), ARFvrs.LIBR (z/VSE), or ARFvrs.SRC (BS2000) for sample job ASMUSERX that can be used to assemble the subscription user exit. Refer to the section entitled Using the Event Replicator Server Subscription User Exit for detailed information on using the exit.
Once the user exit is modified and assembled, it can be called during replication runs. For each combination of subscription and file, the user exit to be called can be specified using the SFSEXIT initialization parameter (file-related parameter of the subscription) in the Event Replicator Server startup job.
Stop and restart the Event Replicator Server to pick up the replication definitions and any subscription user exit specifications you have added.
Note:
If you use a Replicator system file to store your replication
definitions, you can use the RPLREFRESH command to refresh resource definitions
in your Event Replicator Server configuration while the Event Replicator Server is running. For more
information, read RPLREFRESH
Command.
Add the ADARUN parameter REPLICATION=YES to the Adabas nucleus job containing the files available for replication. Add the LRPL parameter for setting the size of the Adabas nucleus replication pool. The replication pool in the Adabas nucleus does not necessarily need to be the same size as the replication pool in the Event Replicator Server. For performance, Software AG recommends setting LRPL to a relatively large value (e.g. LRPL=30M). For more information about these parameters, read Pertinent ADARUN Parameters.
For BS2000 installations, if the database is an Adabas version 8 database, set the ADARUN SUBMPSZ parameter large enough to accommodate the LRPL parameter above. Be sure also to add the ARFvrs.MOD library to the BLSLIB or to the Adabas nucleus to be replicated.
When all modifications have been made, restart the Adabas database.
Start replication processing in any of the following ways, as needed for your organization:
If you need to populate the target database with an initial copy of the data in your Adabas database prior to starting replication, run an Event Replicator initial-state request. For more information about initial-state data, read Replicating an Initial Version of All Your Data.
If you just want to start replicating changed data in the Adabas database, turn replication on for various Adabas files. You can do this in an ADADBS utility run or using Adabas Online System, if it is installed. For more information, read ADADBS REPLICATION Function or Controlling Replication of an Adabas Database File.