Can anyone point me to any docs re. the above ? I have trawled a LOT of online material - Info Centre, Developerworks, Presentations, Redbooks - and while there is a lot of detail re. the syntax of the fte Commands (for example) and worked examples of Chicago talking to NY, etc. I am looking for material that would - for example - give a set of pros and cons (say) for starting with Coord/Cmd/Agent as one Qmgr v Coord/Cmd as one QM and Agent as another v Coord as one QM v Cmd/Agent as another.

Advice along the lines of  'If the Coord Qm goes down, transfers can still occur but no status can be received'; 'If you lose the Cmd server, existing transfers will complet but you can't start any new ones' etc. would be extremely helpful so I can see the wood for the trees.

And that extends to security. If I want to set up an env. that will be centrally administered s(defining Resouce Monitors, Transfer templates) do I have to set up the full gamut of FTE security from the start or can I start with MFT agent MQ access auth + connection security (CHLAUTH) and then grow ?

I have worked some of the above out through trial and error along with help from colleagues and IBM MFT Devt Support in India, but I wonder if I have missed some existing (and accessible) 'how to' doc.

Hello Dermot. 

Without question there is often a great deal of documentation and opinions on IBM products, and MFT (FTE) is not an exception. IBM technology offers great flexibility - but with that, sometimes confusion arises.

While I have not reviewed all of the specific architecture documents and best practices as published via IBM, I will share that MFT implementation decisions depend mostly on your level of experience and knowledge of Websphere MQ and File Transfer in general. Talking with people who have implemented MFT in large and small implementations will help.

For example, we at TxMQ sit down with customers and help them to develop architecture documents (with best practices in mind based on our professional experience and our relationship with IBM), and work through the complexities of their environment to get a robust and stable file transfer platform, designed to meet their business objectives. 

Feel free to email or call if you'd like to chat, we are happy to jump on a call. Or, perhaps you are available to meet with us at the MQ Technical Conference in Sandusky Ohio from September Sept 26-28th.

As a sponsor of the event, our customers and referrals can take advantage of a discount on the passes by using this link:

https://usd.swreg.org/cgi-bin/s.cgi?s=107920&p=107920-92016&q=1&v=0&d=0,&rc=45K2D47F9K 

Happy Messaging!

Miles Roty
VP of Services & Support

Office: (716) - 636 - 0070 x228
Mobile: (415) - 535 - 3960
Linkedin • Twitter • Facebook

TxMQ, Inc.
Imagine, Transform, Engage
TxMQ.com • TxMQStaffing.com

TxMQ is a Premier IBM Business Partner.

>I am looking for material that would - for example - give a set of pros and cons (say)
>for starting with Coord/Cmd/Agent as one Qmgr v Coord/Cmd as one QM and Agent
> as another v Coord as one QM v Cmd/Agent as another.

One qmgr for coord is a practical choice. We have ~2500 agents and use a dedicated qmgr for this purpose.

The agents are split into logical groups, and have their cmd and agent queues (command, state, data, reply, event) together on qmgr assigned for each group.

We have the queues for hundreds for agents on the same qmgr and it works fine. CPU and n/w bandwidth may come into play, depending on your volume.

Also, split production from all non-production environments so that it is not possible to transfer files in non-prod to/from prod agents.
HTH, 

Glenn Baddeley

Coles Supermarkets Australia Pty Ltd