New Version 9.2.0 features for z/OS - base and Advanced VUE entitlement

For Version 9.2.0, IBM MQ for z/OS 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.


Improved log throughput using zHyperWrite

Version 9.2.0 adds the ability to use zHyperWrite, when writing to active log data sets that have been configured for synchronous replication, using IBM MQ Metro Mirror. zHyperWrite can speed up IBM MQ log writes by removing some of the time required for the synchronous replication of data.

For more information, see Use MetroMirror with IBM MQ.


Enhancements to IBM MQ support for IBM z/OS Connect Enterprise Edition

    Runnable Service Archive support for IBM MQ
    z/OS Connect EE Version 3.0.21.0 and later, ships an enhanced version of the MQ Service Provider which supports service archive files. We should migrate to that version of z/OS Connect EE and use the built-in MQ Service Provider, instead of using the service provider shipped with the IBM MQ for z/OS product.
    For more information, see Quick start scenarios for the MQ Service Provider in the z/OS Connect EE documentation in IBM Knowledge Center. Detailed reference information is provided under Use the IBM MQ service provider.

    Support for using client connections with IBM z/OS Connect Enterprise Edition
    The MQ Service Provider for IBM z/OS Connect EE now supports client connections to both remote and local z/OS queue managers. This allows more flexible deployments as the queue manager and IBM z/OS Connect EE server do not need to be running on the same LPAR. For more information, see Use the IBM MQ service provider.


IBM MQ Internet Pass-Thru

    Inclusion of IBM MQ Internet Pass-Thru
    IBM MQ Internet Pass-Thru (MQIPT) is a utility that can be used to implement messaging solutions between remote sites across the internet. In Version 9.2.0, MQIPT is a fully-supported optional component of IBM MQ that you can download from IBM Fix Central for IBM MQ. MQIPT has previously been available as support pack MS81.
    The following changes have been made to MQIPT since Version 2.1 of the support pack:

    • The supplied Java runtime environment (JRE) has been upgraded from Java 7 to Java 8, to match the JRE version supplied with IBM MQ.
    • The SSL 3.0, TLS 1.0, and TLS 1.1 protocols are disabled by default. The only cryptographic protocol that is enabled by default is TLS 1.2. To enable protocols that are disabled, follow the procedure in Enable deprecated protocols and CipherSuites.
    • Support for IBM Network Dispatcher has been removed.
    • The IPT Administration Client graphical user interface has been removed. Previous versions of the IPT Administration Client cannot be used with MQIPT Version 9.2.0. To configure and administer MQIPT, edit the mqipt.conf configuration file and use the mqiptAdmin command, as described in Administer MQIPT by using the command line.
    • All sample files supplied with MQIPT are now located under a new directory called samples in the MQIPT installation directory.
    • The CommandPort property has been removed from the sample configuration file mqiptSample.conf to improve security. This means that when using the sample configuration, MQIPT does not listen on a command port for commands issued by the mqiptAdmin command. To allow MQIPT to be administered remotely using the mqiptAdmin command, change the configuration file to specify a value for the CommandPort or SSLCommandPort property. Review the security considerations in Other security considerations before enabling an MQIPT command port.

    For more information about MQIPT, see IBM MQ Internet Pass-Thru.

    Enhanced protection of stored passwords in MQIPT
    From Version 9.2.0, all passwords that are stored in the MQIPT configuration can be protected by encrypting the passwords using the mqiptPW command. Version 9.2.0 also introduces a new, more secure, protection method for passwords that are stored for use by MQIPT, and the ability for you to specify an encryption key that is used to encrypt and decrypt stored passwords. For more information, see Encrypting stored passwords.

    Improved administration of MQIPT
    The following new features in MQIPT Version 9.2.0 allow easier and more secure administration of MQIPT using the mqiptAdmin command.

    • Local instances of MQIPT can be administered using the mqiptAdmin command without the need for MQIPT to listen on a command port. The mqiptAdmin command must be run under the user ID that was used to start the MQIPT instance. Alternatively, on UNIX and Linux, the root user can be used.
    • MQIPT can be configured to authenticate administrative commands received by a command port. If remote command authentication is enabled, users of the mqiptAdmin command must enter the correct access password, specified in the AccessPW property in the MQIPT configuration, whenever an administrative command is issued using a command port.
    • MQIPT can be configured to listen for administrative commands using a command port that is secured by TLS. This uses encryption to protect data sent between the mqiptAdmin command and the MQIPT instance being administered, including the access password if MQIPT is configured to require authentication for commands received by the command port. The TLS command port can be configured in addition to the unsecured command port that is available in previous versions of MQIPT.
    • A local address can be specified to restrict connections to either the unsecured or the TLS command port to those from a specific network interface. This can be used, for instance, to prevent remote administration of MQIPT, while allowing different users on the local machine to use the command port to administer MQIPT.

    For more information about administering MQIPT using the mqiptAdmin command, see Administer MQIPT by using the command line.


