|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
IGQ - Intra-Group Queuing |
« View previous topic :: View next topic » |
Author |
Message
|
geekgirl |
Posted: Tue Apr 27, 2004 6:41 am Post subject: IGQ - Intra-Group Queuing |
|
|
Newbie
Joined: 25 Apr 2004 Posts: 5
|
We are currently setting up shared queues. It is all setup and working fine. Now for my problem: We have two lpar's in a sysplex: SYSA and SYSB. Each LPAR has a queue manager running on it. MQA1 is running on SYSA. MQB1 is running on SYSB. Our applications programmers have coded the connect to the queue manager with the queue manager name and then they use a scheduling environment or sysaff to get the job to run on the correct LPAR in the sysplex. Is there a way to connect to MQB1 if the job runs on SYSA? I asked IBM this question and they told me to read the chapter on IGQ in the intercommunications manual. I read the chapter and must be missing something, would IGQ solve this? |
|
Back to top |
|
 |
EddieA |
Posted: Tue Apr 27, 2004 9:53 am Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
Quote: |
would IGQ solve this |
I don't think so. IGQ is a way of moving messages between QMs in a Sharing Group without defining Channels. (AFAIK).
Quote: |
Is there a way to connect to MQB1 if the job runs on SYSA |
Again, I don't think so. There is no Client available on z/OS, so the application can only make a Bindings connection. To use a Bindings connection, the application must be in the same 'server' (LPAR) as MQ.
Is there no way the Application can determine which LPAR it's running on. Then it could connect to the correct QM, and with Shared queues, retrieve the messages.
Cheers, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
geekgirl |
Posted: Tue Apr 27, 2004 10:00 am Post subject: |
|
|
Newbie
Joined: 25 Apr 2004 Posts: 5
|
Thank you! I just wanted to make sure I wasn't missing something obvious before I updated my ticket with IBM.
As far as the application determining the LPAR it is running on, we were trying to avoid having applications rewrite their code. But if they are going to have to make programming changes anyway determining what LPAR they are running on should not be to hard, great idea! Thank you so much!
Thanks,
Kris |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Apr 27, 2004 10:36 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
The solution here I think is to have one queue defined as a shared queue between your 2 QMs that would be part of a Queue Sharing Group. Lets call that queue "geekgirlQ".
Now if an application connected to MQA1 on SYSA or MQB1 on SYSB, it could open up geekgirlQ, and get the messages from it.
If you define MQA1 the default QM for SYSA, and define MQB1 the default QM for SYSB, the application, wherever it runs, just issues a MQCONN call specifying a blank QM. It will connect to the correct QM for the environment it is running. There is no need for the app to try and figure out what LPAR it is running under.
The same concept applies for your TEST and QA environments. As long as you maintain the same queue name in all environments, and the respective QMs are defined as defaults for their LPARs, your code can be migrated from TEST to QA to PROD with no code changes. And it can run on either of the LPARs within in an environment, with no code changes. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
geekgirl |
Posted: Tue Apr 27, 2004 10:42 am Post subject: |
|
|
Newbie
Joined: 25 Apr 2004 Posts: 5
|
Peter,
I am able to access the shared queue from both queue managers with no problem. I love how that works!
The defaults sound like a good idea, but can't you only have 1 default queue manager per LPAR? We run test, model and prod all on one LPAR. We have two LPAR's that run test, model, and prod in a sysplex. So for right now the app's people are using either scheduling environments or sysaff to get the job to run on the correct LPAR.
Thanks,
Kris |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Apr 27, 2004 10:47 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Yeah, only 1 default per server/lpar. Looks like in your shop you can't take advantage of this because you have more than 1 QM per LPAR. Oh well. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
offshore |
Posted: Tue Apr 27, 2004 11:34 am Post subject: |
|
|
 Master
Joined: 20 Jun 2002 Posts: 222
|
Thats is a complex question you have proposed.
Here comes my $0.00002:
It's sounds as though what you're describing is a batch job that gets submitted from a scheduler (Control-M, CA-7,ect...) or a job that is submitted manually (by a person???) that has SYSAFF=System_Name in the job.
I really don't believe you can sub/run a job on SYSA and connect to a qmgr on SYSB. MQ doesn't have a generic resource parm like CICS,
DB2, VTAM...ect.
I'm not sure what the goal is here you're trying to accomplish by running a job on SYSA and connecting to queue manager on SYSB, or vice-versa????
I guess what you could do is:
1.] Create a MQ Gateway Queue Manager (ie: MQGW)
2.] Make sure its part of the QSG so that it know where all the queues are at.
3.] Make the application programs connect only to that queue manager.
4.] Make the applications programs have a specific job class. (ie: CLASS=M, make sure an initiator is started for class M)
What this will accomplish is:
Everything will run on SYSA connecting to MQGW which will pass the message on to MQA1.
Now if for some reason you want MQ work to goto SYSB queue manager MQB1. Have automation move class M & qmgr MQGW to SYSB. Now your apps can still be submitted on SYSA, but will get "moved" to SYSB due to the job class. Connecting to MQGW but executing on MQB1 Similar to what the SYSAFF= does.
You might want to check out the IBM Redbook "WebSphere MQ in a z/OS Parallel Sysplex Environment" |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|