New family features

IBM® MQ 8.0 delivers (for all platforms) topic host routing for publish/subscribe clusters, and support for JMS 2.0.

Topic host routing for publish/subscribe clusters

In previous versions, when you configure a clustered topic on a queue manager, all queue managers in the cluster become aware of all other queue managers in the cluster. When performing publish and subscribe operations, each queue manager then connects directly to all the others. This approach is still available in IBM MQ 8.0, where it is known as direct routing.

In Version 8.0, an alternative approach has also been added, known as topic host routing. With this approach, all queue managers in the cluster become aware of the cluster queue managers that host the routed topic definitions. When performing publish and subscribe operations, queue managers in the cluster connect only to these topic host queue managers, and not directly to each other. The topic host queue managers are responsible for routing publications from queue managers on which publications are published to queue managers with matching subscriptions.

A topic host routed publish/subscribe cluster provides the following benefits:
  • Improved scalability of larger clusters. Only the topic host queue managers need to be able to connect to all other queue managers in the cluster. Therefore, there are fewer channels between queue managers, and there is less inter-queue manager publish/subscribe administrative traffic than for direct routing. When subscriptions change on a queue manager, only the topic host queue managers need to be informed.
  • More control over the physical configuration. With direct routing, all queue managers assume all roles, and therefore all need to be equally capable. With topic host routing, you explicitly choose the topic host queue managers. Therefore, you can ensure that those queue managers are running on adequate equipment, and you can use less powerful systems for the other queue managers.
See Designing publish/subscribe clusters, Configuring a publish/subscribe cluster, and Routing for publish/subscribe clusters: Notes on behavior.

Support for JMS 2.0

IBM MQ 8.0 supports the JMS 2.0 version of the JMS standard. This implementation offers all the features of the classic API but requires fewer interfaces and is simpler to use. For more information, see The JMS model and the JMS 2.0 specification at Java.net.

JMS 2.0 support includes the following features:
Delayed delivery
You can now defer message delivery by specifying a delivery delay when sending a message so that the JMS provider does not deliver the message until after the specified delivery delay has elapsed. For more information, see JMS 2.0 delivery delay.
Shared subscriptions
A shared subscription is used to share messages from a topic subscription among multiple consumers. Each message from the subscription is delivered to only one of the consumers on that subscription. For more information, see Cloned and shared subscriptions.
Asynchronous send operation
Applications can now send messages asynchronously. When sending a message asynchronously, control is immediately returned to the sending application without having to wait for a reply from the server, enabling the sending application to do something else, rather than having processing blocked while it waits for a reply from the server.

The JMS 2.0 specification introduces certain changes in behavior. IBM MQ 8.0 includes the property com.ibm.mq.jms.SupportMQExtensions, which can be set to TRUE to revert these changes back to the behavior of the previous version. For more information, see SupportMQExtensions property and Properties used to configure JMS client behavior.

Security: connection authentication

On distributed platforms, for each of your queue managers, you can choose that the queue manager uses either the local operating system or an LDAP server to authenticate user IDs and passwords. You specify this choice by naming the appropriate authentication information object in the queue manager's CONNAUTH attribute.

The new attribute CHCKLOCL is used to turn on user ID and password checking for local connections. When you are migrating between IBM WebSphere® MQ 7.1 and latest version, the CONNAUTH CHCKLOCL attribute on each queue manager is set to NONE, ensuring version to version continuity, but switching connection authentication off. For a new IBM MQ 8.0 installation, the CONNAUTH CHCKLOCL attribute is set to OPTIONAL. This means that user IDs and passwords are not required, but if they are provided they must be a valid pair, or they are rejected.

[z/OS]On z/OS®, IBM MQ 8.0 only supports operating system authentication and does not support LDAP.

For more information, see Connection authentication.

Security: multiple configurable certificates

Clients and queue managers are no longer limited to a single certificate for SSL/TLS channels. You can configure which certificate is used by setting the CERTLABL channel attribute to a value of your choice. See Digital certificate labels: understanding the requirements.

Using multiple certificates allows you to use certificates signed by different Certificate Authorities (CAs). However, note the following:
  • You can choose which certificate IBM MQ sends to its remote partner using the CERTLABL configuration setting. The locally-configured certificate label is used to select a certificate from the local key repository. The chosen certificate is sent to the remote IBM MQ partner for authentication purposes.

    At the remote IBM MQ partner, the certificate is validated according to the SSL/TLS certificate validation policy, and also the IBM MQ security settings.

    One of the security settings is the SSLPEER channel attribute, which specifies a Subject Distinguished Name (DN) filter string, that must match the Subject DN of the certificate received.
    Attention: The channel SSLPEER setting only matches the Subject DN of the certificate, not the Issuer DN, so it is possible for spurious matches to occur.
  • For this reason, you should use SSLPEERMAP channel authentication rules in preference to channel SSLPEER filters, because an SSLPEERMAP authentication is capable of matching both the Subject DN (SSLPEER) and the Issuer DN (SSLCERTI) so it is less likely to match the wrong certificate.
  • The local CERTLABL configuration is separate from the remote SSLPEERMAP configuration, but there is an important relationship between them.

    The local certificate, chosen by its label, contains a Subject DN and Issuer DN that can be validated by the remote IBM MQ partner. For this reason, it is important to configure the local certificate label correctly in order to avoid SSLPEER and SSLPEERMAP matching errors on the remote IBM MQ partner.

