ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » News/Updates » MO71 Version 9.0 Available

Post new topic  Reply to topic Goto page Previous  1, 2, 3  Next
 MO71 Version 9.0 Available « View previous topic :: View next topic » 
Author Message
jcv
PostPosted: Fri Jul 29, 2016 9:20 am    Post subject: Reply with quote

Chevalier

Joined: 07 May 2007
Posts: 411
Location: Zagreb

OK, you weren't mentioning number of qmgrs, but thousands of queues on one qmgr. Anyway, it all revolves around the fact did I specifically ask there for a queue list or not. I would say I did, and if I did, I should get that regardless of number of queues in that list.
Back to top
View user's profile Send private message Visit poster's website
PaulClarke
PostPosted: Fri Jul 29, 2016 9:34 am    Post subject: Reply with quote

Grand Master

Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand

Answering your previous point. No I don't agree. As I said, there could be very valid reasons why MO71 should not just take it upon itself to download all the object definitions. So, there is a preference option, by Queue Manager, for you the user to say whether MO71 should do this automatically or not. If you have not switched that on then I don't think that I can help you further.

MO71 has a rather large set of settings because users use it in all sorts of different situations and have different needs and preferences. It would be arrogant of me as a software writer to assume that everyone wants their system set up the same way as I do and mandate all program behaviours. So, instead I allow users to pick and choose the behaviours they wish to see and tune the application for their set-up. My apologies if the defaults are not the way you would personally like them but unfortunately that has to be the case for someone.

MO71 has been around for 20 years with very many users and you are the first person to object to this setting,

Regards,

Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
jcv
PostPosted: Mon Aug 01, 2016 2:52 pm    Post subject: Reply with quote

Chevalier

Joined: 07 May 2007
Posts: 411
Location: Zagreb

