| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Changes I would like to see in WMQ Version 6.0..... |
« View previous topic :: View next topic » |
| Author |
Message
|
| jefflowrey |
 Posted: Thu Dec 09, 2004 6:05 am Post subject: |
 |
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
As for the Eclipse tooling... I'm sure that's basically a given at this point.
But I'd like to see it be installable in any similar level of eclipse as plug-ins, so that I don't need YET ANOTHER eclipse directory on my machine.
And let's have none of this "can't put messages to remote queues" foolishness. If it can put messages, then it should be able to put messages anywhere that messages can legally be put.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Thu Dec 09, 2004 6:18 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
| 4. Configuration Events for ALL platforms. Why can't MQ track changes to itself? |
That gets my vote!
As does official support for MO71.
Actually there are a lot of good suggestions within this thread. Maybe someone should formalise this and present it to an IBM user group for backing? |
|
| Back to top |
|
|
| JLRowe |
| Posted: Thu Dec 09, 2004 6:29 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
I'm pretty happy with the guts of MQ, my main emphasis would be on administration, management - particularly management of messages.
What we really need is a decent message editor/viewer built in as standard. I'm sure a lot of us have 3rd party or custom editors, message movers, loaders, copiers etc etc. Let's have this as a given, that comes with the product.
1) MQ explorer does not display data > 1000 bytes, cannot put a message > 1000 bytes or a message containing carriage returns, these limits need to be swept away. Also, you can only get to the first 200 messages in a queue.
2) A few CSD's ago an extra tab was added to the message detail to decompose the dead letter header, I would like to see the ability to break down a message into the various structures, decompose the RFH2, provide JMS specific dialogs, format an XML message etc etc.
3) Instead of having to use rfhutil to put/get message in a binary format, lets have a standard XML document for serialising MQ messages, allowing us to describe all the headers and binary fields in a human readable format. This would make testing so much simpler, finally allowing us to banish hex editors into history. For example:
| Code: |
<MQMessage>
<MQMD>
<MsgType>Request</MsgType>
<Persistence>NotPersistent</Persistence>
<Expiry>600</Expiry>
</MQMD>
<Body type="LiteralXML">
<StockRequest>
<Item>1204</Item>
</StockRequest>
</Body>
</MQMessage>
|
4) The ability to move, load, save, delete, copy, cut, paste and edit messages within explorer.
This is a lot of work, but IBM need to standardise the way we perform these functions. 3rd parties have had a chance to provide this function, but every message editor I've looked at so far has been pretty poor.
IBM should also consider open-sourcing the eclipse plugin, then we can do all the grunt work.
5) Allow remote admin by JMX, the eclipse plugin can administer queue managers and messages by JMX, deprecate PCF.
6) Finally, provide an XML equivalent to MQSC. This would really help configuring a large number of QM's/environments. XSLT could be used to build a config for a particular QM/environment, and the eclipse XML editor can validate the document against a schema before you run the commands.
Last edited by JLRowe on Thu Dec 09, 2004 7:09 am; edited 1 time in total |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Dec 09, 2004 6:55 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Ok, now my 2 cents.
To csmith28, item #6. I disagree. I tell programmers/developers at my client's site that it is a better programming practise to open the queue using the defaults. i.e. MQPRI_PRIORITY_AS_Q_DEF, MQPER_PERSISTENCE_AS_Q_DEF, etc...
Therefore, during code reviews, problems can be highlighted and since MQ Admin are NOT allowed to randomly alter queue properties, this keeps everybody honest.
csmith23's item # 7 (and Nigel's response), hopefully people are creating queues using the concept of template queues (hence using the 'LIKE' command). Now that IBM owns Candle, why don't they just 'borrow' the concept of prototypes from CCC MQ Confiugurator and implement it in the base product.
csmith23's item # 10, I would rather have an option for runmqsc to output the MQ objects in the right format.
As per Peter's item # 2, IBM PLEASE, please add a way to get the CSD of a queue manager programmatically. i.e. For Java, getCommandLevel() will give me 530 for v5.3 but not CSD info. People who develop tools cannot add this feature until Hursley adds it to MQ's API.
Peter's #3, this already exists. It has a funny name (I've already complained about the non-standard name). i.e. runmqver
Peter's #5, never mind lottery, what if he got hit by a truck or a large MQ vendor made him a very lucrative job offer?? (hence restrict him)
Peter's #11, absolutely. In this day and age with runaway J2EE applications, we REALLY need this supported directly in the product (rather than as a support pac).
To timna comments, IBM will probably response with "there is a very health 3rd party vendor support for the tools you seek".
| Quote: |
| but every message editor I've looked at so far has been pretty poor. |
Really?? Are you referring to free ones or commercial packages? Do you want to name names and / or missing features?
For timna #5, yes, add JMX support but leave PCF alone for now.
I know a lot of people want to be able to use Client Channel Tables with Java clients. How difficult whould it be for IBM to create a JAR file to do this?
I would love to see Veritas active / active MQ support on Solaris rather than active / passive but this is probably a pipe dream. Although, I know for sure that a couple of LARGE brokerage houses who would cough up money for this feature!!!!!!
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Dec 09, 2004 7:06 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| RogerLacroix wrote: |
To csmith28, item #6. I disagree. I tell programmers/developers at my client's site that it is a better programming practise to open the queue using the defaults. i.e. MQPRI_PRIORITY_AS_Q_DEF, MQPER_PERSISTENCE_AS_Q_DEF, etc...
Therefore, during code reviews, problems can be highlighted and since MQ Admin are NOT allowed to randomly alter queue properties, this keeps everybody honest.
|
I side on Charlie with this. The APP knows if the message needs to be persistent or not, so they should code for it. They don't default for the Qs default Expiry, they don't default for the Qs default Format, they don't default for Queue name. Let them take responsability for it. Let their be a default in the MQMD, and thats it. Same for Prioroity.
The only reason I see for this attribute is if some app needs persistent messages one day, and then NP another day, and rather than coding changes, the q can be changed. 
Alas, I think we are stuck with it, because there are probably millions of apps out there that did code as Q default, and the new version can't break them
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Dec 09, 2004 7:37 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
| Quote: |
| I side on Charlie with this. The APP knows if the message needs to be persistent or not, so they should code for it. They don't default for the Qs default Expiry, they don't default for the Qs default Format, they don't default for Queue name. Let them take responsability for it. Let their be a default in the MQMD, and thats it. Same for Prioroity. |
I always smile when I get into this discussion. Because most MQ Admins that I have met always say that and most architects/developers side with me. I think it comes down to responsibility (and blame when things go wrong). MQ Admins don't want to blamed if they change a queue attribute and developers don't want to be responsible MQ attributes.
I fully agree that the application developers ARE the ones who 'should' know what the application requires. I prefer to give the MQ Admin a spreadsheet of the queues and their attributes and then have it implemented. (i.e. The same way I do for DB schemas and tables).
I think this would be less of an issue if MQ had better change management capabilities.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| JLRowe |
| Posted: Thu Dec 09, 2004 7:42 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
AMI was designed to solve this problem for procedural languages, just like JMS does for java.
In the past, I have almost resorted to tatooing the phrase 'always specify GMO_CONVERT' on each programmers forehead. |
|
| Back to top |
|
|
| WannaBeInAParker |
| Posted: Thu Dec 09, 2004 7:43 am Post subject: |
|
|
Voyager
Joined: 09 Dec 2003
Posts: 81
|
Admins do not know the contents of the messages and the reason for their being. Admins should not be deciding persistence for those messages. How would an admin handle the case where some messages need to persist and some not, a separate queue is the only way I can think of.
To cover myself (an admin, as you could probably figure it out), everything is defined as persistent.
I can see good arguments on both sides, fun to watch/read.
_________________
-WannaBe-
Last edited by WannaBeInAParker on Thu Dec 09, 2004 12:17 pm; edited 1 time in total |
|
| Back to top |
|
|
| JLRowe |
| Posted: Thu Dec 09, 2004 7:51 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
It's analogous with the roles defined in J2EE:
Administrator, defines QM and Q's
Deployer, configure's AMI/JMS
Developer, writes code to AMI/JMS |
|
| Back to top |
|
|
| csmith28 |
| Posted: Thu Dec 09, 2004 2:38 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| fjb_saper wrote: |
| csmith28 wrote: |
| 4. I would like to have an endmq* script for all the runmq* scripts especially the runmqdlq. Currently the only way to stop runmqdlq, runmqchi and runmqchl in UNIX is to do a kill against them. The only way to stop these processes on Microsoft platforms is stop them using the TaskManager or the kill.exe script if you have it. (I have it. PM me if you want it). This always generates an FFSR/.FDC file. I don't know how they take care of this on z/OS, AS/400 or Tandem platforms. |
Chris have you looked into the "WAIT(NO)" part of the first line when using the dlq handler. I use it all the time. As soon as the dlq has been fully scanned and processed according to the rules the process finishes. No need to kill it....
Now I agree that if you want to keep it running there are a few challenges. Setting the dlq get (disabled) should bring the handler down as well.
Same thing for Trigger monitors or channel initiators: Set the initiation queue to get(disabled). And DON'T FORGET to set it to get(enabled) right after
Enjoy 
F.J. |
No but I will now.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Tue Dec 28, 2004 11:18 am Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
I was thinking about this a bit recently.
Wouldn't it be nice to have a standardized .EVENT message handler similar to the runmqdlq utility?
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| kirani |
| Posted: Tue Dec 28, 2004 11:23 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
| csmith28 wrote: |
| Wouldn't it be nice to have a standardized .EVENT message handler similar to the runmqdlq utility? |
If you don't know already there is a SupportPac to read Event messages from different queues. You can also specify the option to write them into a flat file.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| csmith28 |
| Posted: Tue Dec 28, 2004 11:27 am Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
Yes I know, provided as is....
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| kirani |
| Posted: Wed Dec 29, 2004 11:06 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Peter's original post ..
| PeterPotkay wrote: |
The description paramter of all MQ objects is expanded to hold a good anmount of data, maybe like 256 chars.
Sure would be nice to adequately describe what a queue is for, so a few years down the road you can tell what you have on your hands.
|
I created a new thread to discuss WBIMB.
http://www.mqseries.net/phpBB2/viewtopic.php?t=19643
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jan 08, 2005 3:25 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
