IBM Pig Iron: MQ Distribution Issues

The return code is instructive:

2538  0x000009ea  MQRC_HOST_NOT_AVAILABLE

      

        
        
        
      

    

This indicates that Cast Iron is trying to communicate with MQ using a client connection, rather than discovering a listener on the host / port it is using.

There are a couple of possibilities here, but not enough information to tell what it might be. I'll explain and provide some diagnostic tools that you can try.

• 2538 indicates that the attempt to contact QMgr has failed. It could be that, for example, QMgr is not listening on the configured port (1414), or that the MQ listener is not running.
• The error code says the queue name is "null". The question does not indicate which queue name is configured by the connector, but presumably it was configured with some queue name. This error code assumes that the MQ Server-side Secure Connector has no configuration installed.
• The Cast Iron docs advise connecting to an id in a group mqm
  
  , but don't mention that in any version of MQ version 7.1 or higher this could fail unless there are special conditions for an administrator to connect. It may be an authorization error and the connector is not reporting the correct error.

If it's as simple as the listener isn't working, it's easy enough to fix. Just run it and make sure it is at 1414 as expected.

Then make sure the Secure Connector is configured using the Cast Iron admin panel. You need to understand why the error code says the queue name is null.

Now enable authorization events and channel events in QMgr and try reconnecting. The connector on the MQ server should connect at startup, and if successful, you can see this by looking at the MQ channel status. However, if that fails, you can find out by looking at the event messages or the MQ error logs. In both cases, authorization failures and connection attempts will be shown if the connection has gone that far.

The reason I am expecting a 2035 Authorization Error is because any QMgr from v7.1 and up will by default allow an administrative connection on any channel. This is configured in a standard set of rules CHLAUTH

. The goal is for the MQ administrator to explicitly grant administrator access by adding one or more new rules CHLAUTH

.

For security reasons, SYSTEM.DEF.*

and SYSTEM.AUTO.*

channels should never be used for legitimate connections. The best practice is to define a new one SVRCONN

, for example one with a name CAST.IRON.SVRCONN

, and then define a CHLAUTH rule to allow the administrative connection.

For example:

DEFINE CHL(CAST.IRON.SVRCONN) CHLTYPE(SVRCONN) TRPTYPE(TCP) REPLACE
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(ADDRESSMAP) +
    ADDRESS('127.0.0.1') +
    USERSRC(MAP) MCAUSER('mqm') +
    ACTION(REPLACE) 
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(BLOCKUSER) +
    USERLIST('*NOBODY') +
    WARN(NO) ACTION(REPLACE)

      

        
        
        
      

    

The first operator defines a new channel.

The next option allows you to use the connections from 127.0.0.1

where the Secure Connector lives. (Presumably you set up an internal secure connection on the same server as MQ, right?) Ideally, the connector would use TLS on the channel, and instead of IP filtering, the rule CHLAUTH

would be filtered based on the Distinguished Name certificate. This rule is less selective and allows anyone on the local host to be an MQ administrator using this channel.

The last statement overrides the CHLAUTH

default rule that blocks *MQADMIN

with a new rule that blocks *NOBODY

, but only for this channel.