So, you don't agree with me that if data was neither saved from previous sessions nor downloaded in the current, it should be downloaded at the moment when it is explicitly requested? If I say I think it should, you shouldn't interpret that as if objected some settings. For example, in case you have some setting (and I'm not sure if you do) on qmgr location that says to MO71: don't download automatically queue definitions immediately after connecting to this qmgr, I'm perfectly fine with it, because I perfectly understand reasons for existence of such a setting. I just think this setting should not be relevant in this case since I didn't just issue MQCONN, I went on to MQOPEN tab, MQOD section, clearly indicating my interest in queue definitions from that qmgr. That is, nothing for MO71 to take upon itself. That's pretty much the same situation as if I went to open a queue list dialog. If MO71 had no information to show there, you would have enough arrogance to decide that MO71 needs to download queue definitions at that moment, wouldn't you? I mean, you wouldn't force me to go somewhere else to refresh the information, and then return to a queue list dialog to show it there. With respect to setting for saving definitions, same thing. Of course that it is a useful setting, but in this particular case its only relevance would be to narrow the window of opportunity for the defect to be exposed, because queue definitions might be saved. Same thing with object refresh rate, that way not only there would be something to present, but the content might be relatively fresh. That's all great, but what does it all have to do with the fact that if there's nothing to present, that download has to be done? You can't just go saying: "Ha, it's your fault, you didn't turn on that setting". What setting exactly?
And no, I don't think MO71 should download the list of queues every time I dropdown the list of qmgrs. Only for qmgr for which it knows that it has no queue list yet, it should connect to it (if not already connected) and download the queue list, if that particular qmgr is selected from the dropdown list.

Besides that, could you tell me please why can I not find in the API Exerciser the option to define message buffer by pointing it to a file location, as you have it in a "Put message..." option?
Back to top
View user's profile Send private message Visit poster's website
PaulClarke
PostPosted: Mon Aug 01, 2016 3:43 pm    Post subject: Reply with quote

Grand Master

Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand

No I don't agree with you.

I think there is a world of difference between actually clicking on a 'Queue List' and selecting a drop-down in an API exerciser box. In the first case you know that MO71 will have to go and get a list of queues. In the second case it is not entirely clear what will happen. And, in fact, what should happen is definitely up for debate.

At the moment MO71 will put the list of queues it already knows about in the dropdown. However, it has certainly been mentioned that what it should do is show you the last 20 queues (say) that have been used in the API exerciser. This does, on balance, seem not unreasonable. Drop down boxes tend to be small and unwieldy. Put a thousand queues in there can make it a little awkward; you could spend longer searching for the queue you want than just typing in the name. In most other cases in MO71 where there are object dropdowns it does indeed just show you the last few that you have used for this very reason.

However, clearly you feel strongly about this issue. I will add to the MO71 requirements list that a Preference Option should be added, default no, that says if the dropdown is selected and we don't currently have any queues that we should go and get them. Of course I make no promises about when (or if) it will be implemented.

...and as for your second point.

Quote:
could you tell me please why can I not find in the API Exerciser the option to define message buffer by pointing it to a file location, as you have it in a "Put message..." option?

What makes you think it should be there at all ? |This is an API Exerciser. The clue is in the name. This is for trying out all sorts of different API verb and option combinations. What benefit would taking the input from a file give in that respect ?

The bottom line is that MO71 is not perfect, we know that. Over the years we have added more and more function but, as you so vehemently point out, things can always be improved. I still maintain that in terms of capabilities for the price it represents exceedingly good value for money. I don't know who you are or what licence you hold since you seem unwilling to email our support team but take a look at the cost of the licence you hold and ask yourself how many hours of a contract programmer you could get for that. Then ask yourself how many hours you think it would take to write something like MO71.

Regards,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
jcv
PostPosted: Tue Aug 02, 2016 2:03 am    Post subject: Reply with quote

Chevalier

Joined: 07 May 2007
Posts: 411
Location: Zagreb

OK, so now all of a sudden it's not the problem of settings any more. Now the problem is with presenting data.
Wouldn't you agree then that there are better ways of searching and displaying queue names then the simple drop down list, filled statically? For example, if there is a small number of queues, this suffices, otherwise the input tag for a a queue name could direct the search. With every new character input it narrows the list until it can be displayed in a manner that is not unwieldy, to finally select the wanted queue. So that you don't have to display all queues at any time.

As for the other matter, I said that Put message... option is too rudimentary, and you didn't react in any way, whatsoever. So I assumed you consider API Exerciser the option that should be used in case one wants more from the option to put a message, like adjusting precisely MQMD parameters and such things. But it turns out that this option doesn't offer a possibility that a previous does. That's why I assumed that I didn't look properly for the option. Loading a queue from a file with Load/Unload option is the third option to put a message to a queue, but that also doesn't fit the job description entrely. So basically, no option does it all, at least that I know of. I'm sorry if I missed some because I don't investigate the product too much, I just use it.
Back to top
View user's profile Send private message Visit poster's website
hughson
PostPosted: Tue Aug 02, 2016 3:12 am    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

jcv wrote:
put a message, like adjusting precisely MQMD parameters and such things.

It sounds like you want to put messages to a queue where the message data is currently in a file, and that you also need to be able to put some specific MQMD fields. You also say "and such things", what were the other things?

QLOAD allows you to load files onto a queue and at the same time provide all, or as much of the MQMD as you need. This might be a better fit for your needs?

The API Exercisor is a way to learn how to use the MQ API, as a pre-cursor to writing your own MQ application, so you can test out the use of the fields in the MQOD, or try out the options in the PMO, and then you can write an application which can read from a file and put to a queue knowing how the options you have tried out in the Exercisor behave.

Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
jcv
PostPosted: Thu Aug 18, 2016 4:36 am    Post subject: Reply with quote

Chevalier

Joined: 07 May 2007
Posts: 411
Location: Zagreb

Thanks for the pointer, but we purchased MO71 licenses, and we are interested now primarily in getting from that product as much as possible. So I hope that doesn't mean you won't change anything in MO71 in the area of overlapping functionality, in order to not outcompete QLOAD.

Immediately after my last post, I checked how you actually utilize input of characters with dropdown list at that point and saw that you use it for positioning within the ordered list, matching the input string with queue names from the beginning. Which is not much different from implementations that I had in mind, that display only entries that match the input. If I didn't respond so hastily, I would probably not describe them then. I would just say then that searching capability is not much of an argument against long dropdown lists. Normally, input of a few characters reduces reasonably the list, OK, one can think that when there is a lot of queue names starting with the same common long string, that this is not a great help, but even in that case input/selection of a queue name is easier. One can also argue to allow for different matching options, for example if characteristic string appears in the middle or at the end of the queue name, one can argue that last 20 queues that have been used in that option could be better than searching all queues, but in any case, if you already have a dropdown list, it should not be empty.

Besides that, I think that Main window Queue Manager search field input could also influence the content displayed in the left-hand pane of Multi Qmgr list, if you rename the search field to something more generic. Is there any other way to influence that, or is there some particular reason against it?

Cheers
jcv
Back to top
View user's profile Send private message Visit poster's website
PaulClarke
PostPosted: Thu Aug 18, 2016 2:07 pm    Post subject: Reply with quote

Grand Master

Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand

jcv,

We are just trying to understand just what your requirement is. You seem to want to be able to set an arbitrary number of MQMD fields and set arbitrary message content. The best fit for this, in our software, is QLOAD. We are not necessarily suggesting you purchase a QLOAD licence, the bulk of QLOAD functionality is in MO71 itself. You just need to create a QLOAD file containing the data you want and then tell MO71 to upload the file to a queue.

This is all about using the right too for the job. Since we don't really know what job you are trying to perform this makes it awkward to suggest something.

As far as the main window search affecting all the other dialog is concerned I can't say we like that idea. I think people would find it very un-intuitive. One of the strengths of MO71 is that you can show lots of dialogs at the same time that essentially operate independently allowing you to look at different aspects of your MQ estate at the same time. So, I may have a list of queues for one set of Queue Managers and a list of Channels for a different set etc etc.

If you regularly want to set the list of Queue Managers for list dialog then might we suggest you look at the qmloc, qmnet and qm filter functions ? These can be very useful for quickly allowing you to see data for a group of Queue Managers in the same dialog. It is not even necessary to show the QM list and select the entries manually. For example, suppose you had a set of Queue Managers associated with Application Group XYZ. You could add the 'network' XYZ to all the Queue Managers that were involved. Then on any list dialog you need only specify a filter of qmnet("XYZ") and you will be shown the list for that group.

Does that help ?

Regards,

Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
jcv
PostPosted: Fri Aug 19, 2016 3:25 am    Post subject: Reply with quote

Chevalier

Joined: 07 May 2007
Posts: 411
Location: Zagreb

Paul,

I have already looked at those functions, before I concluded that selecting entries (qmgrs) manually is more convenient to me. This suggestion doesn't mean you would reduce that strength, it only means that if user's decision to constrain himself to a certain subset of qmgrs was a really temporary one, he would need to change/remove it whenever opening another dialog that is not reachable with the current setting. And I don't see why would user want to constrain himself in a main window, and be unconstrained in that pane, that is, when opening multi qmgr dialogs. What would be the point of that?
An alternative would be to at least organize qmgrs in that pane in groups defined on location, that enable grouping in a main window, and I don't see why not in that pane too. It consumes some space in a window, but not that much.

Cheers
jcv
Back to top
View user's profile Send private message Visit poster's website
jcv
PostPosted: Fri Aug 19, 2016 10:14 am    Post subject: Reply with quote

Chevalier

Joined: 07 May 2007
Posts: 411
Location: Zagreb

Actually, I see some possibility for this to have some point. If someone has a lot of qmgrs, not organized in groups, and wants to find one particular, to work something only with this qmgr, and afterwards wants to open multi qmgr dialog with all qmgrs and doesn't want to lose this restriction to that qmgr in main window ... there is always a possibility that you implement a separate search field for that pane, if you like that idea better.
Back to top
View user's profile Send private message Visit poster's website
jcv
PostPosted: Tue Aug 23, 2016 5:22 am    Post subject: Reply with quote

Chevalier

Joined: 07 May 2007
Posts: 411
Location: Zagreb

Hi,

I probably shouldn't have mentioned that, because this is actually a corner case. In most cases, when people select multiple qmgrs as a temporary group for a main window session, and it doesn't matter is it a group newly formed just by entering some search expression, that is not persisted in any way in location definitions (neither as QM Group nor as a Network Name), or users specifically target these permanent groups from location definitions by using qualifiers in search expression or without it, they usually want the same restriction in a multi qmgr left pane, if they use it. I use it on a daily basis, and it's annoying when I open that pane, and qmgrs that I'm interested in are scattered all over the place. It's even more annoying when I can restrict the display in a main window (where I don't need it all that much, because of QM groups defined) and the restriction from the main window is not reflected in multi qmgr pane.
However, I gave another chance to your suggestion. What would be interesting here, is that filter expressions that are common to list dialogs of any type, such as those containing functions that influence multi qmgr display (qm, qmnet, qmloc), are shared among list dialogs of all types, by using something like Global filter history mechanism. Currently, global filter history is shared among locations for list dialogs of the same type, and that doesn't help here, to pass filter expressions without copy pasting them, from let's say, queue list to channel list. Maybe naming a filter expression would help to avoid copy paste, if input for invoking of named filters was somehow shortened by context sensitive help, activated after pressing $ character in filter field or something like that, but that also wouldn't be convenient because it would require named filter definition. If you implemented a separate input search field for a multi qmgr context however, it would hopefully help to overcome that minor shortage in an elegant way, by holding that input separately, once for all further multi qmgr lists. You can maybe change the global filter history implementation to address the issue. Because in the end, what you do is that you add the expression resulting from the input from the left hand multi qmgr pane, to the expression entered in the filter field, if the expression from the filter field already contains those functions, it overrides the left hand pane input. At least that's what I see in the current build that I'm using, if I missed something, so that my suggestions are excessive, please let me know.

