IBM Integration Bus, Version 10.0.0.5 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS


Setting up a shared queue on z/OS for the SAP adapter event store

To achieve high availability when processing SAP messages on z/OS®, you can set up a shared queue for the SAP adapter event store.

Before you begin

Ensure that the queue-sharing group name that you are planning to use does not exist in SYS1.PARMLIB(IEFSSNxX). If the name does exist, choose a different name for the new group.

About this task

You can find the data set members, which are referred to in the following steps, as samples in the thlqual.SCSQPROC library, unless stated otherwise. The library is supplied with WebSphere® MQ for z/OS. For important information about using WebSphere MQ with IBM® Integration Bus, see Installing WebSphere MQ.

Procedure

  1. Review your DB2® data-sharing requirements. The queue-sharing group is backed by a DB2 data sharing group. Add entries to DB2 for WebSphere MQ by completing the following steps.
    1. Customize the CSQ4INSS data set member with the structure names and ensure that it is included in the CSQINP2 DD concatenation for one queue manager in the queue-sharing group.
    2. To amend the QSGDATA system parameter, amend and rerun the CSQ4ZPRM sample in the format (Qsgname,Dsgname,Db2name,Db2servers).
    3. Copy, customize, and run the following sample JCLs. These jobs need to be run only once for each DB2 subsystem or data-sharing group.
      1. Customize and run sample JCL CSQ45CSG to create the storage group that is to be used for the WebSphere MQ database, table spaces, and tables.
      2. Customize and run sample JCL CSQ45CDB to create the database to be used by all queue managers that connect to this DB2 data-sharing group.
      3. Customize and run sample JCL CSQ45CTS to create the table spaces to contain the queue manager and channel initiator tables that are used for queue-sharing groups (created in step i).
      4. Customize and run sample JCL CSQ45CTB to create the twelve DB2 tables and associated indexes. Do not change any of the row names or attributes.
      5. Customize and run sample JCL CSQ45BPL to bind the DB2 plans for the queue manager, utilities, and channel initiator.
      6. Customize and run sample JCL CSQ45GEX to grant execute authority to the respective plans for the user IDs that will be used by the queue manager, utilities, and channel initiator. The user IDs for the queue manager and channel initiator are the user IDs under which their started task procedures run. The user IDs for the utilities are the user IDs under which the batch jobs can be submitted. For more information about the names of the appropriate plans, see the WebSphere MQ Version 7.5 product documentation online.
  2. Create a queue-sharing group by completing the following steps.
    1. Define the Coupling Facility structures that are used by the queue managers in the queue-sharing group.
      Define the administration and application structures in the Coupling Facility Resource Management (CFRM) policy data set for the z/OS Sysplex that will host the queue sharing group, as shown in the following example, where MQPU is the queue-sharing name.
      STRUCTURE NAME(MQPUCSQ_ADMIN)  	
      SIZE(20000)  	
      INITSIZE(10000)  	
      PREFLIST(PUCF01)   	
      
      STRUCTURE NAME(MQPUAPPLICATION1) 	
      SIZE(20000)  	
      INITSIZE(10000)  	
      PREFLIST(PUCF01) 
      For more information about setting up the Coupling Facility, see the WebSphere MQ Version 7.5 product documentation online.
    2. Define each of the queue-sharing groups to DB2 by using the ADD QSG function of the queue-sharing group utility (CSQ5PQSG). Sample CSQ45AQS is provided in the SCSQPROC library. Run the sample once for each queue-sharing group.
    3. Define each of the queue managers to DB2 by using the ADD QMGR function of the queue-sharing group utility CSQ5PQSG. Sample CSQ45AQM is provided in the SCSQPROC library. Run the sample for every member of a queue-sharing group.
    4. To activate the changes that you have made, stop and start all the queue managers in the group.
  3. Define the SAP event store queue in the queue sharing group.

    Typically, creating an event store queue is the most effective method. If you are migrating from a previous integration node, ensure that any outstanding SAP requests have been resolved before you move to the new topology.

    1. To create a shared queue, run the following command on one of the queue managers only:
      DEFINE QL(SYSTEM.BROKER.ADAPTER.SHARED)
      LIKE(SYSTEM.BROKER.ADAPTER.PROCESSED) CFSTRUCT(NEW) QSGDISP(SHARED) SHARE DEFSOPT(SHARED)
    2. To allow other queue managers that have been added to the group to use the shared queue, delete their locally defined queues by running the following command on each of those queues:
      DELETE QLOCAL(SYSTEM.BROKER.ADAPTER.PROCESSED) QSGDISP(QMGR)
  4. Configure the integration node.
    1. Create an SAPConnection configurable service for the .inadapter component by using the mqsicreateconfigurableservice command.
    2. Set the sharedTidStoreQueueManger parameter to the name of the queue manager of the integration node.

      For more information about this parameter, see SAPConnection configurable service.

  5. Verify the setup.

    After you have completed these steps, you can verify that the integration node is using the queue as a shared TID store by inspecting user trace. If the setup is successful, message BIP3470 is issued, specifying which queue manager the integration node is using as the TID store.

Results

IBM Integration Bus first attempts to open the SYSTEM.BROKER.ADAPTER.SHARED queue. If that queue is unavailable, IBM Integration Bus opens the SYSTEM.BROKER.ADAPTER.PROCESSED queue instead. The availability of the SYSTEM.BROKER.ADAPTER.SHARED queue indicates that you are operating in a z/OS high availability environment.


bc22190_.htm | Last updated 2016-06-25 08:08:29