I think STOP CONN should do the trick! First you have to find out the connection with "DIS CONN(*) CHANNEL".
Hubert > -----Ursprüngliche Nachricht----- > Von: MQSeries List <[email protected]> > Gesendet: 06.02.08 22:10:19 > An: [email protected] > Betreff: Re: Wish List for the next version of MQ > They are all good. My favorite is the last one: > > > > V. > I would like to be able to stop one particular instance of a named SVRCONN > channel without affecting the others. > > > ----------------------------------------------------------------- > From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M > (ISD, IT) > Sent: Wednesday, February 06, 2008 4:01 PM > To: [email protected] > Subject: Wish List for the next version of MQ > > > > > This thread is surprisingly quiet on MQSeries.net. Does MQ 6.0 have > everything we need or want? When we had a similar one back in 2004 ahead of > MQ 6.0 there was a lot more discussion. > > > http://www.mqseries.net/phpBB2/viewtopic.php?t=41688 > > > Here is a copy of that thread for this audience. I'm curious on your > thoughts. > > > So its been a couple of years since MQ 6.0 came out, and I assume the next > version is coming soon. > > > Here is the thread we had back when MQ 6.0 was our future: > http://www.mqseries.net/phpBB2/viewtopic.php?t=19331&postdays=0&postorder=asc&start=0&sid=e90190e9d1da5b59f8989f9d7d7dc65b > > > > Below are some of the more interesting suggestions from back then, along with > some new ones. > > > Please add on your own. > > > Hopefully the powers that be see this. If just one idea gets implemented, "it > will all be worthwhile." :-D > > > A. > Quote: > 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. > > > > > > Yeah, they are samples and you can recompile them to make the buffer bigger, > but come on, 200 bytes? > > > > B. > Quote: > 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. > > > > > > Yeah, this needs to be done like the new clustering and monitoring > attributes, where you can turn it off, set it at the q level or have it > reference the QM level setting. > > > > C. > Quote: > 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. > > > > > > Same sentiments as in 2004. The APP knows if the message needs to be > persistent or not, so they should code for it. They don't default for the Qs > default Expiry, they don't default for the Qs default Format, they don't > default for Queue name. Let them take responsability for it. Let their be a > default in the MQMD, and thats it. Same for Prioroity. > > > The only reason I see for this attribute is if some app needs persistent > messages one day, and then NP another day, and rather than coding changes, > the q can be changed. > > > Alas, I think we are stuck with it, because there are probably millions of > apps out there that did code as Q default, and the new version can't break > them. > > > > D. > Quote: > 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... > > > > > > Still a valid idea. > > > > E. > Quote: > 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. > > > > > > > > F. > Quote: > 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). > > > > > > > > G. > Quote: > 2. A way to know what CSD you have on a remote QM thru MQExplorer, or MO71. > > > > I don't want to have to log onto a remote MQ server just to get the full MQ > version. > > > > H. > Quote: > 4. Configuration Events for ALL platforms. Why can't MQ track changes to > itself? > > > > SOX. Ugh. Help us deal with SOX. > > > > I. > Quote: > 5. Official support for MO71. If Paul hits the lottery, who is gonna support > MO71? > > > > MO71 continues to impove. Amazing what's being given away for free. > > > > J. > Quote: > 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. > > > > > > Even if the q is open Exclusivly. An MQ Admin should have total and absolute > power. If I want to clear the queue, let me. I suppose you could make > SYSTEM.* queues above and beyond this power to prevent dopey MQ Admins from > shooting themselves in the foot. > > > > K. > Quote: > 7. Make Expiry Interval available for all platforms, and at the Q level. > > > > OK, its a big improvement to have that behind the scenes Expiry Scavenger in > MQ 6.0. That's probably good enough. > > > > L. > Quote: > 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. > > > > > > We now rely on Roger's excellent MQAUSX. And even though it would make > Roger's product a little less valuable I think even he would agree this > feature needs to be in the base product. > > > M. > Quote: > 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). > > > . > . > . > OK, maybe "security hole" is the wrong term. > > > I too configure all my QMs with scripts that fix all this. But really, why in > the world in the absence of a valid ID, would a product default to the most > powerful one?!?!? If an ID is not presented, fail! > > > Knock, knock? > Who's there? > Who's there?...You won't give me your name or show your face? OK! Here are > the keys to my house and my car, my SSN, and a list of all my bank accounts. > > > In today's world of heightened security, defaulting to a super user when no > user is presented is inexcusable. > > > > > > > Plus a couple of new ones since that 2004 post.... > > > N. > There should be a way for an MQ Admin to look at a Client Connection from the > Queue Manager side and tell via Channel Status what the exact MQ version is > of that client. I want to be able to easily identify obsolete clients so we > can go after them. This was a nightmare: > > > http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg21223536 > > > O. > Trigger Type = Group. Don't trigger me until the entire group of messages is > ready to be picked up. I think this might be used more often than Every. > > > P. > Don't change the name of MQ again. > > > Q. > http://www.mqseries.net/phpBB2/viewtopic.php?t=41507&highlight=java+jar > This needs to be settled once and far all. Of course I think my line of > thinking is correct! > > > R. > It would be nice if Media Recovery was provided by a seperate set of logs, > and then Circular Logs could handle the OUW stuff. I still don't understand > why I have to use Linear Logs to get media recovery in the very rare cases an > object becomes damaged. There's probably a million things going on beneath > the covers I'm sure. But if X gigs of data spread across some linear logs can > handle UOW and Media Recovery, why can't the same x Gigs spread across > Circular? > > > S. > Its time for the AMQERROR logs to be made bigger or be able to keep more than > only 3. Yeah yeah, but I don't want to write a script. > > > T. > Clustering - QMA, QMB and QMC are in a cluster, so is QMGateway that load > balances all the work. QMA and QMB host QueueAB. QMB and QMC host QueueBC. > Start sending one message a minute to QueueAB. They load balance. Nice. They > start sending one message to QueueBC every second. They load balance. But the > gateway starts sending all QueueAB traffic to QMA only, because it sees the > channel to QMB is more heavily used. I would like clustering to maintaing its > load balancing for AppAB regardless of what's going on with App BC. > > > U. > I wish MQ would handle port scanners better. I'm tired of the FDCs. The > security team wont stop scanning that server (faces the DMZ) and say the > software (MQ) should be able to handle a port scan. I have to agree with them. > > > V. > I would like to be able to stop one particular instance of a named SVRCONN > channel without affecting the others. > > > > > > Peter Potkay > > ************************************************************************* > This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the intended > recipient, any use, copying, disclosure, dissemination or distribution is > strictly prohibited. If you are not the intended recipient, please notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > ************************************************************************* > > > ----------------------------------------------------------------- > List Archive - Manage Your List Settings - Unsubscribe > > > Instructions for managing your mailing list subscription are provided in the > Listserv General Users Guide available at http://www.lsoft.com > > **** For your information: KeySpan is now part of National Grid.**** > > > > ******************************************************************************** > This e-mail and any files transmitted with it, are confidential to National > Grid and are intended solely for the use of the individual or entity to whom > they are addressed. If you have received this e-mail in error, please reply > to this message and let the sender know. > -- Hubert Kleinmanns Beratung / Schulung / Projektleitung Chairman der WG "WebSphere MQ and Business Integration" in der GSE, deutsche Region. Tel.: +49 (0) 60 78 / 7 12 21 Fax: +49 (0) 60 78 / 7 12 25 Mobil: +49 (0) 178 / 6 97 22 54 Web: www.kleinmanns.eu GSE: www.gsenet.de To unsubscribe, write to [EMAIL PROTECTED] and, in the message body (not the subject), write: SIGNOFF MQSERIES 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
