IBM What's New in MQ V8

© 2014 IBM Corporation
IBM Software Group WebSphere Software
What's new in MQ V8
Morag Hughson
hughson@uk.ibm.com
WebSphere MQ
IBM Software Group | WebSphere software
IBM MQ V8 delivering best in class enterprise
messaging
Platforms &
Standards
Security Scalability System z exploitation
64-bit for all platforms
Userid authentication via
OS & LDAP
Multiplexed client
performance
64-bit buffer pools in MQ for z/OS
means less paging, more
performance
Support for JMS 2.0
User-based
authorisation for Unix
Queue manager vertical
scaling
Performance and capacity
Improved support for
.Net and WCF
AMS for IBM i & z/OS
Publish/Subscribe
improvements
Performance enhancements for
IBM Information Replicator (QRep)
Changes to runmqsc
DNS Hostnames in
CHLAUTH records
Routed publish/subscribe
Exploit zEDC compression
accelerator
SHA-2 for z, i & NSS
Multiple certificates per
queue manager
Multiple Cluster Transmit
Queue on all platforms
SMF and shared queue
enhancements

WebSphere MQ
MQ V8 Dates
Announce: 22 April 2014
Availability:
23 May 2014 (eGA Distributed)
13 June 2014 (z/OS and pGA Distributed)
End of Service for old platforms and versions
MQ V7.0.0 and V7.0.1 for multiplatforms – EOM, EOS effective September 2015
V7.0 will have had more than 7 years of support
MQ V7.0.1 for z/OS – EOM, EOS effective September 2015
V7.0 .0 already out of service
WebSphere MQ
N
O
T
E
S
Dates
• Nothing more to say here

WebSphere MQ
MQ platform consistency
64-bit server support for all queue manager platforms
Completion of platform coverage by adding Windows 64-bit engine
Applications can still be 32-bit
Requires Windows 7 or later
Client only package for 32-bit platforms
Queue Manager requires 64-bit
Integration of AMS and MFT capabilities into z/OS and IBM i platforms
Previously separately installable products
Client Attach Feature no longer needed on z/OS
Single price includes support for clients
WebSphere MQ
N
O
T
E
S
MQ platform consistency
• This release has all the Distributed queue managers fully supporting 64-bit operations.
The final remaining platform had been Windows, but now the queue manager runs as
64-bit processes. Existing 32-bit applications continue to work of course, but this
should bring additional capacity and scalability to the queue managers on that OS. The
lowest level of Windows now supported is Windows 7; older versions are not
supported. A client-only package for 32-bit versions of Windows is provided, but the
qmgr requires the 64-bit OS.
• Another big feature of V7.5 was the closer integration of AMS and File Transfer (MFT).
As we will see later, this pattern has been followed on z/OS and IBM i. On z/OS the
features are still separately licensed, but are better integrated than previously.
• On z/OS, the CAF has been removed both as an installable feature and as a licensing
option. All V8 queue managers are now capable of having any number of MQ clients
directly connected. For customers who previously used the lack of a CAF to block client
connections, we would strongly recommend they look at the other security-related
controls such as CHLAUTH and SSL/TLS, or MAXINST values, to continue to prohibit
clients. If you extend the number of directly-attached clients in your environment,
make sure you first evaluate things such as CPU costs, performance, capacity etc.

WebSphere MQ
JMS 2.0
Long-awaited update from JMS 1.1 standard
JMS 2.0 – JSR 343 Java Message Service (JMS 2.0)
Final release on 21 May 2013.
https://java.net/projects/jms-spec/pages/JMS20FinalRelease
New Messaging Features
Delivery Delay
Asynchronous Send
Subscriptions can be shared across a messaging provider
API Changes
Use of java.lang.AutoCloseable
Simplified API [combined connection/session]
Session doesn't need parameters (for Java EE)
Java 7 prereq
Java EE 7 prereq for use of the Resource Adapter in Application Servers
WebSphere MQ
N
O
T
E
S
JMS 2.0
• The JMS 2.0 specification now requires JMS providers to implement both P2P and Pub-Sub.
• The following new messaging features have been added in JMS 2.0:
– Delivery delay: a message producer can now specify that a message must not be delivered until after a specified time interval.
– New send methods have been added to allow an application to send messages asynchronously.
– JMS providers must now set the JMSXDeliveryCount message property.
• The following change has been made to aid scalability:
– Applications are now permitted to create multiple consumers on the same durable or non-durable topic subscription. In previous versions of JMS only
a single consumer was permitted.
• Several changes have been made to the JMS API to make it simpler and easier to use:
– Connection, Session and other objects with a close method now implement the java.jang.AutoCloseable interface to allow them to be used in a Java
SE 7 try-with-resources statement.
– A new "simplified API" has been added which offers a simpler alternative to the standard API, especially in Java EE applications.
– New methods have been added to create a session without the need to supply redundant arguments.
– Although setting client ID remains mandatory when creating an unshared durable subscription, it is optional when creating a shared durable
subscription.
– A new method getBody has been added to allow an application to extract the body directly from a Message without the need to cast it first to an
appropriate subtype.
• New methods have been added to Session which return a MessageConsumer on a durable topic subscription. Applications could
previously only obtain a domain-specific TopicSubscriber, even though its use was discouraged.
• The specification has been clarified in various places.
• JMS 2.0 implementations require Java 7 for the runtime. They also require Java EE 7 for use of the Resource Adapter in Application
Servers. Not all App Servers currently support Java EE 7. However, as with all client implementations, older versions of the RA still
work when communicating to an MQ V8 queue manager.

