| Author |
Message
|
| skytorch |
 Posted: Tue Aug 13, 2002 7:29 am Post subject: A local queue attribute question |
 |
|
Apprentice
Joined: 10 Jun 2002
Posts: 47
Location: New York City
|
Hi,
What's difference between share/noshare attribute and defsopt attirbute of a local queue definition?
I read the manual and tried it out. it seems that both attributes are for get operation. If I set defsopt to exclusive, I can still put msgs from two mq client to this queue at the same time. share option doesn't seems matter either. How can achieve exclusive put ?
Thanks.
Sky |
|
| Back to top |
|
 |
| oz1ccg |
| Posted: Tue Aug 13, 2002 7:30 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
|
| Back to top |
|
|
| skytorch |
| Posted: Tue Aug 13, 2002 7:59 am Post subject: |
|
|
Apprentice
Joined: 10 Jun 2002
Posts: 47
Location: New York City
|
Thanks Jorgen.
In that case, what's difference between share/noshare attribute and defsopt attirbute ? I guess both are for exclusive get operation ? |
|
| Back to top |
|
|
| mrlinux |
| Posted: Tue Aug 13, 2002 8:52 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Why would you want an exclusive put ???
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| skytorch |
| Posted: Tue Aug 13, 2002 9:38 am Post subject: |
|
|
Apprentice
Joined: 10 Jun 2002
Posts: 47
Location: New York City
|
thanks mrlinux.
how about this scenario: a queue can get messages from a remote via sender-receiver channel, it can also get messages from a mq client via svrconn channel. Assume one application has to put all its messages continuously in the queue before another does so.
It may not be a good example. 
Sky |
|
| Back to top |
|
|
| mrlinux |
| Posted: Tue Aug 13, 2002 10:28 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well again the question is why, but to continue this example
If message sequence is that important MQSeries provides a segmentation feature where each message will get assigned a sequence number.
The putting application will MQPUT the messages and after each MQPUT
MQSeries will bump up the SEQUENCE Number.
The getting application when it issues MQGET it can get messages in order
they were put.
Will this solve your issue ?????
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Tue Aug 13, 2002 3:08 pm Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
I agree with mrlinux, use segmentation, and let MQSeries help you there.
When dealing with a workload balanced cluster, we will really have a challange ensuring to get messages in correct order processed by different tasks on different machines and updateing the same database 
It would be a great idea to keep a unit of work(UOW) together in one msg. if it's possible...
Just my $0.02
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| Fannyfcwong |
| Posted: Tue Aug 13, 2002 8:19 pm Post subject: |
|
|
Novice
Joined: 04 Jul 2002
Posts: 13
|
| However, return to the original question. I also have a question that what's difference between share/noshare attribute? How are they used? When are they used? |
|
| Back to top |
|
|
| mgrabinski |
| Posted: Tue Aug 13, 2002 9:18 pm Post subject: share/noshare |
|
|
Master
Joined: 16 Oct 2001
Posts: 246
Location: Katowice, Poland
|
SHARE means that an application opening the queue with MQOO_INPUT_AS_Q_DEF will open it in SHARED mode (other apps. can read the queue concurently); NOSHARE will efect in opening the for exclusive read (so only the first app opening the queue for get will able to do so)
If programmers use explicitely MQOO_INPUT_SHARED or MQOO_INPUT_EXCLUSIVE, the SHARE/NOSHARE attribute of the queue has no meaning.
_________________
Marcin Grabinski <>< |
|
| Back to top |
|
|
| nimconsult |
| Posted: Tue Aug 13, 2002 9:29 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
The share/noshare attribute: you specify if the queue can be opened (in input) by more than one application.
If noshare is specified, the queue can be opened only once, regardless of the open option.
If share is specified, the queue can be opened by more than one application, if all the applications open the queue in shared mode.
The defsopt is the default sharing option for an application that opens the queue. A queue can be opened in input with MQOO_INPUT_SHARED or MQOO_INPUT_EXCLUSIVE or MQOO_INPUT_AS_Q_DEF. For the last option the defsopt attribue of the queue will be used.
if INPUT_SHARED is specified and the queue is shareable, other applications can open the queue. Otherwise they cannot.
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| mgrabinski |
| Posted: Tue Aug 13, 2002 10:19 pm Post subject: |
|
|
Master
Joined: 16 Oct 2001
Posts: 246
Location: Katowice, Poland
|
Thanks for correcting my post
To clarify it:
It is DEFSOPT that governs what happens if MQOO_INPUT_AS_Q_DEF has been used, I've mistaken it with SHARE/NOSHARE
If SHARE is used, applications can still use MQOO_INPUT_EXCLUSIVE to disallow other apps from reading the queue
If NOSHARE is used, programers have nothing to say - who opens the queue first, has the exclusive right to read from it.
I'm sorry for the disinformation in my previous post - I was to quick 
_________________
Marcin Grabinski <>< |
|
| Back to top |
|
|
|
|
