[V9.0.0.3 Mar 2018]

What's changed in IBM MQ 9.0.0 Fix Pack 3

IBM® MQ 9.0.0 Fix Pack 3 includes a number of changes to functions and resources.

Removal of JSON4J.jar file and com.ibm.msg.client.mqlight package

The JSON4J.jar file and com.ibm.msg.client.mqlight package are not needed by the IBM MQ classes for Java and IBM MQ classes for JMS, therefore the following changes are made from IBM MQ 9.0.0 Fix Pack 3:
  • The JSON4J.jar file is removed from the V.R.M.F-WS-MQ-Install-Java-All.jar file, where V.R.M.F is the product version number, for example 9.0.0.3.
  • The reference to JSON4J.jar file is removed from the class path statement within the manifest file for the com.ibm.mq.allclient.jar file.
  • The package com.ibm.msg.client.mqlight is no longer included inside the com.ibm.mq.allclient.jar file.

See Installing the IBM MQ classes for JMS separately, What is installed for IBM MQ classes for JMS, and What is installed for IBM MQ classes for Java.

Additional permission for java.security.policy file

From IBM MQ 9.0.0 Fix Pack 3, if your Java application uses the Java security manager, you must add a RuntimePermission to the java.security.policy file, otherwise, exceptions will be thrown to the application. This RuntimePermission is required by the client as part of managing the assignment and closure of multiplexed conversations over TCP/IP connections to queue managers.

For more information, see Running IBM MQ classes for Java applications under the Java security manager.

Change to required permissions for Managed File Transfer agent authority queues

From IBM MQ 9.0.0 Fix Pack 3, when user authority management is enabled by setting the agent property authorityChecking=true, inquire is a required permission on all of the agent authority queues.

For more information, see Restricting user authorities on MFT agent actions and The MFT agent.properties file.

New attribute to allow TLS v1.0 to be optionally disabled on a queue manager

From IBM MQ 9.0.0 Fix Pack 3, a new attribute is available in the qm.ini file, under the SSL stanza:
SSL:
   AllowTLSV1=NO
If this attribute is set in the qm.ini file before the queue manager is started, the queue manager does not accept inbound connections using the TLS v1.0 protocol. Similarly, if an LDAP connection is configured using an AUTHINFO object, only TLS 1.2 is used to communicate with the LDAP server if secure communication is enabled for the AUTHINFO object.

Alternatively, the AMQ_TLS_V1_DISABLE environment variable can be set for the environment used to start the queue manager, listener, and channel processes.

If either property is set, as well as disallowing TLS 1.0 connection attempts at the network layer, the queue manager's command server also rejects attempts to define or alter a channel definition to use a TLS 1.0 CipherSpec.

The default queue manager behavior is unchanged, such that TLS 1.0 connections continue to be accepted if the new attribute or environment variable is not set.

Enhancements to runmqras utility

From IBM MQ 9.0.0 Fix Pack 3, the following enhancements are made to the runmqras utility:
  • [Solaris][AIX][Linux]Environment variable information is retrieved by default.
  • [UNIX, Linux, Windows, IBM i]Queue manager data directory listings are retrieved by default.
  • The following two sections are added to the runmqras command:
    • [UNIX][Linux]A leak section to gather IBM MQ process resource usage information.
    • [UNIX, Linux, Windows, IBM i]An mft section to capture the data obtained by the fteRas command.

For more information, see runmqras (collect IBM MQ diagnostic information).

Change to order of authority checks when a Managed File Transfer agent receives a request to cancel a file transfer

From IBM MQ 9.0.0 Fix Pack 3, when user authority management is enabled by setting the agent property authorityChecking=true, the order in which authority checks are performed when an agent receives a request to cancel a file transfer is changed. The change to the order of checking avoids unexpected errors in agent and queue manager error logs when the user who requested the file transfer and the user who requested the cancellation are the same.

For more information, see Restricting user authorities on MFT agent actions.