For more information, see Working with SSL or TLS.

Security: Reverse lookup host names in CHLAUTH rules

The IBM MQ CHLAUTH rules have been enhanced so that CHLAUTH definitions can use Domain Name Server (DNS) host names instead of IP addresses, and IBM MQ performs the reverse DNS hostname lookup to obtain the IP address while performing a channel initialization.

IBM MQ 8.0 also introduces the queue manager REVDNS attribute, which controls whether a reverse DNS hostname lookup of the IP address of an inbound channel should be performed or not during channel initialization.

If this attribute is enabled, DNS host names are reverse looked-up for the IP addresses of inbound channels when this information is required.

If the REVDNS attribute is not enabled, DNS host names are not reverse looked-up for the IP addresses of inbound channels. For more information about the REVDNS attribute, see ALTER QMGR.

Note that APAR IC96408 introduced reverse DNS hostname lookup for previous versions of IBM WebSphere MQ for the purpose of logging some error messages. This holds true for IBM MQ 8.0.

Integration of SupportPac MO03 - IBM MQ Queue load / unload utility

The qload utility, shipped in IBM MQ Supportpac MO03, is now integrated into IBM MQ Version 8.0 as the dmpmqmsg utility.

[UNIX][Linux]On UNIX and Linux® platforms, the utility is available in <installdir>./bin

[Windows]On Windows platforms, the utility is available in <installdir>./bin64 as part of the server fileset.

[z/OS]On z/OS, the utility is available as an executable module, CSQUDMSG in the SCSQLOAD library, with an alias of QLOAD for compatibility. Sample JCL is also provided as member CSQ4QLOD in SCSQPROC.

For more information, see Using the dmpmqmsg utility.

Managed File Transfer: working with IBM MQ security

IBM MQ Managed File Transfer Version 8.0 supports the security features of IBM MQ Version 8.0 with the default mode of disabled. If the associated queue manager has security enabled and requires credential details (user ID and password), you must enable this feature before you can successfully connect to a queue manager. For more information, see Working with IBM MQ security and Connection authentication.

Managed File Transfer: support for specifying ciphers in communications between protocol bridge agents and FTPS servers

You can explicitly specify a list of cipher suites for connections between protocol bridge agents and FTPS protocol servers, using a new property called cipherSuiteList in the ProtocolBridgeProperties.xml file. The list supplied is used in the negotiation between the agent and the FTPS server. For more information, see Protocol bridge properties file format.

Managed File Transfer: new specifications for the resource monitor

The following support has been added to the resource monitor:
  • You can pass user metadata to resource monitor endpoints
  • You can transfer ordered lists of files in a single transfer request
  • You can specify job name information as a user-defined identifier for a resource monitor request
For more information, see the fteCreateMonitor command.

Managed File Transfer: enhancements to working with transfers

The following enhancements are included in Managed File Transfer:

  • You can submit a large one file to one message transfer, up to a file size of 100 MB. To reduce memory usage for large one file to one message transfers, you are recommended to set the -qs parameter on the fteCreateTransfer command equal to the size of message being written. If you have a file larger than 100 MB, and you also specify the -qs parameter on the fteCreateTransfer command, the file is split into multiple messages.

    In the case of recovery of binary one file to message transfers, the transfer restarts from the point that the last checkpoint was written. In the case of recovery of text transfers, the transfer restarts from the beginning of the file, which might result in an incomplete group of messages on the destination queue. When the failed text transfer is restarted, a completely new group of messages is written.

    For more information, see fteCreateTransfer.

  • Transfer progress log messages are published for transfers that fail early. You can then use the information published about the transfer items in the failed transfer to resubmit that transfer.
  • The commandMessagePriority property sets the priority of both internal messages and command messages for the fteStopAgent, fteCancelTransfer, ftePingAgent, and fteSetAgentTraceLevel commands. You can also use the commandMessagePriority property to set the priority of internal acknowledgement and acknowledgement-expected messages. You can set commandMessagePriority to a value to prioritize internal Managed File Transfer messages above new transfer requests, which can improve agent performance. For more information, see installation.properties file.
  • You can use the maxInlineFileSize property to set the maximum size of file that is included in the transfer request message for single file-to-file or file-to-message transfers. This might improve transfer performance. For more information, see agent.properties file.
  • You can use the enableMemoryAllocationChecking property to ensure that the agent checks whether there is sufficient memory available to run a transfer before the transfer is started. If there is insufficient memory available, the transfer is put into recovery, which prevents the agent from failing with an out-of-memory error. For more information, see agent.properties file.
  • Transfer log publications for file-to-message and message-to-file transfers contain all the transfer request attributes.