| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MO71 Version 8.0.4 now available |
« View previous topic :: View next topic » |
| Author |
Message
|
| PaulClarke |
 Posted: Sat Nov 28, 2015 3:05 pm Post subject: MO71 Version 8.0.4 now available |
 |
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Hi,
MQGem Software is pleased to announce that MO71 Version 8.0.4 is now available for download here http://www.mqgem.com/mo71_download.html
The main features of this release are:
• Main window Queue Manager search field
• Connect All Support
• Disconnect All Support
• Channel Mask added to Application Definition
• 'QM Group' in Console list
• Message browsing over the Web improvements
• HTML template specification in URLs
• Option added to location definition to control whether browsing queues is allowed over the Web Interface.
• Improvements to the event message formatting
As before, any current licensed users of MO71 can run the new version on their existing licence. If you don’t have a licence and would like to try out MO71 please send a note to support@mqgem.com and a 1-month trial licence will be sent to you.
As always I welcome any comments or suggestions,
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
 |
| jcv |
| Posted: Fri Apr 15, 2016 8:29 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Hi,
1. Would it be possible to implement a feature that enables alterations of a certain attribute to a same value for multiple objects and multiple qmgrs, by using one input field, from an adequate list of the objects?
2. Although the concept of a browse message summary (not only with regard to event messages) by itself is a an improvement in comparison with what was at disposal earlier, it could be enhanced to add to the summary all relevant information, for example if there is MQRC_UNKNOWN_OBJECT_NAME event message in SYSTEM.ADMIN.QMGR.EVENT, why not adding to the summary the object name in question, since that information is present, etc...
3. I miss the possibility to exploit a list of event messages for creating missing definitions due to a lack of which, these events were generated. This would be particularly useful, for example for security related events. I have written a special event message handler for that purpose in Java, for my personal usage, that sets missing AUTHREC and CHLAUTH records, I may publish it if someone would be interested to review, test or contribute to it.
This is somewhat related to this RFE: http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=67084 ,
in fact such an event handler is the next best thing to potential implementation of that RFE, which is not going to happen.
Event handler cannot completely substitute it, because for example not all authority exceptions generate event messages, for example, lack of authrec to perform MQCMD_INQUIRE_Q would not generate one. Plus, the proposed enhancement would avoid the exceptions completely proactively, while event handler can only react to generation of event messages. Which in some cases could be better, it all depends on circumstances. And I have also not nearly implemented handling of all reasons and reason qualifiers, even those for which there are event messages generated, for example MQRQ_SUB_NOT_AUTHORIZED, MQRQ_CMD_NOT_AUTHORIZED, etc... I implemented only the very basic ones as a proof of concept, that is, these combinations:
MQCMD_Q_MGR_EVENT & MQRC_NOT_AUTHORIZED & MQRQ_CONN_NOT_AUTHORIZED
MQCMD_Q_MGR_EVENT & MQRC_NOT_AUTHORIZED & MQRQ_OPEN_NOT_AUTHORIZED
MQCMD_CHANNEL_EVENT & MQRC_CHANNEL_BLOCKED & MQRQ_CHANNEL_BLOCKED_NOACCESS
4. Another similar request, not implementable at the moment, due to a lack of support in MQ itself, would be a possibility to start/stop a selective api trace by clicking on a certain queue, queue handle, channel, channel instance, connection, conname, ... Both AAT (App.Act.Trac.) & strmqtrc lack such selectivity options, hence there is nothing yet that such parameters (queue, queue handle, channel, channel instance, connection, conname, ...) can be passed on as arguments to produce the trace. And I don't know why request for tracing could not be implemented as a PCF command, so that MO71 can pass it in a normal standard way to qmgr, so I created an RFE for that too.
RFE repeats the fact that tracing selectivity options are not sufficient, and this, that it should be controllable from MO71.
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=86886 |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Fri Apr 15, 2016 9:31 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Hi jcv,
Thanks for your suggestions. My initial answers to the points you raise are:
1/ It is already possible in MO71 to update multiple objects at the same time. However, these have to be for the same queue manager. Extending this concept to multiple queue managers may not be too hard but it is not entirely obvious what it should look like on the screen. As I'm sure you know MO71 already allows you to view objects from different queue managers in the same list (so you can sort across queue managers etc) but updating a particular field is a little more tricky to show.
2/ I agree that Message Summary can always be improved. However, it is not necessarily true to say the data is 'present'. When browsing a queue MO71 only asks for the first 121 bytes (slightly tunable). This is to prevent too much data being sent to MO71, especially over a client connection. If there is a particular 'summary' which you think should be catered for then let us know and we could certainly look in to it.
3/ It is not clear to me how one could easily automate the creation of a queue based on an event saying MQRC_UNKNOWN_OBJECT_NAME. I'm not entirely sure that automating the process is even a good idea. It could just as easily be that the application has misspelled the name. MO71 allows other mechanisms for defining queues. For example, comparing your production and test queue managers to see whether the same queues are defined (even allowing for a slightly different naming).
4/ Generally speaking if the command server allows you to do it then MO71 provides a mechanism of exploiting it. There are many things which would be handy to be able to do remotely. For example, looking at the error logs and INI files would also be useful. Whenever PCF commands are added to the command server then, providing we feel it is of value, we will add that support to MO71.
Regards,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| jcv |
| Posted: Mon Apr 18, 2016 9:08 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Hi Paul,
1. The object dialog would contain composite key field, that is MULTQM in addition to the object name. Its label would reflect that fact, and its values (pairs of them) would be displayed delimited with + sign, similarly as is now. I know that MO71 already allows viewing objects from different queue managers in the same list, and if you select multiple rows from such a list, only object names are passed from the list to the object dialog as key field values, and the qmgr of the first selected row is assumed. And if update button is pressed, objects on that qmgr are altered, ie not exactly those that were originally selected. So, this basically doesn't work quite as I would expect.
2. OK, but this still forces you to look at each message to find out what's there, contrary to the idea of the message summary, some compromise should be made based on the info how many messages are there. If there are only 100 messages in a queue, I guess there is no big difference between asking for the first 121 or 484 bytes in terms of performance of that query, while there is a huge difference between only one view at a list of 100 message summaries and opening each message one by one.
3. Yeah, well, the example you chose may well make no sense to anybody, but that's not what I was focused on. Besides that, this could be semiautomatic processing, not neccessarily fully automatic. But yeah, forget about it.
4. OK, if this gets implemented, I will be able to start, stop, watch the status of tracing (with which parameters it is started), and collect the results of tracing (from SYSTEM.ADMIN.TRACE.ACTIVITY.QUEUE), all from MO71. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Tue Apr 19, 2016 8:12 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Hi,
2/ You are right. I suppose I could check the depth of the queue to determine it's depth and then use some algorithm to decide what type of Message Summary is appropriate. However, I can't help feeling that it would be confusing to users and sooner or later I would have customers complaining that the view is not what they got yesterday etc.
At the moment you can set the number of bytes browse list will ask for in the Preference Dialog. This can be between 108 and 500. The higher this value the more information Message Summary will show you. If you want to see more information then by all means set it to 500.
Regards,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| jcv |
| Posted: Wed Apr 20, 2016 7:58 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Hi,
2. No need to change anything there. I just increased both Message Summary Size & Display parameters in preferences, and this is sufficient. Thanks.
4. I think I was wrongly understood by IBM, so I repeated the request in a more precise manner. Also, I noticed some announcements of enhancements of this feature in v9, so let's wait and see what happens. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Wed Apr 20, 2016 10:26 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Hi,
2/ Great, that's what I like to hear. Customers raising requirements that the product can already do 
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
