It's never a waste of breath to discuss improvements to the product or indeed SupportPac improvements. A particular feature may or may not get done but if it doesn't even get raised as an issue then we might not realise there's even a problem.
My thinking was that if we effectively extended RUNMQSC to the client then you could create whatever channel file you wanted. You could also, of course, pipe in a set of exported definitions created by MS03 or MO71. The consequence of this is that the MQSC script files essentially become the source of the channel definitions and you just generate the client table file for client "groups" as and when you see fit. With such a scheme is it really necessary to do something like channel table defragmentation ? Nor do I really see the need to have the Queue Manager aware of your client grouping ? However, if you have a specific need, and can suggest the way in which you would structure the files and MQSC commands then I'd be very interested. Feel free to contact me directly if you'd rather. Paul G Clarke WebSphere Messaging Clients IBM Hursley MQSeries List <MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT> wrote on 13/07/2006 16:26:47: > > Paul, > > I have very few client channel definitions. I just asked from a > purist point of view. As some other poster suggested, using MS03 > output to rebuild the table works just as well, but that seems like > brute force to me. From a functional point of view, it would have > been nice if the client channels could be defined as *groups*, as > opposed to a single table. For example, you may want to create a > client channel table that is specific to a group of users. I don't > like the idea of giving them a table that has all the client channel > definitions. But, that's more along the lines of feature request. > Heck, for all I know there's a DCR out there that addresses this, > and I'm just wasting my breath. > > > > Paul Clarke <[EMAIL PROTECTED]> > Sent by: MQSeries List <MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT> > 07/13/2006 10:07 AM > > Please respond to > MQSeries List <MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT> > > To > > MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT > > cc > > Subject > > Re: Channel Table (AMQCLCHL.TAB) File > > > > > The proposed functionality is to provide the ability to do DISPLAY, DEFINE, > DELETE and ALTER CHANNEL commands against the AMQCLCHL.TAB file. You could, > in other words, on the client just delete your current file and make the > definitions you need there and then. > > I wasn't planning to have a particular option which said "de-fragment" the > file or whatever. Do you think that would be important to have ? How many > definitions do you have ? > > Cheers, > P. > > Paul G Clarke > WebSphere Messaging Clients > IBM Hursley > > > > MQSeries List <MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT> wrote on 13/07/2006 > 14:11:36: > > > > > Paul, > > > > Will you include the ability to reorg the table, dropping off > > inactive records? > > > > > > > > > Paul Clarke <[EMAIL PROTECTED]> > > Sent by: MQSeries List <MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT> > > 07/13/2006 08:37 AM > > > > Please respond to > > MQSeries List <MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT> > > > > To > > > > MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT > > > > cc > > > > Subject > > > > Re: Channel Table (AMQCLCHL.TAB) File > > > > > > > > > > Mark, > > > > Well, well, great minds think alike and all that. As you may have seen > from > > an append a week or two ago I am in the middle of adding this type of > > support to my MO72 SupportPac. > > > > As you know I'm sure, we can't publish the format of this file nor are we > > supposed to encourage reverse engineering. It's not that we're trying to > be > > unhelpful it's the concern that you might expend considerable effort > > getting your code working and then in the following release we go and > > change the file format on you, causing your application to abend. > > > > However, just between you and me, as I'm sure you've discovered the file > > consists of a number of 'records'. Each of these records has a header > which > > is the length of the record and the length of data within that record. In > > some cases the length of the data is 0 - indicating that although there > is > > space in the file at this point there is no actual data. This can happen > > when a records length increases. For example, suppose you defined a > channel > > X and then did an alter channel to add some channel exits or whatever. > The > > definition of channel X is now longer and will no longer fit in the file > at > > the point where it was. So, a new record is written and the old one is > > marked as length 0. We don't set the whole record to NULLs or whatever > just > > because there's no real point. So, if you just look a the file with an > > editor it can look like the record is in there multiple times. > > > > Anyway, as I said, I am planning to put this kind of support into MO72, > > hopefully in the next couple of weeks. If you decide to continue with > your > > own application then feel free to contact me if you get stuck. > > > > Cheers, > > P. > > > > Paul G Clarke > > WebSphere Messaging Clients > > IBM Hursley > > > > MQSeries List <MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT> wrote on 12/07/2006 > > 23:30:10: > > > > > > > > I have a small Java utility that reads an AMQCLCHL.TAB file and > > > dumps the contents out in RUNMQSC format. It doesn't handle the > > > SSLPEER, Send Exit and Receive Exit information yet--I'm still > > > trying to figure out how they are referenced in the channel table > > > file. Don't suppose IBM would like the save me some time and share > > > the internal structure :-) > > > > > > I'll make it available for download off the web in due course, but > > > until then if anyone wants a copy, feel free to email me. > > > > > > PS. While using it internally I came across something odd. While > > > testing on a Linux MQ V6 system I added several client channels > > > through MQ Explorer, then updated one of them twice, saving changes > > > each time. I found I had three entries in the channel table with the > > > same name, one for each of the changes I made. IBM--possible bug? > > > > > > Mark Durman > > > MQ Solutions LLC Instructions for managing your mailing list > > > subscription are provided in the Listserv General Users Guide available > > at > > > http://www.lsoft.com > > > > > > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > > > Instructions for managing your mailing list subscription are provided in > > the Listserv General Users Guide available at http://www.lsoft.com > > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > > > Instructions for managing your mailing list subscription are > > provided in the Listserv General Users Guide available at > http://www.lsoft.com > > > > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > > Instructions for managing your mailing list subscription are > provided in the Listserv General Users Guide available at http://www.lsoft.com > > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
