Displaying host names in MO71

When looking at channel status as reported by IBM MQ, you see the connection name of the channel’s partner, which shows the IP address. IP addresses are not all that memorable, especially as we move into a world with more IPv6 addresses! If you use generic receiver (RCVR) or server-connection (SVRCONN) channels, as is good practice, this can be especially difficult as the channel name is the same for all connections.

MO71 Channel Status IP addresses

All MQ shows you in channel status connection names are the IP addresses

It is possible to improve your understanding about the connections by also displaying the Remote Queue Manager Name (RQMNAME) or Remote Application Name (RAPPLTAG), but with the latest version of MO71, you can now also improve it further by displaying the host name associated with the IP address.

MO71 Channel Status Hostnames

You can configure MO71 to show you hostnames too

In the background, MO71 will make a call to DNS to find out the host name associated with an IP address should it need to be displayed. You choose to display hostnames in a Channel Status List Dialog (such as those shown above), by going into the Alter List… option on the context menu and adding the “Host Name” column to your display. DNS calls can be slow to return so MO71 will cache the results it obtains. You can control how long this caching is for, and clear the cache completely from the Connection tab in the Preferences dialog. If you check the “Save resolved hostnames” option, MO71 will also save the cached values across a restart of the application.

MO71 DNS preferences

The preference options associated with the host name feature

If you find that host names are mainly from a particular domain, and it would be easier to read them without all those dot separated suffixes, you can also configure in the above preferences section, any DNS suffixes to be removed, for example, we could remove mqgem.com in the above examples.

MO71 Channel Status Hostnames Suffix Removed

You can configure MO71 to remove DNS suffixes from host names

If you find that host names are still not memorable enough, or if you are not able to resolve all your IP addresses to suitable hostnames, there is an additional feature. You can create a DNS User file containing your own values. These will be used in preference to any system values retrieved from the DNS. This file could look as follows:-

* MO71 DNS User Values file

192.168.2.106             Dept ASN.RQ server: Contact x2479
192.168.2.107             Dept SALES server: Contact x2588 (Bob)
fe80::9075:a1eb:379d:e7be Business Partner RGHT: Contact Mark 222-567-9765
fe80::9543:124e:4bf7:6374 Devt/Test server: Contact x2544

which would cause MO71 to display that data as the host name in preference to the DNS retrieved values.

MO71 Channel Status User Hostnames

Using the DNS User file you can display any string you want

UPDATE: A minor enhancement to MO71 V9.0.3 adds this host name display to the Queue Usage (DISPLAY QSTATUS) and Connection List (DISPLAY CONN) dialogs too.

So, never be puzzled about what machine an IP address is again. Set up MO71 to show you the string that is most memorable for you.


The new version can be downloaded from the MO71 Download Page. Any current licensed users of MO71 can run the new version on their existing licence. If you don’t have a licence and would like to try out MO71 then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

Creating a CCDT for any version

You may have read an earlier post where we described being able to determine what version of CCDT you had in your hand.

CCDT Version

How often have you had a CCDT file in your hand and wondered what version it was and whether you can give it to some of your known back-level client machines to use.

MQSCX can help you determine this. Open up your CCDT using the mqscx -n mode and then you can quite simply display the version number of all your client channels therein.

What you may not have realised from that post however, was that not only can MQSCX help to investigate what version number your CCDT is made for, it can also make a CCDT for the correct version as well. If you have back-level clients, it can be a real pain having to keep a queue manager of the same level around just to be able to create a CCDT that it will understand. Well, you can ditch that queue manager and use MQSCX instead. It’s really easy to do as well.

To use MQSCX to work with a CCDT, you need to use the -n parameter. This will then look for the CCDT file in the location specified by the MQCHLLIB and MQCHLTAB environment variables unless you provide the -t parameter to give it a specific file name. If one doesn’t exist, it will make a new one for you, and if one does exist it will read it and allow you to update it. In order to control the version of CCDT you are creating, you should additionally use the -V parameter which allows you to specify the version the CCDT file should be written as.

Here’s an example, run the MQSCX program like this:

