Redpaper - IBM Redbooks

IP13 Statistics MVSM0 MVSM2 Total
Broker Statistics WMQ0BRK WMQ2BRK
Total Number Input Messages 23098 unknown 23098
Total Elapsed Time (seconds) 224.622 unknown
Total CPU Time (seconds) 76.918 unknown
Conclusions
From the results, we concluded:
► Again, the statistics message is dumped by the broker so no statistics are
available for WMQ2BRK. Cancelling the broker caused multiple SVC dumps
to be taken and CPU usage was at 100% on MVSM2 for some time. This
explains why the transaction rate for MVSM2 is less than half of MVSM0.
► 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 WMQ2BRK is down.
4.5 Scenario 4 - Queue manager failover
Scenario 4 tests the failure of WMQ2 queue manager. The failure was simulated
by issuing a MVS cancel command (WMQ2STOP QMGR MODE(RESTART) as illustrated
in Figure 4-4 on page 43. The ARM policy in effect ensures the queue manager
restarts immediately. Upon successful queue manager startup, the Message
Broker dynamically reconnects to the queue manager and issues the following
message to the MVS log:
+BIP2091I WMQ2BRK 0 The broker has reconnected to WebSphere Business
Integration successfully. : ImbAdminAgent(1095)
The OEMPUTX batch job does not reconnect to the queue manager after a
failure, so for this test the batch job was submitted only on MVSM0.
42 High Availability z/OS Solutions for WebSphere Business Integration Message Broker V5