MQ for z/OS v914 CDR - Data Set Encryption performance

By Anthony Sharkey posted Mon January 13, 2020 01:41 AM


Data set encryption (DSE) was originally implemented in z/OS v2r2, and initial MQ support was documented in the blog “MQ and the use of data set encryption for IBM z/OS v2.2”.


As described in the IBM Knowledge Center section titled "Confidentiality for data at rest on IBM MQ for z/OS with data set encryption", MQ for z/OS support for encrypted data set now expands coverage to MQ active logs and page sets in the recently released MQ for z/OS v914 Continuous Delivery Release (CDR). Both of these data set types are accessed using IBM Media Manager calls.


This means that the original DSE support statement on MQ for z/OS can be updated to:

MQ data set encryption support:

Data set


(including existing LTS releases)

V914 CDR







Page set 0

No – Abend 5C6-00C91400


Page sets 1-99

No – MQRC 2193 “Pageset error”

Active log

No – Abend 5C6-00E80084


Archive log

Yes – V800 onwards



No – SMDS marked avail(error)

No – SMDS marked avail(error)


How much does Data Set Encryption cost and how can I predict the impact?


Encryption of data is not free, and as such, consideration should be given as to whether your system has sufficient capacity to support encrypted MQ data sets without impacting the performance of your workloads.


The following section discusses the additional costs from encrypting MQ data sets, based on observations on our dedicated performance systems.

We also try to offer a method to indicate how much additional CPU might be incurred when encrypting your own MQ data sets.

Despite MQ archive logs supporting data set encryption prior to V914, active and archive logging are closely coupled, and so we offer a section encrypting all of your MQ log data sets.


The I/O to MQ page set is somewhat different and will depend on the nature of the workloads using the queue manager. As such, the section on encrypting page sets is kept separate from MQ logs.

Impact to logging - active and archive logs

Before discussing the impact of encrypting your MQ active and archive logs, let’s take a moment to consider what happens when logging occurs where the MQ queue manager has dual active and archive logs, all of which are encrypted:


  • Persistent message workload causes MQ queue manager to encrypt+write to active log copy 1 and encrypt+write to active log copy 2 data sets.
  • At end of current active log:
    • Queue manager reports CSQJ002I “END OF ACTIVE LOG DATA SET”.
    • Current active log switches to next active log(s).
    • Checkpoint starts for all buffer pools.
    • Archive task started, processing the recently filled active log:
      • Select either log copy 1 or 2 to provide the data to archive.
      • Perform until end of the chosen active log:
        • Read+Decrypt chosen active log copy - 1 page at a time
        • Encrypt+Write to archive copy 1
        • Encrypt+Write to archive copy 2


The point of this is to show that dual logging and/or dual archiving causes multiple encrypt calls as well as decrypting the data read from the active logs.


With dual logging and dual archiving all protected with data set encryption, the queue manager is encrypting the data 4 times plus decrypting the data once, for a total of 5 encrypt/decrypt calls for each page logged.


On our systems (z14 and z15) we saw the following increase in cost per copy:

Log type

Microseconds / 4KB page

Microseconds / MB







Note that active logs are accessed via Media Manager which has additional overheads.


Example: MQ configured with dual active and archive log, with 1GB log data sets

Log type

Cost / MB

MB in active log



(Cost * MB  * Factor)





315 CPU milliseconds





550 CPU milliseconds


Notes on table:

  1. Factor of 2 used for the separate encrypt and write to each copy of the archive log.
  2. Factor of 3 used for the separate encrypt and write to each copy of the active log plus the read and decrypt of the log for the archiving task.


So in this example for each 1GB of MQ workload logged, there would be approximately 0.86 CPU seconds additional cost in the MQ MSTR address space.

Impact to page set

The cost of encrypted MQ page sets is slightly more complicated due to the types of I/O supported.


The program MQSMF, available in supportPac MP1B “IBM MQ – Interpreting accounting and statistics data, and other utilities” provides a number of page set related reports, but the one of interest here is the PSET. Note that only selected data is shown in the following sample:


PS01 BP   1, Pages   1040334, Size 4063 MB, … Pageset is encrypted,

     Pages written in checkpoint        875678

     Pages written not in checkpoint       132


PS01 Type :I/O requests,   Pages, Avg I/O time, pages per I/O

PS01 Write:       54739,  875790,         1828,          16.0

PS01 IMW  :          20,      20,          358,           1.0

PS01 GET  :           1,       1,          196,           1.0