mqscx -n -t C:\MQGem\CCDT\MQGEM.TAB -V7.0

And then you can use it to make DISPLAY, ALTER and DELETE commands.

MQSCX Extended MQSC Program – Version 8.0.0

CCDT commands directed to file ‘C:\MQGem\CCDT\MQGEM.TAB’

Licenced to Paul Clarke

Licence Location: Head Office

[12:02:10] DISPLAY CHANNEL(*) CONNAME VERSION

_________________________________________________

CHANNEL(MQG1.SVRCONN) CHLTYPE(CLNTCONN)

CONNAME(win12.mqgem.com(1602)) VERSION(8.0)

_________________________________________________

CHANNEL(MQG2.SVRCONN) CHLTYPE(CLNTCONN)

CONNAME(aix5.mqgem.com(4231)) VERSION(8.0)

_________________________________________________

CHANNEL(MQG3.SVRCONN) CHLTYPE(CLNTCONN)

CONNAME(mvs1.mqgem.com(1255)) VERSION(8.0)

_________________________________________________

Total display responses – Received:3

>

As you can see, at the moment all the channels in this CCDT are at V8.0 which means my V7.0 client won’t be able to read them. I need to make a change to each record to ensure MQSCX will write it out at version V7.0 as I have indicated on my start command. Helpfully, I can do that in one single command:-

ALTER CHANNEL(*)

This makes no actual change to the attributes of the channel definition, but does ‘touch’ each record to ensure that it gets the new version. Displaying the records again as above will show that the version number for each channel mentioned by the ALTER command (in this example all of them), now indicates it is at version V7.0, just what my back-level client application needs.

Exiting MQSCX and re-running it will show you that this earlier version of the CCDT has indeed been hardened.

Note that if you had been using some attributes introduced in later versions than V7.0, this information would be lost when altering the channel definition to be an earlier version.


If you’d like to try out MQSCX, please email support@mqgem.com to request a trial licence.

Which channels are being used?

Which ChannelIt was asked recently on the List-Server whether there was an easy way to determine which MQI channels were being used. The asker also raised an RFE to request Channel Statistics be output by the queue manager for these channels as well as the MCA channels that do currently have statistics.

While that facility would indeed help to show which channels were being used, and for what amount of time/traffic and so on, if the problem at hand is only to determine which channels are used and which are not, for example so that unused ones can be deleted, then a current facility of the queue manager is available to discover that.

The Channel Authentication (CHLAUTH) rules which block connections into the queue manager have two modes, blocking and warning. This is controlled by the WARN(YES|NO) attribute. This was briefly discussed in my blog post CHLAUTH – the back-stop rule, to alleviate any concern of initially blocking all connections into a currently working queue manager.

Now here’s another use for WARN(YES).

If you already use CHLAUTH and already have a back-stop rule that covers all channels, then you know that only those you have positive CHLAUTH rules in place for can be being used.

If you don’t already use CHLAUTH, or at least your use of it is not applied to all channels, you could put a rule very similar to the back-stop rule in place, but using warning mode, and then see which channels are being used over time.

SET CHLAUTH('*')
    TYPE(ADDRESSMAP) ADDRESS('*')
    USERSRC(NOACCESS) WARN(YES)

Alternatively, if you’re just trying to figure out if a specific channel (or channels) is actually ever used, you could make the rule specific to that channel name.

SET CHLAUTH(MORAG.SVRCONN)
    TYPE(ADDRESSMAP) ADDRESS('*')
    USERSRC(NOACCESS) WARN(YES)

Either way, to see useful output from this, you should enable channel events, and monitor for the event messages emitted by the queue manager.

ALTER QMGR CHLEV(EXCEPTION)

Here’s an example event message that would be seen by a channel called MORAG.SVRCONN connecting into the queue manager. As you can see, you are shown the channel name, connection name (i.e. the IP address where the client resides), the client side user id and the application name (in this case q.exe). All very useful for working out what it was that ran and caused this channel to be used.