Cheers
jcv
Back to top
View user's profile Send private message Visit poster's website
jcv
PostPosted: Wed Aug 24, 2016 12:55 am    Post subject: Reply with quote

Chevalier

Joined: 07 May 2007
Posts: 411
Location: Zagreb

OK, that part was maybe interesting to me, but here is what I have a problem with. First you provide an option, and then you say it's not neccessary to use it. What kind of attitude is that?
The decision to use multi qmgr left pane to select qmgrs, or those functions, is a bit a question of how many qmgrs you are dealing with. It's not only a problem of passing those functions between different types of lists. Even if I have to work with only one of them, say queue lists, it's still less convenient to paste expressions like this: qmnet("XYZ") && , or: && qmnet("XYZ"), to the rest of filter expression, instead of a few clicks and unclicks, each time I want to switch from one temporary group to the other, if number of qmgrs is small, and if qmgrs were handy organized or restricted on a less temporary basis.
I don't see how would my suggestion affect those that don't use that pane at all, or how it would be not beneficial to those that do, if you have an explanation, I would like to hear it.
Back to top
View user's profile Send private message Visit poster's website
PaulClarke
PostPosted: Wed Aug 24, 2016 1:54 am    Post subject: Reply with quote

Grand Master

Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand

You sound angry and I don't know why.

