| Author |
Message
|
| KramJ |
 Posted: Thu Feb 02, 2006 7:54 am Post subject: XMIT queue definitions and starting channels |
 |
|
Voyager
Joined: 09 Jan 2006
Posts: 80
Location: Atlanta
|
I've inherited a bunch of queue managers that were set up by ex-employees and have noticed the following about the xmit queues:
Example xmit queue: QMGR2.XMIT
PROCESS parameter is set to QMGR2.MCA.TRIGGER
INITQ parameter is set to SYSTEM.CHANNEL.INITQ
Looking at the QMGR2.MCA.TRIGGER process, it has the USERDATA parameter set to QMGR1.TO.QMGR2
Is this the pre-v5.3 way of starting channels? and what is the preferred way of starting them in MQSeries v5.3? I've always set up the xmit queues without setting the INITQ, PROCESS, or TRIGDATA parameters. |
|
| Back to top |
|
 |
| wschutz |
| Posted: Thu Feb 02, 2006 8:01 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
With "modern" (ie v5 + on distributed and v5.3 + on zOS), you no longer need the PROCESS definition for xmitq's.
Most people still specify the channel they want started in the TRIGDATA of the XMITQ. But this is optional.
You MUST specify an INITQ name on the xmitq, as well as TRIGGER and TRIGTYPE=FIRST (or depth if you like).
_________________
-wayne |
|
| Back to top |
|
|
| KramJ |
| Posted: Thu Feb 02, 2006 8:09 am Post subject: |
|
|
Voyager
Joined: 09 Jan 2006
Posts: 80
Location: Atlanta
|
| It seems like there would be more system overhead doing it the old way because of the additional objects. Would there be a performance benefit if I redefined all of the xmit queues so that the channels are triggered the "modern" way and removed the old triggered processes? |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Feb 02, 2006 8:13 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
I think you would have a hard time measuring any performance difference between the two methods ...
Its really up to you.... usually simplier is better....but there's always a risk when you change something .... 
_________________
-wayne |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Feb 02, 2006 8:17 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| mquseless wrote: |
| One of the risks in this case is that v6 GA channels do not trigger start unless the TRIGDATA attribute is specified. |
Which is fixed in RP1. 
_________________
-wayne |
|
| Back to top |
|
|
| KramJ |
| Posted: Thu Feb 02, 2006 8:34 am Post subject: |
|
|
Voyager
Joined: 09 Jan 2006
Posts: 80
Location: Atlanta
|
| GA channels? What's GA stand for? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Feb 02, 2006 8:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| KramJ wrote: |
| GA channels? What's GA stand for? |
"Generally Available".
In this case, it means "WMQ v6.0.0, as shipped to customers".
And it's fixed in WMQ V6 Refresh Pack 1, so if you are running WMQ v6.0.1, then you don't have to worry.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Feb 02, 2006 8:36 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
mquseless means the "general availability" (aka initial) release of MQ V6 ... it has nothing to do with the channels per se....
_________________
-wayne |
|
| Back to top |
|
|
|
|