[  224 bytes] Message Content
[  224 bytes] Event Header (MQCFH)
Version      :1
Command      :46 (Channel Event)
Sequence No. :1
Reason       :2578 (Channel Blocked Warning.)
Parm Count   :7
[  188 bytes] String (MQCFST)
Parameter Id :2015 (QMgr Name)
String Length:4
Value        :'MQG2'
[  164 bytes] String (MQCFST)
Parameter Id :3506 (Connection Name)
String Length:9
Value        :'127.0.0.1'
[  132 bytes] Integer (MQCFIN)
Parameter Id :1020 (Reason Qualifier)
Value        :23 [0x'17'] MQRQ_CHANNEL_BLOCKED_NOACCESS
[  116 bytes] String (MQCFST)
Parameter Id :3501 (Channel Name)
String Length:13
Value        :'MORAG.SVRCONN'
[   80 bytes] String (MQCFST)
Parameter Id :3567 (Client User Id)
String Length:5
Value        :'morag'
[   52 bytes] String (MQCFST)
Parameter Id :3024 (Appl Name)
String Length:16
Value        :'d:\nttools\q.exe'
[   16 bytes] Integer (MQCFIN)
Parameter Id :1 (Appl Type)
Value        :11 [0x'B'] MQAT_WINDOWS_NT

N.B. When trying this out for yourself, if you truly only want a logging style use of CHLAUTH and you don’t want anything else to be affected while you do this, including SYSTEM channels and remotely asserted privileged user ids, then you’ll have to first remove the default provided CHLAUTH rules.


I was prompted to write this post as a result of this list-server question.

Be sure of your CCDT Version

CCDT VersionWe all know that you can’t use a CCDT file with a client that is older than the CCDT version. For example, a version 6 client can’t understand what the channel definitions in a V8 produced CCDT mean.

How often have you had a CCDT file in your hand and wondered what version it was and whether you can give it to some of your known back-level client machines to use.

MQSCX can help you determine this. Open up your CCDT using the mqscx -n mode and then you can quite simply display the version number of all your client channels therein.

DISPLAY CHANNEL(*) VERSION

CHANNEL(MQGEM.SVRCONN)            CHLTYPE(CLNTCONN)   VERSION(8.0)
CHANNEL(MQGEM.SVRCONN.SSL)        CHLTYPE(CLNTCONN)   VERSION(9.0)
CHANNEL(MQGEM.SVRCONN.ADMIN)      CHLTYPE(CLNTCONN)   VERSION(7.0)

Alternatively, you might like to write a little script that could iterate through all the channels in the table and tell you the minimum and maximum versions in use within that CCDT.

if (_ccdtmode)
  @minVer = 999999999
  @maxVer = 0
  foreach (DISPLAY CHANNEL(*) VERSION)
    if (VERSION < @minVer)
      @minVer = VERSION
    endif
    if (VERSION > @maxVer)
      @maxVer = VERSION
    endif
  endfor
  if (_numEach)
    print "Channel version in",_ccdt
    print "Minimum:",@minVer,"Maximum:",@maxVer
  else
    print "No channels found in",_ccdt
  endif
else
  print "Run this script with MQSCX in CCDT mode"
endif

Running this against a multi-version CCDT might produce output such as:-

Channel version in C:\MQGem\CCDT\MQGEM101.TAB
Minimum: 7.00 Maximum: 9.00

foreachThis type of CCDT analysis is possible due to the recent addition of the foreach construct to the CCDT processing in MQSCX.

If you are a current MQSCX licence holder, you can simply download the new version of MQSCX and start using it. If you’re not a current licence holder, and you’d like to try out MQSCX, please email support@mqgem.com to request a trial licence.

MaxChannels vs DIS QMSTATUS CONNS

I got asked this question on twitter the other day, so I thought it would make an interesting blog post.

Let’s look at each piece of the question.

DISPLAY QMSTATUS CONNS

You can use the DISPLAY QMSTATUS command to see how many connections there are currently made into the queue manager. This is a count of the number of applications (or some queue manager processes too) that have made an MQCONN(X) to the queue manager. It is also the same number of responses you should see returned by DISPLAY CONN(*) – if you don’t want to count them, find an MQ admin tool that counts them for you. These connections might be local or client connections – both contribute to the total.

