Redpaper - IBM Redbooks

More documents

Recommendations

Info

4.1 Test environment setup As previously mentioned, the SupportPac IP13 batch job (OEMPUTX) was used to drive a message load to a shared queue. Note: For further information about all components of the <strong>IBM</strong> Category 2 SupportPac IP13 refer to the documentation available from: http://www-306.ibm.com/software/integration/support/supportpacs/ The SupportPac IP13 message flow (DB2U) running on both brokers consumed these messages, then placed reply messages on a second shared queue. The reply messages were subsequently picked up by OEMPUTX, completing the request-reply loop. Statistics generated by OEMPUTX were compared to statistics generated by the Message Broker and the results evaluated. The DB2U message flow also updates a DB2 database called SHAREPRICES. We executed all test scenarios at least three times to provide reasonable accuracy in reporting statistics. Transaction rates for the applications (running on the MVSM0 and MVSM2 LPARs) and the brokers (WMQ0BRK, WMQ2BRK) can be compared only within a given test scenario. Comparison of these rates between test scenarios is meaningless. 4.1.1 SupportPac IP13 setup This section provides details on the SupportPac IP13 setup. DB2 configuration JCL is supplied with SupportPac IP13 to both set up the application environment and run the tests. Job JDB2DEFS creates a DB2 SHAREPRICES table and inserts some initial data. Since this table is unique, the JDB2DEFS job should only be run once. However, the JCL in this job would normally create the table by taking the user ID of one broker as the schema name. When the other broker later tries to access the table, it refers to it by taking a different user ID, under which it runs, as the schema. This is because in each broker’s dsnaoini file the CURRENTSQLID is set to the user ID of that broker. So, the second broker is not able to access the table. To avoid this problem in the environment for this book, broker 2 was given authority to set its CURRENTSQLID to the user ID of broker 0. However, a better 34 High Availability z/OS Solutions for WebSphere Business Integration Message Broker V5
solution for setting up SupportPac IP13 for running in a sysplex is to follow the steps below: 1. Create a new RACF group that will be the schema name for the unique SupportPac IP13 DB2 table. 2. Connect the user IDs under which the broker started tasks run to the previously created RACF group. 3. Create the SupportPac IP13 SHAREPRICES table using job JBDB2DEFS, inserting the new RACF group name as the schema. 4. SET CURRENTSQLID in the ESQL of the mesageflow. See DB2U message flow configuration below for details. OEMPUTX batch job configuration There are several parameters that can be passed to OEMPUTX in order to cause different behavior of the application. The parameters we chose for our testing included: -n25000 Total number of messages to put, in this case 25000. -m4 Causes the program to run for four minutes. In the test environment, no single broker was capable of processing 25000 messages within four minutes, so these first two parameters provided a steady-state message flow rate. -gm Causes OEMPUTX to use same MQMD.MsgId for all MQPUTs in the loop, and MQGET replies by this MsgId. With this option, there is no Message Broker affinity. -w45 Sets the MQGET MQMD.WaitInterval to wait_time seconds. -c Commit every msgs_in_loop messages. msgs-in-loop was not set and the default is one message per batch. We also used non-persistent messages. DB2U message flow configuration Recall that in each broker’s dsnaoini file, the CURRENTSQLID is set to the user ID of that broker. This configuration would normally prevent brokers from accessing DB2 tables outside of their schema. To circumvent this behavior: ► Add the following line of ESQL to the DB2U message flow to set the CURRENTSQLID to the RACF group name created for the SupportPac IP13 SHAREPRICES table (see Chapter 3, “Topology and system setup” on page 21). This value has to have single quotes surrounding it for z/OS DB2 to process it correctly, as shown in the example below: PASSTHRU('SET CURRENT SQLID= ''SYSDSP'''); Chapter 4. Failover scenarios 35
Page 1: High Availability z/OS Solutions fo
Page 4 and 5: Note: Before using this information
Page 6 and 7: 3.7 Automatic Restart Management co
Page 8 and 9: Trademarks The following terms are
Page 10 and 11: From left: Dean, Steve, and Jon Dea
Page 12 and 13: Become a published author Join us f
Page 14 and 15: 1.1 Project overview This paper exp
Page 16 and 17: e compromised while the failing com
Page 18 and 19: Figure 1-2 Test environment topolog
Page 20 and 21: Message Broker is a WebSphere MQ an
Page 22 and 23: 2.1 Considerations when designing f
Page 24 and 25: Table 2-1 Advantages and disadvanta
Page 26 and 27: Advantages Disadvantages Uses the a
Page 28 and 29: In this instance, you should consid
Page 30 and 31: of messages making up a transaction
Page 32 and 33: 20 High Availability z/OS Solutions
Page 34 and 35: 3.1 High Availability configuration
Page 36 and 37: 3.3 The z/OS LPARs There are three
Page 38 and 39: ► Review actual structure sizes r
Page 40 and 41: pool is not available, errors occur
Page 42 and 43: 3.7 Automatic Restart Management co
Page 48 and 49: ► In a production environment, yo
Page 50 and 51: The batch jobs provided work for th
Page 52 and 53: IP13 Statistics MVSM0 MVSM2 Total B
Page 58 and 59: z/OS DB2 (DSG) QMGR (QSG) Message B
Page 62 and 63: ARM policy Example A-1 displays the
Page 66 and 67: Using the Web material The addition
Page 70 and 71: How to get IBM Redbooks You can sea
Page 72: U UNIX System Services (USS) enviro

Redpaper - IBM Redbooks

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?