The explanation is that software is imperfect. Developing software, including ours, is an iterative process. You develop version 1 and see what works and what doesn't and then you try and improve it. There are two main complications to this process.

Firstly many users have different perceptions on what should be improved and they are often directly conflicting. No two people seem to use software in exactly the same way. If you asked 10 people how a piece of software should operate I suspect you'd get 10 different answers. The more flexible and complex the software is the more difference you will see in the answers. And MO71 is a very complicated piece of software. It has gone through many improvements over the years. There have been at least 44 versions of the manual. I suspect there have been well over 50 versions of the program itself! Each one, I hope, better than the last.

Secondly, Developing Software is hard, it's complicated and it's expensive. There are nearly always more things one would like to do than the time in which to do it. You can describe something in a couple of sentences, and it sounds easy, but it could takes weeks, months or even years to Develop. Consequently Software houses, ours included, have to prioritise. Generally speaking we do the things asked for the most or that we think will generate the most revenue. If, for example, you said you really wanted these features and were willing to pay extra for them then clearly that would increase their priority.

I have asked you in the past who you are and what licence you hold but you have not responded. I don't think it an unreasonable request. I am spending time responding to your comments and I am curious to what extent you have invested in the product. We try very hard to keep our customers satisfied and we believe that MO71 (and our other products) represent very good value for money. However, at the end of the day, if you do not believe you are getting value from the software you always have the option of voting with your feet and using some other solution. Clearly we would prefer to keep you as a customer but you must recognise that it is a partnership.