To see the local ones use command:-

DISPLAY CONN(*) ALL WHERE(CHANNEL EQ ' ')

To see the remote ones use command:-

DISPLAY CONN(*) ALL WHERE(CHANNEL NE ' ')

Client Connections and MaxChannels

So having ruled out the local connections what should you think if the number of connections coming in over a channel is more than MaxChannels? As the question asks, “Shouldn’t that be failing?”

The other thing to remember here is that, since MQ V7, one SVRCONN channel can relay several client MQCONNs over to the queue manager.

To see this take a look at the DISPLAY CHSTATUS command. There is a status attribute CURSHCNV that shows the number currently being shared over that one SVRCONN instance.

To see the number of running channels, use the command:-

DISPLAY CHSTATUS(*) CURSHCNV

The number of responses will show you how many running channel instances there are – which is the number to compare against MaxChannels. If you add up the total of all the numbers shown in CURSHCNV, this total will be less than (or equal to) the above number of channel based connections shown when you used the DISPLAY CONN command. Both queue manager channels and client channels contribute to that total.

HINT: If you want an easy way to total up all the numbers shown in CURSHCNV, try out MQSCX with this single line:-

@total=0;foreach(DISPLAY CHSTATUS(*) CURSHCNV);@total=@total+CURSHCNV;endfor;print @total

Or you could make a little import file to print out all the various numbers:-

=echo cmds(NO)
=echo resp(NO)
print 'Show all the connections into queue manager',_connqmgr
print _sep

DISPLAY QMSTATUS CONNS
print 'Total connections ',CONNS

DISPLAY CONN(*) ALL WHERE(CHANNEL EQ ' ')
print 'Local connections ',_matches

DISPLAY CONN(*) ALL WHERE(CHANNEL NE ' ')
print 'Remote connections',_matches

@total = 0
@svrcn = 0
foreach(DISPLAY CHSTATUS(*) CURSHCNV CHLTYPE)
  if (CHLTYPE = "SVRCONN")
    @svrcn = @svrcn + 1
  endif
  @total = @total + CURSHCNV
endfor
print 'Total Channel instances ',_matches
print 'QMgr Channel instances  ',_matches - @svrcn
print 'Client Channel instances',@svrcn
print 'Client connections',@total
=echo cmds(YES)
=echo resp(YES)

UPDATE: This script evolved further with the release of MQSCX V9.0.0 and the use of functions – see more in MQSCX Functions.


IBM Certified SpecialistIBM Champion 2016 Middleware

Morag Hughson
IBM Champion 2016 – Middleware
IBM Certified System Administrator – MQ V8.0
Find her on: LinkedIn: http://uk.linkedin.com/in/moraghughson Twitter: https://twitter.com/MoragHughson SlideShare: http://www.slideshare.net/moraghughson developerWorks: https://www.ibm.com/developerworks/community/profiles/html/profileView.do?userid=110000EQPN

SVRCONNs and INDISP(SHARED) listeners

Colin Paice has been writing a number of blog posts that highlight issues you need to know about and avoid in your MQ environment. You can follow Colin’s writing over on his blog, and also on the MQDev blog. Recently he wrote a short post on that “well known SVRCONN shared listener problem in a QSG” highlighting that not all MQ users realise it is something to be avoided.

I thought this topic could do with a fuller explanation – after all, sometimes understanding the reason behind something helps it stick in your mind better why not to do it.


Goals when connecting clients into a Queue Sharing Group

When you have client connected applications that are going to connect into a Queue Sharing Group (QSG) you have two main goals:-

  • Be able to connect to any member
    A QSG is all about availability, so you want to ensure that your clients always have somewhere to connect to. Unless something drastic happens, a QSG should always have at least one member queue manager running at all times, and your clients need to be able to find their way there.
  • Put/Get messages to/from Shared queues
    Your client applications want to be able to make use of the resources in a QSG, the shared queues – this gives the overall application (from client to backend) the best availability. Of course, it is also the case that clients connecting into the QSG can put to local queues, cloned local queues if you want it to work regardless of where the client application connected.

