Author |
Message
|
giuly020277 |
Posted: Mon Nov 12, 2007 7:16 am Post subject: Some questions |
|
|
 Centurion
Joined: 07 Aug 2007 Posts: 146 Location: Florence,Italy
|
Hello...
excuse me...but here thare are some works in progress I'm not so expert with MQ...so...i need your help please:
1- Can i attach one CICS on different Queue Manager On the same LPAR ?I want to attach one cics to 4 different qm
2- Can i pass a variable from trigger to transaction ?
I mean...i have two environment (test and svil). Programmers have to set QM name and Queue name on thei programs. Can i pass a variable from trigger to transaction ...so programmers have not to modify thei programs when i work on test or svil?
3- Programmers always have to set Queue manager name on their programs?
4- When i configure a channel.....on the "connection name" ..... i have to specify an IP address...or maybe i can use a mnemonic name?
thank u all... |
|
Back to top |
|
 |
Vitor |
Posted: Mon Nov 12, 2007 7:21 am Post subject: Re: Some questions |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
giuly020277 wrote: |
1- Can i attach one CICS on different Queue Manager On the same LPAR ?I want to attach one cics to 4 different qm
|
No. The association is 1-to-1. Why would you want to?
giuly020277 wrote: |
2- Can i pass a variable from trigger to transaction ?
I mean...i have two environment (test and svil). Programmers have to set QM name and Queue name on thei programs. Can i pass a variable from trigger to transaction ...so programmers have not to modify thei programs when i work on test or svil? |
Yes, in a variety of ways. You shouldn't need to because the environmental differences should be handled at an MQ level not an application one. Certainly a triggered application shouldn't need additional information passed to it, and could potentially work out where it's running from the trigger info.
giuly020277 wrote: |
3- Programmers always have to set Queue manager name on their programs?
|
Programmers always have to connect to a queue manager. This may or may not involve setting a name (CICS is an example of when you don't).
giuly020277 wrote: |
4- When i configure a channel.....on the "connection name" ..... i have to specify an IP address...or maybe i can use a mnemonic name?
|
You should always specify a hostname and let the network sort it out unless there's a compelling reason to use the IP address (which there might be). _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Nov 12, 2007 8:00 am Post subject: |
|
|
Guest
|
Quote: |
3 - Programmers always have to set Queue manager name on their programs? |
If you are asking if a CICS application that has MQ calls in it needs to have an MQCONN call naming a qmgr, then the answer is no. The MQ-CICS adapter does the connect. Any MQCONN call is ignored in this case. |
|
Back to top |
|
 |
zpat |
Posted: Mon Nov 12, 2007 12:39 pm Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Applications should connect to only one queue manager. To send messages to another (even on the same platform) use remote queues and define channels between the queue managers.
I can't believe that you need four QMs on one LPAR and would point out that a mainframe app can never connect as a MQ client to a remote QM. |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Nov 12, 2007 12:54 pm Post subject: |
|
|
Guest
|
zpat said:
Quote: |
Applications should connect to only one queue manager. |
I'd have said that applications should connect to one queue manager at a time.
As with any rule, there are exceptions. It is possible to have multiple ocncurrent connections with multiple TCBs - assembly language stuff.
Last edited by bruce2359 on Tue Nov 13, 2007 6:47 am; edited 1 time in total |
|
Back to top |
|
 |
zpat |
Posted: Mon Nov 12, 2007 11:26 pm Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
MQ apps should have minimal awareness of the MQ topology. They should let their nearest QM deal with message routing. That way they will be as portable as possible and unaffected by changes in topology. |
|
Back to top |
|
 |
|