| |
|
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
|
| csmith28 |
 Posted: Wed Dec 08, 2004 5:43 pm Post subject: Changes I would like to see in WMQ Version 6.0..... |
 |
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
1. I would like it if they would change the sample scripts like amqsget and amqsgbr to handle messages that are at least (the default message size (4194304)) 4meg. 200 bytes is just stupid.
2. I would like them to introduce sample scripts that can handle message up to 100meg like amqsgetbig or amqsgbrbig. Yeah I know IBM says these scripts are samples but they have become a standard. We pay a lot for MQSeries Liscenses. I don't think we should have to re-compile these scripts anymore.
3. I would like to have a "clear ql(QLOCAL.NAME) mode(force)" regarless of whether the queue is busy or not. If/when I get to a point where I want to do a distructive clear of the messages on a Queue, I really don't care if the Queue is busy or not.
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.
5. I would like to see the TRIGINT attribute moved to the XMITQ definition instead of the qmgr definintion. I would like to be able to define TRIGINT based on the individual XMITQ and the way it is used.
6. Since Message Persistence is now and has been for some time, ultimately up to the Application, what would it hurt to remove the DEFPSIST value from Queue and Channel Definitions? I mean whats the point? Regardless of whether you set DEFPSIST to YES or NO the application overrides it. So YES or NO means maybe... or not so much.
7. If I define an QLocal with USAGE(XMITQ), TRIGGER, TRIGTYPE(FIRST), TRIGDEPTH(1), would it be to much trouble to autofill INITQ with (SYSTEM.CHANNEL.INITQ)?
8. Move the AdoptNewMCA from the qm.ini to the Channel Definition.
9. Lets increase some of the defaults like MaxChannel 100 and MaxActiveChannels 200. I've lost count of how many times these default thresholds have been reached. Whataya say? 400/800...
10. I would like IBM to make the saveqmr script a part of the standard install for WMQ Server by platform. Updates to the saveqmgr script should be included in the Service Packs.
Well these are some of the things I would like to see in WMQ6.0.0.0. A WMQ6.0 wishlist if you will. How about the rest of you.
I welcome, questions, comments, disagreements, flames and other suggestions.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial.
Last edited by csmith28 on Thu Dec 09, 2004 7:45 am; edited 12 times in total |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Dec 08, 2004 5:54 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I view new software versions much the way I view new babies.
I want them healthy and functional.
Features are less important.
I would like to see MQ Version 6 go GA without a required fix pack.
I would like to see FixPack 1 for MQ Version 6 to be significantly smaller in size than the entire product.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Wed Dec 08, 2004 6:09 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| jefflowrey wrote: |
I view new software versions much the way I view new babies.
I want them healthy and functional.
Features are less important.
I would like to see MQ Version 6 go GA without a required fix pack.
I would like to see FixPack 1 for MQ Version 6 to be significantly smaller in size than the entire product. |
Oh yeah, too be sure I will wait for a healthy period of time before I move from 5.3 to 6.0 all the while evaluating the new version from feedback on this forum, literature and whatever other resources make themselves available. I also intend to load WMQ6.0 on a LAB Server and do my best to break it.
The above is a wish list. I have heard that IBM has made a lot of signifigant changes and the decision to change the Version Numbering from 5.4 to 6.0 was not entirely based on the fact that the next version of WebSphere Application Server will be 6.0. Or not so much...
So, I am expecting/dreaming some major improvements in certain areas.
Come on Jeff, as long as we are writing a wish list you have to have at least one or two changes you would like to see or perhaps some comments on my wishlist.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| WannaBeInAParker |
| Posted: Wed Dec 08, 2004 7:06 pm Post subject: |
|
|
Voyager
Joined: 09 Dec 2003
Posts: 81
|
csmith28,
Great enhancements, but I agree with Jeff, make it work out of the box!
How about multiple version installs on the Open Systems platforms?
How about a Shared Queueing solution using Veritas or HACMP (similar to Oracle RAC) where the objects are kept on some kind of clustering facility. HA without bringing down the queue manager, imagine the possibilities.
_________________
-WannaBe- |
|
| Back to top |
|
|
| csmith28 |
| Posted: Wed Dec 08, 2004 7:36 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| WannaBeInAParker wrote: |
How about multiple version installs on the Open Systems platforms?
|
I agreed with Jeff too.
I was recently (under duress) forced to open a ticket with IBM/MQSupport because a PM wanted me to install two versions of WMQ on one SUN/Solaris Server. I told this individual it could not be done due to the way MQSeries accesses Shared Memory resources but when I told him that I was accused of being combative. The PM said I was refusing to support his objective. 
Ok, so, I said "you can't do that". The 1st level of IBM/WMQ Support said, "you can't do that." Mr. PM still wasn't happy so the IBM Ticket was escalated. Level 2 IBM/WMQ Support said, "you can't do that." Then IBM/WMQ 3rd Level support said...
"you can't do that."
Still the PM is not happy.
Finally I ended up speaking with an MQ Guru in Hersly who was actually writing the code for what was then being referred to as WMQ5.4 and he said, "you can't do that and you will not be able to do that in the forseeable future."
| Quote: |
How about a Shared Queueing solution using Veritas or HACMP (similar to Oracle RAC) where the objects are kept on some kind of clustering facility. HA without bringing down the queue manager, imagine the possibilities.
|
Please explain in more detail. I am not familiar with "Oracle RAC" or the "Shared Queueing solution using Veritas/HACMP"
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 08, 2004 8:43 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| 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. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Dec 08, 2004 11:24 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
1 & 2. Not much point. These are sample apps.
3. Not really possible.
4. I agree with this; there have been some complaints about this 5.3 introduced feature. You can of course stop the trigger monitor and channel intiator by setting the queues to GET(DISABLED), but runmqdlq should be stoppable without killing it.
5. Good idea. I never understood why it is a qmgr attribute.
6. Yes, I never thought that persistence as q def was a good idea. Unfortunately we are stuck with it.
7. Could do, I suppose. you could of course define a template xmitq with all these features defined, and define your new xmitqs with the keyword LIKE(TEMPLATE.XMITQ).
8. That would make channel definition rather repetitive. Why would you want to allow only some channels to be restarted?
Having said that of course, why have the restriction? Allow both!
9. Yes, why not. These defaults are years old, when systems had a lot less use than they do now.
Chris, is your company on the early release program, or part of the UCD, or on a beta program or anything? You could put these ideas to people who have the power to do something about it (like JasonE!).
These are rather trivial requirements. Does everybody generally think that WMQ does what you want, and only needs a few cosmetic and useability changes?
What about the big changes in the next release, like scrapping Explorer and replacing it with an Eclipse based version. What do you think of that? |
|
| Back to top |
|
|
| markt |
| Posted: Thu Dec 09, 2004 12:55 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
| Apart from the June Statement of Direction which has some limited information, there is nothing much public that can be said (by anyone authoritative) at the moment about any future release of WMQ. What I will say is that anything raised here is not likely to get into the next release ... way way way too late. |
|
| Back to top |
|
|
| Tibor |
| Posted: Thu Dec 09, 2004 2:18 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
Nigel,
1. I would like to bind the mq processes for CPUs on distributed platforms. As csmith28 wrote We pay a lot for MQSeries Liscenses... and we pay by CPUs. Look an example: there is a box with 16 CPUs needed by a heavy-weight application but I can't pay MQ for 16 CPU because the price. For messaging functionality only 2 CPU would be enough.
2. I would like a text-based client-channel-connection table (AMQCLCHL.TAB). I can't remove the entry for SYSTEM.DEF.SVRCONN  Or in other cases I have to delete all entries and rebuild this table from the scratch. I know there is an existing converter in the MQ for Perl module, but this is not official.
3. I would like to change the transaction log parameters 'on the fly' (see DB2) ... not all parameters  the numbers of log files would be enough.
Tibor |
|
| Back to top |
|
|
| WannaBeInAParker |
| Posted: Thu Dec 09, 2004 2:42 am Post subject: |
|
|
Voyager
Joined: 09 Dec 2003
Posts: 81
|
Chris,
Oracle RAC allows for the database files (log and data) to be shared between multiple systems. The same database appears to be running on both sides of an HA cluster, in fact I believe that you may have it running in more than two locations. If Host A goes away, you can continue to access the database using Hsot B. You may say that MQSeries offers this using MQSeries Clustering, but it actually does not provide the same functionality because with MQ Clustering, it is a separate queue manager. With a separate queue manager, there is a chance of messages being in flight on the queue manager that was running on the host that disappeared, we call these marooned messages. The RAC solution allows for 100% availability of a database until all hosts that it is available on have disappeared. It is truly 100% continuous availability.
As for HA and MQ, we have the log and data installed on Veritas shared file systems and are able to bring the queue manager online on several systems. The problem is that we need to stop MQSeries on Host A and restart on Host B. Since you cannot access the queue manager from Host A and Host B at the same time and the queue manager must be brought down and back up to make it available on Host B, it is not continuous availability.
The client channel does not help in this situation either. It only helps with access to the queue manager from another host. If the host where the queue manager goes away, the queue manager is no longer available.
nigelg,
As for the Eclipse framework, this seems like a great enhancement, but I am curious to see how it works. Does it require a client channel to use. Client channels are outlawed at our establishment due to the fact that delivery cannot be guaranteed. (Financial institution, 99% persistent messages, no client channels)
_________________
-WannaBe- |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Dec 09, 2004 3:14 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Tibor
1. Pricing is rather out of my league, I am on the technical side...
2. The Perl converter works fine. Any IBM offering in this area would only be a cat 2 support pack anyway.
3. The log parms can be changed (just recycle the qmgr). No change possible in this area.
As a thought, you could try planning your qmgr setup before creating it, using the detailed guide to the amount of log space needed in the Sys Admin manual...
Jack...
I do not think that the new Eclipse admin tool will need a client channel.
I am rather curious as to the reason why client channels are banned at your site. I know many large banks and other financial institutions that only use client channels to connect to the qmgr.
What exactly are the objections at your organisation to clients? |
|
| Back to top |
|
|
| WannaBeInAParker |
| Posted: Thu Dec 09, 2004 4:34 am Post subject: |
|
|
Voyager
Joined: 09 Dec 2003
Posts: 81
|
I basically work at a post office for my organization. We basically handle the messaging between all systems. We have several different levels of programmers that send/receive messages through our queue managers from people not knowing how to spell MQ to the people that want to use the latest/greatest stuff we have not implemented. Every queue that we set up is defined as persistent and we tell our users that if they do not want persistent messages, then specify it at the message level (good idea anyway). The bottom line is that we cannot lose any messages due to the infrastructure. As it is 99% of our volume is persistent messages.
With the client channels there are some obvious security holes. MQSeries requires that you know enough to secure the access through the channels. I am all for MQSeries being tightly locked down and then having the admins knowingly unlock access. Basically anyone can be an MQSeries God through a client channel if a queue manager is simply created. We have fixed the security issues by deleting the default SVRCON channels, enabling blockip, getting away from default ports and changing the MCAUSer of the client channels.
We feel better from a security aspect, but there is still the issue that delivery is not guaranteed with the default client. I understand that this is offered via the transactional client but also understand the cost is equivalent to licensing a full blown MQSeries installation.
We cannot guarantee delivery for our users if IBM cannot guarantee delivery.
That being said. we do allow the use of client channels, but it is definitely on an exception basis, where we need signoff form managers involved to implement.
The other thing is with OS390, I believe that there is a separately licensed product that is needed in order to use the client that we did not purchase.
I wonder how they are going to use the eclipse framework without client channels, maybe another agent process accepting requests across IP? If so, how would they handle security?
_________________
-WannaBe- |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Dec 09, 2004 4:44 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| The way to get product changes is to submit them as requirements for formal consideration by IBM. In the UK, the Websphere MQ user group runs this process. See http://www.mqug.org.uk |
|
| Back to top |
|
|
| Tibor |
| Posted: Thu Dec 09, 2004 5:31 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| Nigelg wrote: |
1. Pricing is rather out of my league, I am on the technical side...
2. The Perl converter works fine. Any IBM offering in this area would only be a cat 2 support pack anyway.
3. The log parms can be changed (just recycle the qmgr). No change possible in this area.
As a thought, you could try planning your qmgr setup before creating it, using the detailed guide to the amount of log space needed in the Sys Admin manual... |
Nigel,
1. This is not a pricing question. I need a feature to set MQ for using CPU 3 and 4, for example.
2. mqchl2ini & mqini2chl works fine, but not official just a hacking
3. OK. But sometimes would be nice to increase the log space depend on traffic without recycling qmgr
Tibor |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Dec 09, 2004 5:57 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
1. When applying a CSD on Windows, it just works thru the GUI. The GUI will stop or ignore all these mystery running processes that are using MQ (I know about the switch while running the CSD from the command line).
2. A way to know what CSD you have on a remote QM thru MQExplorer, or MO71.
3. An mqver command for clients.
4. Configuration Events for ALL platforms. Why can't MQ track changes to itself?
5. Official support for MO71. If Paul hits the lottery, who is gonna support MO71?
6. If clear Q FORCE is not possible, cheat and make the command destructivly get all the messages off of the queue, accomplishing the same thing.
7. Make Expiry Interval available for all platforms, and at the Q level.
8. When CSDs come out, they often have changes for the documentation. Whn I go to the manuals, and I am at 5.3 CSD 13, I don't want to double check the answer in the manual by looking at the CSD's read mes. Please keep the manuals current.
9. Channels go right to the state they were before the QM restart. If the channel was runing with 555 left before it DISCINTs, I want it to come up RUNNING with 555 left in DISCINT. etc, etc.
10. An official way to limit the number of instances a SVRCONN channel can be started, configurable at the channel level. I don't want to rely on a Cat 4 Support Pack Exit. Otherwise, 1 lousy app can swamp the QM with running channels.
11. An FDCs manual!
12. Fix the security hole that SVRCONN channels with a blanck MCAUSER hit us with (Java apps default to connecting as mqm or MUSR_MQADMIN).
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2, 3 Next |
Page 1 of 3 |
|
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
|
|
|
|