You can connect to any available QSG member with any kind of front-end routing (Sysplex Distributor; Big IP; CCDT; even a comma-separated CONNAME!) that points to the normal (non-shared) listener port.

Client into QSG

Clients connecting into QSG can use the non-shared listener port

What’s the difference between private and shared SVRCONN channels?

To understand the difference for SVRCONN, it pays to first understand the difference for MCA channels. In a QSG there are two different ways channels can run – referred to as the disposition of the channel, this can either be SHARED or PRIVATE.

  • A CHLDISP(SHARED) Channel
    • Outbound Channel
      An outbound channel, e.g. a SENDER, that is running as a shared channel is one that reads messages from a QSGDISP(SHARED) transmission queue. If you try to tell a sender channel to run shared and it’s transmission queue is not stored in the Coupling Facility (CF) it won’t let you.
    • Inbound Channel
      An inbound channel, e.g. a RCVR, that is running as a shared channel is one that connected itself to the queue manager through the shared/group listener port – that is the listener which has been started as INDISP(GROUP). This is the exact and only definition of an inbound CHLDISP(SHARED) channel.

    When running as a CHLDISP(SHARED) channel the other thing that is important to understand is the storage of state. Channel status is stored both locally in the in-memory channel status table, and also in the shared DB2 status table. This means that commands like DISPLAY CHSTATUS can be issued anywhere in the QSG and status about the channel can be displayed.

    Committed status, that is the details about the last batch of messages sent/received is stored on the SYSTEM.QSG.CHANNEL.SYNCQ (which is a QSGDISP(SHARED) queue) instead of the SYSTEM.CHANNEL.SYNCQ. This means that when a shared channel ends in-doubt, and is restarted on a different member of the QSG, the batch can be resolved and messaging can continue.

  • A CHLDISP(PRIVATE) Channel
    • Outbound Channel
      An outbound channel, e.g. a SENDER, that is running as a private channel is one that reads messages from a QSGDISP(PRIVATE) transmission queue. If you try to tell a sender channel to run private and it’s transmission queue is not stored on a Page Set it won’t let you.
    • Inbound Channel
      An inbound channel, e.g. a RCVR, that is running as a private channel is one that connected itself to the queue manager through the normal queue manager listener port – that is the listener which has been started as INDISP(QMGR). This is the exact and only definition of an inbound CHLDISP(PRIVATE) channel.

    When running as a CHLDISP(PRIVATE) channel the other thing that is important to understand is the storage of state. Channel status is only stored in the local in-memory channel status table. This means that to obtain information about channel status you must use the CMDSCOPE(*) construct and ask every queue manager about it’s channels.

    Committed status, that is the details about the last batch of messages sent/received is stored on the SYSTEM.CHANNEL.SYNCQ. This means that only the same queue manager can resolve an in-doubt batch for messaging to continue.

All of the above describes the messaging channels that go between two queue managers. It doesn’t say anything about CLNTCONN-SVRCONN channels.

The same rules still apply to SVRCONN channels in so much as they are applicable. First off a SVRCONN is an inbound channel, so we’re only interested in the inbound set of rules. Secondly, a SVRCONN channel has no committed status because it doesn’t move batches of messages in the way MCA channels do. So all we’re left with is the status used by DISPLAY CHSTATUS. So here’s the difference between a SVRCONN that is either SHARED or PRIVATE.

  • A CHLDISP(SHARED) Channel
    A SVRCONN that is running as a shared channel is one that connected itself to the queue manager through the shared/group listener port – that is the listener which has been started as INDISP(GROUP). When running as a CHLDISP(SHARED) channel the thing that is important to understand is the storage of state. Channel status is stored both locally in the in-memory channel status table, and also in the shared DB2 status table. This means that commands like DISPLAY CHSTATUS can be issued anywhere in the QSG and status about the channel can be displayed.
  • A CHLDISP(PRIVATE) Channel
    A SVRCONN that is running as a private channel is one that connected itself to the queue manager through the normal queue manager listener port – that is the listener which has been started as INDISP(QMGR). When running as a CHLDISP(PRIVATE) channel the thing that is important to understand is the storage of state. Channel status is only stored in the local in-memory channel status table. This means that to obtain information about channel status you must use the CMDSCOPE(*) construct and ask every queue manager about it’s channels.

