Steve, >>>I don't have all the details but I think I soon may >>>be involved in a project where, I hear that the >>>messages would be sent to WMQI from AIX (in a >>>send-and-forget fashion)without the involment of >>>MQSeries. In other words, a program (not an MQ >>>program) or a 3rd-party file sending software will >>>send the messages after setting all the required MQMD >>>header and concatinating that with the App. data. >>>This approach makes me a bit nervous. Has anyone every >>>done this? What are the things to watch for?
Hmmm. By this, do they mean on the AIX box they would be using an MQ client? That would not require any MQSeries server code on the AIX box in question. If not, simply creating a data object prepended with the equivelent of an MQMD will not cause it to magically appear on an MQ queue. You can't (legally) put something on an MQ queue without using the services of a queue manager, which requires following a strict set of formats and protocols (which is what an MQ Client does). However, I believe the FAP for MQ is proprietary and would have to be licensed (I'm sure reverse-engineering the FAP is prohibited by the license agreement). And the effort would be non-trivial (especially given that an MQ Client could be used on AIX for no additional charge). If they are not planning to use an MQ Client, I wonder if what they are looking at doing is writing (or expecting someone to write) a custom input node to accept data for input from somewhere other than an MQSeries queue. This is certainly possible with WMQI V2.1. You could write an input node to accept input from a file, or HTTP, etc. However, this would not be sent through MQSeries and would not be retrieved using an MQInput node. By prepending a file with a pseudo-MQMD and using a file-oriented custom WMQI input node, in theory the remainder of the message flow could be built to operate exactly as it would if an MQInput node had been used. However, if this is the intent, the biggest thing to watch out for would be, How would transactionalization be maintained (you mentioned this would be sent "in a fire-and-forget fashion")? By not using an MQInput node, the substitute node would be responsible for persisting the data somewhere and retrying in the event the message flow could not successfully process it. It's hard to be more specific until you have the additional details you currently lack. Regards, Christopher Frank Sr. I/T Specialist - IBM Software Group IBM Certified Solutions Expert - Websphere MQ & MQ Integrator -------------------------------------------- Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