Support for data set encryption

From Version 9.2.0, IBM MQ for z/OS introduces support for the use of z/OS data set encryption, for active log data sets, page sets, and shared message data sets. This means that all data stored in IBM MQ for z/OS data sets can now be protected on disk. For more information, see Confidentiality for data at rest on IBM MQ for z/OS with data set encryption.


Support for Transport Layer Security (TLS) 1.3

    Transport Layer Security (TLS) 1.3 support for a range of protocols
    Version 9.2.0 supports Transport Layer Security (TLS) 1.3 for a range of protocols. TLS 1.3 can be used for connections between queue managers and for C, C++, IBM MQ classes for Java, and IBM MQ classes for JMS client applications.
    Support for TLS 1.3 for Java and JMS client applications is provided when using Java 11.

    New CipherSpecs for TLS 1.3
    The new CipherSpecs for TLS 1.3 that Version 9.2.0 provides are described in Enable CipherSpecs. (For a list of these CipherSpecs, see the TLS 1.3 CipherSpecs section in Table 1.) All the new CipherSpecs work both with RSA and Elliptic Curve certificates.
    For ease of configuration and future migration, Version 9.2.0 also provides a set of alias CipherSpecs including ANY_TLS12, ANY_TLS12_OR_HIGHER, and ANY_TLS13_OR_HIGHER among others. Migrating existing security configurations to use an alias CipherSpec means that we can adapt to cipher additions and deprecations without needing to make further invasive configuration changes in the future. Adding an alias CipherSpec to message channel agent channels, MQI, Java and .NET clients, and cluster channels means that we can:

    • Configure TLS channel security without needing to know a long complicated IBM MQ specific CipherSpec string.
    • Adapt without any configuration change to use new ciphers, and handle deprecation of weak ciphers. This feature is particularly useful within clusters.

    For more information about the alias CipherSpecs, see Enable CipherSpecs. (For a list of these CipherSpecs, see the Alias CipherSpecs section in Table 1.) See also SSLCIPH, and Migrating existing security configurations to use an alias CipherSpec.

    Note: When using earlier CipherSpecs on a queue manager that has TLS 1.3 enabled, there are some changes that we should be aware of.In accordance with the TLS 1.3 specification, many earlier CipherSpecs are disabled and cannot be enabled by use of the existing configuration options. These include:

    • All SSLv3 CipherSpecs
    • All RC2 or RC4 CipherSpecs
    • All CipherSpecs with an encryption key size of less than 112 bits

    To restore previous behavior, TLS 1.3 can be disabled as described in Use TLS 1.3 in IBM MQ.

    Provision for a list of acceptable TLS CipherSpecs
    From Version 9.2.0, we can provide a custom list of ordered and enabled CipherSpecs that IBM MQ is permitted to use. For more information on how to configure a custom list, see Providing a custom list of ordered and enabled CipherSpecs on IBM MQ for z/OS.
    For more information about CipherSpec ordering, see CipherSpec order.


SECPROT attribute available on z/OS

From Version 9.2.0, the SECPROT (MQIACH_SECURITY_PROTOCOL) attribute, which displays the security protocol currently in use, is available on z/OS. For more information, see DISPLAY CHSTATUS.


Simplified support for backwards migration

IBM MQ for z/OS Version 9.2.0 makes backwards migration simpler by removing the need to apply a migration PTF to earlier version of the product prior to performing backwards migration. Instead, before performing backwards migration, we issue the command START QMGR BACKMIG(target_vrm), where target_vrm is the VRM of the release to backwards migrate to, which causes the queue manager to start up and perform the necessary backwards migration steps on its data before shutting down again.

Once the command has been successfully processed, we can backwards migrate the queue manager. For more information see Migrating IBM MQ on z/OS, and START QMGR.


Simplified installation of continuous delivery releases

IBM MQ for z/OS Version 9.2.0 makes it easier to keep Continuous Delivery releases at the most recent level, particularly when moving over Long Term Support release boundaries. For more information, see IBM MQ release types.


Version 2 of the REST API

Version 9.2.0 introduces version 2 of the REST API. This version increase applies to the administrative REST API, messaging REST API, and MFT REST API. This version increase changes the resource URL that is used for the REST API. The URL prefix for the resource URLs at version 2 is the following URL:
https://host:port/ibmmq/rest/v2/