WebSphere MQ
.Net enhancements
MQ .Net classes can now use SSL without needing the C client installed
A secure fully-managed .Net implementation
Uses Windows native certificate stores
For MQ .NET classes (aka Base .NET Classes) SSL properties can be set at
MQEnvironment.cs
Hashtable properties (input parameter to MQQueueManager constructor)
For XMS .NET, SSL properties can be set as ConnectionFactory properties
WCF interface extended to non-SOAP, non-JMS messages
Making it easier for apps using WCF to communicate with any other MQ application
WebSphere MQ
N
O
T
E
S
.Net enhancements: SSL + WCF
• MQ .NET in unmanaged mode has supported the use of SSL since MQ
v6.0.1. It was based on the C Client (and GSKit).
• In V8 MQ .NET Managed mode now supports SSL based on Microsoft
SSLStreams/Security kit.
• There are some limitations when using SSL with Managed .NET.
• CipherSpec setting can be made only at Windows Group policy
(gpedit.msc).
– CipherSpec set on client channel is used only to determine SSLProtocol.
– Make sure you set same cipherspec on Windows group policy and
client channel to make sure correct protocol version is flowed.
• KeyRepository uses Windows Key Store only.
– Set value as *SYSTEM for accessing certificates under Computer
Account
– Set value as *USER for accessing certificates under User account
• FIPS can be enabled only from Windows group policy.
• KEYRESET is not supported by Microsoft SSLStreams
– This limitation is overridden by using KEYRESETCOUNT and Client Auto
Reconnect feature of MQ.
– Application can set KEYRESETCOUNT during connection, once the
number of bytes sent/received reaches the count, connection will be
forcibly broken. If Client Auto Reconnect facility is enabled, connection
will be automatically reconnected.
• No managed way to support Cryptographic hardware
• Product samples have been updated to demonstrate SSL Connections.
These can be found in
WebSphere MQtoolsdotnetsamplescsbaseSimple
• Additional model for sending MQ messages from WCF applications
– Both SOAP/JMS and MQMessaging can be used
• SOAP/JMS
– Supported since MQ v7.0.1
– Based on XMS .NET and makes JMS-like calls for MQI
– Uses JMS nomenclature for URI(jms:) and Bindings
– Now also supports “wmq:” style of URI
• Uses MA93 supportpac specification for URI format/syntax
– Messages can be delivered only to SOAP enabled Client/Service
• MQMessaging
– New in MQ V8.0
– Transmits MQ Messages over the WCF Channel without any SOAP
headers
– Use “wmq:” style of URI
• Uses MA93 supportpac specification for URI format/syntax
– Messages can be delivered to SOAP or NON-SOAP MQ applications

WebSphere MQ
Changes to runmqsc
Can now be run by any user (not just mqm group)
Can take a userid/password for authentication: new "-u" flag
Can now connect as a client to remote systems: new "-c" flag
Client channel definitions located by MQSERVER -> MQCHLLIB -> MQCHLTAB
Can act as standalone program to create local CCDT: new "-n" flag
Does not connect to queue manager; commands subset to update local channel definition
file
Ease of use
Customisable prompt
using environment
variable
New "exit" and "quit"
synonyms for "end"
$ ls –l runmqsc
-r-xr-xr-x 1 mqm mqm 25930 06 Mar 04:46 runmqsc
$ export MQPROMPT="MQ +MQ_INSTALLATION_NAME+> "
$ runmqsc –u metaylor QM1
5724-H72 (C) Copyright IBM Corp. 1994, 2014.
Enter password:
******
Starting MQSC for queue manager QM1.
MQ Installation5> DIS QMGR
…
WebSphere MQ
N
O
T
E
S
Changes to runmqsc
• This release introduces a number of changes to the runmqsc program
• Firstly, it is now exectuable by any user, not just members of the mqm group. Security controls still apply of
course, but the security is checked on each individual command. This makes it easier to have MQ administrators
who have been granted full access to objects, but who are not in the mqm group.
• Another reason for making runmqsc world-executable was to make it usable on machines which do not have
queue managers installed. It is now installed even on client-only systems, and it can be run either as a client
program connecting directly to a remote queue manager, or as a completely standalone program to permit
local creation of the Client Channel Definition Table. So you can create and modify a CCDT with no queue
manager access at all.
• The program is one of several that have been updated to accept a userid for authentication. If the –u flag is
given, then a password is requested. Note that the password is read from stdin so that it can be redirected from
a file if necessary. If you also use scripts piped into runmqsc, then you can group commands to avoid having to
put the password in the same script as the MQSC commands.
– Unix: (cat password.stash ; cat script.mqsc) | runmqsc –u userid QM1
– Windows: (type password.stash & type script.mqsc) | runmqsc –u userid QM1
• There are also a couple of usability enhancements. Firstly, there are some synomyms added to complete an
MQSC session – END, QUIT and EXIT can all be used so you don't have to try them all. Different scripting
environments for different products typically use one of these commands, and it's annoying to have to
remember which goes with which.
• Secondly, you can now make it easier to see that you are in an MQSC command environment and some details
of the current environment by setting the MQPROMPT environment variable. Replaceable inserts are
recognised such as date and time, and installation-specific details. These are the same variable subsitutions as
available for SERVICE objects.

