WMQ FTE in a Distributed Environment

Question

QMGR A has an MFT agent called AgentA. QMGR B has an MFT agent called AgentB. QMGR C has an MFT agent called AgentC. These are all MFT Server deployments, not "client".

QMGR A and B are members of an MQ cluster, called FTECluster

QMGR C connects to QMGR B via a simple sender/receiver pair (outside the cluster).

MFT users on the server where QMGR A runs want to send a file FROM that server to the server where QMGR C runs.

QMGR B is the designated Coordination Qmgr, so if, when connected there via the explorer, I create a transfer, using

QMGRA as the source and QMGRC as the destination, will I always expect that the agent will encounter a 2087 error (which is what I'm getting), that the target remote queue is not known? Or is there some "extra" setup than needs to be performed to acquaint QMGRA with QMGRC by way of QMGRB?

The application is this: I have enclave based queue managers (QMGRA) that are behind a DMZ (the gateway, QMGR B), and would like to move files for external partners to those inside/outside the enclave via MFT, not unlike we use queues to move messages from overlapping clusters or from queue managers in /out of the cluster to those out/in of an adjoining cluster. OR, to permit file transfers BETWEEN MFT users INSIDE the enclave, so that the traffic is not paraded out onto the DMZ for internal transfers.

If this is not possible, then we'll have to have MFT transfers that are created between clients on internal enclave servers, thru DMZ based MFT servers, and out/in to the external customer base, AND have internal agent/servers on designated enclave queue managers, for the purpose of exchanging files internally.

T.Rob · Accepted Answer · 2012-09-27T19:10:31.120

FTE agents can use standard QMgr routing and aliasing. The textbook way to do this is to name the transmission queues after the destination QMgr and add aliases. For example, on QMGRA you'd define:

* On QMGRA
DEFINE QL(QMGRB) USAGE(XMITQ)
DEFINE QR(QMGRC) XMITQ(QMGRB) RQMNAME('') RNAME('')

Now any messages addressed to QMGRC go through normal name resolution. The QMgr finds the route to QMGRC through QMGRB because of the QRemote. A QRemote definition with a blank RNAME is called a QMgr alias for this reason.

Then on QMGRB you'd have a transmit queue leading to QMGRC and coincidentally named QMGRC. The reverse would apply for getting messages back. You'd need a QMgr alias on C pointing to B.

If your XMit queues do not use the name of the remote QMgr then you'd need additional QMgr aliases. For example, many people append the string XMITQ to an XMit queue name (which in my opinion causes more problems than it solves) and on a system like that you'd need the following:

* On QMGRA
DEFINE QL(QMGRB.XMITQ) USAGE(XMITQ)
DEFINE QR(QMGRC) XMITQ(QMGRB.XMITQ) RQMNAME('') RNAME('')


* On QMGRB
DEFINE QL(QMGRC.XMITQ) USAGE(XMITQ)
DEFINE QR(QMGRC) XMITQ(QMGRC.XMITQ) RQMNAME('') RNAME('')

The first part of this works the same way as before. WMQ looks for QMGRC, finds the QRemote and puts the message onto the named XMitQ. But when the message arrives on QMGRB it cannot resolve directly to the transmission queue because the name doesn't match the remote QMgr. So we define a new QRemote that resolves the name QMGRC to the XMitQ leading to QMGRC.

You can also use cluster resolution between QMGRA and QMGRB. In that case you probably could get away with setting RQMNAME and leaving the XMitQ blank on the QMgr alias on A. Or set both. Another option would be to create a QMgr alias named QMGRC on B and advertise it to the cluster.

Using a dedicated channel keeps the file transfer traffic off of the cluster XMitQ and out of the cluster channel, and so provides a class of service isolation from regular traffic. File transfer traffic is all non-persistent though and no more than a frame-per-file will sit on the XMitQ at a time so you may not need that level of isolation. (With WMQ V7.5 could do the same thing with overlapping cluster and split cluster XMitQ!)

You don't need FTE agents to test this, just use the Q program from SupportPac MA01 and specify both the local QMgr and the remote QMgr name when connecting.

UPDATE from email thread:
OK, so here are the definitions I used to mock this up using the cluster scenario. I defined 3 QMgrs, created a cluster with QMGRA as the repository, QMGRB as a member and a gateway between QMGRB and C using SDR/RCVR channels. Any messages arriving on B from A addressed to C resolve to the XMitQ. A knows about C because of the QMgr alias named QMGRC pointing to QMGRC.XMITQ. (I tried advertising an XMitQ called QMGRC to the cluster but it seems the cluster recognizes it as a local queue and does not perform QMgr name resolution on it. Defining it as QMGRC.XMITQ and creating the QMGRC QMgr alias over it allows QMGRC to resolve locally and from the cluster.)

After running these, I was able to connect using the Q program, without the benefit of QREMOTE definitions that specify an RNAME, and send messages from C to A and from A to C into the queues named TEST.NAME.RESOLUTION like so:

C:\Users\T.Rob>q -m QMGRA -oQMGRC/TEST.NAME.RESOLUTION
MQSeries Q Program by Paul Clarke [ V6.0.0 Build:May  1 2012 ]
Connecting ...connected to 'QMGRA'.
>Testing A to C
>^C
C:\Users\T.Rob>q -m QMGRC -oQMGRA/TEST.NAME.RESOLUTION
MQSeries Q Program by Paul Clarke [ V6.0.0 Build:May  1 2012 ]
Connecting ...connected to 'QMGRC'.
>Testing C to A
>^C

Yes, the cluster name is 'EDELMANN' and in this usage it is pronounced just like Jerry Seinfeld used to pronounce "Newman". ;-)