We can continue to use the version 1 URL for existing applications. Most REST API resources are available in both versions. However, new REST API resources are available only with the version 2 URL. For example, the new publish URL in the messaging REST API is available only with the version 2 URL.

The following REST API resources are not available in version 2:

  • GET subscription
  • GET channel
  • POST queue
  • PATCH queue
  • GET queue
  • DELETE queue

We can use the MQSC resource URL as an alternative to using these version 1 REST API resources.

For more information, see REST API versions.


Enhancements to the administrative REST API

Version 9.2.0 introduces new administrative REST API enhancements with the /admin/action/qmgr/{qmgrName}/mqsc resource. Before Version 9.2.0, this resource could be used to send MQSC commands to a queue manager for processing. Now, we can choose to send the MQSC command to the queue manager, and receive responses, in JSON format instead of the MQSC command format.

For example, before Version 9.2.0 the MQSC command could be sent to the /admin/action/qmgr/{qmgrName}/mqsc resource in the following format: 
{
  "type": "runCommand",
  "parameters": {
    "command": "DEFINE CHANNEL(NEWSVRCONN) CHLTYPE(SVRCONN)"
}
From Version 9.2.0, we can send the command in the following JSON format:
{
   "type": "runCommandJSON",
   "command": "define",
   "qualifier": "channel",
   "name": "NEWSVRCONN",
   "parameters": {
      "chltype": "svrconn"
   }
}
From Version 9.2.0, the following enhancements are available with the JSON format MQSC REST API:

  • The following commands are now supported:

    • DISPLAY CONN(connectionID) TYPE (HANDLE)
    • DISPLAY CONN(connectionID) TYPE (*)
    • DISPLAY CONN(connectionID) TYPE (ALL)

  • Single quotation marks are automatically escaped. You no longer need to use an additional single quotation mark to specify a single quotation mark in an attribute value.
  • In the SET POLICY command, the SIGNER and RECIP attributes are now list attributes. Instead of specifying a string value for these attributes, you now use a JSON array. This change enables you to specify multiple values for the SIGNER and RECIP within a single command.
  • Enhanced MQSC syntax error checking is now available. When an MQSC syntax error is detected in the JSON input, instead of returning a 200 response and the MQSC error in the response body, a 400 response is returned with a new error message indicating where the syntax error occurred.

For more information about the /admin/action/qmgr/{qmgrName}/mqsc resource and the format of the JSON we can specify in the request body, see POST /admin/action/qmgr/{qmgrName}/mqsc.


Updated IBM MQ Console look and feel

From Version 9.2.0 a new console, with a new look and feel, is available on z/OS. For more information, see Quick tour of the New Web Console.


Simpler configuration of the product ID (PID) that the mqweb server runs under

Version 9.2.0 simplifies the process used to associate the mqweb server with a PID, replacing the old manual approach. When Create a new mqweb server, the crtmqweb command now takes a parameter specifying which PID the server will run under. The setmqweb command has been enhanced to allow the PID associated with an existing mqweb server to be changed. For more information on how we use the mqweb server on z/OS, see Associating the mqweb server with a PID.


Host header validation for the IBM MQ Console and REST API

We can configure the mqweb server to restrict access to the IBM MQ Console and REST API such that only requests that are sent with a host header that matches a specified allowlist are processed. An error is returned if a host header value that is not on the allowlist is used. For more information, see Configure host header validation for the IBM MQ Console and REST API.


Message-driven bean problem resolution

Version 9.1.1 introduces the maxSequentialDeliveryFailures activation specification property, which defines the maximum number of sequential message delivery failures to a message-driven bean (MDB) instance that the resource adapter tolerates, before pausing the MDB. For more information, see IBM MQ message-driven bean pause in WebSphere Liberty.


Enhancements to the messaging REST API

    Ability to browse messages on a queue
    Version 9.2.0 introduces the ability to browse messages on a queue by using the messaging REST API:

    Enhanced REST messaging performance with connection pools
    To optimize the performance of the messaging REST API, connections to IBM MQ queue managers are pooled. That is, instead of each REST request creating, using, and destroying its own connection, each REST request uses a connection from a connection pool. By default, 20 connections are available for each queue manager pool. We can change the maximum number of pooled connections and the default behavior of the messaging REST API when all connections are in use by using the setmqweb properties command. For more information, see Configure the messaging REST API.

    Publish messages to topics with the messaging REST API
    From Version 9.2.0, we can publish messages to a specified topic by using the messaging REST API. We can use the /messaging/qmgr/{qmgrName}/topic/{topicString}/message resource with an HTTP POST to publish a message to the topic. For more information, see POST /messaging/qmgr/{qmgrName}/topic/{topicString}/message.

Parent topic: What's new in Version 9.2.0


Related concepts