As highlighted in the sample report, there are 3 types of I/O performed on MQ page sets, namely WRITE, IMW (immediate write) and GET.


GETs are performed when MQ determines it necessary to read (and decrypt) from page set. Reads are performed 1 page per I/O request.

IMW (Immediate writes) occur when the buffer pool reaches the 95% full and the data is moved from buffer pool to page set synchronously. Immediate writes are performed 1 page per I/O request. This is an indication that the buffer pool is not sufficiently large for optimal performance.

Writes are performed at 2 points – at checkpoint and when the buffer pool reaches 85% full (also termed “written not in checkpoint”). In each instance, each I/O request will write up to 16 pages.


In terms of additional cost from data set encryption:

GET +0.7 microseconds / page read

IMW +0.7 microseconds / page written

WRITE +2.7 microseconds / page (+43.2 microseconds per I/O) on z15.
+3.2 microseconds / page (+51.2 microseconds per I/O) on z14.

The PSET report can be used to predict the cost impact from data set encryption.

Referring back to the earlier example PSET report, we see:

WRITE  54,739 requests for 875,790 pages – which we would predict as costing an additional 2.3 CPU seconds.

IMW 20 requests for 20 pages – for an additional cost of 12 CPU microseconds

GET 1 – additional 0.7 microseconds, i.e. not a discernible impact from data set encryption.

Observations on the reported costs:

  • The cost per page when writing multiple pages per I/O request is higher than the cost of a single page.
  • Costs may vary depending on how busy your system is – lightly loaded systems or tasks (such as the MQ logger task) may see higher cost per page than we have reported.
  • Data set encryption costs were generally similar on z14 and z15 for our measurements, as they used AES encryption which has been optimized on CPACF. Costs may be higher on earlier generations of IBM z hardware.
  • Consider that in CPU constrained systems that the additional cost from encryption may impact existing workload characteristics, resulting in more data written at checkpoint or needing to be read from page set.
  • Page set immediate writes and gets can be minimised with sufficiently large buffer pools. Over-sized buffer pools can minimise immediate writes to page set.
    • Over-sized buffer pools are buffer pools that are sized at 105% of the corresponding page set.
      • By setting the buffer pool to 105% of the size of the page set, you can avoid the additional I/O’s for immediate writes.
      • When multiple page sets map to a single buffer pool, over-sizing the buffer pool may not have the desired impact of avoiding immediate writes.


How do the costs look in context of a workload?


So far we have identified the additional cost to the MQ queue manager from adding data set encryption, but how does that appear when put into the context of a workload?


In this example we are running a workload that is driving workload to a fixed sustainable rate when logging 1MB messages. In our case this is driving the logs at 270 MB / second.

The workload is simple – 3 batch applications that put, commit, get, commit 1MB persistent messages for a set time. We know the rate of logging and can determine the MQ MSTR costs from the RMF Workload Activity report.


For this particular workload, the queues are always low depth and there is minimal activity at checkpoint – therefore the cost of page set encryption is negligible, and thus not included.


The following chart indicates the cost of processing 1MB of data logged in the MQ MSTR address space.

 Dataset Encryption costs on MQ active and archive logs


Notes on chart:

  1. The cost in the MQ MSTR address space for logging 1MB of data when configured with dual logs was 978 CPU microseconds.
  2. Enabling archiving added an additional 568 CPU microseconds per MB, for a total of 1566 microseconds.
  3. Applying data set encryption to the archives added a further 390 CPU microseconds, for a total of 1956 CPU microseconds.
    • If data set encryption was subsequently applied to the active logs, a further 684 microseconds would be added, giving a total of 2640 CPU microseconds per MB. This additional 684 microseconds includes the active log encryption plus the active log read/decrypt for archiving.
  4. If dataset encryption was applied only to active logging but archiving is enabled, the cost would be 978 + 568 + 430 + 254, for a total of 2230 CPU microseconds.





V914 CDR introduces data set encryption support for some MQ data sets that are accessed via Media Manager – page sets and active logs.


Existing non-media manager data sets continue to support data set encryption, e.g. BSDS and archive logs.


Media manager controlled data set encryption is slightly more expensive per I/O than non-media managed I/O, due to additional data gathering in IEAVRT05 (TIMEUSED macro).


Data set encryption is not zero cost, which in CPU constrained systems can have an impact on the performance achieved.


Consider the use of your queue manager before applying data set encryption. There may be circumstances where applying Advanced Message Security (AMS) message protection to all queues in use, where messages are encrypted at rest, is lower cost than applying data set encryption.