So the difference is whether you have to issue this command (works for CHLDISP(SHARED)) which is answered by a single queue manager:-

DISPLAY CHSTATUS(MQGEM.SVRCONN) CHLDISP(SHARED) SHORT

Or this command (works for CHLDISP(PRIVATE)) which is answered by every queue manager in the QSG:-

DISPLAY CHSTATUS(MQGEM.SVRCONN) CHLDISP(PRIVATE) CMNDSCOPE(*)

to find out where your SVRCONN is actually running.

In order to have this slight difference in DISPLAY CHSTATUS command, you pay a cost, and that cost is the expense of updating the DB2 table with the information about the current owner of this channel. For a short lived SVRCONN channel, this cost can be a major proportion of it’s overall cost.

Summary

There is no difference that affects your goals when connecting clients to a QSG, but there is a cost. This is why Knowledge Center now carries the following advice:

Configuring SVRCONN channels for a queue-sharing group
The optimal configuration for SVRCONN channels in a queue sharing group is to set up private listeners in each CHINIT which use a different port number from the point to point channels. These listener ports are then used as the ‘back-end’ resources for a new workload distribution mechanism such as Sysplex Distributor using Virtual IP addresses (VIPA). The external VIPA address is then used as the target address for the CLNTCONN definitions in the network. The SVRCONN channel can be defined with QSGDISP(GROUP) so the same definition is available to all queue managers in the QSG. This configuration avoids using a shared listener, and therefore the reduces performance effect of the QSG maintaining shared channel state which is not needed for client/server channels.


IBM Certified SpecialistIBM Champion 2016 Middleware

Morag Hughson
IBM Champion 2016 – Middleware
IBM Certified System Administrator – MQ V8.0
Find her on: LinkedIn: http://uk.linkedin.com/in/moraghughson Twitter: https://twitter.com/MoragHughson SlideShare: http://www.slideshare.net/moraghughson developerWorks: https://www.ibm.com/developerworks/community/profiles/html/profileView.do?userid=110000EQPN

Deprecated CipherSpecs

Cracked PadlockEarlier in Blog Post: Know your protocol I wrote about how IBM MQ V8 FixPack 2 had deprecated all the SSL 3.0 CipherSpecs and turned them off by default.

Now in FixPack 3 a further set of CipherSpecs have been deprecated so that, by default, attempts to use them will result in a error. The additional CipherSpecs deprecated in FixPack 3 are those which use no encryption; the RC algorithms (RC2 and RC4); and single DES.

UPDATE: Now with APAR IV90867, which is targeted for IBM MQ V8 FixPack 6, a further set of CipherSpecs have been deprecated. The additional CipherSpecs deprecated in FixPack 6 are those which use the Triple DES algorithm.

Whether you are currently on IBM MQ V8 at any of these FixPacs or not, you should consider this as a strong hint to look at your use of any of these CipherSpecs and change to a stronger one where possible.

