IBM MQ on IBM Cloud – MCA Channels

One of the first things I wanted to do with my new IBM Cloud Queue Manager was to make channels to/from another queue manager on my own machine. Here are some tips that I learned from doing that. Screenshots below show the MQ Console making MQ objects, but of course you can also use all your favourite tools to manage your IBM Cloud queue manager.

Inbound Channel to an IBM Cloud Queue Manager

So I defined a sender channel and transmission queue on the queue manager on my own machine, thus:-

DEFINE CHANNEL(MORAG.TO.MQG1) CHLTYPE(SDR) TRPTYPE(TCP) +
       CONNAME('mqg1-xxxx.qm.beta.mqcloud.ibm.com(nnnnn)') +
       XMITQ(MQG1)
DEFINE QLOCAL(MQG1) USAGE(XMITQ)

And defined a receiver channel on my IBM Cloud queue manager, thus:-

IBM Cloud MQ Console Create Receiver

Create a Receiver channel using the MQ Console

Starting the sender channel on my own machine, targeting my IBM Cloud queue manager failed with:-

AMQ9558: The remote channel 'MORAG.TO.MQG1' .. is not currently available.

Turns out you also need to allow this receiver channel through CHLAUTH. IBM Cloud queue managers come with a back-stop rule already in place, unlike any queue manager you have created yourself using crtmqm. Once you know this, it is a simple matter to get the channel running.

I created a CHLAUTH rule on my IBM Cloud queue manager. I chose to make a Queue Manager Map and not to put an Address filter on it because of all the network translation that goes on between you and your IBM Cloud queue manager. Perhaps later I’ll look into the address the queue manager thinks I’m connecting in from to add an Address filter to my inbound check.

IBM Cloud MQ Console Create CHLAUTH

Create a CHLAUTH rule to allow my receiver in

And then my inbound channel was able to run successfully

IBM Cloud MQ Console Running Channel

And now my receiver is running

Outbound channel from an IBM Cloud Queue Manager

If you have an external IP address for your own machine then you should be able to just plug it into the CONNAME of a sender channel on your IBM Cloud queue manager and get going as you might expect.

If you’re trying this out from home, you may well be behind a router, and using the ipconfig command (or equivalent) will only tell you the IP address assigned to your machine internally, e.g. if it’s a 192.168.* address it’s an internal private address and external connections such as the channels coming out from your IBM Cloud queue manager cannot see it.

One way around this is to use a VPN – if you have one for dialing into work when you are working from home that may well be enough. If you run it and then try the ipconfig command (or equivalent) again, you’ll see that you now have an external IP address. It’s likely that your IBM Cloud queue manager can see that address.

Without a VPN

One of the reasons I decided to write this part of the blog post, is that I think IBM Cloud queue managers may mean that more people are trying to connect between them and a ‘home’ address. Trying out MQ in the cloud is free at the moment, and may well encourage lots of people to try it out.

If you don’t have a VPN, and you are behind a router with a 192.168.* address, you do still have an external IP address, and you can find out what it is by asking google (or using a variety of other websites that will also be listed by this search).

If using your external IP address and queue manager’s port number still don’t work, this is likely because you are behind a router that doesn’t know what to do with this inbound connection. It doesn’t know to send it to your computer rather than any other computer on the internal private network.

You’re better off to have a static IP address for your machine when doing the following to save you having to continually make changes to this configuration every time the DHCP server gives you a new IP address, but it is not absolutely essential. My internal IP address in the following examples is 192.168.1.113. You need to configure your router to tell it where to send connections that come in on the port in question, in the following examples, my queue manager is listening on port 2222.

All routers are different, but you’ll find some kind of section, probably in an advanced setup section, that mentions NAT Forwarding. In that section look for something like Virtual Servers, and then add in configuration that tells the router when it sees traffic on your external IP address and the port your queue manager is listening (2222 in my example), to send that on to the machine with internal IP address 192.168.1.113. You can change the port number at the same time, but I’ve kept it simple and used the same port internally and externally.

IBM Cloud Router config

Configuring my router to pass on connections targeted for my queue manager

Now when I start my sender channel from my IBM Cloud queue manager to the queue manager on my own machine, it connects successfully.

IBM Cloud MQ Console Two Running Channels

Now both my channels, inbound and outbound, are able to run

Since you’ve opened up a port to the outside world to get your channel running into your own machine from the IBM Cloud, you’ll now be able to see the IP address it comes in from. You may want to add an IP address filter with a CHLAUTH rule so that only your cloud queue manager can make that connection.

The next thing I’d like to see from the MQ on IBM Cloud team is how to use SSL/TLS on my channels.

Advertisements

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