Dennis Moore -

For MQ sites looking for ways to improve performance, the recent support of zHyperWrite will likely come as welcome news. Recent versions of Db2 and MQ have provided support for zHyperWrite with the goal of improving overall subsystem performance. zHyperWrite improves response times for log writes in shops that use synchronous replication to ensure a copy of the log exists on a remote secondary device.

In this blog we’ll examine the before-and-after measurements of a recent zHyperWrite implementation for MQ logging in a large z/OS environment.

Importance of MQ Log Performance

Speed of logging is very important to the health and performance of the overall subsystem. For MQ, improved log performance improves scalability and the ability to handle spikes in workload. It also improves the overall efficiency and lowers the cost of operation.

Before zHyperWrite, I/O drivers such as Media Manager would issue a write to the primary device, and the primary would initiate the mirroring to the secondary in a peer-to-peer manner.

With zHyperWrite, the mirroring is initiated concurrently with the primary I/O, speeding up the process. Note that this results in the number of reported writes doubling, since Media Manager is writing to both the primary and secondary device, and the peer-to-peer activity is eliminated. The improvement in response time is greater with short distances between primary and secondary.

Analyzing MQ Log Performance Before and After Implementing zHyperWrite

Figure 1 below shows an example of implementing zHyperWrite in a large MQ environment, with comparison data for key before-and-after metrics.

IntelliMagic Vision report comparing MQ Logging with and without zHyperWrite

Figure 1: IntelliMagic Vision report comparing MQ Logging with and without zHyperWrite


Figure 1 shows MQ logging data for several business days before the zHyperWrite implementation on the left and several business days after implementation, on the right. You can see that the I/O rate doubled, since there are now FICON channel I/Os to both the primary and secondary device. Metro Mirror ops/second are shown in red. These are the ops that were peer to peer from primary to secondary but are now direct writes from the system to the secondary. Notably, the response time was greatly improved, roughly cut in half.

Breaking down the response time components, as shown in Figure 2 below, we can see that the improvement is primarily due to the elimination of disconnect time (the red area).

Implementing zHyperWrite Eliminated Disconnect Time, Improving Response Time

Figure 2: Implementing zHyperWrite Eliminated Disconnect Time, Improving Response Time


Further breaking down the components of disconnect time shows that the improvement comes from eliminating the synchronous copy contribution. This data can be obtained from the type 74 records combined with intelligence built into IntelliMagic Vision. Here is an example of a volume used for MQ logging, not using zHyperWrite.

Figure 3: Name


Note that the overall disconnect time is approximately .2 milliseconds, as we saw at the dataset level in Figure 2 before zHyperWrite. Also note that almost all the disconnect time is the synchronous copy contribution (in red).

In contrast, the Figure 4 shows a volume with MQ logging using zHyperWrite, with essentially zero disconnect time.

Figure 4


The most important bottom-line comparison is the overall response time improvement. Figure 5 shows a 54% improvement for this heavily used MQ subsystem.

MQ Logging Response Time Comparison with and without zHyperWrite

Figure 5: MQ Logging Response Time Comparison with and without zHyperWrite


zHyperWrite Implementations Receiving Positive Response Time Results

Thus far, the customers we have seen implementing zHyperWrite are receiving positive results. The customer site referenced above is already planning further rollout to additional subsystems and environments.

Of course, in any complex implementation project, it is important to be able to clearly communicate the initial results as well as further improvement as you proceed with additional stages of implementation. Quantifying the benefit of one project can pave the way for approval of the next. Having the reporting you need, in an easy to use and visually compelling manner, makes it much easier.

If you are considering implementing zHyperWrite, or any other new technology, at your site but want to be sure you have a clear baseline of performance results to measure the impact, reach out to us to help you set that up.

This article's author

Dennis Moore
Senior Consultant
More from Dennis

Share this blog

zHyperLink Read Performance & Lessons Learned

You May Also Be Interested In:


What's New with IntelliMagic Vision for z/OS? 2024.2

February 26, 2024 | This month we've introduced changes to the presentation of Db2, CICS, and MQ variables from rates to counts, updates to Key Processor Configuration, and the inclusion of new report sets for CICS Transaction Event Counts.

Read more

Viewing Connections Between CICS Regions, Db2 Data Sharing Groups, and MQ Queue Managers

This blog emphasizes the importance of understanding connections in mainframe management, specifically focusing on CICS, Db2, and MQ.

Read more

What's New with IntelliMagic Vision for z/OS? 2024.1

January 29, 2024 | This month we've introduced updates to the Subsystem Topology Viewer, new Long-term MSU/MIPS Reporting, updates to ZPARM settings and Average Line Configurations, as well as updates to TCP/IP Communications reports.

Read more

Go to Resources

Book a Demo or Connect With an Expert

Discuss your technical or sales-related questions with our mainframe experts today