CipherSpecs now deprecated in IBM MQ V8, highlighted column shows the reason for deprecation.
CipherSpec Name Protocol Used Data Integrity Encryption Deprecated in
Algorithm Bits
AES_SHA_US SSL 3.0 SHA-1 AES 128 V8 FixPack 2
DES_SHA_EXPORT SSL 3.0 SHA-1 DES 56 V8 FixPack 2
DES_SHA_EXPORT1024 SSL 3.0 SHA-1 DES 56 V8 FixPack 2
FIPS_WITH_DES_CBC_SHA SSL 3.0 SHA-1 DES 56 V8 FixPack 2
FIPS_WITH_3DES_EDE_CBC_SHA SSL 3.0 SHA-1 3DES 168 V8 FixPack 2
NULL_MD5 SSL 3.0 MD5 None 0 V8 FixPack 2
NULL_SHA SSL 3.0 SHA-1 None 0 V8 FixPack 2
RC2_MD5_EXPORT SSL 3.0 MD5 RC2 40 V8 FixPack 2
RC4_MD5_EXPORT SSL 3.0 MD5 RC4 40 V8 FixPack 2
RC4_MD5_US SSL 3.0 MD5 RC4 128 V8 FixPack 2
RC4_SHA_US SSL 3.0 SHA-1 RC4 128 V8 FixPack 2
RC4_56_SHA_EXPORT1024 SSL 3.0 SHA-1 RC4 56 V8 FixPack 2
TRIPLE_DES_SHA_US SSL 3.0 SHA-1 3DES 168 V8 FixPack 2
TLS_RSA_EXPORT_WITH_RC2_40_MD5 TLS 1.0 MD5 RC2 40 V8 FixPack 3
TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS 1.0 MD5 RC4 40 V8 FixPack 3
TLS_RSA_WITH_DES_CBC_SHA TLS 1.0 SHA-1 DES 56 V8 FixPack 3
TLS_RSA_WITH_NULL_MD5 TLS 1.0 MD5 None 0 V8 FixPack 3
TLS_RSA_WITH_NULL_SHA TLS 1.0 SHA-1 None 0 V8 FixPack 3
TLS_RSA_WITH_RC4_128_MD5 TLS 1.0 MD5 RC4 128 V8 FixPack 3
ECDHE_ECDSA_NULL_SHA256 TLS 1.2 SHA-1 None 0 V8 FixPack 3
ECDHE_ECDSA_RC4_128_SHA256 TLS 1.2 SHA-1 RC4 128 V8 FixPack 3
ECDHE_RSA_NULL_SHA256 TLS 1.2 SHA-1 None 0 V8 FixPack 3
ECDHE_RSA_RC4_128_SHA256 TLS 1.2 SHA-1 RC4 128 V8 FixPack 3
TLS_RSA_WITH_NULL_NULL TLS 1.2 None None 0 V8 FixPack 3
TLS_RSA_WITH_NULL_SHA256 TLS 1.2 SHA-256 None 0 V8 FixPack 3
TLS_RSA_WITH_RC4_128_SHA256 TLS 1.2 SHA-1 RC4 128 V8 FixPack 3
TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS 1.0 SHA-1 3DES 168 V8 FixPack 6
ECDHE_ECDSA_3DES_EDE_CBC_SHA256 TLS 1.2 SHA-1 3DES 168 V8 FixPack 6
ECDHE_RSA_3DES_EDE_CBC_SHA256 TLS 1.2 SHA-1 3DES 168 V8 FixPack 6

As an alternate way of thinking about it, you should be choosing a CipherSpec from the 14 listed in the following table.

CipherSpecs still supported in IBM MQ V8. All of these are FIPS 140-2 certified.
Platform CipherSpec Name Protocol Used Data Integrity Encryption Suite B Added in
Algorithm Bits
All TLS_RSA_WITH_AES_128_CBC_SHA TLS 1.0 SHA-1 AES 128 No V7
All TLS_RSA_WITH_AES_256_CBC_SHA TLS 1.0 SHA-1 AES 256 No V7
All TLS_RSA_WITH_AES_128_CBC_SHA256 TLS 1.2 SHA-256 AES 128 No V7
All TLS_RSA_WITH_AES_256_CBC_SHA256 TLS 1.2 SHA-256 AES 256 No V7
LUW TLS_RSA_WITH_AES_128_GCM_SHA256 TLS 1.2 AEAD AES-128 GCM AES 128 No V7.1
LUW TLS_RSA_WITH_AES_256_GCM_SHA384 TLS 1.2 AEAD AES-128 GCM AES 256 No V7.1
Not IBM i ECDHE_ECDSA_AES_128_CBC_SHA256 TLS 1.2 SHA-256 AES 128 No V7.1
Not IBM i ECDHE_ECDSA_AES_256_CBC_SHA384 TLS 1.2 SHA-384 AES 256 No V7.1
LUW ECDHE_ECDSA_AES_128_GCM_SHA256 TLS 1.2 AEAD AES-128 GCM AES 128 128 bit V7.1
LUW ECDHE_ECDSA_AES_256_GCM_SHA384 TLS 1.2 AEAD AES-128 GCM AES 256 192 bit V7.1
Not IBM i ECDHE_RSA_AES_128_CBC_SHA256 TLS 1.2 SHA-256 AES 128 No V7.1
Not IBM i ECDHE_RSA_AES_256_CBC_SHA384 TLS 1.2 SHA-384 AES 256 No V7.1
LUW ECDHE_RSA_AES_128_GCM_SHA256 TLS 1.2 AEAD AES-128 GCM AES 128 No V7.1
LUW ECDHE_RSA_AES_256_GCM_SHA384 TLS 1.2 AEAD AES-128 GCM AES 256 No V7.1

