Redpaper - IBM Redbooks

IP13 Statistics MVSM0 MVSM2 Total
Broker Statistics WMQ0BRK WMQ2BRK
Total Number Input Messages 17051 12010 29061
Total Elapsed Time (seconds) 181.542 124.319
Total CPU Time (seconds) 61.153 42.033
Conclusions
From the results, we concluded the following:
► At first glance, it would seem as though messages were lost under this test,
but this is not the case for this or any other test scenario. When the execution
group is cancelled, the statistics message is dumped by the broker. Upon
successful execution group startup, a new statistics message is created, the
interval time is reset, and accounting starts fresh. Since the execution group
was cancelled very close to the beginning of the test and it recovered quickly,
there are 735 messages that WMQ2BRK processed that are not accounted
for in the above table.
► The high number of messages consumed by WMQ2BRK underscores the
speed of the execution group recovery.
► The higher number of messages consumed by WMQ0BRK compared to
transactions completed on MVSM0 illustrates how broker 0 processes
messages from the SupportPac IP13 batch jobs on both systems, taking the
extra load while the execution group is down on MVSM2.
4.4 Scenario 3 - Message Broker failover
The third scenario tests the failure of WMQ2BRK Message Broker. The failure
was simulated by issuing a MVS cancel command (C WMQ2BRK,ARMRESTART), as
illustrated in Figure 4-3 on page 41. The ARM policy in effect ensures the broker
restarts immediately. You can find the policy details in Appendix A, “Sample
code” on page 49.
40 High Availability z/OS Solutions for WebSphere Business Integration Message Broker V5