WebSphere logo Classic Federation Server for z/OS, Version 9.1
WebSphere logo Classic Replication Server for z/OS, Version 9.1
WebSphere logo Classic Data Event Publisher for z/OS, Version 9.1
WebSphere logo Data Integration Classic Connector for z/OS, Version 9.1


Specifying the WebSphere MQ objects to use for change capture

WebSphere® MQ is the means of transporting messages in both Classic event publishing and Classic replication. One message queue, called the administration queue, is used for administrative tasks for change capture. Another message queue, called the restart queue, is used for data recovery tasks.

About this task

You must specify the name of the WebSphere MQ queue manager that will manage all of the send queues, the name of the administration queue, and the name of the restart queue in your configuration.

Procedure

To specify the WebSphere MQ objects that you want to use for change capture:

  1. Open the Configure WebSphere MQ Values wizard. To open the wizard, in the Database Explorer right-click the data server where you plan to create your publications or subscriptions. Select Configure WebSphere MQ Values.
  2. In the wizard, specify the names of the following objects:
    Queue manager
    The WebSphere MQ program that manages the queues that you will use as the restart queue, administration queue, and send queues.
    Restart queue
    The queue that holds restart information that is required if change capture goes into recovery mode. This queue is also called the in-doubt resolution queue.
    Administration queue (for Classic replication only)
    A queue that receives control messages from a Q Apply program or ASNCLP.
  3. Specify a value in milliseconds for the commit interval. The default is 500 milliseconds.

    The commit interval specifies how often, in milliseconds, a publication service commits transactions to WebSphere MQ. At each interval, the publication service issues an MQCMIT call. This call signals the WebSphere MQ queue manager to make messages that were placed on send queues available to the Q Apply program (in Classic replication) or other user applications (in Classic event publishing).

    All of the transactions that are grouped within an MQCMIT call are considered to be a WebSphere MQ unit of work, or transaction. Typically, each WebSphere MQ transaction contains several transactions. If a transaction is large, the publication service will not issue an MQCMIT call even if the commit interval is reached. The publication service will commit only after the entire large transaction is put on the send queue.

    Finding the best commit interval is a compromise between latency (the delay between the time that transactions are committed at the source and target databases) and CPU overhead that is associated with the commit process:

    • To reduce latency, shorten the commit interval.

      Transactions will be pushed through with less delay. Reduced latency is especially important if changes are used to trigger events (in Classic event publishing).

    • To reduce CPU overhead, lengthen the commit interval.

      A longer commit interval lets you send as many transactions as possible for each WebSphere MQ transaction. If you lengthen the commit interval, you might be limited by the maximum depth (number of messages) for send queues and by the queue manager's maximum uncommitted messages (MAXUMSGS) attribute. If a publication service waits longer between commits, the publication of some transactions might be delayed, which could increase latency.

Related concepts
Specifying the WebSphere MQ objects to use for change capture
Related tasks
Creating and modifying publishing queue maps for Classic event publishing


Feedback

Update icon Last updated: 2006-12-15