Having said all that we have discussed the possible solutions and have decided to investigate providing a search field at the top of each multi-QM panel in each list dialog. A preference option will be added to allow this field to be initialised from the main window on start up if required. We can not, of course, guarantee when this will be made available but it seems like a reasonable requirement.

Regards,

Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
jcv
PostPosted: Wed Aug 24, 2016 5:39 am    Post subject: Reply with quote

Chevalier

Joined: 07 May 2007
Posts: 411
Location: Zagreb

I'm not angry. And I understand all that you said here. I'm also not interested in imposing requirements that would be not beneficial to majority of other users. That's why we would like to stay at regular price, and hear maybe from other users if they have something to say publicly. You don't have to react immediately to such requests, we don't expect that. We would rather wait for something that is even better than we suggest. For example, I'm looking now at Network Names window. That is another good possibility to organize multi qmgr left hand pane, ie displaying not just individual qmgrs, but QM groups and Network Names too, with a tick/cross icon next to it, that enables user to either include or exclude multiple qmgrs in a single mouse click on a group icon, or single qmgr by clicking on individual qmgr icon, although there might be some potential ambiguities in that case between group and individual inclusions that would have to be clearly explained, maybe.
Possibilities are numerous, as well as problems that each idea brings, and it is actually a good thing, not bad, I would say.
Back to top
View user's profile Send private message Visit poster's website
jcv
PostPosted: Fri Aug 26, 2016 9:05 am    Post subject: Reply with quote

Chevalier

Joined: 07 May 2007
Posts: 411
Location: Zagreb

Hi,

weighing between restricting and organizing that pane, I would definitely prefer organizing. The simplest way would be to just organize it as a main window, ie only individual qmgr icons would be clickable, but grouped in QM groups which allows collapsing/expanding. For the latest idea however, you would also do that, but additionally QM group icons would be clickable, and you would add Network Names icons besides (also clickable). I mean, icon besides them (tick/cross) would be clickable, wherever I said here clickable.

And there is no possibility for any ambiguity here, clicking for group inclusion would be translated to such additional expression:
(qm('QM1')||qm('QM2')||...qm('QMn')) && , where QMi is the ith member of the group, it's even not neccessary to involve qmnet functions, both QM groups and Network Names can be handled this way, and this would cause all individual qmgr icons of members of that group to be changed to indicate inclusion (tick), clicking for group exclusion would result in removing of all its individual members from filter expression, and changing of all individual qmgr icons of members of that group to indicate exclusion (red cross), and it's obvious what would clicking on individual qmgr do. It doesn't matter that QM groups are strictly disjoint sets, and Network Names are not, inclusion of qmnet1 followed by inclusion of qmnet2 would result in their union, following exclusion of qmnet1 would result in qmnet2 minus qmnet1. If some of their members are included and some excluded, group icons would indicate inclusion.

I like that, how about you? You already have all parts of that solution in your product, you just didn't apply it combined in such way to that pane.

Once qmgrs are selected, the set should be remembered for the rest of MO71 session, that is, possible to recall for a multi qmgr list dialog of any type.
Plus, since this pane is I think much more important option than API Exerciser (at least to me), a new preference setting should allow switching between new feature and default old display.

Cheers
jcv
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2, 3  Next Page 2 of 3

MQSeries.net Forum Index » News/Updates » MO71 Version 9.0 Available
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.