I have requested that the table in Knowledge Center: Specifying CipherSpecs is updated to only show the supported CipherSpecs and that the details of the deprecated ones are moved out of the way to a separate page.

EDIT: Knowledge Center has now been updated to only show the supported ones and there is a separate page for the list of Deprecated CipherSpecs.

Re-enabling the deprecated CipherSpecs

Be aware that if you have re-enabled SSL V3.0 CipherSpecs at IBM MQ V8 FixPack 2, and you upgrade to FixPack 3, you will have further re-enabling to do. It is not sufficient simply to re-enable the SSL V3.0 protocol as you did with FixPack 2, you also have to specify the weak CipherSpec you wish to allow use of.

If the CipherSpec you wish to re-enable is an SSL V3.0 CipherSpec one step you will need to do is re-enable the protocol. As detailed in Know your protocol this is done by editing the qm.ini file:-

SSL:

AllowSSLV3=Y

or setting the AMQ_SSL_V3_ENABLE=1 environment variable.

Additionally, to re-enable the specific CipherSpec, you can edit the qm.ini file to provide the name of the CipherSpec you wish to allow to be used:-

SSL:

AllowWeakCipherSpec=TRIPLE_DES_SHA_US

or set the AMQ_SSL_WEAK_CIPHER_ENABLE=TRIPLE_DES_SHA_US environment variable.

This setting can be a list of CipherSpecs, or ‘All’ to turn them all back on.

Without these settings use of a weak CipherSpec at define-time will result in:-

AMQ8242: SSLCIPH definition wrong.

and at run-time will result in an error message thus:-

-------------------------------------------------------------------------------
20/07/2015 17:42:26 - Process(6040.1) User(MUSR_MQADMIN3) Program(runmqchl.exe)
                      Host(GEM45) Installation(800FP3)
                      VRMF(8.0.0.3) QMgr(QM1)
                     
AMQ9674: The channel 'QM1.TO.QM2.SSL01' specified a weak or broken CipherSpec.

EXPLANATION:
The SSL or TLS channel 'QM1.TO.QM2.SSL01' is configured to use a weak or broken
CipherSpec 'TRIPLE_DES_SHA_US'. 

This error occurs when the channel has requested to use a CipherSpec that
utilizes cryptographic algorithms or protocols that are now considered to be
broken or weak. 

The channel did not start.
ACTION:
Ensure that the channel is configured to use a CipherSpec that uses a stronger
set of cryptographic algorithms or a stronger protocol. 

Alternatively, configure the queue manager to re-enable the weaker CipherSpec
'TRIPLE_DES_SHA_US' using the AMQ_SSL_WEAK_CIPHER_ENABLE environment variable,
or via the 'AllowWeakCipherSpec' attribute under the SSL stanza in the qm.ini
file. 
-------------------------------------------------------------------------------

Hopefully you won’t ever need to re-enable these old, weak CipherSpecs, but there’s always the chance that you have a channel that talks to an old version queue manager, and you’ll need one of these weaker CipherSpecs for that purpose. At least with this new re-enablement method you’ll only be allowing the one you need to be used, instead of opening them all up.

IBM resources on the same subject:-


IBM Certified Specialist

Morag Hughson is a Certified IBM MQ Specialist
IBM Certified System Administrator – MQ V8.0
Find her on: LinkedIn: http://uk.linkedin.com/in/moraghughson   Twitter: https://twitter.com/MoragHughson   SlideShare: http://www.slideshare.net/moraghughson