* On QMGRA:
ALTER QMGR +
   REPOS(EDELMANN)

DEFINE QLOCAL('TEST.NAME.RESOLUTION') +
   DEFPSIST(YES) +
   REPLACE

DEFINE CHANNEL('EDELMANN.QMGRA') +
   CHLTYPE(CLUSRCVR) +
   CLUSTER('EDELMANN') +
   CONNAME('localhost(3414)') +
   TRPTYPE(TCP) +
   REPLACE


* On QMGRB:
DEFINE QREMOTE('QMGRC') +
   CLUSTER('EDELMANN') +
   RQMNAME('QMGRC') +
   XMITQ('QMGRC.XMITQ') +
   REPLACE

DEFINE QLOCAL('QMGRC.XMITQ') +
   INITQ('SYSTEM.CHANNEL.INITQ') +
   TRIGGER +
   TRIGDATA('QMGRB.QMGRC') +
   USAGE(XMITQ) +
   REPLACE

DEFINE CHANNEL('EDELMANN.QMGRA') +
   CHLTYPE(CLUSSDR) +
   CLUSTER('EDELMANN') +
   CONNAME('localhost(3414)') +
   TRPTYPE(TCP) +
   REPLACE

DEFINE CHANNEL('EDELMANN.QMGRB') +
   CHLTYPE(CLUSRCVR) +
   CLUSTER('EDELMANN') +
   CONNAME('localhost(3415)') +
   TRPTYPE(TCP) +
   REPLACE

DEFINE CHANNEL('QMGRB.QMGRC') +
   CHLTYPE(SDR) +
   CONNAME('localhost(3416)') +
   TRPTYPE(TCP) +
   XMITQ('QMGRC.XMITQ') +
   REPLACE

DEFINE CHANNEL('QMGRC.QMGRB') +
   CHLTYPE(RCVR) +
   TRPTYPE(TCP) +
   REPLACE

* On QMGRC:
DEFINE QREMOTE('QMGRA') +
   RQMNAME('QMGRA') +
   XMITQ('QMGRB') +
   REPLACE

DEFINE QLOCAL('QMGRB') +
   INITQ('SYSTEM.CHANNEL.INITQ') +
   TRIGGER +
   TRIGDATA('QMGRC.QMGRB') +
   USAGE(XMITQ) +
   REPLACE

DEFINE QLOCAL('TEST.NAME.RESOLUTION') +
   REPLACE

   DEFINE CHANNEL('QMGRB.QMGRC') +
   CHLTYPE(RCVR) +
   TRPTYPE(TCP) +
   REPLACE

DEFINE CHANNEL('QMGRC.QMGRB') +
   CHLTYPE(SDR) +
   CONNAME('localhost(3415)') +
   TRPTYPE(TCP) +
   XMITQ('QMGRB') +
   REPLACE

If A and B are in an MQ cluster, however, i'm guessing the xmitq QMGR2 doesn't need to be defined on QMGRA correct? I don't want to use an xmitq and a trigger sender channel from A to B... — John Edelmann, Sep 27 '12 at 12:30
Yeah, you can use cluster resolution. In that case you probably could get away with setting RQMNAME and leaving the XMitQ blank. Or set both. Using a dedicated channel keeps the file XFer traffic off the cluster XMitQ and out of the cluster channel and so provides a class of service isolation from regular traffic. File XFer traffic is all non-persistent though and no more than a frame-per-file will sit on the XMitQ at a time so you may not need that level of isolation. (With WMQ V7.5 could do the same thing with overlapping cluster and split cluster XMitQ!) — T.Rob, Sep 27 '12 at 12:53
Actually this is an FTE specific queue manager setup to keep it totally isolated from our regular MQ traffic, even though Len McWilliams assured me that FTE is designed to run a a non-invasive lower priority. ALSO: won't qmgrc need a similar remote definition BACK to QMGRA? — John Edelmann, Sep 27 '12 at 13:22
In fairness, I did say "The reverse would apply for getting messages back" but I've updated the answer to clarify. Also moved the cluster info into the answer for the benefit of those who don't read comments. — T.Rob, Sep 27 '12 at 13:30
Indeed you did. I skipped over that in my zealous excitement to get this to work. However, I have to petition to have that definition applied on the queumgr at the remote side. thanks! — John Edelmann, Sep 27 '12 at 13:36
This all works now!! the lapse was the shared qremote definition for the remote queue manager QMGRC. I had to create a differently named xmitq (QMGRC.XMITQ) as suggested here, in order to create a remote queue definition named QMGRC(!) — John Edelmann, Sep 28 '12 at 13:39

WMQ FTE in a Distributed Environment

1 Answers1