[z/OS][MQ 9.3.2 FEB 2023]

What's new in IBM MQ 9.3.2 for z/OS - base and Advanced VUE entitlement

On z/OS®, IBM® MQ 9.3.2 delivers a number of new features and enhancements that are available with base and IBM MQ Advanced for z/OS Value Unit Edition (VUE) entitlement.

Administration
Application Development

Enhancements to SMF accounting data

From IBM MQ 9.3.2, SMF accounting data tracks a new datapoint, StreamedN, in the CSQDWQ macro, which allows you to track the number of messages being streamed using the Streaming queues feature added in IBM MQ 9.3.0. The header file CSQDSMFC.H has also been updated to accommodate this new datapoint.

For more information, see Interpreting IBM MQ for z/OS accounting data and Streaming queues.

New application view in IBM MQ Console

From IBM MQ 9.3.2, the console has a view that shows details of applications that are connected to queue managers. The view includes a panel that shows a quick view of how many applications are connected to a queue manager and enables you to drill down to see more details. For more information, see IBM MQ Console: Working with applications.

New property to set the strategy for sharing TCP/IP connections in IBM MQ classes for JMS or IBM MQ classes for Jakarta Messaging

From IBM MQ 9.3.2, for applications that use IBM MQ classes for JMS or IBM MQ classes for Jakarta Messaging, you can now choose a strategy for sharing TCP/IP connections between JMS objects.

You can choose one of the following strategies:
  • The GLOBAL strategy. The GLOBAL strategy minimizes the number of open sockets at the expense of a longer connect time. This is the default strategy for non-reconnectable applications.
  • The CONNECTION strategy. The CONNECTION strategy minimizes the connect time at the expense of higher socket usage. This strategy is always used for reconnectable applications. You can enable this strategy for non-reconnectable applications on an application-wide basis by setting the system property com.ibm.mq.jms.channel.sharing to the value CONNECTION

For more information, see Sharing a TCP/IP connection in IBM MQ classes for JMS.

Support for using modular applications with IBM MQ classes for JMS and IBM MQ classes for Jakarta Messaging

From IBM MQ 9.3.2, when you develop modular applications you can configure your applications to use IBM MQ classes for JMS and IBM MQ classes for Jakarta Messaging. Each of the JAR files now includes modular names, and the JAR files are provided in directories that contain only the JAR files that are needed, with no duplication of packages between the JARs. Therefore, you can include the IBM MQ classes for JMS and IBM MQ classes for Jakarta Messaging in your application in a modular manner by requiring the appropriate module within your application, and including the appropriate directory in the module-path. This support is available within the JAR files that are provided with your IBM MQ installation and is also available in the redistributable client images.

For more information, see Configuring your modular application to use IBM MQ classes for JMS or IBM MQ classes for Jakarta Messaging.

New property to set the user context that is used for authorization in the messaging REST API

From IBM MQ 9.3.2, you can simplify your security configuration for the messaging REST API by configuring what user context is used for authorization when you are using the messaging REST API to send, receive, browse, or publish a message.

By default, all requests are authorized to use IBM MQ objects based on the user ID that is logged in to the messaging REST API. Therefore, each user that exists as a messaging REST API user must also exist as an IBM MQ user and be authorized to access the appropriate IBM MQ objects.

From IBM MQ 9.3.2, you can configure what user context is used for authorization when you are using the messaging REST API. That is, you can configure the messaging REST API such that each request is authorized to access IBM MQ objects based on the user that started the mqweb server instead of the user that is logged in to the messaging REST API. Therefore, each user that exists as a messaging REST API user does not need exist as an IBM MQ user. Only the user that starts the mqweb server needs authorization to access the IBM MQ objects.

For more information, see Configuring the user context that is used for authorization in the messaging REST API.