WebSphere MQ
SHA-2 Support
Stronger algorithms are now available and recommended
In many cases available pre-V8
See technote http://www.ibm.com/support/docview.wss?uid=swg21639606
Changes also rolled into V8
CipherSpecs include:-
ECDHE_RSA_AES_128_CBC_SHA256
ECDHE_RSA_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_NULL_SHA256
WebSphere MQ
N
O
T
E
S
SHA-2 Support
• SHA-2 stands for Secure Hash Algorithm 2. This is the generic name for a family of hash
functions SHA-224, SHA-256, SHA-384, and SHA-512; the numbers refer to the bit-size
of the generated hash value.
• The hashing algorithms historically supported by WebSphere MQ channel cipherSpecs
(SSLCIPH) were MD5 and SHA-1. These are no longer regarded as adequately secure
due to successful attacks on them which have been widely publicized, and because
NIST (the American National Institute of Standards and Technology) has mandated
(http://csrc.nist.gov/groups/ST/hash/policy.html) that both MD5 and SHA-1 no longer
be used. So we have had considerable customer pressure for provision of “SHA-2
support.”
• This support is in MQ V8, but also in earlier releases by applying appropriate fix pacs
for the platform or component on MQ where you are interested in using it. A technote
at http://www.ibm.com/support/docview.wss?uid=swg21639606 details exactly which
fix pacs or APARs are required in each case.

WebSphere MQ
MQ Security – Authentication (1)
Verify userid and password
Typically supplied in MQI CSP structure or
from channel security exit
Or JMS createConnection(user,pass)
method
New client exit and tool provided to help
unchanged applications insert passwords
Can verify against operating system
Including PassPhrase for z/OS
Can verify against LDAP repository on
Distributed platforms
Enabling centralised identity control
MQCNO cno = {MQCNO_DEFAULT};
cno.Version = MQCNO_VERSION_5;
cno.SecurityParmsPtr = &csp;
MQCONNX(QMName,
&cno,
&hConn,
&CompCode,
&Reason);
MQCSP csp = {MQCSP_DEFAULT};
csp.AuthenticationType = MQCSP_AUTH_USER_ID_AND_PWD;
csp.CSPUserIdPtr = "hughson";
csp.CSPUserIdLength = 7; /* Max: MQ_CLIENT_USER_ID_LENGTH */
csp.CSPPasswordPtr = "passw0rd";
csp.CSPPasswordLength = 8; /* Max: MQ_CSP_PASSWORD_LENGTH */
WebSphere MQ
Object Oriented MQ classes changes
cf = getCF();
System.out.println("Creating the Connection with UID and Password");
Connection conn = cf.createConnection("hughson", "passw0rd");
JMS/XMS classes changes
MQEnvironment.properties = new Hashtable();
MQEnvironment.userID = "hughson";
MQEnvironment.password ="passw0rd";
System.out.println("Connecting to queue manager");
MQQueueManager qMgr = new MQQueueManager(QMName);

WebSphere MQ
MQ Security – Authentication (2)
Independent configuration for local bindings and clients
Ignored, Optional, Required, Required for admin id
Queue Manager checks password against OS or LDAP
ALTER QMGR CONNAUTH(‘CHECK.PWD’)
DEFINE AUTHINFO(‘CHECK.PWD’)
AUTHTYPE(IDPWOS|IDPWLDAP)
CHCKLOCL(NONE|OPTIONAL|REQUIRED|REQDADM)
CHCKCLNT(NONE|OPTIONAL|REQUIRED|REQDADM)
ADOPTCTX(YES)
+ various LDAP attributes
REFRESH SECURITY TYPE(CONNAUTH)
Password protection is provided when SSL/TLS not in use
Both ends of client channel are V8 or above
WebSphere MQ
N
O
T
E
S
MQ Security - Authentication
• Applications can now be authenticated with a userid/password. This can be provided explicitly by the
application as parameters in the MQCONNX verb or equivalent. This builds on features originally implemented
in the MQI for MQ v6, but which were never exploited until now.
• Also, to support client applications, a security exit is provided that can add the userid/password to a connection
request if it is not supplied by the app. The exit reads the qmgr name from an ini file; the file contains the userid
and a protected form of the password – ie not plaintext. The protection of the password is done by a tool that is
also provided.
• When V8 clients connect to V8 qmgrs, the userid/password information is protected against casual wire-
sniffing, even when SSL/TLS is not used. This protection is not as strong as a full TLS-encrypted session, which is
preferred, but is better than sending data in the clear. Obviously both the client and the qmgr must be at V8 for
this protection to work; older clients can still send passwords but they are not protected.
• Authentication is performed against the local OS (all platforms) or against an LDAP directory (Distributed only).
Some operating systems may integrate LDAP services into their local user registry, in the same way as NIS, but
when this is done transparently MQ does not know about it explicitly and can use the OS authentication
method.
• Using a central LDAP server means that passwords can be set in a single place. For example, we have used IBM's
LDAP services (BluePages) to authenticate userids. When using LDAP, there is lots of flexibility in what the
"userid" is – in BluePages it is generally the email address – but there must be a field in the schema to return a
short name that can fit into the 12 character MQMD.UserIdentifier field. This short name is also used for
authorisation and must be locally defined to the OS so that permissions can be calculated.
• There are various configuration rules for different modes of connection, to specify whether a password is
required, optional or ignored.

WebSphere MQ
MQ Security - Authorisation
Make Unix OAM userid-based
Optional configuration
Consistent with other platforms
Will no longer add primary group
to authorities during setmqaut
Chosen at queue manager creation
or by editing qm.ini
Default is still group-based authorisations
Delete Authority record by SID
Solve problem of orphaned authorities when Windows id is deleted
$ crtmqm –oa user QMU
----------------
Service:
Name=AuthorizationService
EntryPoints=14
SecurityPolicy=User
WebSphere MQ
N
O
T
E
S
MQ Security - Authorisation
• One further point of consistency in this release is making the Unix authorisation model the same
as for Windows – permissions can now be set for individual users, and not just groups. So running
a command such as "setmqaut –t qmgr –p usr1 +connect" works for just that user, and not the
primary group.
• This is configured by either creating the queue manager with the "-oa user" option or by editing
the ini file as shown for existing queue managers – restarting the queue manager sets it to work in
the new mode. The change is deliberately not dynamic, and requires the restart, because it is so
fundamental to how the queue manager permissions operate, and is not something we would
expect to be done frequently.
• All existing permissions are left unchanged when you switch to user-mode authorisations, so the
group permissions that have been set remain, but new permissions can be set for the users.
• The user-based model is not the default for new queue managers; to keep compatibility with
older systems, the default is still the group-based model.
• One final security feature is specifically for Windows, to deal with situations where users have
been deleted from the system but their MQ permissions have not been deleted from the OAM.
You can now use the setmqaut command to delete permissions based on SID instead of name,
and this will remove the orphaned entries.

WebSphere MQ
MQ Security - CHLAUTH
Use DNS hostnames in CHLAUTH records
Not allowed in TYPE(BLOCKADDR)
Used in TYPE(ADDRESSMAP) instead of an IP address
Also as an address restrictor on any other mapping type, instead of an IP address, e.g.
SET CHLAUTH(‘*’) TYPE(SSLPEERMAP)
SSLPEER(‘CN=“Morag Hughson”’) ADDRESS(‘*.ibm.com’)
MCAUSER(HUGHSON)
Must ensure DNS can reverse look-up IP address -> Hostname
Also we provide a way to disable reverse lookup
ALTER QMGR REVDNS(ENABLED|DISABLED)
CHLAUTH also hooks into other security features in V8
Granular connection authentication control with CHCKCLNT on CHLAUTH rules
Better Certificate DN filtering with SSLCERTI on CHLAUTH rules
WebSphere MQ
N
O
T
E
S
MQ Security - CHLAUTH
• The CHLAUTH rules that were introduced in V7.1 have been extended to meet the
most frequently-requested enhancement – the ability to use hostnames in the rules as
well as IP addresses. Names can be used all the same rules, and in the same way, as IP
addresses with the one exception of the listener blocking which is still only address-
based.
• The hostnames can include wildcard patterns such as "*.example.com". The matching
is simple string-based; the "." characters are not treated as special separators.

WebSphere MQ
MQ Security - Certificates
Configurable default certificate label for qmgrs and clients
Instead of "ibmwebspheremq<qmgr>" or "ibmwebspheremq<userid>“
ALTER QMGR CERTLABL('My certificate name')
Channel-level certificates
To support different business partners using different CAs.
For queue managers and C clients
Not Java yet, because Java 7 JSSE does not fully support SNI
Both ends must be V8
Per Channel Certificate
ALTER CHANNEL … CERTLABL('This channel certificate')
Certificate Matching
SET CHLAUTH('*')
TYPE(SSLPEERMAP)
SSLPEER('CN=Morag Hughson')
SSLCERTI('CN=IBM CA')
MCAUSER('hughson')
WebSphere MQ
N
O
T
E
S
MQ Security - Certificates
• The label used to find the queue manager or client's certificate in the SSL keystore is
now configurable. This gives more flexibility in naming, and can even permit sharing of
the keystore between multiple queue managers if you wish. On z/OS, there is in
addition a configuration attribute for the QSG-related certificate (traditionally
"ibmwebspheremq<qsgname>".
• A further extension for certificate use is designed for scenarios where you may wish to
use different certificates when communicating with different partners. A common
reason for this is when a queue manager is used for both "internal-facing" channels
and for connections to a partner, who may have different certificate requirements,
such as using a different CA. You can now configure a different certificate label to be
used on individual channels. The implementation of this requires both ends of the
channel to be at MQ V8, as there has to be cooperation between the sending side and
the receiving side of the channel. And it is not available in all environments; in
particular, Java clients cannot currently participate as the standard JSSE provider does
not yet support the Server Name Indication (SNI) flows that go alongside the socket
setup calls.

WebSphere MQ
Multiplexed client performance
Version 7 introduced support for SHARECNV
Multiple client conversations (e.g. threads) can use the same TCP/IP socket (channel
instance)
SHARECNV(0)
No conversation sharing, behaviour as per version 6
SHARECNV(1)
No conversation sharing
Heartbeats, asynchronous message consumption and read-ahead support
SHARECNV(n>1)
Up to n conversations per channel instance - reduces number of sockets and channel
instances
Performance improvements
On distributed, SHARECNV(n>1) can impact performance if multiple conversations are
busy due to contention for the socket
In version 8, SHARECNV(1) optimized for parity with SHARECNV(0)
WebSphere MQ
N
O
T
E
S
Multiplexed client performance
• Prior to version 7 each client conversation uses a separate socket and channel instance. If clients
establish multiple conversations using different threads this can create a large demand for sockets
on the server. Each channel instance also requires storage on the queue manager.
• In version 7 support was added to allow client conversations to share the same socket/channel
instance. This can significantly reduce the resource overhead associated with these connections.
Support for bi-directional communication was also introduced that supports new capabilities, such
as heartbeats, read-ahead and asynchronous message consumption.
• However, if multiple conversations share the same socket, contention can arise if the total
workload for the conversations exceeds the capacity of the socket. Additionally, an overhead is
also introduced to serialize access when sending and receiving TCP/IP data.
• SHARECNV(0) disables all version 7 enhancements. SHARECNV(1) can be used to disable only
conversation sharing. Unfortunately, in version 7 the latter incurs a notable performance
overhead as a result of enabling the other version 7 capabilities. In version 8, support for
SHARECNV(1) has been optimized to achieve parity with SHARECNV(0).

WebSphere MQ
Distributed vertical scaling
Vertical scaling of distributed queue managers has been enhanced
Various efficiency improvements, including
Better cache alignment
Extended 64-bit exploitation for locking primitives
Better compiler optimisations
Faster data conversion, especially for UTF-8
Object catalogue restructured
Better exploitation of SMP machines
Less targeted at internal benchmarks – hopefully more realistic scenarios
WebSphere MQ
N
O
T
E
S
Distributed vertical scaling
• A number of enhancements have been implemented in version 8 to improve the
vertical scaling of queue managers on the distributed platforms. Some of these
improvements are listed on the previous slide.
• We’ve also updated the focus of our performance testing to be less reliant on some
internal benchmarks that do not represent realistic customer workloads. Although
each customer workload is different, so guarantees are not possible, the performance
improvements in version 8 are more likely to be relevant to real-world scenarios.

WebSphere MQ
Publish/subscribe improvements
Improved PROXYSUB(FORCE) behaviour
Version 7 uses individual proxy subscriptions
Version 8 uses wildcards where appropriate to reduce flows
Improved error handling in multi-queue manager environments
Improved scaling for large topic trees
Linear scaling to at least a million topics
Improved DISPLAY PUBSUB
Allows detection of unexpected growth in topics/subscriptions
AMQ8723: Display pub/sub status details.
QMNAME(QMGR3) TYPE(LOCAL)
STATUS(ACTIVE) SUBCOUNT(241)
TPCOUNT(105)
WebSphere MQ
N
O
T
E
S
Publish/subscribe improvements
• In a publish/subscribe hierarchy, or cluster, proxy subscriptions are used to indicate
which queue managers in the topology publications need to be propagated to for
remote subscribers. If applications have short-lived subscriptions the delay incurred
propagating the proxy subscriptions to all queue managers can result in some remote
publications not being delivered. PROXYSUB(FORCE) can be specified on a topic to
force all publications to be propagated to all remote queue managers. This avoids this
problem at the expense of propagating messages even when there are no subscribers
connected to a queue manager. In version 8 using PROXYSUB(FORCE) also significantly
reduces the overhead of propagating proxy subscriptions for a given topic node.
• Internal topic tree management has been enhanced for large numbers of topics.
Performance should scale linearly up to at least a million topics.
• The DISPLAY PUBSUB command has also been enhanced to report the total number of
topics and subscribers. This can be used to detect growth in these and help determine
the potential impact of a wildcard in a DISPLAY TOPIC/SUB/TPSTATUS/SBSTATUS
command.

WebSphere MQ
Routed Publish/Subscribe
In version 7, all queue managers in a cluster know everything and need to be
able to connect to anyone
CLUS1
FR
TOPIC(T1) CLUSTER(CLUS1)
Sub to T1
Pub to T1
Queue manager
CLUSQMGR knowledge
Channel
Proxy subscription
WebSphere MQ
Routed Publish/subscribe
In version 8 you can configure a subset of queue managers to know
everything and connect to everyone
Publications are sent via
these queue managers
Queue manager
CLUSQMGR knowledge
Channel
Proxy subscription
CLUS1
TOPIC(TOPIC1) CLUSTER(CLUS1)
FR
Sub to T1
Pub to T1

WebSphere MQ
Configuration of routed topics
Topic routing is configured in the TOPIC object definition
Uses the CLROUTE property:
DIRECT: Provides V7 behaviour, publications travel directly from publishing queue
managers to subscribing queue managers
TOPICHOST: publications travel via a topic hosting queue manager
New function in MQ V8
Only V8 queue managers can participate in routed clustered publish/subscribe
Full repositories must also be at V8
Older queue managers are not told of the routed topic definitions and therefore behave as
if the topic was not clustered.
All V7 queue managers can continue to participate in direct clustered pub/sub
DEFINE TOPIC(topic)
CLUSTER(clustername)
CLROUTE(DIRECT|TOPICHOST)
WebSphere MQ
N
O
T
E
S
Routed topics
• In previous releases, if publish/subscribe is used within a cluster, all queue managers require knowledge of all
subscriptions throughout the cluster for publications to locally connected applications.
• Similarly, every queue manager requires connectivity to every other queue manager to establish proxy-
subscriptions and/or deliver publications throughout the cluster.
• Now routing via intermediary queue managers in the cluster is possible
– The aim is to allow topologies where queue manager-to-queue manager connectivity and knowledge is restricted
• With DIRECT pub/sub:
– Direct publication routing
– Every queue manager must scale with the size of the system
• With ROUTED pub/sub
– The load on the majority of queue managers is independent from the size of the system
– Publications may incur additional hops
• Messages published on topic host routed topics are similar to messages put to clustered queues:
– Think of a routed topic def as a clustered queue and a publisher to the topic as an app putting to that queue
– Each message published is sent to one of the topic host queue managers, and from there onto the queue managers where
subscriptions exist
– Messages are workload balanced across all topic hosts with available channels from the publishing queue manager to the
topic hosts
• Unavailable topic hosts are avoided
– Workload balancing behaviour is as for a clustered queue using all default settings (CLWLPRTY, CLWLRANK, etc.) except for
DEFBIND, which is effectively set to NOT_FIXED
• Each individual message is ‘evenly’ workload balanced across topic hosts
• Workload balancing is based on the cluster channel rather than the topic (as for queues), so channel workload balancing control still applies
(CLWLPRTY, CLWLRANK, CLWLWGHT)

WebSphere MQ
Multiple cluster transmission queues
Multiple cluster transmission queues added in V7.5
Support for z/OS and IBM i added in V8
Benefits of using multiple transmission queues
Separation of message traffic
With a single transmission queue, pending messages for one channel can interfere
with those for another, especially when messages build up on the queue
Management of messages
Use of queue concepts such as MAXDEPTH are not useful when using a single
transmission queue for all cluster-sender channels
System monitoring
Tracking the number of messages processed by a cluster-sender channel is not
possible using queue monitoring if a single transmission queue is shared by multiple
channels, although some information is available using channel status
WebSphere MQ
N
O
T
E
S
Multiple cluster transmission queues
• Support for multiple cluster transmission queues was added on the distributed
platforms in version 7.5. Version 8 adds support for this capability on z/OS and IBM i.
• A different transmission queue can now be used by each cluster-sender channel, or a
subset of cluster-sender channels, instead of all channels using
SYSTEM.CLUSTER.TRANSMIT.QUEUE.
• The introduction of multiple cluster transmission queues is not designed to improve
performance, but to provide a capability to isolate message traffic.
– It is quicker to assess the impact of an issue if traffic is separated for different applications.
– If a queue manager is a member of multiple clusters, a different transmission queue can be
used for each cluster. This can prevent a build up of messages for one cluster, that results in
a full page set or MAXDEPTH being reached, impacting the other clusters.
– If messages for different applications are sent over different cluster channels* a problem for
one application can be prevented from impacting others.
• * This can be achieved by using a separate cluster for each application, which may
overlap with other clusters, or hosting the target queues for each application on
different cluster queue managers.

WebSphere MQ
Configuring cluster transmission queues
DEFCLXQ queue manager attribute
Default transmission queue for cluster-sender channels
SCTQ
Use SYSTEM.CLUSTER.TRANSMIT.QUEUE
CHANNEL
Create a permanent-dynamic transmission queue per cluster-sender channel called
SYSTEM.CLUSTER.TRANSMIT.<channel name>
CLCHNAME queue attribute
Set on a manually defined transmission queue
Generic name for channels that should use it
DEFINE QLOCAL(CLUSTER.XMITQ1) USAGE(XMITQ) CLCHNAME(‘AAA.*’) …
Most specific match is used by a channel
WebSphere MQ
N
O
T
E
S
Configuring cluster transmission queues
• The transmission queue to use for each channel can be configured in two ways:
• A manually defined transmission queue can be configured using the CLCHNAME
attribute. The value of this attribute is a generic, or specific, name for the channels
that should use it. The mapping is defined on the transmission queue instead of the
channel because the channel’s definition is determined from the cluster-receiver
definition on the remote queue manager. If a channel’s name matches multiple
CLCHNAME values the most specific match is used to determine which transmission
queue to use.
• If no matching queue is found the queue manager uses the default transmission queue
setting, specified by the DEFCLXQ queue manager attribute, to determine which
transmission queue to use. This attribute indicates whether to use
SYSTEM.CLUSTER.TRANSMIT.QUEUE or to create a permanent-dynamic
transmission queue called SYSTEM.CLUSTER.TRANSMIT.<channel name>.

WebSphere MQ
MQ for z/OS: 64-bit bufferpools
64-bit buffer pools in MQ for z/OS
Allows large numbers of messages to be cached before writing to pagesets
Allows MQ to exploit the vast amount of storage on today's machines
Improves performance of putting/getting messages by minimizing disk I/O
Minimizes administrative overhead of managing buffer pools
Buffer pool LOCATION attribute says where it is located relative to the bar
BELOW: The default. Buffer pool is located below the bar in 31 bit storage
ABOVE: Buffer pool is located above the bar in 64 bit storage
This can be altered dynamically
Storage can be pinned based on pageclass attribute
WebSphere MQ
N
O
T
E
S
Buffer pool problems before V8
• There is not much space below the bar for buffer pools once queue manager code and
data is taken into account. Maximum 1.6GB available for buffer pools depending on
common area
• Putting/getting messages into the buffer pool works at 'memory' speed,
putting/getting messages from the page set works at 'disk' speed
• For scenarios where several applications read and/or write large number of messages
to the same buffer pool a lot of time is spent getting pages from page set into buffer
pool and getting pages from buffer pool into page set
– This is detrimental for performance
• A maximum of 16 buffer pools are supported while up to 100 page sets are supported
• This can result in a lot of time spent tuning buffer pool sizes and the relationship
between queues, buffer pools and page sets
• These problems are resolved by allowing bufferpools to be defined in 64-bit space,
above the bar

WebSphere MQ
Buffer pools above the bar can (theoretically) use up to 16 EB storage
Increased maximum size of pool to 999,999,999 buffers
Was 500,000
Allows up to 100 buffer pools
Previously only 16
Can have a 1-1 page set – buffer pool mapping
DATA
CODE
DATA
Buffer Pool
Buffer
Pool
Buffer
Pool
Buffer Pool
2 GB
BAR
16 EB
Up to 1.6 GB
Available
Queue Manager Address Space
Buffer
Pool
WebSphere MQ
N
O
T
E
S
• 64-bit bufferpools can now theoretically use a huge amount of storage
• Having the same number of pools and pagesets makes it much simpler to monitor and
control the usage of these resources
• SMF 115, subtype 215
– Up to 100 buffer pools are now supported. However there is not enough space for 100 buffer
manager statistics records (QPST) in the existing SMF 115, subtype 2, record
– If OPMODE(NEWFUNC,800) is specified in system parameters then an SMF 115, subtype 215,
record will be cut for buffer manager statistics. The SMF 115, subtype 2, record will still
contain the self-defining section for buffer manager but it will be all zeros
– If OPMODE(COMPAT,800) is specified in system parameters then buffer manager statistics
will continue to be in SMF 115, subtype 2.

WebSphere MQ
MQ for z/OS: Performance and Capacity
Log RBA constraint relief
Already improved messages to warn of approaching RBA
Now widening RBA field from 6 to 8 bytes
At 100MB/sec this will now take about 5578 years to fill, whereas with 6 byte RBA some
customers reach the limit in 12-18 months
Support for LP64 batch/RRS C applications
Performance enhancements for IBM Information Replicator (QRep) and
similar application patterns
Read-ahead and changes to deferred write processing allows MQ to increase
sustainable data rates
General improvements to channel performance
WebSphere MQ
N
O
T
E
S
Log RBA extensions
• WebSphere MQ for z/OS V7 implements a 6 byte Log RBA (Relative Byte Address)
– This give an RBA range of 0 to x'FFFFFFFFFFFF' (= 255TB)
– Some customers are now reaching this limit in 12 months
• If we reach the end of the Log RBA range (i.e. “wrap”):
– Queue Manager terminates and requires a cold start – a disruptive outage
– Potential for loss of persistent data
• To avoid an outage:
– Run CSQUTIL RESETPAGE, at regular planned intervals, to RESET the LOG RBA
• With current maintenance, MQ V7.x issues warning messages when approaching maximum
– Then terminates, to prevent loss of data, if log RBA reaches x'FFF800000000'.
• V8 increases size of Log RBA to 8 bytes
– Upper limit on logical log will be 64K times bigger
– Format of BSDS and log records will change to accommodate 8 byte RBAs, URIDs will become 8 bytes long
– Like DB2, the control point for new function is a BSDS conversion utility
– Run the new CSQJUCNV utility
• utility will check that entire QSG is at correct level
• copies data from old primary / secondary BSDS pair to new primary / secondary pair
• All V8 queue managers can read data in both the old and new formats
• All V8 queue managers and utilities will display all log RBAs as 8 bytes
• V8 will ONLY write in new format, once BSDS has been converted

WebSphere MQ
N
O
T
E
S
LP64 Support
• Externalising technology previously used by Broker and JMS
• Limited to C language (no 64bit COBOL)
– LP64 compile option
– Supported by cmqc.h
• Restricted environments
– Batch, TSO, USS
– CICS and IMS do not support 64bit apps
• Must use sidedeck & DLL, not stubs:
– csqbmq2x (uncoordinated batch & USS)
– csqbrr2x (RRS coordinated, srrcmit())
– csqbri2x (RRS coordinated, MQCMIT)
WebSphere MQ
N
O
T
E
S
Performance improvements
• QRep has implemented a common application pattern – basically a single-stream
reading or writing of messages. That program, and others that follow the same
pattern, can benefit from some of the performance enhancements in MQ. For
example, fetching data for the "next message" from a pageset at the same time as for
the "current message" (readahead) can reduce the I/O operations and hence reduce
CPU and increase throughput.

WebSphere MQ
MQ for z/OS: Other features
Exploitation of zEDC compression accelerator
MSGCOMP(ZLIBFAST)
Requires zEC12 GA2 + zEDC card
Can yield higher throughput and reduced CPU for SSL channels
Support for Flash Express feature on zEC12 and zBC12 servers
Improves resiliency of Coupling Facility with cost-effective standby capacity to handle
overflow of shared queues
Messages <63K fully held in Flash
Messages >63K have pointers in Flash, body in SMDS just as for traditional CF structures
SMF enhancements
Channel statistics allow better monitoring and tuning of channel behaviour
Correlation of MQ and CICS statistics
Message suppression
Up to 16 message numbers (particularly X511,X512) can be defined to be excluded
Removes cost of writing WTO messages which are then ignored
Can now differentiate between messages for client chls (X511) and other types (X500)
WebSphere MQ
N
O
T
E
S
MQ for z/OS: Other features
• A number of internal performance improvements have been implemented in version 8,
including some internal optimisations in the channel initiator.
• Some changes have been introduced to significantly improve performance for IBM
Information Replicator (QREP). This product is used to replicate DB2 logs from one
system to another. It is used for disaster recovery and in IBM’s active-active solution
for z/OS. The improvements made for this type of workload include support for pre-
fetching pages from page sets in to buffers and optimizations to the algorithm used to
write data to page sets too. These improvements are likely to also benefit other
customer workloads.
• If you configure channel compression using MSGCOMP(ZLIBFAST) and you are running
on suitable zEC12 hardware, a zEDC card is exploited if available. This can improve
performance as well as reducing CPU activity.
• Another improvement, although not strictly for performance, is the introduction of a
new system parameter, EXCLMSG, that allows you to suppress up to 16 console
messages. This can be used to reduce ‘noise’ on the console. It is preferable to using
the z/OS Message Processing Facility (MPF) to suppress messages, because using this
parameter avoids the CPU overhead of generating the message and issuing the WTO.

WebSphere MQ
IBM has a 20 year track record of innovation in
Messaging
1990s
2000s
JMS
MQI
Assured
delivery
IBM
MQSeries
Multi-platform
Mobile
.NET
Common criteria
Eclipse
JMS 1.1
RCMS
IBM MQ Low
Latency
V1.1
V2
V5 V5.1
V5.3
V2.1
V5.2
V6
V7
V7.0.1
SSL
SOAP
XML
IBM MQ
Managed File
Transfer
IBM MQTT
HTTP
AJAX
REST
Web 2.0
Managed
File Transfer
Pub/sub
IBM MQ
Everyplace
IBM MQ
Advanced
Message
Security
V7.1
V7.5
Integrated
Messaging
Hypervisors
IBM MQ
Advanced
System Pattern
Application Pattern
IBM MQ
Advanced for
Developers
IBM
MessageSight
Multiple cluster
XMIT queue
Multi-instance
QMGR
IBM MQ Low
Latency
20th
Anniversary of
MQ at IMPACT
V8
2010s
WebSphere MQ
And continues to invest in all Messaging markets
Enterprise Messaging where MQ continues to lead
Messaging for Mobile and the Internet of Things
Supporting Cloud deployments with Messaging services
Helping developers use Application Messaging to create better
applications

IBM What's New in MQ V8

More Related Content

What's hot (20)

Similar to IBM What's New in MQ V8 (20)

More from IBM Systems UKI (17)

Recently uploaded (20)

IBM What's New in MQ V8