RE: MQ Series -- MIDRANGE-L

Title: MQ Series

I've taken this off-line as you were the only person who replied.

Thanks for taking the time to think about my question and to reply. Yes it was stated in a complex manner. Your diagram was more concise., and you understood what I was trying to do. It sounds like I really can't do what I want to do! Ihave parameterized almost everything so that the process machine doesn't need to keep track of where the original message came from. I did this according to the manual by letting MQ be aware of which MQ Manager sent the original message, and then using that parameter in the reply and setting the OUTQ in the process machine to have a blank MQ manager name so that it could be resolved dynamically at execution time.

This solution was easy because it meant the configuration for each display machine was the same. In other words the display machines all have an OUTQ declared as remote (located on the display machine).

If I use a different OUTQ on the process machine it would then mean that the process code would have to be aware of where the original request message came from. I was trying to avoid this situation as its not particularly elegant.

I haven't attended any IBM courses as yet and have been doing this via Red Books and the reference manuals so far. I'm about to attend an MQ Administration course shortly so hoprfully there might be some ideas coming from that.

Regards and thank you,

Mike Pantzopoulos

-----Original Message-----
From: Alistair Rooney [mailto:alistairr@tbsa.co.za]
Sent: Friday, 28 July 2000 20:03
To: MIDRANGE-L@midrange.com
Subject: RE: MQ Series

Ok I hope I understand all this correctly. To make sure I'm going to explain it back to you in simpler terms.

Process Machine----------------------------------------------------------------------------------Display Machine

OUTQ (remote)--------------------------------------------------------------------------------->>>OUTQ(local)

INQ(local)<<<-------------------------------------------------------------------------------------------INQ(Remote)

Now what you want to do is put data on to the OUTQ from the Process machine but still direct it to the process machine. The answer is no. You can't do that. Parameterise your queue in your put program and when the data needs to be "sent" to the same machine then put it to a local queue (OUTQ.LOCAL) which can be triggered in exactly the same way as OUTQ on the display machine. The same process can be triggered from different queues and the actual queue name will be passed as a parameter (but you know that).

I hope this answers your question.

Alistair Rooney
Project Leader (Interfaces)
Tibbett & Britten South Africa
+27 (0) 31 2047701
+27 (0) 82 9023797

-----Original Message-----
From: owner-midrange-l@midrange.com [mailto:owner-midrange-l@midrange.com]On Behalf Of Pantzopoulos, Mike
Sent: 28 July 2000 08:17
To: 'MIDRANGE-L@midrange.com'
Subject: 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!