RE: MQ Series

Does anyone know of a good forum for questions and answers for MQ/MQSI
please

thanks

Steve Blair
AS/400 Systems Administrator
Vodafone Central Services Ltd
> -----Original Message-----
> From: Pantzopoulos, Mike [SMTP:mikepantzopoulos@mynd.com]
> Sent: Monday, July 31, 2000 12:35 AM
> To:   'MIDRANGE-L@midrange.com'
> Subject:      RE: 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! 
> 
> 
>                   
> 

Vodafone Central Services Ltd
Registered Office: The Courtyard,2-4 London Road, Newbury, 
Berkshire,
England, RG14 1JX

Registered in England No. 3750974

**********************************************************************
This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they   
are addressed. If you have received this email in error please notify 
the system manager.

This confirms that this email message has been swept by MIMEsweeper 
for the presence of computer viruses.
**********************************************************************
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---