+

Search Tips | Advanced Search

New Version 9.2.0 features for Multiplatforms - base and Advanced entitlement

For Multiplatforms, IBM MQ Version 9.2.0 delivers a number of new features that are available with base product entitlement, and also with Advanced entitlement.


Automatic balancing of a pool of connected applications across a set of available queue managers

    Uniform clusters
    Uniform clusters are a specific pattern of an IBM MQ cluster that provides applications with a highly available and horizontally scaled collection of queue managers. When an application interacts with a uniform cluster as a single group, the queue managers work together to maintain an even balance of application instances across the cluster, including across queue manager maintenance and restarts. Automatic balancing across a set of clustered queue managers is supported for applications written in C, JMS, IBM MQ .NET, and XMS .NET. For more information, see About uniform clusters.
    Application balancing is done at the application instance level. An application instance is a group of related connections identified within the queue manager by a shared connection tag.

    Single set of configuration files
    A single set of configuration files can be defined once and used to deploy multiple queue managers into the uniform cluster, ensuring the configuration is consistent across them. We have various options to help you configure uniform clusters. We can:

    Application resource monitoring
    We can display the status of one or more applications, and application instances, connected to a queue manager, cluster, or a uniform cluster by using the DISPLAY APSTATUS MQSC command or the Inquire Application Status and Inquire Application Status (Response) PCF commands. This information allows you to monitor and troubleshoot application balancing.
    We can monitor usage statistics for each application that you specify by adding the STATAPP class to the amqsrua command. We can use this information to help you understand how the applications are being moved between queue managers and identify any anomalies. For more information, see Monitor system resource usage by using the amqsrua command.

    JSON format client channel definition table
    The JSON format for the client channel definition table (CCDT) gives various improvements over the existing binary format CCDT, including the ability to define duplicate channel definitions of the same name. This is a client-side feature (that is, we need a Version 9.2.0 client, not a Version 9.2.0 queue manager). For more information, see Configure a JSON format CCDT.


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 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.

    To use TLS 1.3 or TLS 1.3 alias CipherSpecs, the JRE running your Java or JMS application must support TLS 1.3.
    Note: When using earlier CipherSpecs on a queue manager that has TLS 1.3 enabled through a server qm.ini property or a client mqclient.ini property, which is the default setting on a new queue manager, 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 Multiplatforms.
    For more information about CipherSpec ordering, see CipherSpec order.

    TLS Handshake Transcript
    Version 9.2.0 adds support for the TLS handshake transcript available from the GSKit cryptographic provider. This functionality is available on Distributed platforms that utilize IBM MQ both in the queue manager and client. To view the TLS handshake transcript, GSKit and GSKit trace must be enabled and a TLS handshake must fail. The transcript will then be collected and written out as part of the amqrmppa or client application trace file.

    TLS 1.3 on IBM i
    The availability of TLS 1.3 on IBM MQ is dependent on the availability of TLS 1.3 in the underlying IBM i operating system. For details on what IBM i versions support TLS 1.3 and how to enable it, see System TLS support for TLSv1.3.


Increased level of control to determine how IBM MQ uses available storage

From Version 9.2.0, you have the option of configuring and monitoring queues that will support substantially more than the two terabyte default limit used in releases of IBM MQ prior to Version 9.2.0. You also have the option of reducing the size a queue file can grow to. To enable you to configure queues, there is an additional attribute on local and model queues, MAXFSIZE and to monitor queues there are two additional queue status attributes, CURFSIZE and CURMAXFS. For more information, see Modifying IBM MQ queue files.


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.


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.


Updated IBM MQ Console look and feel

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


Enhancements to the IBM MQ Bridge to Salesforce


Configurable ephemeral directory

Version 9.2.0 introduces the EphemeralPrefix, which defines the location that data ephemeral to the queue manager should go, such as queue manager operating system sockets, allowing the UNIX domain sockets to be placed on a non-mounted file system in a Red Hat OpenShift environment. For more information, see Configurable ephemeral directory.Note: You do not have to run in Red Hat OpenShift to run in this environment. We have the option to use an alternative ephemeral data directory on all platforms except z/OS, and on the IBM MQ Appliance.


Userdata directory

From Version 9.2.0, the queue manager filestore includes a userdata directory that we can use for storing the persistent state of an application. For more information, see Userdata directory and Storing persistent application status.


License acceptance after installation on Linux

From Version 9.2.0, on Linux, you have the option of accepting the correct license for the enterprise after you install the product. For more information, see License acceptance on IBM MQ for Linux.


More effective integration with WebSphere Liberty

    Message-driven bean problem resolution
    From Version 9.2.0, the maxSequentialDeliveryFailures activation specification property 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.

    Full Liberty XA support with client channel definition tables
    When using WebSphere Liberty Version 18.0.0.2 onwards, with Version 9.2.0, we can make use of queue manager groups within the client channel definition table (CCDT) in conjunction with XA transactions. This means that it is now possible to make use of workload distribution and availability, provided by queue manager groups, whilst maintaining transaction integrity. For more information, see Full Liberty XA support with client channel definition tables.
    This is a client-side feature, that is, we need a Version 9.2.0 resource adapter, not a Version 9.2.0 queue manager.


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.


Support for running applications on Microsoft .NET Core


Advanced Message Queuing Protocol (AMQP) shared subscription enhancement

Version 9.2.0 adds support to AMQP channels for consuming data from subscriptions and shared-subscriptions for example when using the Qpid JMS client library. For more information, see Developing AMQP client applications.

Parent topic: What's new in Version 9.2.0


Related concepts

Last updated: 2020-10-04