| Author |
Message
|
| PaulClarke |
 Posted: Tue Jun 23, 2015 7:17 am Post subject: MQGem announces supported QLOAD |
 |
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Dear MQers,
MQGem is pleased to announce the availability of a supported version of QLOAD. This is an evolution of the MO03 SupportPac I wrote while working for IBM. My thanks to everyone for their encouragement to develop this product. All of your bug reports and most of your suggestions have been incorporated into this version.
The program is available to download for free trial until September from http://www.mqgem.com/qload.html. After this time the standard MQGem Software licence requirements will apply.
Please feel free to download the program and have a play with the new features. As always I welcome your comments and suggestions, please send them to support@mqgem.com.
Regards,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
 |
| gbaddeley |
| Posted: Wed Jun 24, 2015 5:14 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
|
| Back to top |
|
|
| PaulClarke |
| Posted: Wed Jun 24, 2015 11:08 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
When I left IBM they decided that my SupportPac MO03 was so useful that they wanted to incorporate it into the product. So, they essentially built exactly the same source as MO03 but called it DMPMQMSG instead.
In the meantime I had been asking IBM whether they could release the source code to me so that I could respond to a number of MO03 customer who have asked for new features (and bug fixes). For example, a number of customers wanted the ability switch on Read-Ahead and Async Put. Others wanted the ability to be able to select messages based on an explicit time-stamp rather than message age. Anyway IBM refused to give me sole access to the source code but instead decided to put the source on GitHub so that anyone could take the source and develop their own version of it and, if they wish, create a commercial product out of it.
I have to admit that the fact that the source was now freely available initially put me off trying to make a commercial product out of it since now anyone could build it themselves for free. However, I was convinced by a number of people that they didn't the considerable hassle of building and maintaining code. However they did want a version with the features they had requested. In essence they were willing to pay a small licence fee to have me continue to develop MO03.
So, I have decided to try and continue my support and enhancement of MO03 Support it's just that I am doing so under the guise of the QLOAD MQGem product.
Basically, in a nutshell, DMPMQMSG and MQGem's QLOAD product are both derivatives of my original MO03 SupportPac and use much of the same source code.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jun 25, 2015 3:45 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Might be worth bundling it with MA01 (q) in the same way.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu Jun 25, 2015 5:47 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
One enhancement (maybe it is in the tools and I missed it) to tools like q and qload that I would find helpful is the ability to use a queue manager "group" as your source or target.
For example, you could say I want to move the messages on Q1 and QM1 to Q2 on QMGRP2 and QMGRP2 would resolve to a list of queue managers to act on (i.e. QM2, QM3, QM4, QM5). Maybe the tool would just start spawning threads to perform the message move against each queue manager in the queue manager group.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 25, 2015 5:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| tczielke wrote: |
| Maybe the tool would just start spawning threads to perform the message move against each queue manager in the queue manager group. |
It's that or pub/sub.
This is how MS0S does it, when you tell it to run the mqsc on multiple queue managers. One at a time. |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu Jun 25, 2015 5:57 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
Sorry for going a little off topic, but something like this would be helpful for mqscx (if it currently does not support it).
For example, you could run an mqscx command line command to do a DIS Q(APP*) against a queue manager group, and then you would get a list of results back from all the queue managers in that queue manager group. I have written a multi-threaded PCF tool that can do this for queue attributes, channel attributes, etc., and have found it very helpful for administrative analysis.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Thu Jun 25, 2015 6:21 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Hi,
Thanks for the suggestion. The idea of issuing commands against a group of Queue Manager in MQSCX is an interesting one. Of course you can already do this kind of thing in MO71. MO71 allows you to dynamically set the list of Queue Managers you are interested in and then display all the objects. So, for example you can easily look at all your transmission queues in one dialog or you could display all your dead letter queues etc etc.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Jun 25, 2015 8:09 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Paul, thanks for the explanation. I have a withdrawn SupportPac that I am not allowed to continue support by my own effort (after leaving IBM). I receive emails nearly every month from IBM customers asking questions, wanting enhancements, fixing bugs, and requesting support for more platforms. I have to apologise to them and suggest alternatives.
It would be an interesting scenario if QLOAD features diverged from dmpmqmsg, and then IBM customers requested similar enhancements to dmpmqmsg.
_________________
Glenn |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Thu Jun 25, 2015 8:43 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Well, I'm sure that will happen. QLOAD can already do quite a lot of things which can't be done in DMPMQMSG and I fully expect that difference to grow. So it would not surprise me if customers ask for enhancements. But then that's life. When a feature is added to any product or architecture you quite often see a flurry of requests for similar things to be added to any related technologies.
However, as we all know, raising requirements is far different from having that need full filled. Each requirement has to be prioritised against hundreds of other requests. That means that, often, perfectly reasonable requests for function go unsatisfied for years. That's why it is my belief that vendors such as myself can provide such a useful service for IBM and it's customers. We are smaller and more nimble and can react to customer requests far more quickly. We can plug the gap until IBM gets around to it.
But, of course, we always have the risk hanging over us that IBM could change or add something to the product which makes our products less sell-able. It's all part of the challenge of being a software vendor 
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Jun 28, 2015 5:16 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| PaulClarke wrote: |
...That's why it is my belief that vendors such as myself can provide such a useful service for IBM and it's customers. We are smaller and more nimble and can react to customer requests far more quickly. We can plug the gap until IBM gets around to it.
But, of course, we always have the risk hanging over us that IBM could change or add something to the product which makes our products less sell-able. It's all part of the challenge of being a software vendor
Cheers,
Paul. |
For sure. I am sure Roger L is aware of that!
It appears that IBM leaves s/w segments vacant in its own products, hoping that vendors will release products, and IBM doesn't need to invest to produce its own. If its too hard, acquire.
_________________
Glenn |
|
| Back to top |
|
|
|
|
