MQ Series -- MIDRANGE-L

Title: MQ Series

A question for any MQ Series buffs out there in cyberland......
I have an MQ application I've built which is working fine for a multi-AS400 Q configuration. In essence, we have layered our application so that the presentation layer is on one AS400 and the processing logic is on another. The two layers communicate through MQ Series.

A functional transaction is initiated by a command on the presentation layer which generates a message to an triggered request Q. The trigger program then manages a 'dialogue' across the network using a Q in either direction.

In essence we have an OUTQ which is used to pass screen buffer information to the presentation layer and an INQ (these are the actual names of the queues in use) which is used to pass screen input to the process layer. I have achieved this by defining OUTQ as a local Q on the display machine, and as a remote Q on the process machine, because that is the directional flow of information. The INQ is, conversely, a remote Q on the presentation machine and a local Q on the process machine, because screen input needs to be passed to the process layer of code.

The OUTQ is not defined with a remote MQ manager name as I need to b able to set this dynamically depending on which machine the original request message came from. ( ultimately, requests may come form many disparate machines and platforms)This also works ok, when the request message is coming from a remote AS400.

This works fine across two or more machine(One process machine and a number of presentation machines - we will soon replace the AS400 as a presentation layer with an NT to interface to the web (sorry!), thus preserving our 15 years of debugged processing code). The use of dynamic allocation of remote MQ manager name solves the dialogue separation issues.

For various reasons, we also want to be able to run the interface on the same machine as the process. In other words I want to be able to pass the screen data from the process code into OUTQ, on the process machine, but without the message being dispatched to a remote MQ manager. This seems ambiguous because the OUTQ is defined as a remote Q and the message goes to the OUTQ located on the MQ Manager defined by the original request message. But of course, there is no remote MQ manager name in this circumstance!, And in fact even when I use debug and put in the local Q manager name in the MQ Open API it fails with the 2087 code.

I've actually tried this on the same machine and I've managed to get the request message generated so that the trigger is activated, however the open of the OUTQ always ends up failing with a reason code 2087 - Unknown Remote MQ manager, because the dynamic identification of the MQ manager issuing the original request is blank when I try this from the process machine.

I've tried defining a new OUTQ as local to the process layer but MQM won't allow me to create a duplicate of OUTQ even thought the new definition has an attribute of *LCL.

I've read the application programming interface manual several times and I can't see a clear solution. I think it may have something to do with the way the parameters are used, but again it's not obvious

The easy question to ask is ...............can I write to OUTQ and expect that the local MQM manager name (from the process machine) be placed in the MDRM parameter of the MQMD data structure?

Sorry for the complexity!