Re: Problem with clearing open connections on a queue
You can check the "status" of the queue and find the process that have the queue open. Then you can kill that process using the PID. Regards, Ruzi -Original Message-From: Mittal, Gaurav [mailto:[EMAIL PROTECTED]Sent: Thursday, August 05, 2004 11:31 AMTo: [EMAIL PROTECTED]Subject: Problem with clearing open connections on a queueDoes any one know how to refresh/stop all the connections to a queue.The problem we are facing is that one of the subscriber queue is showingOpen Input Count as 1 and when we try to start the subscriberapplication we get an error JMS2008 failed to open queue. The linkedexception is 2042-Object in use.To release this we tried the following:* Check if any old subscriber process is running, which isconnected to the queue.* Stopped and restarted the svr connection channel on the queuemanager* Stopped and restarted the message flow.We are not able to figure out what else could be blocking the queue andhow can we release this lock from the queue(with recyling the queuemanager).Any help will be useful.RegardsGaurav Mittal___EAI ConsultantWipro Technologies(612)-291-4551 (W)Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archiveThis communication, including attachments, is for the exclusive use ofaddressee and may contain proprietary, confidential or privilegedinformation. If you are not the intended recipient, any use, copying,disclosure, dissemination or distribution is strictly prohibited. Ifyou are not the intended recipient, please notify the senderimmediately by return email and delete this communication and destroy all copies.Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive
Problem with clearing open connections on a queue
Does any one know how to refresh/stop all the connections to a queue. The problem we are facing is that one of the subscriber queue is showing Open Input Count as 1 and when we try to start the subscriber application we get an error JMS2008 failed to open queue. The linked exception is 2042-Object in use. To release this we tried the following: * Check if any old subscriber process is running, which is connected to the queue. * Stopped and restarted the svr connection channel on the queue manager * Stopped and restarted the message flow. We are not able to figure out what else could be blocking the queue and how can we release this lock from the queue(with recyling the queue manager). Any help will be useful. Regards Gaurav Mittal ___ EAI Consultant Wipro Technologies (612)-291-4551 (W) Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Problem with clearing open connections on a queue
You could use the QueueStat SC command and get the PID of the process and Kill it. bobbee From: Mittal, Gaurav [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Problem with clearing open connections on a queue Date: Thu, 5 Aug 2004 10:30:42 -0500 Does any one know how to refresh/stop all the connections to a queue. The problem we are facing is that one of the subscriber queue is showing Open Input Count as 1 and when we try to start the subscriber application we get an error JMS2008 failed to open queue. The linked exception is 2042-Object in use. To release this we tried the following: * Check if any old subscriber process is running, which is connected to the queue. * Stopped and restarted the svr connection channel on the queue manager * Stopped and restarted the message flow. We are not able to figure out what else could be blocking the queue and how can we release this lock from the queue(with recyling the queue manager). Any help will be useful. Regards Gaurav Mittal ___ EAI Consultant Wipro Technologies (612)-291-4551 (W) Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ Express yourself instantly with MSN Messenger! Download today - it's FREE! hthttp://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Problem with clearing open connections on a queue
Some app has the queue OPEN_INPUT_EXCLUSIVE. You could try GET_INHIBITING the queue to cause that app to fail on its outstanding GET with WAIT. Of course there is no guarantee that its not in a tight loop and it will just grab the queue again as soon as you GET_ENABLE it. And there is the chance that the app simply MQOPENed the queue, but did not have a GET with WAIT on it, in which case you would still be stuck. Do a Queue Usage command against the queue to get details of what has the queue open. -Original Message- From: Mittal, Gaurav [mailto:[EMAIL PROTECTED] Sent: Thursday, August 05, 2004 11:31 AM To: [EMAIL PROTECTED] Subject: Problem with clearing open connections on a queue Does any one know how to refresh/stop all the connections to a queue. The problem we are facing is that one of the subscriber queue is showing Open Input Count as 1 and when we try to start the subscriber application we get an error JMS2008 failed to open queue. The linked exception is 2042-Object in use. To release this we tried the following: * Check if any old subscriber process is running, which is connected to the queue. * Stopped and restarted the svr connection channel on the queue manager * Stopped and restarted the message flow. We are not able to figure out what else could be blocking the queue and how can we release this lock from the queue(with recyling the queue manager). Any help will be useful. Regards Gaurav Mittal ___ EAI Consultant Wipro Technologies (612)-291-4551 (W) Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential 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 email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Automated re-establishment of channel connections [Deutsche Boerse Systems:Virus checked]
Mike, check the ADOPTMCA settings. Regards, Stefan Mike Kenny - BCX - Infrastructure Services [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 14.06.2004 12:18 Please respond to MQSeries List To:[EMAIL PROTECTED] cc:(bcc: Stefan Raabe/DBS/GDB) Subject:Automated re-establishment of channel connections [Deutsche Boerse Systems:Virus checked] . Our situation is that we have many Q managers distributed over a WAN. On occasion we will lose a network connection. Normally when the n/w is back up the channels will ultimately re-connect. However, sometimes the receiver does not recognize that the n/w had a problem. When this happens, it will reject all efforts by the sender to create a connection. We must then manually stop and start the receiver to allow the sender to connect. I thought that the idea of MQ was to provide resilience against n/w failures without the necessity of manual intervention. This being the case, I have obviously got something messed up in my configuration. Any ideas on what this could be? Kind Regards, Mike Kenny Principal Consultant Professional Services Business Connexion (Pty) Ltd Office: +27 (0)11 266 5703 Mobile: +27 (0)83 266 1437 Fax: +27 (0)11 266 5769 Email: [EMAIL PROTECTED] Web Site: www.bcx.co.za NOTICES: 1. This message and any attachments are confidential and intended solely for the addressee. If you have received this message in error, please notify the sender at Business Connexion (Pty) Ltd immediately. Any unauthorised use, alteration or dissemination is prohibited. 2. Business Connexion (Pty) Ltd accepts no liability whatsoever for any loss whether it be direct, indirect or consequential, arising from information made available and actions resulting there from. 3. Please note that Business Connexion only binds itself by way of signed agreements. 'Signed' refers to a hand-written signature, excluding any signature appended by 'electronic communication' as defined in the Electronic Communications and Transactions Act, no. 25 of 2002. 4. Directors: P.A. Watt, B. Mophatlane, A.C. Farthing (British), B. Sithole, I. Mophatlane, M.W. Schoeman. 5. Business Connexion (Pty) Ltd Company Registration Number: 1993/003683/07. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive --Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen.Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bittesofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet.The information contained in this message is confidential or protected bylaw. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited.
Re: Automated re-establishment of channel connections
Thanks Rob and Somesh. The AdoptNewMCA looks like what I am looking for. Mike -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Monday, June 14, 2004 1:25 PM To: [EMAIL PROTECTED] Subject: Re: Automated re-establishment of channel connections The AdoptNewMCA stanza of the QM.ini file addresses this. See: http://www-306.ibm.com/software/integration/mqfamily/library/m anualsa/amqzag /amqzag2j.htm#HDRAMQ521U http://www-306.ibm.com/software/integration/mqfamily/library/m anualsa/csqzae 05/csqzae0578.htm -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Mike Kenny - BCX - Infrastructure Services Sent: Monday, June 14, 2004 6:19 AM To: [EMAIL PROTECTED] Subject: Automated re-establishment of channel connections Our situation is that we have many Q managers distributed over a WAN. On occasion we will lose a network connection. Normally when the n/w is back up the channels will ultimately re-connect. However, sometimes the receiver does not recognize that the n/w had a problem. When this happens, it will reject all efforts by the sender to create a connection. We must then manually stop and start the receiver to allow the sender to connect. I thought that the idea of MQ was to provide resilience against n/w failures without the necessity of manual intervention. This being the case, I have obviously got something messed up in my configuration. Any ideas on what this could be? Kind Regards, Mike Kenny Principal Consultant Professional Services Business Connexion (Pty) Ltd Office: +27 (0)11 266 5703 Mobile: +27 (0)83 266 1437 Fax: +27 (0)11 266 5769 Email: [EMAIL PROTECTED] Web Site: www.bcx.co.za NOTICES: 1. This message and any attachments are confidential and intended solely for the addressee. If you have received this message in error, please notify the sender at Business Connexion (Pty) Ltd immediately. Any unauthorised use, alteration or dissemination is prohibited. 2. Business Connexion (Pty) Ltd accepts no liability whatsoever for any loss whether it be direct, indirect or consequential, arising from information made available and actions resulting there from. 3. Please note that Business Connexion only binds itself by way of signed agreements. 'Signed' refers to a hand-written signature, excluding any signature appended by 'electronic communication' as defined in the Electronic Communications and Transactions Act, no. 25 of 2002. 4. Directors: P.A. Watt, B. Mophatlane, A.C. Farthing (British), B. Sithole, I. Mophatlane, M.W. Schoeman. 5. Business Connexion (Pty) Ltd Company Registration Number: 1993/003683/07. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Automated re-establishment of channel connections
Our situation is that we have many Q managers distributed over a WAN. On occasion we will lose a network connection. Normally when the n/w is back up the channels will ultimately re-connect. However, sometimes the receiver does not recognize that the n/w had a problem. When this happens, it will reject all efforts by the sender to create a connection. We must then manually stop and start the receiver to allow the sender to connect. I thought that the idea of MQ was to provide resilience against n/w failures without the necessity of manual intervention. This being the case, I have obviously got something messed up in my configuration. Any ideas on what this could be? Kind Regards, Mike Kenny Principal Consultant Professional Services Business Connexion (Pty) Ltd Office: +27 (0)11 266 5703 Mobile: +27 (0)83 266 1437 Fax: +27 (0)11 266 5769 Email: [EMAIL PROTECTED] Web Site: www.bcx.co.za NOTICES: 1. This message and any attachments are confidential and intended solely for the addressee. If you have received this message in error, please notify the sender at Business Connexion (Pty) Ltd immediately. Any unauthorised use, alteration or dissemination is prohibited. 2. Business Connexion (Pty) Ltd accepts no liability whatsoever for any loss whether it be direct, indirect or consequential, arising from information made available and actions resulting there from. 3. Please note that Business Connexion only binds itself by way of signed agreements. 'Signed' refers to a hand-written signature, excluding any signature appended by 'electronic communication' as defined in the Electronic Communications and Transactions Act, no. 25 of 2002. 4. Directors: P.A. Watt, B. Mophatlane, A.C. Farthing (British), B. Sithole, I. Mophatlane, M.W. Schoeman. 5. Business Connexion (Pty) Ltd Company Registration Number: 1993/003683/07. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Automated re-establishment of channel connections
Hi Mike, Could you please tell us the operating systems on which your queue managers are running especially the ones on which the receivers are not detecting the network failure. If these systems are running onOS/390 then there is a parameter which needs to be set to resolve this problem. The parameter is AdoptNewMCA = YES needs to be set. And the same way for distributed systems also. And the parameter is AdoptNewMCA = ALL needs to set on windows and check for the corresponding parameters on Unix systems ( as I am not sure the exact value of the parameters). Hope this helps. Regards, Somesh Mike Kenny - BCX - Infrastructure Services [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 06/14/2004 03:48 PM Please respond to MQSeries List To [EMAIL PROTECTED] cc Subject Automated re-establishment of channel connections Our situation is that we have many Q managers distributed over a WAN. On occasion we will lose a network connection. Normally when the n/w is back up the channels will ultimately re-connect. However, sometimes the receiver does not recognize that the n/w had a problem. When this happens, it will reject all efforts by the sender to create a connection. We must then manually stop and start the receiver to allow the sender to connect. I thought that the idea of MQ was to provide resilience against n/w failures without the necessity of manual intervention. This being the case, I have obviously got something messed up in my configuration. Any ideas on what this could be? Kind Regards, Mike Kenny Principal Consultant Professional Services Business Connexion (Pty) Ltd Office: +27 (0)11 266 5703 Mobile: +27 (0)83 266 1437 Fax: +27 (0)11 266 5769 Email: [EMAIL PROTECTED] Web Site: www.bcx.co.za NOTICES: 1. This message and any attachments are confidential and intended solely for the addressee. If you have received this message in error, please notify the sender at Business Connexion (Pty) Ltd immediately. Any unauthorised use, alteration or dissemination is prohibited. 2. Business Connexion (Pty) Ltd accepts no liability whatsoever for any loss whether it be direct, indirect or consequential, arising from information made available and actions resulting there from. 3. Please note that Business Connexion only binds itself by way of signed agreements. 'Signed' refers to a hand-written signature, excluding any signature appended by 'electronic communication' as defined in the Electronic Communications and Transactions Act, no. 25 of 2002. 4. Directors: P.A. Watt, B. Mophatlane, A.C. Farthing (British), B. Sithole, I. Mophatlane, M.W. Schoeman. 5. Business Connexion (Pty) Ltd Company Registration Number: 1993/003683/07. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Automated re-establishment of channel connections
The AdoptNewMCA stanza of the QM.ini file addresses this. See: http://www-306.ibm.com/software/integration/mqfamily/library/manualsa/amqzag /amqzag2j.htm#HDRAMQ521U http://www-306.ibm.com/software/integration/mqfamily/library/manualsa/csqzae 05/csqzae0578.htm -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Mike Kenny - BCX - Infrastructure Services Sent: Monday, June 14, 2004 6:19 AM To: [EMAIL PROTECTED] Subject: Automated re-establishment of channel connections Our situation is that we have many Q managers distributed over a WAN. On occasion we will lose a network connection. Normally when the n/w is back up the channels will ultimately re-connect. However, sometimes the receiver does not recognize that the n/w had a problem. When this happens, it will reject all efforts by the sender to create a connection. We must then manually stop and start the receiver to allow the sender to connect. I thought that the idea of MQ was to provide resilience against n/w failures without the necessity of manual intervention. This being the case, I have obviously got something messed up in my configuration. Any ideas on what this could be? Kind Regards, Mike Kenny Principal Consultant Professional Services Business Connexion (Pty) Ltd Office: +27 (0)11 266 5703 Mobile: +27 (0)83 266 1437 Fax: +27 (0)11 266 5769 Email: [EMAIL PROTECTED] Web Site: www.bcx.co.za NOTICES: 1. This message and any attachments are confidential and intended solely for the addressee. If you have received this message in error, please notify the sender at Business Connexion (Pty) Ltd immediately. Any unauthorised use, alteration or dissemination is prohibited. 2. Business Connexion (Pty) Ltd accepts no liability whatsoever for any loss whether it be direct, indirect or consequential, arising from information made available and actions resulting there from. 3. Please note that Business Connexion only binds itself by way of signed agreements. 'Signed' refers to a hand-written signature, excluding any signature appended by 'electronic communication' as defined in the Electronic Communications and Transactions Act, no. 25 of 2002. 4. Directors: P.A. Watt, B. Mophatlane, A.C. Farthing (British), B. Sithole, I. Mophatlane, M.W. Schoeman. 5. Business Connexion (Pty) Ltd Company Registration Number: 1993/003683/07. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
QPasa! - client connections
Before acting on this e-mail or opening any attachment, you are advised to read the disclaimer at the end of this mail. Hi, Does QPasa! use client connections to do any of its processing? Does it use the command server? (I am looking to eliminate/prevent client connections on a queue manager.) Thanks in advance, Pat ** This e-mail is intended solely for the addressee and is strictly confidential. If you are not the addressee, please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead please e-mail it back to the sender and delete the message from your computer. E-mail transmission cannot be guaranteed to be secure or error free and The Co-operative Bank accepts no liability for changes made to this e-mail (and any attachments) after it was sent or for viruses arising as a result of this e-mail transmission. Any unauthorised reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message is strictly prohibited. The Co-operative Bank reserves the right to intercept any e - mails or other communication for permitted purposes in accordance with the current legislation which you send to, or receive from, any of the employees or agents of the Bank via Bank telecommunication systems. By so corresponding you also give your consent to the Bank monitoring and recording of any correspondence using these systems. The Co-operative Bank p.l.c. is registered in England and Wales, number 990937. The registered office is at PO Box 101, 1, Balloon Street, Manchester, M60 4EP. ** Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: How many concurrent client channel connections do you run to a si ngle queue manger?
Matt, In my experience this was limited by memory. Each connection takes a certain amount and your basic limit was the box memory. Ross Stephens +61 (2) 9410 9930 +61 (419) 494 489 [EMAIL PROTECTED] www.mqis.com.au -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Gurney, Matthew Sent: Thursday, 25 March 2004 7:48 PM To: [EMAIL PROTECTED] Subject: How many concurrent client channel connections do you run to a si ngle queue manger? We have an application where 100 applications each running on their own W2K server have a client connection to the same single queue manager and all 100 applications are in a get-wait state on the same queue. The queue manager is hosted on W2K and is currently 5.2 we have a requirement to increase the number of applications connected to that queue from 100 to 1000. MQ will be upgraded to 5.3 for this change. I am concerned as to what the useable connection limit may be, before the queue manager become unstable or performance degrades significantly. I am aware of the various soft limits that need to be adjusted (max handles, max channels, max active channels etc etc). What I am interested from the list is some real world examples of large numbers of mq clients connected to the same queue manager, and if applicable, the same queue. I have read the relevant Performance Evaluation support pacs on this issue. So my question is, what is the highest number of concurrent client channel connections that you run to a single queue manger? Thanks, Matt == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. == Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Many Client connections - how many svrconn channels?
Hi Sid, Yes, I'll put your changes into the code, no problem. I thinks it's a good idea just to keep one version of BlockIP/BlockIP2 so we allways know how to solve problems, and not have to deal with at lot of cousins. Just send me the code, and I'll review the code before release. Kind regards Jxrgen www.mrmq.dk the author of BlockIP From: [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? Date: Mon, 22 Mar 2004 11:26:44 +1000 Jxrgen, I need to make some changes to BlockIP2 for logging of information, the logs grow way to big on my systems and I need then stamped by date: ie BlockLog_2004_03_22.log I also need to be able to specify a log directory, so I was going to add the following commands: # on NT systems LogDirecty=\qml\log LogDrive=c: LogFormat=NameDate LogBaseName=BlockLog # on Linux systems LogDirecty=/var/spool/blockip2/logs LogFormat=NameDate LogBaseName=BlockLog On the linux the LogDrive would be ignored and just the LogDirectory would be applicable using /s If I make the changes, are you happy to add them into your code for the benefit of the community as a whole, or would you prefer me to start my own stream of BlockIP ??? Sid Young QML Pathology Brisbane _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Many Client connections - how many svrconn channels?
I just updated BlockIP2 so it might help Ruzi R with some of the security
challanges.
It's quite simple what can be done, su}ntax of the new CON parameter:
CON=conname;userids[;MCA={*|userid}];
and an example of parameter file
#
# Simple filter implemented in BlockIP2 version 1.22
#
# 1. stop all connection attempts from mqm (NoBody is an undefined or
blocked userid).
CON=*;mqm;MCA=NoBody;
#
# 2. Stop users starting with ww14 from 10.31.* Might be a foregin network
CON=10.31.*;ww14*;MCA=NoBody;
#
# 3. Allow master03 wjen comming from 172.20.10.31
CON=172.20.10.31;master03;
#
# 4. Allow spider when comming from 10.*, and set MCAUSER to master04
CON=10.*;spider;MCA=master04;
#
# 5. Block all other attempts.
CON=*;*;MCA=NoBody;
# EOF
Just my $0.02 ;o)
Kind regards
Jxrgen
www.mrmq.dk
the author of BlockIP
_
Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Many Client connections - how many svrconn channels?
Jxrgen,
I need to make some changes to BlockIP2 for logging of information, the logs
grow way to big on my systems and I need then stamped by date:
ie BlockLog_2004_03_22.log
I also need to be able to specify a log directory, so I was going to add the
following commands:
# on NT systems
LogDirecty=\qml\log
LogDrive=c:
LogFormat=NameDate
LogBaseName=BlockLog
# on Linux systems
LogDirecty=/var/spool/blockip2/logs
LogFormat=NameDate
LogBaseName=BlockLog
On the linux the LogDrive would be ignored and just the LogDirectory would
be applicable using /s
If I make the changes, are you happy to add them into your code for the
benefit of the community as a whole, or would you prefer me to start my own
stream of BlockIP ???
Sid Young
QML Pathology
Brisbane
-Original Message-
From: Jxrgen Pedersen [mailto:[EMAIL PROTECTED]
Sent: Monday, 22 March 2004 9:44 AM
To: [EMAIL PROTECTED]
Subject: Re: Many Client connections - how many svrconn channels?
I just updated BlockIP2 so it might help Ruzi R with some of the security
challanges.
It's quite simple what can be done, su}ntax of the new CON parameter:
CON=conname;userids[;MCA={*|userid}];
and an example of parameter file
#
# Simple filter implemented in BlockIP2 version 1.22
#
# 1. stop all connection attempts from mqm (NoBody is an undefined or
blocked userid).
CON=*;mqm;MCA=NoBody;
#
# 2. Stop users starting with ww14 from 10.31.* Might be a foregin network
CON=10.31.*;ww14*;MCA=NoBody;
#
# 3. Allow master03 wjen comming from 172.20.10.31
CON=172.20.10.31;master03;
#
# 4. Allow spider when comming from 10.*, and set MCAUSER to master04
CON=10.*;spider;MCA=master04;
#
# 5. Block all other attempts.
CON=*;*;MCA=NoBody;
# EOF
Just my $0.02 ;o)
Kind regards
Jxrgen
www.mrmq.dk
the author of BlockIP
_
Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: JMS resource problems after 254 'connections' ?
Hi Peter, Yes, you can find out the num of connections from the CHSATUS of the SVRCONN. Since your environment sounds like mine, I have 2 unrelated questions for you: 1-PS apps are running in a client mode on the server. I would like to change it the TRANSPORT(BIND) in the bindings file. However, the people working as middleman between us and PS are saying that PS wants to run in CLIENT mode. I don t understand why. I have never been able to get a reason for this. DO you know why they want to run as a client app? 2-Apparently, PS default message size is 15 MB that they use between their internal programs. They have one interface in which they put 15 MB messages on the queue despite the fact that I repeatedly asked them to make the messages shorter (for obvious reasons) by using various techniques. They have been reluctant to do this as they claim that, since WMQ can handle 100 MB they are only using 15% of the capacity, what is the big deal etc etc.. There have been problems with this big messages in Prod. I had to increase the number of log files (circular) to the max. LogFileSize is still at 512. (When I have a chance I am going to change to linear and increase the LogFileSize to 16384). My question is: During our conversations, a person using the PS Handler mentioned that it is faster to send 15 MB messages than many smaller messages. I think he based his assumption based on another interface which takes about 10-30 sec to Put a 32 K message. He demonstrated it to me. Since this is not happening in other interfaces, I assume it has something to do with the app. Have you been aware of this ? If so, what was the problem? Thanks, Ruzi --- Heggie, Peter [EMAIL PROTECTED] wrote: Thanks Ruzi, We are going to increase MAXHANDS for now. I just got off the phone with our PeopleSoft administrators and they discovered late last night that PeopleSoft/JMS code never lets go of these handles. They modified some of the PS JMS classes to force the release of the connections and the problem disappeared. They are pursuing the issue with PS to get an approved fix. Is it correct to say that each of these handles is associated with a SVRCONN channel connection, and that I can display the CHSTATUS to see the open handles? So counting the number of connections would give me the number of handles and confirm the problem. We could run 254 of these synchronous requests and we should see the 254 open connections in the display. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Ruzi R Sent: Thursday, March 18, 2004 4:00 PM To: [EMAIL PROTECTED] Subject: Re: JMS resource problems after 254 'connections' ? Hi Peter, We had the same problem with PeopleSoft/JMS. We increased MAXHANDS to 512 about a year ago, and we have never had this problem again since then. Ruzi --- Heggie, Peter [EMAIL PROTECTED] wrote: More information - the source of the '254' connections is the MQ queue manager MAXHANDS attribute. When we raised it, we immediately were able to run more transactions before encountering exceptions. The new number we could run exactly matched the new MAXHANDS value, minus 2. We tried explicitly closing the temporary queues as soon as we received the reply on them, but we still encountered exceptions (in PeopleSoft) after the limit was reached. From a distance, it looks like PeopleSoft's implementation of JMS is not releasing the queue handles. We will try to test more with a much higher limit, and see if the higher limit allows more time for requests to complete and release enough queue handles to stay below the limit. I'm hoping we will find some kind of JMS configuration parameter that has been set incorrectly which can release handles quickly. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T. Rob Sent: Wednesday, March 17, 2004 11:01 AM To: [EMAIL PROTECTED] Subject: Re: JMS resource problems after 254 'connections' ? Peter, I agree that the number sounds suspicious. Especially in relation to messages as opposed to connections. It suggests the app is making a new connection for each message and not releasing them. Have you checked for that? Alternatively, what kind of logging are you using and are all the messages in a single unit of work? -- T.Rob -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 10:05 AM To: [EMAIL PROTECTED] Subject: JMS resource problems after 254 'connections' ? Has anyone encountered a problem with a MQ to JMS environment, where a synchronous transfer (request/reply) encounters a 'Resouce Exception' after 245 reply messages are processed? We have an MQ to PeopleSoft environment where we send messages from an MQ application
Re: JMS resource problems after 254 'connections' ?
Hi Ruzi, I have one answer for you - PS requires CLIENT mode because of their architecture requirements, which allow for the components to run on separate machines, if the customer desires to split the components. We have them running on separate servers.. So far, no one here has heard about a 15M message size requirement/standard. I'll post again if I hear any more about it. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Ruzi R Sent: Friday, March 19, 2004 8:13 AM To: [EMAIL PROTECTED] Subject: Re: JMS resource problems after 254 'connections' ? Hi Peter, Yes, you can find out the num of connections from the CHSATUS of the SVRCONN. Since your environment sounds like mine, I have 2 unrelated questions for you: 1-PS apps are running in a client mode on the server. I would like to change it the TRANSPORT(BIND) in the bindings file. However, the people working as middleman between us and PS are saying that PS wants to run in CLIENT mode. I don t understand why. I have never been able to get a reason for this. DO you know why they want to run as a client app? 2-Apparently, PS default message size is 15 MB that they use between their internal programs. They have one interface in which they put 15 MB messages on the queue despite the fact that I repeatedly asked them to make the messages shorter (for obvious reasons) by using various techniques. They have been reluctant to do this as they claim that, since WMQ can handle 100 MB they are only using 15% of the capacity, what is the big deal etc etc.. There have been problems with this big messages in Prod. I had to increase the number of log files (circular) to the max. LogFileSize is still at 512. (When I have a chance I am going to change to linear and increase the LogFileSize to 16384). My question is: During our conversations, a person using the PS Handler mentioned that it is faster to send 15 MB messages than many smaller messages. I think he based his assumption based on another interface which takes about 10-30 sec to Put a 32 K message. He demonstrated it to me. Since this is not happening in other interfaces, I assume it has something to do with the app. Have you been aware of this ? If so, what was the problem? Thanks, Ruzi --- Heggie, Peter [EMAIL PROTECTED] wrote: Thanks Ruzi, We are going to increase MAXHANDS for now. I just got off the phone with our PeopleSoft administrators and they discovered late last night that PeopleSoft/JMS code never lets go of these handles. They modified some of the PS JMS classes to force the release of the connections and the problem disappeared. They are pursuing the issue with PS to get an approved fix. Is it correct to say that each of these handles is associated with a SVRCONN channel connection, and that I can display the CHSTATUS to see the open handles? So counting the number of connections would give me the number of handles and confirm the problem. We could run 254 of these synchronous requests and we should see the 254 open connections in the display. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Ruzi R Sent: Thursday, March 18, 2004 4:00 PM To: [EMAIL PROTECTED] Subject: Re: JMS resource problems after 254 'connections' ? Hi Peter, We had the same problem with PeopleSoft/JMS. We increased MAXHANDS to 512 about a year ago, and we have never had this problem again since then. Ruzi --- Heggie, Peter [EMAIL PROTECTED] wrote: More information - the source of the '254' connections is the MQ queue manager MAXHANDS attribute. When we raised it, we immediately were able to run more transactions before encountering exceptions. The new number we could run exactly matched the new MAXHANDS value, minus 2. We tried explicitly closing the temporary queues as soon as we received the reply on them, but we still encountered exceptions (in PeopleSoft) after the limit was reached. From a distance, it looks like PeopleSoft's implementation of JMS is not releasing the queue handles. We will try to test more with a much higher limit, and see if the higher limit allows more time for requests to complete and release enough queue handles to stay below the limit. I'm hoping we will find some kind of JMS configuration parameter that has been set incorrectly which can release handles quickly. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T. Rob Sent: Wednesday, March 17, 2004 11:01 AM To: [EMAIL PROTECTED] Subject: Re: JMS resource problems after 254 'connections' ? Peter, I agree that the number sounds suspicious. Especially in relation to messages as opposed to connections. It suggests the app is making a new connection for each message and not releasing them. Have you checked
Re: MQ Client Connections
Title: MQ Client Connections I know this is an old thread but have an interesting corollary scenario. My QMgrs are backedby HA software, thus a QMgr'sIP address(es) and Listener process(es) are linked to VIP address(es). If the QMgr is down there is a good chance the VIP address is not attached to a NIC andunknown within the network -- and all the stuff that means My problem is at the client level rather than the SVRCONN definition on the QMgr. Myinitial testing is with round-robin DNS. I amgetting a 2059 -- as expected -- when the QMgr is unavailable. However,itis taking aboutabout 4 minutesfor theMQ Client MQCONN call tofail. My guess is the network is attempting to locate the VIP address? The question is there a way to tune this failure at the clientto happenquicker. Additional Note... Thecacheing of the IP/Hostname isdisabled on the client. Thanks in advance, -B Brian Bumpass Wachovia Bank Enterprise Infrastructure [EMAIL PROTECTED] Phone - (704) 590-5620 Pager - (800) 425-2613 -Original Message-From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]Sent: Friday, April 18, 2003 5:01 PMTo: [EMAIL PROTECTED]Subject: Re: MQ Client Connections Once the KeepAlive interval passes, the QM should realize that there in nobody home on the other end of the SRVRCONN channel, and the orphaned instance should go away. Make sure KeepAlive is turned on to a reasonable value at the server level (it effects all TCP/IP apps, not just MQ), and then set the KeepAlive parameter to on at the QM level. And like Darren said, make sure the app always MQCLOSEs and MQDISCs (check all those try/catch blocks!) Transaction Vision is a cool tool that allows you to see what apps are really doing. Lots of times I was able to prove the app was doing XYZ when theyswear they were doing ABC by using this tool. (Among other things, it list all the MQ API calls any app executes, and gives the details on exactly how and when it did what MQ-wise) -Original Message-From: Darren Douch [mailto:[EMAIL PROTECTED]Sent: Friday, April 18, 2003 1:37 PMTo: [EMAIL PROTECTED]Subject: Re: MQ Client Connections Rich I may be corrected, but I don't think there is a way to get MQ to terminate the channels automatically from the server side. re: the problem app... it may do a nice MQDISC when it terminates cleanly... but what if it doesn't terminate cleanly - the designer / coder may have neglected proper cleanup in the 'bad' scenarios. Regards Darren. - Original Message - From: Garcia Rich (SYS1RXG) To: [EMAIL PROTECTED] Sent: Thursday, April 17, 2003 3:11 PM Subject: MQ Client Connections I am currently seeing an issue with MAX channels on one of my systems OS is not important, I understand that the fix for this would be add the MAXACTIVECHANNEL into the QM.ini stanza and increase the connections to something higher than the default of 100. I have spoken to the application which is connecting via a JVM Server, via the MQ client on the same system to ensure that they are performing a MQDISC and they of course say that ' they are '. Question: Is there a portion in the QM.ini stanza that will disconnect MQ Client connections after being idle for a certain length of time. If the application connecting refuses to make changes to their application I would like to perform the disconnects at the MQ Layer. I am seeing the following to give a better idea 1. Connection to HTTPSRV is made from the web. 2. HTTPSRV makes an internal client connection on the same machine to Loopback 127.0.0.1 and spawns a AMQCRSTA job. B. The application states that they perfom a MQ Close and DISC disconnect but I still see AMQCRSTA jobs in idle for more than 60 hrs. Any help woould be appreciated. Thank You Rich This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential 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 email and delete this communication and destroy all copies.
Re: MQ Client Connections
Brian, I think the first thing to do is find out exactly what the client is waiting for for 4 minutes (who would have thought there was a valid sentence with 'for' being used 3 times consecutively ?). I suggest you switch on MQ trace and try the connect again. Look at the tracefile and look at the timestamps to make sure it's the connect() verb and not some strange ldap or authority call that's delaying you. Cheers, P. Paul G Clarke WebSphere MQ Development |-+ | | Bumpass, Brian | | | [EMAIL PROTECTED]| | | CHOVIA.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 19/03/2004 16:37 | | | Please respond to| | | MQSeries List| |-+ -| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MQ Client Connections | | | | | -| I know this is an old thread but have an interesting corollary scenario. My QMgrs are backed by HA software, thus a QMgr's IP address(es) and Listener process(es) are linked to VIP address(es). If the QMgr is down there is a good chance the VIP address is not attached to a NIC and unknown within the network -- and all the stuff that means My problem is at the client level rather than the SVRCONN definition on the QMgr. My initial testing is with round-robin DNS. I am getting a 2059 -- as expected -- when the QMgr is unavailable. However, it is taking about about 4 minutes for the MQ Client MQCONN call to fail. My guess is the network is attempting to locate the VIP address? The question is there a way to tune this failure at the client to happen quicker. Additional Note... The cacheing of the IP/Hostname is disabled on the client. Thanks in advance, -B Brian Bumpass Wachovia Bank Enterprise Infrastructure [EMAIL PROTECTED] Phone - (704) 590-5620 Pager - (800) 425-2613 -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Friday, April 18, 2003 5:01 PM To: [EMAIL PROTECTED] Subject: Re: MQ Client Connections Once the KeepAlive interval passes, the QM should realize that there in nobody home on the other end of the SRVRCONN channel, and the orphaned instance should go away. Make sure KeepAlive is turned on to a reasonable value at the server level (it effects all TCP/IP apps, not just MQ), and then set the KeepAlive parameter to on at the QM level. And like Darren said, make sure the app always MQCLOSEs and MQDISCs (check all those try/catch blocks!) Transaction Vision is a cool tool that allows you to see what apps are really doing. Lots of times I was able to prove the app was doing XYZ when they swear they were doing ABC by using this tool. (Among other things, it list all the MQ API calls any app executes, and gives the details on exactly how and when it did what MQ-wise) -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Friday, April 18, 2003 1:37 PM To: [EMAIL PROTECTED] Subject: Re: MQ Client Connections Rich I may be corrected, but I don't think there is a way to get MQ to terminate the channels automatically from the server side. re: the problem app... it may do a nice MQDISC when it terminates cleanly... but what if it doesn't terminate cleanly - the designer / coder may have neglected proper cleanup in the 'bad' scenarios. Regards Darren. - Original Message - From: Garcia Rich (SYS1RXG) To: [EMAIL PROTECTED] Sent: Thursday, April 17, 2003 3:11 PM
Re: MQ Client Connections
Peter, I agree but what I'm saying is let's not guess. First find out exactly what we're waiting for and then work out how to tune it down. There are quite a number of areas in the client code where we 'could' spend some time; I've even seen pretty innocuous registry calls taking minutes to return. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Heggie, Peter | | | [EMAIL PROTECTED]| | | NGRID.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 19/03/2004 17:05 | | | Please respond to| | | MQSeries List| |-+ -| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MQ Client Connections | | | | | -| I have seen a network request take 4 minutes or a little longer to look for an name that is no longer there. Depends on your DNS setup. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Clarke Sent: Friday, March 19, 2004 11:53 AM To: [EMAIL PROTECTED] Subject: Re: MQ Client Connections Brian, I think the first thing to do is find out exactly what the client is waiting for for 4 minutes (who would have thought there was a valid sentence with 'for' being used 3 times consecutively ?). I suggest you switch on MQ trace and try the connect again. Look at the tracefile and look at the timestamps to make sure it's the connect() verb and not some strange ldap or authority call that's delaying you. Cheers, P. Paul G Clarke WebSphere MQ Development |-+ | | Bumpass, Brian | | | [EMAIL PROTECTED]| | | CHOVIA.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 19/03/2004 16:37 | | | Please respond to| | | MQSeries List| |-+ --- --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MQ Client Connections | | | | | --- --| I know this is an old thread but have an interesting corollary scenario. My QMgrs are backed by HA software, thus a QMgr's IP address(es) and Listener process(es) are linked to VIP address(es). If the QMgr is down there is a good chance the VIP address is not attached to a NIC and unknown within the network -- and all the stuff that means My problem is at the client level rather than the SVRCONN definition on the QMgr. My initial testing is with round-robin DNS. I am getting a 2059 -- as expected -- when the QMgr is unavailable. However, it is taking about about 4 minutes for the MQ Client MQCONN call to fail. My guess is the network is attempting to locate the VIP address? The question is there a way to tune this failure at the client to happen quicker. Additional Note... The cacheing of the IP/Hostname is disabled on the client. Thanks in advance, -B Brian Bumpass Wachovia Bank Enterprise Infrastructure [EMAIL PROTECTED] Phone - (704) 590-5620 Pager - (800) 425-2613 -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Friday, April 18, 2003 5:01 PM To: [EMAIL PROTECTED] Subject: Re: MQ Client Connections Once the KeepAlive interval passes, the QM should realize
Re: MQ Client Connections
Good idea.. sorry! Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Clarke Sent: Friday, March 19, 2004 12:35 PM To: [EMAIL PROTECTED] Subject: Re: MQ Client Connections Peter, I agree but what I'm saying is let's not guess. First find out exactly what we're waiting for and then work out how to tune it down. There are quite a number of areas in the client code where we 'could' spend some time; I've even seen pretty innocuous registry calls taking minutes to return. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Heggie, Peter | | | [EMAIL PROTECTED]| | | NGRID.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 19/03/2004 17:05 | | | Please respond to| | | MQSeries List| |-+ --- --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MQ Client Connections | | | | | --- --| I have seen a network request take 4 minutes or a little longer to look for an name that is no longer there. Depends on your DNS setup. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Clarke Sent: Friday, March 19, 2004 11:53 AM To: [EMAIL PROTECTED] Subject: Re: MQ Client Connections Brian, I think the first thing to do is find out exactly what the client is waiting for for 4 minutes (who would have thought there was a valid sentence with 'for' being used 3 times consecutively ?). I suggest you switch on MQ trace and try the connect again. Look at the tracefile and look at the timestamps to make sure it's the connect() verb and not some strange ldap or authority call that's delaying you. Cheers, P. Paul G Clarke WebSphere MQ Development |-+ | | Bumpass, Brian | | | [EMAIL PROTECTED]| | | CHOVIA.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 19/03/2004 16:37 | | | Please respond to| | | MQSeries List| |-+ --- --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MQ Client Connections | | | | | --- --| I know this is an old thread but have an interesting corollary scenario. My QMgrs are backed by HA software, thus a QMgr's IP address(es) and Listener process(es) are linked to VIP address(es). If the QMgr is down there is a good chance the VIP address is not attached to a NIC and unknown within the network -- and all the stuff that means My problem is at the client level rather than the SVRCONN definition on the QMgr. My initial testing is with round-robin DNS. I am getting a 2059 -- as expected -- when the QMgr is unavailable. However, it is taking about about 4 minutes for the MQ Client MQCONN call to fail. My guess is the network is attempting to locate the VIP address? The question is there a way to tune this failure at the client to happen quicker. Additional Note... The cacheing of the IP/Hostname is disabled on the client. Thanks in advance, -B Brian Bumpass Wachovia Bank Enterprise Infrastructure [EMAIL PROTECTED] Phone - (704) 590-5620 Pager - (800) 425-2613 -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Friday, April 18, 2003 5:01 PM To: [EMAIL PROTECTED] Subject: Re: MQ Client Connections Once the KeepAlive interval passes, the QM should realize that there in nobody home on the other end of the SRVRCONN channel, and the orphaned instance should go away. Make sure KeepAlive is turned on to a reasonable value at the server level (it effects all TCP/IP apps, not just MQ), and then set the KeepAlive parameter to on at the QM level. And like Darren said, make sure the app always MQCLOSEs and MQDISCs (check all those try
Re: MQ Client Connections
Not to digress, but Giambi went 4 for 4 yesterday. Ernest Roberts - Forwarded by Ernest Roberts/171/DCAG/DCX on 03/19/2004 01:42 PM - Paul Clarke [EMAIL PROTECTED] To: [EMAIL PROTECTED] .IBM.COMcc: Sent by: Subject: Re: MQ Client Connections MQSeries List [EMAIL PROTECTED] en.AC.AT 03/19/2004 11:53 AM Please respond to MQSeries List Brian, I think the first thing to do is find out exactly what the client is waiting for for 4 minutes (who would have thought there was a valid sentence with 'for' being used 3 times consecutively ?). I suggest you switch on MQ trace and try the connect again. Look at the tracefile and look at the timestamps to make sure it's the connect() verb and not some strange ldap or authority call that's delaying you. Cheers, P. Paul G Clarke WebSphere MQ Development |-+ | | Bumpass, Brian | | | [EMAIL PROTECTED]| | | CHOVIA.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 19/03/2004 16:37 | | | Please respond to| | | MQSeries List| |-+ -| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MQ Client Connections | | | | | -| I know this is an old thread but have an interesting corollary scenario. My QMgrs are backed by HA software, thus a QMgr's IP address(es) and Listener process(es) are linked to VIP address(es). If the QMgr is down there is a good chance the VIP address is not attached to a NIC and unknown within the network -- and all the stuff that means My problem is at the client level rather than the SVRCONN definition on the QMgr. My initial testing is with round-robin DNS. I am getting a 2059 -- as expected -- when the QMgr is unavailable. However, it is taking about about 4 minutes for the MQ Client MQCONN call to fail. My guess is the network is attempting to locate the VIP address? The question is there a way to tune this failure at the client to happen quicker. Additional Note... The cacheing of the IP/Hostname is disabled on the client. Thanks in advance, -B Brian Bumpass Wachovia Bank Enterprise Infrastructure [EMAIL PROTECTED] Phone - (704) 590-5620 Pager - (800) 425-2613 -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Friday, April 18, 2003 5:01 PM To: [EMAIL PROTECTED] Subject: Re: MQ Client Connections Once the KeepAlive interval passes, the QM should realize that there in nobody home on the other end of the SRVRCONN channel, and the orphaned instance should go away. Make sure KeepAlive is turned on to a reasonable value at the server level (it effects all TCP/IP apps, not just MQ), and then set the KeepAlive parameter to on at the QM level. And like Darren said, make sure the app always MQCLOSEs and MQDISCs (check all those try/catch blocks!) Transaction Vision is a cool tool that allows you to see what apps are really doing. Lots of times I was able to prove the app was doing XYZ when they swear they were doing ABC by using this tool. (Among other things, it list all the MQ API calls any app executes, and gives the details on exactly how and when it did what MQ-wise) -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Friday, April 18, 2003 1:37 PM To: [EMAIL PROTECTED] Subject: Re: MQ Client Connections Rich I may be corrected, but I don't think there is a way to get MQ to terminate the channels automatically from the server side. re: the problem app... it may do a nice MQDISC when it terminates cleanly... but what if it doesn't terminate cleanly - the designer / coder may have neglected proper cleanup in the 'bad' scenarios. Regards Darren. - Original Message - From: Garcia Rich (SYS1RXG) To: [EMAIL PROTECTED] Sent: Thursday, April 17, 2003 3:11 PM
Re: MQ Client Connections
Is this cricket ? 'fraid I don't follow it. He could have been 4 for 4 for 4 hours as far as I know :-) P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | earMERC Roberts | | | [EMAIL PROTECTED]| | | BUSA.COM| | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 19/03/2004 18:42 | | | Please respond to| | | MQSeries List| |-+ -| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MQ Client Connections | | | | | -| Not to digress, but Giambi went 4 for 4 yesterday. Ernest Roberts - Forwarded by Ernest Roberts/171/DCAG/DCX on 03/19/2004 01:42 PM - Paul Clarke [EMAIL PROTECTED] To: [EMAIL PROTECTED] .IBM.COMcc: Sent by: Subject: Re: MQ Client Connections MQSeries List [EMAIL PROTECTED] en.AC.AT 03/19/2004 11:53 AM Please respond to MQSeries List Brian, I think the first thing to do is find out exactly what the client is waiting for for 4 minutes (who would have thought there was a valid sentence with 'for' being used 3 times consecutively ?). I suggest you switch on MQ trace and try the connect again. Look at the tracefile and look at the timestamps to make sure it's the connect() verb and not some strange ldap or authority call that's delaying you. Cheers, P. Paul G Clarke WebSphere MQ Development |-+ | | Bumpass, Brian | | | [EMAIL PROTECTED]| | | CHOVIA.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 19/03/2004 16:37 | | | Please respond to| | | MQSeries List| |-+ -| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MQ Client Connections | | | | | -| I know this is an old thread but have an interesting corollary scenario. My QMgrs are backed by HA software, thus a QMgr's IP address(es) and Listener process(es) are linked to VIP address(es). If the QMgr is down there is a good chance the VIP address is not attached to a NIC and unknown within the network -- and all the stuff that means My problem is at the client level rather than the SVRCONN definition on the QMgr. My initial testing is with round-robin DNS. I am getting a 2059 -- as expected -- when the QMgr is unavailable. However, it is taking about about 4 minutes for the MQ Client MQCONN call to fail. My guess is the network is attempting to locate the VIP address? The question is there a way to tune this failure at the client to happen quicker. Additional Note... The cacheing of the IP/Hostname is disabled on the client. Thanks in advance, -B Brian Bumpass Wachovia Bank Enterprise Infrastructure [EMAIL PROTECTED] Phone - (704) 590-5620 Pager - (800) 425-2613 -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Friday, April 18, 2003 5:01 PM To: [EMAIL PROTECTED] Subject: Re: MQ Client
Re: MQ Client Connections
It's me again Did not think it was DNS issue. Ran my tests using DNS hostname resolution and IP address. The results are the same. The trace just shows about a 3-4 minute gap in time following the connect request. Next step... Running netstat -an shows the connection in a SYN_SENT state Since the VIP is not active nothing is ever going to be returned Reviewing some further information it looks like the default TIME_OUT condition on Solaris is 4 minutes -- I think I've run across that value before in my DCE days. I guess my options are... o Reduce the SYN_SENT wait time to something lower. But this is probably a bad thing since supporting this on a a number of client boxes may not be scalable to support. Additionally, the value that requires changing probably will affect every connection. o Find a way to do it within the client application. Does MQCONNX have anything? Or I could fork/thread a timer event around the MQCONN[X] call? Any input would be nice? Thanks, -B Brian Bumpass Wachovia Bank Enterprise Infrastructure [EMAIL PROTECTED] Phone - (704) 590-5620 Pager - (800) 425-2613 -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Heggie, Peter Sent: Friday, March 19, 2004 1:00 PM To: [EMAIL PROTECTED] Subject: Re: MQ Client Connections Good idea.. sorry! Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Clarke Sent: Friday, March 19, 2004 12:35 PM To: [EMAIL PROTECTED] Subject: Re: MQ Client Connections Peter, I agree but what I'm saying is let's not guess. First find out exactly what we're waiting for and then work out how to tune it down. There are quite a number of areas in the client code where we 'could' spend some time; I've even seen pretty innocuous registry calls taking minutes to return. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Heggie, Peter | | | [EMAIL PROTECTED]| | | NGRID.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 19/03/2004 17:05 | | | Please respond to| | | MQSeries List| |-+ --- --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MQ Client Connections | | | | | --- --| I have seen a network request take 4 minutes or a little longer to look for an name that is no longer there. Depends on your DNS setup. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Clarke Sent: Friday, March 19, 2004 11:53 AM To: [EMAIL PROTECTED] Subject: Re: MQ Client Connections Brian, I think the first thing to do is find out exactly what the client is waiting for for 4 minutes (who would have thought there was a valid sentence with 'for' being used 3 times consecutively ?). I suggest you switch on MQ trace and try the connect again. Look at the tracefile and look at the timestamps to make sure it's the connect() verb and not some strange ldap or authority call that's delaying you. Cheers, P. Paul G Clarke WebSphere MQ Development |-+ | | Bumpass, Brian | | | [EMAIL PROTECTED]| | | CHOVIA.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 19/03/2004 16:37 | | | Please respond to| | | MQSeries List| |-+ --- --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MQ Client Connections | | | | | --- --| I know this is an old thread but have an interesting corollary scenario. My QMgrs are backed by HA software, thus a QMgr's IP address(es) and Listener process(es) are linked to VIP address(es). If the QMgr is down there is a good chance the VIP address is not attached to a NIC and unknown within the network -- and all the stuff that means My problem is at the client level
Re: JMS resource problems after 254 'connections' ?
More information - the source of the '254' connections is the MQ queue manager MAXHANDS attribute. When we raised it, we immediately were able to run more transactions before encountering exceptions. The new number we could run exactly matched the new MAXHANDS value, minus 2. We tried explicitly closing the temporary queues as soon as we received the reply on them, but we still encountered exceptions (in PeopleSoft) after the limit was reached. From a distance, it looks like PeopleSoft's implementation of JMS is not releasing the queue handles. We will try to test more with a much higher limit, and see if the higher limit allows more time for requests to complete and release enough queue handles to stay below the limit. I'm hoping we will find some kind of JMS configuration parameter that has been set incorrectly which can release handles quickly. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T. Rob Sent: Wednesday, March 17, 2004 11:01 AM To: [EMAIL PROTECTED] Subject: Re: JMS resource problems after 254 'connections' ? Peter, I agree that the number sounds suspicious. Especially in relation to messages as opposed to connections. It suggests the app is making a new connection for each message and not releasing them. Have you checked for that? Alternatively, what kind of logging are you using and are all the messages in a single unit of work? -- T.Rob -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 10:05 AM To: [EMAIL PROTECTED] Subject: JMS resource problems after 254 'connections' ? Has anyone encountered a problem with a MQ to JMS environment, where a synchronous transfer (request/reply) encounters a 'Resouce Exception' after 245 reply messages are processed? We have an MQ to PeopleSoft environment where we send messages from an MQ application via JMS to the PeopleSoft Integration Broker, which then sends a PS message to a PS component. When PS sends a reply back to the PS Integration Broker, after 254 replies have been received by the Integration Broker (and passed on to JMS MQ), the 255th reply causes a JMS resource exception. The number 254 is very suspicious, but also, I would perfer eliminating a 'limit number' altogether, rather than just raising it. Has anyone seen something like this before? 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. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: JMS resource problems after 254 'connections' ?
Hi Peter, We had the same problem with PeopleSoft/JMS. We increased MAXHANDS to 512 about a year ago, and we have never had this problem again since then. Ruzi --- Heggie, Peter [EMAIL PROTECTED] wrote: More information - the source of the '254' connections is the MQ queue manager MAXHANDS attribute. When we raised it, we immediately were able to run more transactions before encountering exceptions. The new number we could run exactly matched the new MAXHANDS value, minus 2. We tried explicitly closing the temporary queues as soon as we received the reply on them, but we still encountered exceptions (in PeopleSoft) after the limit was reached. From a distance, it looks like PeopleSoft's implementation of JMS is not releasing the queue handles. We will try to test more with a much higher limit, and see if the higher limit allows more time for requests to complete and release enough queue handles to stay below the limit. I'm hoping we will find some kind of JMS configuration parameter that has been set incorrectly which can release handles quickly. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T. Rob Sent: Wednesday, March 17, 2004 11:01 AM To: [EMAIL PROTECTED] Subject: Re: JMS resource problems after 254 'connections' ? Peter, I agree that the number sounds suspicious. Especially in relation to messages as opposed to connections. It suggests the app is making a new connection for each message and not releasing them. Have you checked for that? Alternatively, what kind of logging are you using and are all the messages in a single unit of work? -- T.Rob -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 10:05 AM To: [EMAIL PROTECTED] Subject: JMS resource problems after 254 'connections' ? Has anyone encountered a problem with a MQ to JMS environment, where a synchronous transfer (request/reply) encounters a 'Resouce Exception' after 245 reply messages are processed? We have an MQ to PeopleSoft environment where we send messages from an MQ application via JMS to the PeopleSoft Integration Broker, which then sends a PS message to a PS component. When PS sends a reply back to the PS Integration Broker, after 254 replies have been received by the Integration Broker (and passed on to JMS MQ), the 255th reply causes a JMS resource exception. The number 254 is very suspicious, but also, I would perfer eliminating a 'limit number' altogether, rather than just raising it. Has anyone seen something like this before? 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. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: JMS resource problems after 254 'connections' ?
Thanks Ruzi, We are going to increase MAXHANDS for now. I just got off the phone with our PeopleSoft administrators and they discovered late last night that PeopleSoft/JMS code never lets go of these handles. They modified some of the PS JMS classes to force the release of the connections and the problem disappeared. They are pursuing the issue with PS to get an approved fix. Is it correct to say that each of these handles is associated with a SVRCONN channel connection, and that I can display the CHSTATUS to see the open handles? So counting the number of connections would give me the number of handles and confirm the problem. We could run 254 of these synchronous requests and we should see the 254 open connections in the display. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Ruzi R Sent: Thursday, March 18, 2004 4:00 PM To: [EMAIL PROTECTED] Subject: Re: JMS resource problems after 254 'connections' ? Hi Peter, We had the same problem with PeopleSoft/JMS. We increased MAXHANDS to 512 about a year ago, and we have never had this problem again since then. Ruzi --- Heggie, Peter [EMAIL PROTECTED] wrote: More information - the source of the '254' connections is the MQ queue manager MAXHANDS attribute. When we raised it, we immediately were able to run more transactions before encountering exceptions. The new number we could run exactly matched the new MAXHANDS value, minus 2. We tried explicitly closing the temporary queues as soon as we received the reply on them, but we still encountered exceptions (in PeopleSoft) after the limit was reached. From a distance, it looks like PeopleSoft's implementation of JMS is not releasing the queue handles. We will try to test more with a much higher limit, and see if the higher limit allows more time for requests to complete and release enough queue handles to stay below the limit. I'm hoping we will find some kind of JMS configuration parameter that has been set incorrectly which can release handles quickly. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T. Rob Sent: Wednesday, March 17, 2004 11:01 AM To: [EMAIL PROTECTED] Subject: Re: JMS resource problems after 254 'connections' ? Peter, I agree that the number sounds suspicious. Especially in relation to messages as opposed to connections. It suggests the app is making a new connection for each message and not releasing them. Have you checked for that? Alternatively, what kind of logging are you using and are all the messages in a single unit of work? -- T.Rob -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 10:05 AM To: [EMAIL PROTECTED] Subject: JMS resource problems after 254 'connections' ? Has anyone encountered a problem with a MQ to JMS environment, where a synchronous transfer (request/reply) encounters a 'Resouce Exception' after 245 reply messages are processed? We have an MQ to PeopleSoft environment where we send messages from an MQ application via JMS to the PeopleSoft Integration Broker, which then sends a PS message to a PS component. When PS sends a reply back to the PS Integration Broker, after 254 replies have been received by the Integration Broker (and passed on to JMS MQ), the 255th reply causes a JMS resource exception. The number 254 is very suspicious, but also, I would perfer eliminating a 'limit number' altogether, rather than just raising it. Has anyone seen something like this before? 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. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
JMS resource problems after 254 'connections' ?
Has anyone encountered a problem with a MQ to JMS environment, where a synchronous transfer (request/reply) encounters a 'Resouce Exception' after 245 reply messages are processed? We have an MQ to PeopleSoft environment where we send messages from an MQ application via JMS to the PeopleSoft Integration Broker, which then sends a PS message to a PS component. When PS sends a reply back to the PS Integration Broker, after 254 replies have been received by the Integration Broker (and passed on to JMS MQ), the 255th reply causes a JMS resource exception. The number 254 is very suspicious, but also, I would perfer eliminating a 'limit number' altogether, rather than just raising it. Has anyone seen something like this before? 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. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: JMS resource problems after 254 'connections' ?
Peter, I agree that the number sounds suspicious. Especially in relation to messages as opposed to connections. It suggests the app is making a new connection for each message and not releasing them. Have you checked for that? Alternatively, what kind of logging are you using and are all the messages in a single unit of work? -- T.Rob -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 10:05 AM To: [EMAIL PROTECTED] Subject: JMS resource problems after 254 'connections' ? Has anyone encountered a problem with a MQ to JMS environment, where a synchronous transfer (request/reply) encounters a 'Resouce Exception' after 245 reply messages are processed? We have an MQ to PeopleSoft environment where we send messages from an MQ application via JMS to the PeopleSoft Integration Broker, which then sends a PS message to a PS component. When PS sends a reply back to the PS Integration Broker, after 254 replies have been received by the Integration Broker (and passed on to JMS MQ), the 255th reply causes a JMS resource exception. The number 254 is very suspicious, but also, I would perfer eliminating a 'limit number' altogether, rather than just raising it. Has anyone seen something like this before? 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. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Many Client connections - how many svrconn channels?
Just to make a correction to my previous note before anyone jumps in: I would want to leave the MCAUSER blank so that I can tell who put the message onsee whothe message on the queue. Svrconn does not show the userid but the connectin name. Thanks, Ruzi --- Ruzi R [EMAIL PROTECTED] wrote: But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. Thanks Dennis. However, I think it would be safe and maybe even better to leave MCAUSER blank. Because BLOCKIP2 will allow only the users (and IP addresses) in the security exit file anyway. This would come in handy during a problem investigation -- for example, things like inquiring the status of the svrconn channel or the userid of the message on the queue etc. would indicate the actual user rather than the group userid. Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I took a look at the BLOCKIP2 URL provided by SID. Very neat. I did notice that BLOCKIP2 only supports setting the MCAUSER on SSL channels. But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 11:49 AM To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? Dennis, BlockIP2 is the latest version of BlockIP. It is a secrity exit program. I don't have the link on the computer that I am using right now. Maybe, someone on the list will post it. It basically lets you specify the userids and the IP addresses from which the client connections will be made. Most (if not all) of these clients will have the same authority. I am thinking of leaving the MCAUSER blank on an svrconn and specify the userids in a file to be used by the security exit. I think this would do what I want to acheive. Maybe I could secure this file by giving access only to MQ admins and MUSR_MQADMIN. What would you or or anyone else suggest? Thanks, Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I don't see the point of dedicating svrconn's to a specific number of clients. Dedicating a svrconn a specific MCAUSER and sharing it among many clients is a different story. Seems you would only need one MCAUSER+srvrconn for each authority level. But to gain a semblence of security from either of those schemes, you still need to control client access to the srvrcon's. Not sure how you accomplish that. Unfortunately, I do not know what BlockIP2 is about(and neither does Google). -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 12:35 PM To: [EMAIL PROTECTED] Subject: Many Client connections - how many svrconn channels? Hi all, We have over 200 users requiring client connection from their Windows2000 workstations to the queue managers on Windows 2000 (WMQ 5.3). The company does not have and is unwilling to buy any third product right now or in the foreseeable future. I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited access. I have started using BlockIP2 as well. I have brought up the use of SSL but the company is reluctant to do that (I don t know about all the concerns surrounding the issue probably something political that I don t get involved in as a contractor). Because I want to make the client connections as secure as possible with what I have at my disposal, I feel that I should set up the rest of the 200 clients (most of whom will be in the Prod env.) the same way as the others: Dedicated svrconn channel with MCAUSER populated with a userid having limited access, and IPBlock2. But then again, since all of the interfaces are internal, maybe I could dedicate 1 svrconn to, say, 20 people. I can still give limited access to the users, leave the MCUSER blank and specify the valid IP addresses in IPBlock2. What do you think? Any ideas/insights would be much appreciated. Thanks in advance, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your
Re: Many Client connections - how many svrconn channels?
Just to make a correction to my previous note before anyone jumps in: I would want to leave the MCAUSER blank so that I can tell who put the message onsee whothe message on the queue. Svrconn does not show the userid but the connectin name. Thanks, Ruzi things like inquiring the status of the svrconn channel or the userid of the message on the queue etc. would indicate the actual user rather than the group userid. --- Ruzi R [EMAIL PROTECTED] wrote: But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. Thanks Dennis. However, I think it would be safe and maybe even better to leave MCAUSER blank. Because BLOCKIP2 will allow only the users (and IP addresses) in the security exit file anyway. This would come in handy during a problem investigation -- for example, things like inquiring the status of the svrconn channel or the userid of the message on the queue etc. would indicate the actual user rather than the group userid. Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I took a look at the BLOCKIP2 URL provided by SID. Very neat. I did notice that BLOCKIP2 only supports setting the MCAUSER on SSL channels. But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 11:49 AM To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? Dennis, BlockIP2 is the latest version of BlockIP. It is a secrity exit program. I don't have the link on the computer that I am using right now. Maybe, someone on the list will post it. It basically lets you specify the userids and the IP addresses from which the client connections will be made. Most (if not all) of these clients will have the same authority. I am thinking of leaving the MCAUSER blank on an svrconn and specify the userids in a file to be used by the security exit. I think this would do what I want to acheive. Maybe I could secure this file by giving access only to MQ admins and MUSR_MQADMIN. What would you or or anyone else suggest? Thanks, Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I don't see the point of dedicating svrconn's to a specific number of clients. Dedicating a svrconn a specific MCAUSER and sharing it among many clients is a different story. Seems you would only need one MCAUSER+srvrconn for each authority level. But to gain a semblence of security from either of those schemes, you still need to control client access to the srvrcon's. Not sure how you accomplish that. Unfortunately, I do not know what BlockIP2 is about(and neither does Google). -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 12:35 PM To: [EMAIL PROTECTED] Subject: Many Client connections - how many svrconn channels? Hi all, We have over 200 users requiring client connection from their Windows2000 workstations to the queue managers on Windows 2000 (WMQ 5.3). The company does not have and is unwilling to buy any third product right now or in the foreseeable future. I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited access. I have started using BlockIP2 as well. I have brought up the use of SSL but the company is reluctant to do that (I don t know about all the concerns surrounding the issue probably something political that I don t get involved in as a contractor). Because I want to make the client connections as secure as possible with what I have at my disposal, I feel that I should set up the rest of the 200 clients (most of whom will be in the Prod env.) the same way as the others: Dedicated svrconn channel with MCAUSER populated with a userid having limited access, and IPBlock2. But then again, since all of the interfaces are internal, maybe I could dedicate 1 svrconn to, say, 20 people. I can still give limited access to the users, leave the MCUSER blank and specify the valid IP addresses in IPBlock2. What do you think? Any ideas/insights would be much appreciated. Thanks in advance, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided
Re: Many Client connections - how many svrconn channels?
Hi Ruzi, Should BlockIP2 changed so you would be able to change MCAUSER depending on the connectioname/userid ? Maybe something like the options for SSL ? (Without SSL it might introduce security risks, anyway the best way of protection is a set of exits, so you get an authentication of the real user using userid/password) BlockIP and BlockIP2 was just a small security enhancement, but it seems that there is a need for WebSphere MQ security tools. Let me hear your oppinion on this issue. Just my $0.02 ;o) Kind regards Jxrgen www.MrMQ.dk - the home of BlockIP From: Ruzi R [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? Date: Mon, 15 Mar 2004 04:49:35 -0800 Just to make a correction to my previous note before anyone jumps in: I would want to leave the MCAUSER blank so that I can tell who put the message onsee whothe message on the queue. Svrconn does not show the userid but the connectin name. Thanks, Ruzi things like inquiring the status of the svrconn channel or the userid of the message on the queue etc. would indicate the actual user rather than the group userid. --- Ruzi R [EMAIL PROTECTED] wrote: But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. Thanks Dennis. However, I think it would be safe and maybe even better to leave MCAUSER blank. Because BLOCKIP2 will allow only the users (and IP addresses) in the security exit file anyway. This would come in handy during a problem investigation -- for example, things like inquiring the status of the svrconn channel or the userid of the message on the queue etc. would indicate the actual user rather than the group userid. Ruzi _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk/ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Many Client connections - how many svrconn channels?
Just to make a correction to my previous note before anyone jumps in: The reason why I want to leave the MCAUSER blank is so that I can tell who put the message on the the queue. Status of Svrconn does not show the userid but the connectin name, which is OK. Thanks, Ruzi --- Ruzi R [EMAIL PROTECTED] wrote: But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. Thanks Dennis. However, I think it would be safe and maybe better to leave MCAUSER blank. Because BLOCKIP2 will allow only the users (and IP addresses) in the security exit file anyway. This would come in handy during a problem investigation -- for example, things like inquiring the status of the svrconn channel or the userid of the message on the queue etc. would indicate the actual user rather than the group userid. Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I took a look at the BLOCKIP2 URL provided by SID. Very neat. I did notice that BLOCKIP2 only supports setting the MCAUSER on SSL channels. But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 11:49 AM To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? Dennis, BlockIP2 is the latest version of BlockIP. It is a secrity exit program. I don't have the link on the computer that I am using right now. Maybe, someone on the list will post it. It basically lets you specify the userids and the IP addresses from which the client connections will be made. Most (if not all) of these clients will have the same authority. I am thinking of leaving the MCAUSER blank on an svrconn and specify the userids in a file to be used by the security exit. I think this would do what I want to acheive. Maybe I could secure this file by giving access only to MQ admins and MUSR_MQADMIN. What would you or or anyone else suggest? Thanks, Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I don't see the point of dedicating svrconn's to a specific number of clients. Dedicating a svrconn a specific MCAUSER and sharing it among many clients is a different story. Seems you would only need one MCAUSER+srvrconn for each authority level. But to gain a semblence of security from either of those schemes, you still need to control client access to the srvrcon's. Not sure how you accomplish that. Unfortunately, I do not know what BlockIP2 is about(and neither does Google). -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 12:35 PM To: [EMAIL PROTECTED] Subject: Many Client connections - how many svrconn channels? Hi all, We have over 200 users requiring client connection from their Windows2000 workstations to the queue managers on Windows 2000 (WMQ 5.3). The company does not have and is unwilling to buy any third product right now or in the foreseeable future. I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited access. I have started using BlockIP2 as well. I have brought up the use of SSL but the company is reluctant to do that (I don t know about all the concerns surrounding the issue probably something political that I don t get involved in as a contractor). Because I want to make the client connections as secure as possible with what I have at my disposal, I feel that I should set up the rest of the 200 clients (most of whom will be in the Prod env.) the same way as the others: Dedicated svrconn channel with MCAUSER populated with a userid having limited access, and IPBlock2. But then again, since all of the interfaces are internal, maybe I could dedicate 1 svrconn to, say, 20 people. I can still give limited access to the users, leave the MCUSER blank and specify the valid IP addresses in IPBlock2. What do you think? Any ideas/insights would be much appreciated. Thanks in advance, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions
Re: Many Client connections - how many svrconn channels?
Hi Jxrgen, Thanks for your response. Should BlockIP2 changed so you would be able to change MCAUSER depending on the connectioname/userid ? Yes, this would come in very handy. (Without SSL it might introduce security risks, anyway the best way of protection is a set of exits, BlockIP2 is the only thing I can use currently. What I don't understand is, if user1/machine1, user2/machine2 and user3/machine3 are the only ids/machines permitted to access the svrconn1 (NO mqm!!), and I can secure the security file (for SCYDATA) somehow, what security risk I should be aware of? I am not quite sure, though, about whether I can secure this file. Maybe, this is what you mean by security risk? If someone else finds out the valid userids and uses one of them get (from one of the valid machines) to access my MQ queues/qmgr then,yes, I would be doomed. Any other security risk involved? Also would giving read access to MUSR_MQADMIN on this file be sufficient? Thanks, Ruzi --- Jxrgen Pedersen [EMAIL PROTECTED] wrote: Hi Ruzi, Should BlockIP2 changed so you would be able to change MCAUSER depending on the connectioname/userid ? Maybe something like the options for SSL ? (Without SSL it might introduce security risks, anyway the best way of protection is a set of exits, so you get an authentication of the real user using userid/password) BlockIP and BlockIP2 was just a small security enhancement, but it seems that there is a need for WebSphere MQ security tools. Let me hear your oppinion on this issue. Just my $0.02 ;o) Kind regards Jxrgen www.MrMQ.dk - the home of BlockIP From: Ruzi R [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? Date: Mon, 15 Mar 2004 04:49:35 -0800 Just to make a correction to my previous note before anyone jumps in: I would want to leave the MCAUSER blank so that I can tell who put the message onsee whothe message on the queue. Svrconn does not show the userid but the connectin name. Thanks, Ruzi things like inquiring the status of the svrconn channel or the userid of the message on the queue etc. would indicate the actual user rather than the group userid. --- Ruzi R [EMAIL PROTECTED] wrote: But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. Thanks Dennis. However, I think it would be safe and maybe even better to leave MCAUSER blank. Because BLOCKIP2 will allow only the users (and IP addresses) in the security exit file anyway. This would come in handy during a problem investigation -- for example, things like inquiring the status of the svrconn channel or the userid of the message on the queue etc. would indicate the actual user rather than the group userid. Ruzi _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk/ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Many Client connections - how many svrconn channels?
Jxrgen, I should add that I am not concerned with the eavesdropping at this point. All of our interfaces are internal. I will push for SSL very soon. Ruzi --- Ruzi R [EMAIL PROTECTED] wrote: Hi Jxrgen, Thanks for your response. Should BlockIP2 changed so you would be able to change MCAUSER depending on the connectioname/userid ? Yes, this would come in very handy. (Without SSL it might introduce security risks, anyway the best way of protection is a set of exits, BlockIP2 is the only thing I can use currently. What I don't understand is, if user1/machine1, user2/machine2 and user3/machine3 are the only ids/machines permitted to access the svrconn1 (NO mqm!!), and I can secure the security file (for SCYDATA) somehow, what security risk I should be aware of? I am not quite sure, though, about whether I can secure this file. Maybe, this is what you mean by security risk? If someone else finds out the valid userids and uses one of them get (from one of the valid machines) to access my MQ queues/qmgr then,yes, I would be doomed. Any other security risk involved? Also would giving read access to MUSR_MQADMIN on this file be sufficient? Thanks, Ruzi --- Jxrgen Pedersen [EMAIL PROTECTED] wrote: Hi Ruzi, Should BlockIP2 changed so you would be able to change MCAUSER depending on the connectioname/userid ? Maybe something like the options for SSL ? (Without SSL it might introduce security risks, anyway the best way of protection is a set of exits, so you get an authentication of the real user using userid/password) BlockIP and BlockIP2 was just a small security enhancement, but it seems that there is a need for WebSphere MQ security tools. Let me hear your oppinion on this issue. Just my $0.02 ;o) Kind regards Jxrgen www.MrMQ.dk - the home of BlockIP From: Ruzi R [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? Date: Mon, 15 Mar 2004 04:49:35 -0800 Just to make a correction to my previous note before anyone jumps in: I would want to leave the MCAUSER blank so that I can tell who put the message onsee whothe message on the queue. Svrconn does not show the userid but the connectin name. Thanks, Ruzi things like inquiring the status of the svrconn channel or the userid of the message on the queue etc. would indicate the actual user rather than the group userid. --- Ruzi R [EMAIL PROTECTED] wrote: But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. Thanks Dennis. However, I think it would be safe and maybe even better to leave MCAUSER blank. Because BLOCKIP2 will allow only the users (and IP addresses) in the security exit file anyway. This would come in handy during a problem investigation -- for example, things like inquiring the status of the svrconn channel or the userid of the message on the queue etc. would indicate the actual user rather than the group userid. Ruzi _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk/ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Many Client connections - how many svrconn channels?
Maybe I'm misunderstaning your goal, but I don't see what BLOCKIP2 accomplishes if you leave MCAUSER blank. Suppose you want two levels of access: limited and unlimited. So you set up an SVRCONN for each, leaving MCAUSER blank on both. Then, you block limited users (or IP addresses) from one of the SVRCONNs. So what? As far as security is concerned, both SVRCONNs are identical. From what I can tell, both kinds of users can still connect. And once connected, either kind of user can do exactly the same things as had they connected on the other SVRCONN. The only thing you've done is added front-end complexity for choosing the right SVRCONN. Let's stand back and look at your original statement: I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited access. Why the dedicated SVRCONN's? You get exactly the same security with one SVRCONN where MCAUSER is blank. I'm confused. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 6:48 PM To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. Thanks Dennis. However, I think it would be safe and maybe better to leave MCAUSER blank. Because BLOCKIP2 will allow only the users (and IP addresses) in the security exit file anyway. This would come in handy during a problem investigation -- for example, things like inquiring the status of the svrconn channel or the userid of the message on the queue etc. would indicate the actual user rather than the group userid. Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I took a look at the BLOCKIP2 URL provided by SID. Very neat. I did notice that BLOCKIP2 only supports setting the MCAUSER on SSL channels. But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 11:49 AM To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? Dennis, BlockIP2 is the latest version of BlockIP. It is a secrity exit program. I don't have the link on the computer that I am using right now. Maybe, someone on the list will post it. It basically lets you specify the userids and the IP addresses from which the client connections will be made. Most (if not all) of these clients will have the same authority. I am thinking of leaving the MCAUSER blank on an svrconn and specify the userids in a file to be used by the security exit. I think this would do what I want to acheive. Maybe I could secure this file by giving access only to MQ admins and MUSR_MQADMIN. What would you or or anyone else suggest? Thanks, Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I don't see the point of dedicating svrconn's to a specific number of clients. Dedicating a svrconn a specific MCAUSER and sharing it among many clients is a different story. Seems you would only need one MCAUSER+srvrconn for each authority level. But to gain a semblence of security from either of those schemes, you still need to control client access to the srvrcon's. Not sure how you accomplish that. Unfortunately, I do not know what BlockIP2 is about(and neither does Google). -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 12:35 PM To: [EMAIL PROTECTED] Subject: Many Client connections - how many svrconn channels? Hi all, We have over 200 users requiring client connection from their Windows2000 workstations to the queue managers on Windows 2000 (WMQ 5.3). The company does not have and is unwilling to buy any third product right now or in the foreseeable future. I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited access. I have started using BlockIP2 as well. I have brought up the use of SSL but the company is reluctant to do that (I don t know about all the concerns surrounding the issue probably something political that I don t get involved in as a contractor). Because I want to make the client connections as secure as possible with what I have at my disposal, I feel that I should set up the rest of the 200 clients (most of whom will be in the Prod env.) the same way as the others: Dedicated svrconn channel with MCAUSER populated with a userid having limited access, and IPBlock2. But then again, since all of the interfaces are internal, maybe I could
Re: Many Client connections - how many svrconn channels?
From what I can tell, both kinds of users can still connect. And once connected, either kind of user can do exactly the same things as had they connected on the other SVRCONN. The only thing you've done is added front-end complexity for choosing the right SVRCONN. For example: Svrconn123 on QM1 is limited to user1, user2 and user3 with MCAUSER blank. SvrconnABC on QM1 is limited to userA, userB and userC with MCAUSER blank. BlockIP2 will prevent anyone from accessing QM1 via Svrconn123 other than user1, user2 and user3. So the MCAUSER will be populated by one of these userids. Similarly SvrconnABC would be available only to userA, userB and userC. This is my understanding of how I can make use of BlockIP2. Of course I cannot prevent anyone from impersonating one of the userids. I could use the one of the valid userids in MCAUSER. Or create a specific userid to put in MCAUSER having the same level of privilages as the others (e.g. user1, 2 and 3). But I fail to see the reason for it since BlockIP2 will only let the userids I specify have access to QM1 via the security exit. Am I missing something? I said: I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited accesss. You said: Why the dedicated SVRCONN's? You get exactly the same security with one SVRCONN where MCAUSER is blank. I'm confused. Using separate svrconn channels with MCAUSER set to an ID with limited access is one of the things that can be done to prevent unauthorized access. And this is highly recommended on this list. Because leaving the MCAUSER blank creates a security exposure --apparently, it is very easy for a client to present mqm userid to the svrconn channel-- which is done in the application code like Java... (Of course you would need SSL as well to really secure the channel). For this reason, I think it is best to have a dedicated svrconn for each client connection with MCAUSER set to their id having limited access. Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: Maybe I'm misunderstaning your goal, but I don't see what BLOCKIP2 accomplishes if you leave MCAUSER blank. Suppose you want two levels of access: limited and unlimited. So you set up an SVRCONN for each, leaving MCAUSER blank on both. Then, you block limited users (or IP addresses) from one of the SVRCONNs. So what? As far as security is concerned, both SVRCONNs are identical. From what I can tell, both kinds of users can still connect. And once connected, either kind of user can do exactly the same things as had they connected on the other SVRCONN. The only thing you've done is added front-end complexity for choosing the right SVRCONN. Let's stand back and look at your original statement: I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited access. Why the dedicated SVRCONN's? You get exactly the same security with one SVRCONN where MCAUSER is blank. I'm confused. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 6:48 PM To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. Thanks Dennis. However, I think it would be safe and maybe better to leave MCAUSER blank. Because BLOCKIP2 will allow only the users (and IP addresses) in the security exit file anyway. This would come in handy during a problem investigation -- for example, things like inquiring the status of the svrconn channel or the userid of the message on the queue etc. would indicate the actual user rather than the group userid. Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I took a look at the BLOCKIP2 URL provided by SID. Very neat. I did notice that BLOCKIP2 only supports setting the MCAUSER on SSL channels. But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 11:49 AM To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? Dennis, BlockIP2 is the latest version of BlockIP. It is a secrity exit program. I don't have the link on the computer that I am using right now. Maybe, someone on the list will post it. It basically lets you specify the userids and the IP addresses from which the client connections will be made. Most (if not all) of these clients will have the same authority. I am thinking of leaving the MCAUSER blank on an svrconn
Re: Many Client connections - how many svrconn channels?
Dennis, I think the whole point is when you leave the MCAUSER of the SVRCONN blank, any (java) client can come in and pretend to be mqm. One of the features of BlockIP2 is that it can block 'unidentified' users, mqm, MUSR_ADMIN etc and on top of that use a 'list' of authorised users and a 'pattern' of IP adresses where they are supposed to be coming from. I do understand the requirement to leave MCAUSER blank as filling it with anything automatically gives all users that do come in the same authority, leaving it blank means the actual user coming in is given the permissions originally granted using setmqauth. I hope this made some sense. Michael -Oorspronkelijk bericht- Van: MQSeries List [mailto:[EMAIL PROTECTED] Miller, Dennis Verzonden: maandag 15 maart 2004 19:39 Aan: [EMAIL PROTECTED] Onderwerp: Re: Many Client connections - how many svrconn channels? Maybe I'm misunderstaning your goal, but I don't see what BLOCKIP2 accomplishes if you leave MCAUSER blank. Suppose you want two levels of access: limited and unlimited. So you set up an SVRCONN for each, leaving MCAUSER blank on both. Then, you block limited users (or IP addresses) from one of the SVRCONNs. So what? As far as security is concerned, both SVRCONNs are identical. From what I can tell, both kinds of users can still connect. And once connected, either kind of user can do exactly the same things as had they connected on the other SVRCONN. The only thing you've done is added front-end complexity for choosing the right SVRCONN. Let's stand back and look at your original statement: I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited access. Why the dedicated SVRCONN's? You get exactly the same security with one SVRCONN where MCAUSER is blank. I'm confused. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 6:48 PM To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. Thanks Dennis. However, I think it would be safe and maybe better to leave MCAUSER blank. Because BLOCKIP2 will allow only the users (and IP addresses) in the security exit file anyway. This would come in handy during a problem investigation -- for example, things like inquiring the status of the svrconn channel or the userid of the message on the queue etc. would indicate the actual user rather than the group userid. Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I took a look at the BLOCKIP2 URL provided by SID. Very neat. I did notice that BLOCKIP2 only supports setting the MCAUSER on SSL channels. But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 11:49 AM To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? Dennis, BlockIP2 is the latest version of BlockIP. It is a secrity exit program. I don't have the link on the computer that I am using right now. Maybe, someone on the list will post it. It basically lets you specify the userids and the IP addresses from which the client connections will be made. Most (if not all) of these clients will have the same authority. I am thinking of leaving the MCAUSER blank on an svrconn and specify the userids in a file to be used by the security exit. I think this would do what I want to acheive. Maybe I could secure this file by giving access only to MQ admins and MUSR_MQADMIN. What would you or or anyone else suggest? Thanks, Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I don't see the point of dedicating svrconn's to a specific number of clients. Dedicating a svrconn a specific MCAUSER and sharing it among many clients is a different story. Seems you would only need one MCAUSER+srvrconn for each authority level. But to gain a semblence of security from either of those schemes, you still need to control client access to the srvrcon's. Not sure how you accomplish that. Unfortunately, I do not know what BlockIP2 is about(and neither does Google). -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 12:35 PM To: [EMAIL PROTECTED] Subject: Many Client connections - how many svrconn channels? Hi all, We have over 200 users requiring client connection from their Windows2000 workstations to the queue managers on Windows 2000 (WMQ 5.3). The company does not have and is unwilling to buy any third product right now
Re: Many Client connections - how many svrconn channels?
So when all's said and done: user1 has the mcauser = user1 user2 has the mcauser = user2 ... userb has the mcauser = userb userc has the mcauser = userc Which is the standard behavior when MCAUSER is blank. You only need 1 SVRCONN and no exits. Regards, Dennis -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 1:07 PM To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? From what I can tell, both kinds of users can still connect. And once connected, either kind of user can do exactly the same things as had they connected on the other SVRCONN. The only thing you've done is added front-end complexity for choosing the right SVRCONN. For example: Svrconn123 on QM1 is limited to user1, user2 and user3 with MCAUSER blank. SvrconnABC on QM1 is limited to userA, userB and userC with MCAUSER blank. BlockIP2 will prevent anyone from accessing QM1 via Svrconn123 other than user1, user2 and user3. So the MCAUSER will be populated by one of these userids. Similarly SvrconnABC would be available only to userA, userB and userC. This is my understanding of how I can make use of BlockIP2. Of course I cannot prevent anyone from impersonating one of the userids. I could use the one of the valid userids in MCAUSER. Or create a specific userid to put in MCAUSER having the same level of privilages as the others (e.g. user1, 2 and 3). But I fail to see the reason for it since BlockIP2 will only let the userids I specify have access to QM1 via the security exit. Am I missing something? I said: I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited accesss. You said: Why the dedicated SVRCONN's? You get exactly the same security with one SVRCONN where MCAUSER is blank. I'm confused. Using separate svrconn channels with MCAUSER set to an ID with limited access is one of the things that can be done to prevent unauthorized access. And this is highly recommended on this list. Because leaving the MCAUSER blank creates a security exposure --apparently, it is very easy for a client to present mqm userid to the svrconn channel-- which is done in the application code like Java... (Of course you would need SSL as well to really secure the channel). For this reason, I think it is best to have a dedicated svrconn for each client connection with MCAUSER set to their id having limited access. Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: Maybe I'm misunderstaning your goal, but I don't see what BLOCKIP2 accomplishes if you leave MCAUSER blank. Suppose you want two levels of access: limited and unlimited. So you set up an SVRCONN for each, leaving MCAUSER blank on both. Then, you block limited users (or IP addresses) from one of the SVRCONNs. So what? As far as security is concerned, both SVRCONNs are identical. From what I can tell, both kinds of users can still connect. And once connected, either kind of user can do exactly the same things as had they connected on the other SVRCONN. The only thing you've done is added front-end complexity for choosing the right SVRCONN. Let's stand back and look at your original statement: I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited access. Why the dedicated SVRCONN's? You get exactly the same security with one SVRCONN where MCAUSER is blank. I'm confused. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 6:48 PM To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. Thanks Dennis. However, I think it would be safe and maybe better to leave MCAUSER blank. Because BLOCKIP2 will allow only the users (and IP addresses) in the security exit file anyway. This would come in handy during a problem investigation -- for example, things like inquiring the status of the svrconn channel or the userid of the message on the queue etc. would indicate the actual user rather than the group userid. Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I took a look at the BLOCKIP2 URL provided by SID. Very neat. I did notice that BLOCKIP2 only supports setting the MCAUSER on SSL channels. But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 11:49 AM To: [EMAIL PROTECTED] Subject: Re: Many
Re: Many Client connections - how many svrconn channels - BlockIP 2
Many Thx. Looks to be quite useful for limiting access by machine in environments where IP addresses are tightly controlled. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 3:45 PM To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels - BlockIP 2 G'Day Dennis, Here is a link to BlockIP2, it doesn't appear in google because it looks like it is not an absolute path in the URL and hence not findable by page scrapping. http://www.mrmq.dk/index.htm?tips_and_tricks.htm#BlockIP2 Sid -Original Message- From: Miller, Dennis [mailto:[EMAIL PROTECTED] Sent: Friday, 12 March 2004 8:38 AM To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? I don't see the point of dedicating svrconn's to a specific number of clients. Dedicating a svrconn a specific MCAUSER and sharing it among many clients is a different story. Seems you would only need one MCAUSER+srvrconn for each authority level. But to gain a semblence of security from either of those schemes, you still need to control client access to the srvrcon's. Not sure how you accomplish that. Unfortunately, I do not know what BlockIP2 is about(and neither does Google). -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 12:35 PM To: [EMAIL PROTECTED] Subject: Many Client connections - how many svrconn channels? Hi all, We have over 200 users requiring client connection from their Windows2000 workstations to the queue managers on Windows 2000 (WMQ 5.3). The company does not have and is unwilling to buy any third product right now or in the foreseeable future. I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited access. I have started using BlockIP2 as well. I have brought up the use of SSL but the company is reluctant to do that (I don t know about all the concerns surrounding the issue probably something political that I don t get involved in as a contractor). Because I want to make the client connections as secure as possible with what I have at my disposal, I feel that I should set up the rest of the 200 clients (most of whom will be in the Prod env.) the same way as the others: Dedicated svrconn channel with MCAUSER populated with a userid having limited access, and IPBlock2. But then again, since all of the interfaces are internal, maybe I could dedicate 1 svrconn to, say, 20 people. I can still give limited access to the users, leave the MCUSER blank and specify the valid IP addresses in IPBlock2. What do you think? Any ideas/insights would be much appreciated. Thanks in advance, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Many Client connections - how many svrconn channels?
Dennis, BlockIP2 is the latest version of BlockIP. It is a secrity exit program. I don't have the link on the computer that I am using right now. Maybe, someone on the list will post it. It basically lets you specify the userids and the IP addresses from which the client connections will be made. Most (if not all) of these clients will have the same authority. I am thinking of leaving the MCAUSER blank on an svrconn and specify the userids in a file to be used by the security exit. I think this would do what I want to acheive. Maybe I could secure this file by giving access only to MQ admins and MUSR_MQADMIN. What would you or or anyone else suggest? Thanks, Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I don't see the point of dedicating svrconn's to a specific number of clients. Dedicating a svrconn a specific MCAUSER and sharing it among many clients is a different story. Seems you would only need one MCAUSER+srvrconn for each authority level. But to gain a semblence of security from either of those schemes, you still need to control client access to the srvrcon's. Not sure how you accomplish that. Unfortunately, I do not know what BlockIP2 is about(and neither does Google). -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 12:35 PM To: [EMAIL PROTECTED] Subject: Many Client connections - how many svrconn channels? Hi all, We have over 200 users requiring client connection from their Windows2000 workstations to the queue managers on Windows 2000 (WMQ 5.3). The company does not have and is unwilling to buy any third product right now or in the foreseeable future. I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited access. I have started using BlockIP2 as well. I have brought up the use of SSL but the company is reluctant to do that (I don t know about all the concerns surrounding the issue probably something political that I don t get involved in as a contractor). Because I want to make the client connections as secure as possible with what I have at my disposal, I feel that I should set up the rest of the 200 clients (most of whom will be in the Prod env.) the same way as the others: Dedicated svrconn channel with MCAUSER populated with a userid having limited access, and IPBlock2. But then again, since all of the interfaces are internal, maybe I could dedicate 1 svrconn to, say, 20 people. I can still give limited access to the users, leave the MCUSER blank and specify the valid IP addresses in IPBlock2. What do you think? Any ideas/insights would be much appreciated. Thanks in advance, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Many Client connections - how many svrconn channels?
I took a look at the BLOCKIP2 URL provided by SID. Very neat. I did notice that BLOCKIP2 only supports setting the MCAUSER on SSL channels. But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 11:49 AM To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? Dennis, BlockIP2 is the latest version of BlockIP. It is a secrity exit program. I don't have the link on the computer that I am using right now. Maybe, someone on the list will post it. It basically lets you specify the userids and the IP addresses from which the client connections will be made. Most (if not all) of these clients will have the same authority. I am thinking of leaving the MCAUSER blank on an svrconn and specify the userids in a file to be used by the security exit. I think this would do what I want to acheive. Maybe I could secure this file by giving access only to MQ admins and MUSR_MQADMIN. What would you or or anyone else suggest? Thanks, Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I don't see the point of dedicating svrconn's to a specific number of clients. Dedicating a svrconn a specific MCAUSER and sharing it among many clients is a different story. Seems you would only need one MCAUSER+srvrconn for each authority level. But to gain a semblence of security from either of those schemes, you still need to control client access to the srvrcon's. Not sure how you accomplish that. Unfortunately, I do not know what BlockIP2 is about(and neither does Google). -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 12:35 PM To: [EMAIL PROTECTED] Subject: Many Client connections - how many svrconn channels? Hi all, We have over 200 users requiring client connection from their Windows2000 workstations to the queue managers on Windows 2000 (WMQ 5.3). The company does not have and is unwilling to buy any third product right now or in the foreseeable future. I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited access. I have started using BlockIP2 as well. I have brought up the use of SSL but the company is reluctant to do that (I don t know about all the concerns surrounding the issue probably something political that I don t get involved in as a contractor). Because I want to make the client connections as secure as possible with what I have at my disposal, I feel that I should set up the rest of the 200 clients (most of whom will be in the Prod env.) the same way as the others: Dedicated svrconn channel with MCAUSER populated with a userid having limited access, and IPBlock2. But then again, since all of the interfaces are internal, maybe I could dedicate 1 svrconn to, say, 20 people. I can still give limited access to the users, leave the MCUSER blank and specify the valid IP addresses in IPBlock2. What do you think? Any ideas/insights would be much appreciated. Thanks in advance, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Many Client connections - how many svrconn channels?
But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. Thanks Dennis. However, I think it would be safe and maybe better to leave MCAUSER blank. Because BLOCKIP2 will allow only the users (and IP addresses) in the security exit file anyway. This would come in handy during a problem investigation -- for example, things like inquiring the status of the svrconn channel or the userid of the message on the queue etc. would indicate the actual user rather than the group userid. Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I took a look at the BLOCKIP2 URL provided by SID. Very neat. I did notice that BLOCKIP2 only supports setting the MCAUSER on SSL channels. But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 11:49 AM To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? Dennis, BlockIP2 is the latest version of BlockIP. It is a secrity exit program. I don't have the link on the computer that I am using right now. Maybe, someone on the list will post it. It basically lets you specify the userids and the IP addresses from which the client connections will be made. Most (if not all) of these clients will have the same authority. I am thinking of leaving the MCAUSER blank on an svrconn and specify the userids in a file to be used by the security exit. I think this would do what I want to acheive. Maybe I could secure this file by giving access only to MQ admins and MUSR_MQADMIN. What would you or or anyone else suggest? Thanks, Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I don't see the point of dedicating svrconn's to a specific number of clients. Dedicating a svrconn a specific MCAUSER and sharing it among many clients is a different story. Seems you would only need one MCAUSER+srvrconn for each authority level. But to gain a semblence of security from either of those schemes, you still need to control client access to the srvrcon's. Not sure how you accomplish that. Unfortunately, I do not know what BlockIP2 is about(and neither does Google). -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 12:35 PM To: [EMAIL PROTECTED] Subject: Many Client connections - how many svrconn channels? Hi all, We have over 200 users requiring client connection from their Windows2000 workstations to the queue managers on Windows 2000 (WMQ 5.3). The company does not have and is unwilling to buy any third product right now or in the foreseeable future. I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited access. I have started using BlockIP2 as well. I have brought up the use of SSL but the company is reluctant to do that (I don t know about all the concerns surrounding the issue probably something political that I don t get involved in as a contractor). Because I want to make the client connections as secure as possible with what I have at my disposal, I feel that I should set up the rest of the 200 clients (most of whom will be in the Prod env.) the same way as the others: Dedicated svrconn channel with MCAUSER populated with a userid having limited access, and IPBlock2. But then again, since all of the interfaces are internal, maybe I could dedicate 1 svrconn to, say, 20 people. I can still give limited access to the users, leave the MCUSER blank and specify the valid IP addresses in IPBlock2. What do you think? Any ideas/insights would be much appreciated. Thanks in advance, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available
Re: Many Client connections - how many svrconn channels?
But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. Thanks Dennis. However, I think it would be safe and maybe even better to leave MCAUSER blank. Because BLOCKIP2 will allow only the users (and IP addresses) in the security exit file anyway. This would come in handy during a problem investigation -- for example, things like inquiring the status of the svrconn channel or the userid of the message on the queue etc. would indicate the actual user rather than the group userid. Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I took a look at the BLOCKIP2 URL provided by SID. Very neat. I did notice that BLOCKIP2 only supports setting the MCAUSER on SSL channels. But if you've got relatively few access levels, you can define a svrconn with appropriate MCAUSER for each and then restrict which users are permitted to use which connections from the exit. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 11:49 AM To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? Dennis, BlockIP2 is the latest version of BlockIP. It is a secrity exit program. I don't have the link on the computer that I am using right now. Maybe, someone on the list will post it. It basically lets you specify the userids and the IP addresses from which the client connections will be made. Most (if not all) of these clients will have the same authority. I am thinking of leaving the MCAUSER blank on an svrconn and specify the userids in a file to be used by the security exit. I think this would do what I want to acheive. Maybe I could secure this file by giving access only to MQ admins and MUSR_MQADMIN. What would you or or anyone else suggest? Thanks, Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: I don't see the point of dedicating svrconn's to a specific number of clients. Dedicating a svrconn a specific MCAUSER and sharing it among many clients is a different story. Seems you would only need one MCAUSER+srvrconn for each authority level. But to gain a semblence of security from either of those schemes, you still need to control client access to the srvrcon's. Not sure how you accomplish that. Unfortunately, I do not know what BlockIP2 is about(and neither does Google). -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 12:35 PM To: [EMAIL PROTECTED] Subject: Many Client connections - how many svrconn channels? Hi all, We have over 200 users requiring client connection from their Windows2000 workstations to the queue managers on Windows 2000 (WMQ 5.3). The company does not have and is unwilling to buy any third product right now or in the foreseeable future. I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited access. I have started using BlockIP2 as well. I have brought up the use of SSL but the company is reluctant to do that (I don t know about all the concerns surrounding the issue probably something political that I don t get involved in as a contractor). Because I want to make the client connections as secure as possible with what I have at my disposal, I feel that I should set up the rest of the 200 clients (most of whom will be in the Prod env.) the same way as the others: Dedicated svrconn channel with MCAUSER populated with a userid having limited access, and IPBlock2. But then again, since all of the interfaces are internal, maybe I could dedicate 1 svrconn to, say, 20 people. I can still give limited access to the users, leave the MCUSER blank and specify the valid IP addresses in IPBlock2. What do you think? Any ideas/insights would be much appreciated. Thanks in advance, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide
Many Client connections - how many svrconn channels?
Hi all, We have over 200 users requiring client connection from their Windows2000 workstations to the queue managers on Windows 2000 (WMQ 5.3). The company does not have and is unwilling to buy any third product right now or in the foreseeable future. I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited access. I have started using BlockIP2 as well. I have brought up the use of SSL but the company is reluctant to do that (I don t know about all the concerns surrounding the issue probably something political that I don t get involved in as a contractor). Because I want to make the client connections as secure as possible with what I have at my disposal, I feel that I should set up the rest of the 200 clients (most of whom will be in the Prod env.) the same way as the others: Dedicated svrconn channel with MCAUSER populated with a userid having limited access, and IPBlock2. But then again, since all of the interfaces are internal, maybe I could dedicate 1 svrconn to, say, 20 people. I can still give limited access to the users, leave the MCUSER blank and specify the valid IP addresses in IPBlock2. What do you think? Any ideas/insights would be much appreciated. Thanks in advance, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Many Client connections - how many svrconn channels?
I don't see the point of dedicating svrconn's to a specific number of clients. Dedicating a svrconn a specific MCAUSER and sharing it among many clients is a different story. Seems you would only need one MCAUSER+srvrconn for each authority level. But to gain a semblence of security from either of those schemes, you still need to control client access to the srvrcon's. Not sure how you accomplish that. Unfortunately, I do not know what BlockIP2 is about(and neither does Google). -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 12:35 PM To: [EMAIL PROTECTED] Subject: Many Client connections - how many svrconn channels? Hi all, We have over 200 users requiring client connection from their Windows2000 workstations to the queue managers on Windows 2000 (WMQ 5.3). The company does not have and is unwilling to buy any third product right now or in the foreseeable future. I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited access. I have started using BlockIP2 as well. I have brought up the use of SSL but the company is reluctant to do that (I don t know about all the concerns surrounding the issue probably something political that I don t get involved in as a contractor). Because I want to make the client connections as secure as possible with what I have at my disposal, I feel that I should set up the rest of the 200 clients (most of whom will be in the Prod env.) the same way as the others: Dedicated svrconn channel with MCAUSER populated with a userid having limited access, and IPBlock2. But then again, since all of the interfaces are internal, maybe I could dedicate 1 svrconn to, say, 20 people. I can still give limited access to the users, leave the MCUSER blank and specify the valid IP addresses in IPBlock2. What do you think? Any ideas/insights would be much appreciated. Thanks in advance, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Many Client connections - how many svrconn channels - BlockIP 2
G'Day Dennis, Here is a link to BlockIP2, it doesn't appear in google because it looks like it is not an absolute path in the URL and hence not findable by page scrapping. http://www.mrmq.dk/index.htm?tips_and_tricks.htm#BlockIP2 Sid -Original Message- From: Miller, Dennis [mailto:[EMAIL PROTECTED] Sent: Friday, 12 March 2004 8:38 AM To: [EMAIL PROTECTED] Subject: Re: Many Client connections - how many svrconn channels? I don't see the point of dedicating svrconn's to a specific number of clients. Dedicating a svrconn a specific MCAUSER and sharing it among many clients is a different story. Seems you would only need one MCAUSER+srvrconn for each authority level. But to gain a semblence of security from either of those schemes, you still need to control client access to the srvrcon's. Not sure how you accomplish that. Unfortunately, I do not know what BlockIP2 is about(and neither does Google). -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 12:35 PM To: [EMAIL PROTECTED] Subject: Many Client connections - how many svrconn channels? Hi all, We have over 200 users requiring client connection from their Windows2000 workstations to the queue managers on Windows 2000 (WMQ 5.3). The company does not have and is unwilling to buy any third product right now or in the foreseeable future. I have set up 10-15 users with a dedicated SVRCONN channels with the MCUSER set to their respective userids and giving each userid a limited access. I have started using BlockIP2 as well. I have brought up the use of SSL but the company is reluctant to do that (I don t know about all the concerns surrounding the issue probably something political that I don t get involved in as a contractor). Because I want to make the client connections as secure as possible with what I have at my disposal, I feel that I should set up the rest of the 200 clients (most of whom will be in the Prod env.) the same way as the others: Dedicated svrconn channel with MCAUSER populated with a userid having limited access, and IPBlock2. But then again, since all of the interfaces are internal, maybe I could dedicate 1 svrconn to, say, 20 people. I can still give limited access to the users, leave the MCUSER blank and specify the valid IP addresses in IPBlock2. What do you think? Any ideas/insights would be much appreciated. Thanks in advance, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
MQ under HACMP with client connections (remote JMS/MDB's)
Title: MQ under HACMP with client connections (remote JMS/MDB's) Can anyone explain what the effect would be or has done one or both of the configurations below? Active/Standby: With only 1 queue manager that has, client connections over SVRCONN channels I would think that the client would stay connected to the active queue manager as normal, but when the failover to the standby box occurs there would be a brief interruption until the client could reconnect. We are doing this from JMS Queue Connection Factories from WAS 5.0 so I think it will be ok as they are configurable retry/time-out type parameters. Do you think this is accurate? Active/Active: Instead of having a two separate client connections to two separate queue managers on each of the active boxes (this could use some kind of application side load balancing) Could it be possible to have the client connected directly to the HACMP hardware cluster using a virtual IP address or hostname if both of the active queue managers would be DefaultQueueManager and have the same channel name and port number defined? Then the application would only specify the virtual IP or hostname, channel, and port but leave the queue manager blank so the default is chosen. In essence, it would be like shared channels on z/OS. We see several issues with this that would need to be worked out (like what happens with the static port if failover occurs), but I am interested in you opinion. What were trying to achieve is having a highly available queue manager configuration remote from our WAS hardware. In this way, the same MDB can be run on multiple JVMs but listen for messages from a single shared remote queue. If any MDB were in a wait-state, it would be available to process the message. At least that is what we are going to try. If anyone has an opinion, I would like to hear it. Thanks, Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 WMQ(I) Specialist/Solutions Expert e-business Solution Advisor/Designer/Technologist
More on 'orphaned' SVRCONN connections
Last night I made the change to include TCP: KeepAlive=Yes and CHANNELS: AdoptNewMCA=ALL/Check=QM,ADDRESS,NAME and recycled the Queue Manager.. (FYI the manual says you can use 'ALL' for the AdoptNewMCACheck parm, but MQ does not like it). These parameters were not used previously. This morning I have 10 times as many 'orphaned' connections to my SYSTEM.DEF.SVRCONN channel as yesterday (several hundred connections). Except for a few connections coming from its own server, all the connections are coming from PeopleSoft web servers (using JMS listeners). What must be done to get rid of these connections? Peter Heggie 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. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: More on 'orphaned' SVRCONN connections
Hi Peter, Last night I made the change to include TCP: KeepAlive=Yes and CHANNELS: AdoptNewMCA=ALL/Check=QM,ADDRESS,NAME and recycled the Queue Manager.. (FYI the manual says you can use 'ALL' for the AdoptNewMCACheck parm, but MQ does not like it). These parameters were not used previously. This morning I have 10 times as many 'orphaned' connections to my SYSTEM.DEF.SVRCONN channel as yesterday (several hundred connections). Except for a few connections coming from its own server, all the connections are coming from PeopleSoft web servers (using JMS listeners). What must be done to get rid of these connections? I believe AdoptNewMCA is only meaningful with SDR/RCVR-type channels, not client channels. I believe KeepAlive is still the recommended approach to cleaning up orphaned client connections. Do you know what interval is specified? I believe the default on most IP stacks is 2 hours. Regards, Christopher Frank Certified I/T Specialist - WebSphere Software IBM Certified Solutions Expert - Websphere MQ MQ Integrator -- Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: More on 'orphaned' SVRCONN connections
I don't know what that interval is.. I'll have to ask a sysadmin. Its probably the default for AIX. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Frank Sent: Friday, January 09, 2004 10:24 AM To: [EMAIL PROTECTED] Subject: Re: More on 'orphaned' SVRCONN connections Hi Peter, Last night I made the change to include TCP: KeepAlive=Yes and CHANNELS: AdoptNewMCA=ALL/Check=QM,ADDRESS,NAME and recycled the Queue Manager.. (FYI the manual says you can use 'ALL' for the AdoptNewMCACheck parm, but MQ does not like it). These parameters were not used previously. This morning I have 10 times as many 'orphaned' connections to my SYSTEM.DEF.SVRCONN channel as yesterday (several hundred connections). Except for a few connections coming from its own server, all the connections are coming from PeopleSoft web servers (using JMS listeners). What must be done to get rid of these connections? I believe AdoptNewMCA is only meaningful with SDR/RCVR-type channels, not client channels. I believe KeepAlive is still the recommended approach to cleaning up orphaned client connections. Do you know what interval is specified? I believe the default on most IP stacks is 2 hours. Regards, Christopher Frank Certified I/T Specialist - WebSphere Software IBM Certified Solutions Expert - Websphere MQ MQ Integrator -- Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: More on 'orphaned' SVRCONN connections
Thanks.. At least I've got it set for the regular channels.. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Anderson Sent: Friday, January 09, 2004 11:31 AM To: [EMAIL PROTECTED] Subject: Re: More on 'orphaned' SVRCONN connections Chris is correct, AdoptNewMCA is not applicable to client connection. If the queue manager receives a request for a new connection, it will check to see if it already has a amqcrsta process running for that channel name. How it handles that request depends on if you have a AdoptNewMCA stanza in your qm.ini file or not. Client connections are not associated with the amqcrsta process, and are thus not effected by AdoptNewMCA. Cheers Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Christopher Frank [EMAIL PROTECTED]To: [EMAIL PROTECTED] COM cc: Sent by: MQSeriesSubject: Re: More on 'orphaned' SVRCONN connections List [EMAIL PROTECTED] N.AC.AT 01/09/2004 10:24 AM Please respond to MQSeries List Hi Peter, Last night I made the change to include TCP: KeepAlive=Yes and CHANNELS: AdoptNewMCA=ALL/Check=QM,ADDRESS,NAME and recycled the Queue Manager.. (FYI the manual says you can use 'ALL' for the AdoptNewMCACheck parm, but MQ does not like it). These parameters were not used previously. This morning I have 10 times as many 'orphaned' connections to my SYSTEM.DEF.SVRCONN channel as yesterday (several hundred connections). Except for a few connections coming from its own server, all the connections are coming from PeopleSoft web servers (using JMS listeners). What must be done to get rid of these connections? I believe AdoptNewMCA is only meaningful with SDR/RCVR-type channels, not client channels. I believe KeepAlive is still the recommended approach to cleaning up orphaned client connections. Do you know what interval is specified? I believe the default on most IP stacks is 2 hours. Regards, Christopher Frank Certified I/T Specialist - WebSphere Software IBM Certified Solutions Expert - Websphere MQ MQ Integrator -- Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Server Connections Channels
I have a WebMethod's client that is connecting to my MQ V5.1 Queue Manager from a remote system using a Server Connection channel. I believe the WebMethod client is not disconnecting (or ending cleanly) which results in many orphan active connections. Is there a parameter in QM.INI or another place which will stop the channel after a certain amount of inactivity? Robert S. Kasischke 415-243-6975
Re: Server Connections Channels
See AdoptNewMCA parameter for qm.ini (System Admin Guide) Bob Kasischke [EMAIL PROTECTED]To: [EMAIL PROTECTED] SFARGO.COM cc: Sent by: MQSeries List Subject: Server Connections Channels [EMAIL PROTECTED] 01/08/2004 01:43 PM Please respond to MQSeries List I have a WebMethod's client that is connecting to my MQ V5.1 Queue Manager from a remote system using a Server Connection channel. I believe the WebMethod client is not disconnecting (or ending cleanly) which results in many orphan active connections. Is there a parameter in QM.INI or another place which will stop the channel after a certain amount of inactivity? Robert S. Kasischke 415-243-6975 This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Auditting SSL Connections
Looking at using channel exits to perform audits of connections coming into an MQ manager, is there any way to inquire/access the actual distinguished name values (SSL Peer) of the verified partner? Here's the scenario: We'd like to setup to allow multiple clients to connect to the same SVRCONN channel using PKI certificates. We can control who gets access via that channel by configuring what issuing certificate authorities are trusted and using wildcarded SSL PEER settings. But we have a requirement to audit the connections. We have a channel security exit that records some values. We'd like to enhance it to capture the specifics of the SSL certs. Is this possible and what are the specific fields we'd need to access? Thanks. -tom Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Auditting SSL Connections
All are in the MQCD - see below: The following fields in this structure are not present if Version is less than MQCD_VERSION_7. SSLCipherSpec (MQCHAR32) SSL CipherSpec is an optional field. This parameter is valid for all channel types. It is supported on AIX, HP-UX, Linux, OS/400, Solaris, Windows, and z/OS. It is valid only for channel types of a transport type (TRPTYPE) of TCP. This is an input field to the exit. The length of this field is given by MQ_SSL_CIPHER_SPEC_LENGTH. The field is not present if Version is less than MQCD_VERSION_7. SSLPeerNamePtr (MQPTR) Address of the SSL peer name. This is an input field to the exit. The field is not present if Version is less than MQCD_VERSION_7. SSLPeerNameLength (MQLONG) Length of SSL peer name. This is the length in bytes of SSL peer name pointed to by SSLPeerNamePtr. This is an input field to the exit. The field is not present if Version is less than MQCD_VERSION_7. SSLClientAuth (MQLONG) Determines whether SSL client authentication is required. The value is one of the following: MQSCA_REQUIRED Client authentication required. MQSCA_OPTIONAL Client authentication optional. This is an input field to the exit. The field is not present if Version is less than MQCD_VERSION_7. Dave Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Auditting SSL Connections
Yes there is. The SSLPEER parameter is set to the remote Distinguished Name. But you must wait to the INIT-SEC phase.. Tom Fox [EMAIL PROTECTED]To: [EMAIL PROTECTED] .COMcc: Sent by: MQSeriesSubject: Auditting SSL Connections List [EMAIL PROTECTED] n.AC.AT 11/19/2003 10:24 AM Please respond to MQSeries List Looking at using channel exits to perform audits of connections coming into an MQ manager, is there any way to inquire/access the actual distinguished name values (SSL Peer) of the verified partner? Here's the scenario: We'd like to setup to allow multiple clients to connect to the same SVRCONN channel using PKI certificates. We can control who gets access via that channel by configuring what issuing certificate authorities are trusted and using wildcarded SSL PEER settings. But we have a requirement to audit the connections. We have a channel security exit that records some values. We'd like to enhance it to capture the specifics of the SSL certs. Is this possible and what are the specific fields we'd need to access? Thanks. -tom Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Multiple client connections.....
Has anyone had any problems with hundreds of client connections to a Queue Manager left connected for long periods of time (hours)? Also if there is no activity on the connection for a period of time (hour or so) will MQ automatically drop that connection and if so can I set that time limit Thanks, Dennis Bryngelson Phone: (763) 765-4224 Fax: (763) 765-3820 mailto:[EMAIL PROTECTED] * PRIVILEGED AND CONFIDENTIAL: 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. * Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Multiple client connections.....
We have several hundred users that start an MQ client app as soon as they arrive in the morning, and shut it down when they leave for the night. They are connected the whole time, and it doesn't cause any problems. As long as both halfs of the connection are alive (even if they're not especially active), MQ keeps the connection intact. I know that many of my users go hours without issuing an MQI call, and there isn't a problem. Dennis Bryngelson [EMAIL PROTECTED]To: [EMAIL PROTECTED] RDLIFE.COM cc: Sent by: MQSeries List Subject: Multiple client connections. [EMAIL PROTECTED] 11/06/2003 08:30 AM Please respond to MQSeries List Has anyone had any problems with hundreds of client connections to a Queue Manager left connected for long periods of time (hours)? Also if there is no activity on the connection for a period of time (hour or so) will MQ automatically drop that connection and if so can I set that time limit Thanks, Dennis Bryngelson Phone: (763) 765-4224 Fax: (763) 765-3820 mailto:[EMAIL PROTECTED] * PRIVILEGED AND CONFIDENTIAL: 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. * Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Client channel connections on MQV5.3
I have and MQ client V5.2.1 running on NT that client connect to Solaris MQ V5.3 (CDS05). Has anyone else seen a delay in the MQ connection of 2-3 seconds? Thanks, Dennis Bryngelson Phone: (763) 765-4224 Fax: (763) 765-3820 mailto:[EMAIL PROTECTED] * PRIVILEGED AND CONFIDENTIAL: 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. * Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Client Connections
Howdy all, This is a general question, if I want to use a security exit on a client computer, do I have to use client connections AND is there anyway around needing the table file installed on the client, can the definition be created in software only using the C++ API ? Thanks in advance Sid Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: To many SVRCONN Connections on WebSphere MQ V5.3
There are two things that can be done: One is to check if the current version of MQ that you are using properly close the connection. MQ5.2 up to csd04 had problem, i.e. if the program was not disconnected gracefully, it will think that the connection to the queue manager is still open. I would check with IBM to see if that problem was carried over to MQ5.3 or not. Two is to insure that the program closes the connection, but you have no control ... --- Nick Dilauro [EMAIL PROTECTED] wrote: You should also check the server side setting since the default is sometimes high (On Windows the default is something like 2 hours). I'm not that familiar with AIX but the following might help. www.sybase.com/detail?id=611 http://www.sybase.com/detail?id=611 Nick -Original Message- From: Bill Anderson [mailto:[EMAIL PROTECTED] Sent: Thursday, October 23, 2003 12:10 PM To: [EMAIL PROTECTED] Subject: Re: To many SVRCONN Connections on WebSphere MQ V5.3 I did forget to mention this is on AIX 3.3 / WebSphere MQ V5.3. And that is half of my problem, I don't know if the clients are holding on to the connection or not. I guess it is worth setting up the KeepAlive settings in the mq.ini file (I think that's where it goes) and see if it helps at all. Does anyone know if the problem with the Java client is correct as I explained it in my original post? I got the info from a lecture I attended in Vegas early this year. As I said, all of these connections are from external customers, so I can't do much about their code. But it would be nice to be able to give them some solid clues on what to do. Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Nick Dilauro [EMAIL PROTECTED]To: [EMAIL PROTECTED] cc: Sent by: MQSeries Subject: Re: To many SVRCONN Connections on WebSphere MQ V5.3 List [EMAIL PROTECTED] N.AC.AT 10/23/2003 02:02 PM Please respond to MQSeries List This problem might be solved by a TCP/IP KeepAlive setting. It needs to be set on the server and in the qmgr. What platform are you on? If the clients are actually holding on to all the connections this won't work. Nick -Original Message- From: Bill Anderson [mailto:[EMAIL PROTECTED] Sent: Thursday, October 23, 2003 10:25 AM To: [EMAIL PROTECTED] Subject: To many SVRCONN Connections on WebSphere MQ V5.3 On several occasions, we have had customers making 30 + (one did over 200) connections to a server connection channel. Each customer has a dedicated channel used only by them. Almost all of the connections have very low message counts (like 4 or 6) that do not change. Only one or two have significant message counts (like 500 + and rising). I am assuming that their applications are misbehaving by making erroneous connections for some reason. Many of the customers had contractors develop the code, and they have no Idea what it is doing (great !) but they agree they do not intend to make so many connections. I remember hearing that applications written as Java clients can experience false 2009 errors which, could cause them to re-connect. The problem being that the original connections is still valid. That would explain the problem I think. But regardless of the cause of the problem, I need a way to manage it on my side. I can't limit the number of connections on a channel by channel basis so I need to figure out a way to discover erroneous connections and kill them. They all come from the same IP address, and that don't help at all. I may have to just bring the whole channel down and restart it. But I would really like to find a way to have the queue manager end the channels that are not in use. If the connection between a client application and an in between router was truly lost, but the queue manager side of the router was OK, would the queue manager not at some point clean up the defunct connection? Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http
Re: To many SVRCONN Connections on WebSphere MQ V5.3
This problem might be solved by a TCP/IP KeepAlive setting. It needs to be set on the server and in the qmgr. What platform are you on? If the clients are actually holding on to all the connections this won't work. Nick -Original Message- From: Bill Anderson [mailto:[EMAIL PROTECTED] Sent: Thursday, October 23, 2003 10:25 AM To: [EMAIL PROTECTED] Subject: To many SVRCONN Connections on WebSphere MQ V5.3 On several occasions, we have had customers making 30 + (one did over 200) connections to a server connection channel. Each customer has a dedicated channel used only by them. Almost all of the connections have very low message counts (like 4 or 6) that do not change. Only one or two have significant message counts (like 500 + and rising). I am assuming that their applications are misbehaving by making erroneous connections for some reason. Many of the customers had contractors develop the code, and they have no Idea what it is doing (great !) but they agree they do not intend to make so many connections. I remember hearing that applications written as Java clients can experience false 2009 errors which, could cause them to re-connect. The problem being that the original connections is still valid. That would explain the problem I think. But regardless of the cause of the problem, I need a way to manage it on my side. I can't limit the number of connections on a channel by channel basis so I need to figure out a way to discover erroneous connections and kill them. They all come from the same IP address, and that don't help at all. I may have to just bring the whole channel down and restart it. But I would really like to find a way to have the queue manager end the channels that are not in use. If the connection between a client application and an in between router was truly lost, but the queue manager side of the router was OK, would the queue manager not at some point clean up the defunct connection? Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: To many SVRCONN Connections on WebSphere MQ V5.3
What platform and CSD are you on? we had a lot of defunct processes on 5.2 after applying the latest CSD at that time it has stopped. We migrated from 5.2 CSD 5 to 5.3 CSD4 (where we don't see this behaviour either), so it could be solved by a CSD. Michael -Oorspronkelijk bericht- Van: MQSeries List [mailto:[EMAIL PROTECTED] Bill Anderson Verzonden: donderdag 23 oktober 2003 19:25 Aan: [EMAIL PROTECTED] Onderwerp: To many SVRCONN Connections on WebSphere MQ V5.3 On several occasions, we have had customers making 30 + (one did over 200) connections to a server connection channel. Each customer has a dedicated channel used only by them. Almost all of the connections have very low message counts (like 4 or 6) that do not change. Only one or two have significant message counts (like 500 + and rising). I am assuming that their applications are misbehaving by making erroneous connections for some reason. Many of the customers had contractors develop the code, and they have no Idea what it is doing (great !) but they agree they do not intend to make so many connections. I remember hearing that applications written as Java clients can experience false 2009 errors which, could cause them to re-connect. The problem being that the original connections is still valid. That would explain the problem I think. But regardless of the cause of the problem, I need a way to manage it on my side. I can't limit the number of connections on a channel by channel basis so I need to figure out a way to discover erroneous connections and kill them. They all come from the same IP address, and that don't help at all. I may have to just bring the whole channel down and restart it. But I would really like to find a way to have the queue manager end the channels that are not in use. If the connection between a client application and an in between router was truly lost, but the queue manager side of the router was OK, would the queue manager not at some point clean up the defunct connection? Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: To many SVRCONN Connections on WebSphere MQ V5.3
I did forget to mention this is on AIX 3.3 / WebSphere MQ V5.3. And that is half of my problem, I don't know if the clients are holding on to the connection or not. I guess it is worth setting up the KeepAlive settings in the mq.ini file (I think that's where it goes) and see if it helps at all. Does anyone know if the problem with the Java client is correct as I explained it in my original post? I got the info from a lecture I attended in Vegas early this year. As I said, all of these connections are from external customers, so I can't do much about their code. But it would be nice to be able to give them some solid clues on what to do. Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Nick Dilauro [EMAIL PROTECTED]To: [EMAIL PROTECTED] cc: Sent by: MQSeriesSubject: Re: To many SVRCONN Connections on WebSphere MQ V5.3 List [EMAIL PROTECTED] N.AC.AT 10/23/2003 02:02 PM Please respond to MQSeries List This problem might be solved by a TCP/IP KeepAlive setting. It needs to be set on the server and in the qmgr. What platform are you on? If the clients are actually holding on to all the connections this won't work. Nick -Original Message- From: Bill Anderson [mailto:[EMAIL PROTECTED] Sent: Thursday, October 23, 2003 10:25 AM To: [EMAIL PROTECTED] Subject: To many SVRCONN Connections on WebSphere MQ V5.3 On several occasions, we have had customers making 30 + (one did over 200) connections to a server connection channel. Each customer has a dedicated channel used only by them. Almost all of the connections have very low message counts (like 4 or 6) that do not change. Only one or two have significant message counts (like 500 + and rising). I am assuming that their applications are misbehaving by making erroneous connections for some reason. Many of the customers had contractors develop the code, and they have no Idea what it is doing (great !) but they agree they do not intend to make so many connections. I remember hearing that applications written as Java clients can experience false 2009 errors which, could cause them to re-connect. The problem being that the original connections is still valid. That would explain the problem I think. But regardless of the cause of the problem, I need a way to manage it on my side. I can't limit the number of connections on a channel by channel basis so I need to figure out a way to discover erroneous connections and kill them. They all come from the same IP address, and that don't help at all. I may have to just bring the whole channel down and restart it. But I would really like to find a way to have the queue manager end the channels that are not in use. If the connection between a client application and an in between router was truly lost, but the queue manager side of the router was OK, would the queue manager not at some point clean up the defunct connection? Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: To many SVRCONN Connections on WebSphere MQ V5.3
All... Try lowering the heartbeat interval from the 300 default to 30 seconds then change the queue manager configuration by adding the AdoptNewMCA=ALL AdoptNewMCACheck=ALL. Check the System Admin guide for details... Phil Scott Gray [EMAIL PROTECTED]To: [EMAIL PROTECTED] cc: Sent by: MQSeriesSubject: Re: To many SVRCONN Connections on WebSphere MQ V5.3 List [EMAIL PROTECTED] n.AC.AT 10/23/2003 02:10 PM Please respond to MQSeries List actually you can...there is a MAXCONN channel exit. Look at: http://www-3.ibm.com/software/integration/support/supportpacs/individual/me7 1.html Source is provided. Scott -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Bill Anderson Sent: Thursday, October 23, 2003 1:25 PM To: [EMAIL PROTECTED] Subject: To many SVRCONN Connections on WebSphere MQ V5.3 On several occasions, we have had customers making 30 + (one did over 200) connections to a server connection channel. Each customer has a dedicated channel used only by them. Almost all of the connections have very low message counts (like 4 or 6) that do not change. Only one or two have significant message counts (like 500 + and rising). I am assuming that their applications are misbehaving by making erroneous connections for some reason. Many of the customers had contractors develop the code, and they have no Idea what it is doing (great !) but they agree they do not intend to make so many connections. I remember hearing that applications written as Java clients can experience false 2009 errors which, could cause them to re-connect. The problem being that the original connections is still valid. That would explain the problem I think. But regardless of the cause of the problem, I need a way to manage it on my side. I can't limit the number of connections on a channel by channel basis so I need to figure out a way to discover erroneous connections and kill them. They all come from the same IP address, and that don't help at all. I may have to just bring the whole channel down and restart it. But I would really like to find a way to have the queue manager end the channels that are not in use. If the connection between a client application and an in between router was truly lost, but the queue manager side of the router was OK, would the queue manager not at some point clean up the defunct connection? Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: To many SVRCONN Connections on WebSphere MQ V5.3
Title: RE: To many SVRCONN Connections on WebSphere MQ V5.3 You should also check the server side setting since the default is sometimes high (On Windows the default is something like 2 hours). I'm not that familiar with AIX but the following might help. www.sybase.com/detail?id=611 Nick -Original Message- From: Bill Anderson [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 23, 2003 12:10 PM To: [EMAIL PROTECTED] Subject: Re: To many SVRCONN Connections on WebSphere MQ V5.3 I did forget to mention this is on AIX 3.3 / WebSphere MQ V5.3. And that is half of my problem, I don't know if the clients are holding on to the connection or not. I guess it is worth setting up the KeepAlive settings in the mq.ini file (I think that's where it goes) and see if it helps at all. Does anyone know if the problem with the Java client is correct as I explained it in my original post? I got the info from a lecture I attended in Vegas early this year. As I said, all of these connections are from external customers, so I can't do much about their code. But it would be nice to be able to give them some solid clues on what to do. Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Nick Dilauro [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Sent by: MQSeries Subject: Re: To many SVRCONN Connections on WebSphere MQ V5.3 List [EMAIL PROTECTED] N.AC.AT 10/23/2003 02:02 PM Please respond to MQSeries List This problem might be solved by a TCP/IP KeepAlive setting. It needs to be set on the server and in the qmgr. What platform are you on? If the clients are actually holding on to all the connections this won't work. Nick -Original Message- From: Bill Anderson [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 23, 2003 10:25 AM To: [EMAIL PROTECTED] Subject: To many SVRCONN Connections on WebSphere MQ V5.3 On several occasions, we have had customers making 30 + (one did over 200) connections to a server connection channel. Each customer has a dedicated channel used only by them. Almost all of the connections have very low message counts (like 4 or 6) that do not change. Only one or two have significant message counts (like 500 + and rising). I am assuming that their applications are misbehaving by making erroneous connections for some reason. Many of the customers had contractors develop the code, and they have no Idea what it is doing (great !) but they agree they do not intend to make so many connections. I remember hearing that applications written as Java clients can experience false 2009 errors which, could cause them to re-connect. The problem being that the original connections is still valid. That would explain the problem I think. But regardless of the cause of the problem, I need a way to manage it on my side. I can't limit the number of connections on a channel by channel basis so I need to figure out a way to discover erroneous connections and kill them. They all come from the same IP address, and that don't help at all. I may have to just bring the whole channel down and restart it. But I would really like to find a way to have the queue manager end the channels that are not in use. If the connection between a client application and an in between router was truly lost, but the queue manager side of the router was OK, would the queue manager not at some point clean up the defunct connection? Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: rc=2195 for java client connections to MQSeries 5.2
Hi Vitaliy, unless you can find either an FDC or a log file on the client side, you will have difficulty chasing this down. Unexpected Error could mean almost anything, although most times I have seen it, it is due to MQ processes have died and MQ then having problems. Regards... Neil Casey. |-+ | | Vitaliy Ilyin| | | [EMAIL PROTECTED]| | | HOO.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | n.AC.AT | | || | || | | 23/07/2003 14:32 | | | Please respond to| | | MQSeries List| | || |-+ --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: rc=2195 for java client connections to MQSeries 5.2 | --| Hi all, I know that this question popped up several times already in discussions already. Still, I didn't find a meaningful, precise and concise answer at either list server or mqseries.net to why this might be happening and what could be the possible reason for this error. The environment: MQSeries ma88 java client classes based application occasionally gets 2195 during MQPUT/MQGET calls connecting to MQ v5.2 with CSD03 on aix4.3 and to Solaris 78 with MQ v5.2 with CSD05. No FFST/FDC files on the server (on a client side they use jar files with ma88 installed). This situation seem to be happening randomly. Again, here we are talking java classes going against v5.2 with different CSD levels on different platforms. Any suggestions/clues?? Thanks a lot, Vitaliy = Vitaliy Ilyin Principal Middleware Architect IBM Certified Solutions Expert - WMQ (MQSeries v5.3) WMQI (WebSphereMQ Integrator) IBM Certified Specialist- WMQ (MQSeries v5.3) WMQI (WebSphereMQ Integrator) IBM Certified Developer - WMQI (MQSeries v5.2) 781-363-3474 http://www.ICnowledge.com __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
rc=2195 for java client connections to MQSeries 5.2
Hi all, I know that this question popped up several times already in discussions already. Still, I didn't find a meaningful, precise and concise answer at either list server or mqseries.net to why this might be happening and what could be the possible reason for this error. The environment: MQSeries ma88 java client classes based application occasionally gets 2195 during MQPUT/MQGET calls connecting to MQ v5.2 with CSD03 on aix4.3 and to Solaris 78 with MQ v5.2 with CSD05. No FFST/FDC files on the server (on a client side they use jar files with ma88 installed). This situation seem to be happening randomly. Again, here we are talking java classes going against v5.2 with different CSD levels on different platforms. Any suggestions/clues?? Thanks a lot, Vitaliy = Vitaliy Ilyin Principal Middleware Architect IBM Certified Solutions Expert - WMQ (MQSeries v5.3) WMQI (WebSphereMQ Integrator) IBM Certified Specialist- WMQ (MQSeries v5.3) WMQI (WebSphereMQ Integrator) IBM Certified Developer - WMQI (MQSeries v5.2) 781-363-3474 http://www.ICnowledge.com __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Multipe Connections at the same time possible?
Hi all, Need a clarification: When it says in the manuals that via a channel table your MQ Client app can connect to multiple qmgrs, does it mean that one connection or multiple connections at the same time? Also, on MQ server 5.3 on Windows NT server: If you have 3 qmgrs on the same machine, and your server app resides on that machine, can your server app connect to more than 1 qmgr at the same time (getting 3 HCONNs). I do not see any reason why multiple concurrent connections may not be possible, as you may be able to get multiple conn handles. But I just would like to confirm that... How is it on OS/390? Thanks, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Multipe Connections at the same time possible? A bit more info
I should re-word this part: Also, on MQ server 5.3 on Windows NT server: If you have 3 qmgrs on the same machine, and your server app resides on that machine, can your server app connect to more than 1 qmgr at the same time -- if it knows the names of these queue managers (not via a channel table of course which is accessable only to clients). Thanks, Ruzi --- Ruzi R [EMAIL PROTECTED] wrote: Hi all, Need a clarification: When it says in the manuals that via a channel table your MQ Client app can connect to multiple qmgrs, does it mean that one connection or multiple connections at the same time? Also, on MQ server 5.3 on Windows NT server: If you have 3 qmgrs on the same machine, and your server app resides on that machine, can your server app connect to more than 1 qmgr at the same time (getting 3 HCONNs). I do not see any reason why multiple concurrent connections may not be possible, as you may be able to get multiple conn handles. But I just would like to confirm that... How is it on OS/390? Thanks, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Multipe Connections at the same time possible?
Title: RE: Multipe Connections at the same time possible? you can certainly connect to as many qmgrs as you have and want. just need more handles open, and in the case of client, as many client connections defined. But it's not very common to connect to more than one qmgr at a time, although using client, you may need to connect to more than one qmgr. that's the convenience of using MQ client. cheers, Benjamin Zhou State Street. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 26, 2003 8:31 AM To: [EMAIL PROTECTED] Subject: Multipe Connections at the same time possible? Hi all, Need a clarification: When it says in the manuals that via a channel table your MQ Client app can connect to multiple qmgrs, does it mean that one connection or multiple connections at the same time? Also, on MQ server 5.3 on Windows NT server: If you have 3 qmgrs on the same machine, and your server app resides on that machine, can your server app connect to more than 1 qmgr at the same time (getting 3 HCONNs). I do not see any reason why multiple concurrent connections may not be possible, as you may be able to get multiple conn handles. But I just would like to confirm that... How is it on OS/390? Thanks, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Multipe Connections at the same time possible? A bit more info
Ruzi, You cannot have more than one queue manager connected from the same application unless you are using threads. If you are using threads, then you can connect to more than one queue manager from within the same application process, but you need to do so in different threads and nota single one. Again you have to bear in mind that you cannot share Hconnsbetween threads. Cheers Kumar ---Original Message--- From: MQSeries List Date: Thursday, June 26, 2003 11:03:57 AM To: [EMAIL PROTECTED] Subject: Re: Multipe Connections at the same time possible? A bit more info I should re-word this part: Also, on MQ server 5.3 on Windows NT server: If you have 3 qmgrs on the same machine, and your server app resides on that machine, can your server app connect to more than 1 qmgr at the same time -- if it knows the names of these queue managers (not via a channel table of course which is accessable only to clients). Thanks, Ruzi --- Ruzi R [EMAIL PROTECTED] wrote: Hi all, Need a clarification: When it says in the manuals that via a channel table your MQ Client app can connect to multiple qmgrs, does it mean that "one" connection or "multiple" connections at the same time? Also, on MQ server 5.3 on Windows NT server: If you have 3 qmgrs on the same machine, and your server app resides on that machine, can your server app connect to more than 1 qmgr at the same time (getting 3 HCONNs). I do not see any reason why multiple concurrent connections may not be possible, as you may be able to get multiple conn handles. But I just would like to confirm that... How is it on OS/390? Thanks, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive . IncrediMail - Email has finally evolved - Click Here
Re: Multipe Connections at the same time possible? A bit more info
Just a small clarification, my previous response was with reference to you being a serve app. Cheers Kumar ---Original Message--- From: MQSeries List Date: Thursday, June 26, 2003 11:03:57 AM To: [EMAIL PROTECTED] Subject: Re: Multipe Connections at the same time possible? A bit more info I should re-word this part: Also, on MQ server 5.3 on Windows NT server: If you have 3 qmgrs on the same machine, and your server app resides on that machine, can your server app connect to more than 1 qmgr at the same time -- if it knows the names of these queue managers (not via a channel table of course which is accessable only to clients). Thanks, Ruzi --- Ruzi R [EMAIL PROTECTED] wrote: Hi all, Need a clarification: When it says in the manuals that via a channel table your MQ Client app can connect to multiple qmgrs, does it mean that "one" connection or "multiple" connections at the same time? Also, on MQ server 5.3 on Windows NT server: If you have 3 qmgrs on the same machine, and your server app resides on that machine, can your server app connect to more than 1 qmgr at the same time (getting 3 HCONNs). I do not see any reason why multiple concurrent connections may not be possible, as you may be able to get multiple conn handles. But I just would like to confirm that... How is it on OS/390? Thanks, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive . IncrediMail - Email has finally evolved - Click Here
Re: Multipe Connections at the same time possible?
Thanks Benjamin and Kumar... I thought so too... Ruzi --- Benjamin Zhou [EMAIL PROTECTED] wrote: you can certainly connect to as many qmgrs as you have and want. just need more handles open, and in the case of client, as many client connections defined. But it's not very common to connect to more than one qmgr at a time, although using client, you may need to connect to more than one qmgr. that's the convenience of using MQ client. cheers, Benjamin Zhou State Street. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 8:31 AM To: [EMAIL PROTECTED] Subject: Multipe Connections at the same time possible? Hi all, Need a clarification: When it says in the manuals that via a channel table your MQ Client app can connect to multiple qmgrs, does it mean that one connection or multiple connections at the same time? Also, on MQ server 5.3 on Windows NT server: If you have 3 qmgrs on the same machine, and your server app resides on that machine, can your server app connect to more than 1 qmgr at the same time (getting 3 HCONNs). I do not see any reason why multiple concurrent connections may not be possible, as you may be able to get multiple conn handles. But I just would like to confirm that... How is it on OS/390? Thanks, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Multipe Connections at the same time possible? A bit more info
There are two types of connections: client connections and server connections. You can do either from an application that runs on the same machine as the MQ server. On a machine without an MQ server you can only use client connections. Using server connections, an application can only connect to one MQ server at a time. Using client connections, an application can connect to multiple MQ servers--even if they are on the same machine as the application. -Original Message- From: Ruzi R [SMTP:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 6:48 AM To: [EMAIL PROTECTED] Subject: Re: Multipe Connections at the same time possible? A bit more info I should re-word this part: Also, on MQ server 5.3 on Windows NT server: If you have 3 qmgrs on the same machine, and your server app resides on that machine, can your server app connect to more than 1 qmgr at the same time -- if it knows the names of these queue managers (not via a channel table of course which is accessable only to clients). Thanks, Ruzi --- Ruzi R [EMAIL PROTECTED] wrote: Hi all, Need a clarification: When it says in the manuals that via a channel table your MQ Client app can connect to multiple qmgrs, does it mean that one connection or multiple connections at the same time? Also, on MQ server 5.3 on Windows NT server: If you have 3 qmgrs on the same machine, and your server app resides on that machine, can your server app connect to more than 1 qmgr at the same time (getting 3 HCONNs). I do not see any reason why multiple concurrent connections may not be possible, as you may be able to get multiple conn handles. But I just would like to confirm that... How is it on OS/390? Thanks, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Multipe Connections at the same time possible? A bit more info
Dennis, Using server connections, an application can only connect to one MQ server at a time. If the App is threaded, can't each thread connect to a different qmgr at the same time? Thanks, Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: There are two types of connections: client connections and server connections. You can do either from an application that runs on the same machine as the MQ server. On a machine without an MQ server you can only use client connections. Using server connections, an application can only connect to one MQ server at a time. Using client connections, an application can connect to multiple MQ servers--even if they are on the same machine as the application. -Original Message- From: Ruzi R [SMTP:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 6:48 AM To: [EMAIL PROTECTED] Subject: Re: Multipe Connections at the same time possible? A bit more info I should re-word this part: Also, on MQ server 5.3 on Windows NT server: If you have 3 qmgrs on the same machine, and your server app resides on that machine, can your server app connect to more than 1 qmgr at the same time -- if it knows the names of these queue managers (not via a channel table of course which is accessable only to clients). Thanks, Ruzi --- Ruzi R [EMAIL PROTECTED] wrote: Hi all, Need a clarification: When it says in the manuals that via a channel table your MQ Client app can connect to multiple qmgrs, does it mean that one connection or multiple connections at the same time? Also, on MQ server 5.3 on Windows NT server: If you have 3 qmgrs on the same machine, and your server app resides on that machine, can your server app connect to more than 1 qmgr at the same time (getting 3 HCONNs). I do not see any reason why multiple concurrent connections may not be possible, as you may be able to get multiple conn handles. But I just would like to confirm that... How is it on OS/390? Thanks, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Multipe Connections at the same time possible? A bit more info
I believe V5.3 on NT differentiates applications at the thread level, so each thread can connect to a different qmgr. -Original Message- From: Ruzi R [SMTP:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 11:30 AM To: [EMAIL PROTECTED] Subject: Re: Multipe Connections at the same time possible? A bit more info Dennis, Using server connections, an application can only connect to one MQ server at a time. If the App is threaded, can't each thread connect to a different qmgr at the same time? Thanks, Ruzi --- Miller, Dennis [EMAIL PROTECTED] wrote: There are two types of connections: client connections and server connections. You can do either from an application that runs on the same machine as the MQ server. On a machine without an MQ server you can only use client connections. Using server connections, an application can only connect to one MQ server at a time. Using client connections, an application can connect to multiple MQ servers--even if they are on the same machine as the application. -Original Message- From: Ruzi R [SMTP:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 6:48 AM To: [EMAIL PROTECTED] Subject: Re: Multipe Connections at the same time possible? A bit more info I should re-word this part: Also, on MQ server 5.3 on Windows NT server: If you have 3 qmgrs on the same machine, and your server app resides on that machine, can your server app connect to more than 1 qmgr at the same time -- if it knows the names of these queue managers (not via a channel table of course which is accessable only to clients). Thanks, Ruzi --- Ruzi R [EMAIL PROTECTED] wrote: Hi all, Need a clarification: When it says in the manuals that via a channel table your MQ Client app can connect to multiple qmgrs, does it mean that one connection or multiple connections at the same time? Also, on MQ server 5.3 on Windows NT server: If you have 3 qmgrs on the same machine, and your server app resides on that machine, can your server app connect to more than 1 qmgr at the same time (getting 3 HCONNs). I do not see any reason why multiple concurrent connections may not be possible, as you may be able to get multiple conn handles. But I just would like to confirm that... How is it on OS/390? Thanks, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: opening multiple connections from C program on solaris
Hi, The reason for requiring multiple connections - is the application is designed as a gateway to two other applicatins. Hence there is a possiblity of getting messages from either interfaces asynchronously. further the async. processing is based on a dialog. Unless the dialog is complete, messages that are retreived or put cannot be commited. If there is an error in completing the dialog, then it should be rolled-back for the particular message in question, rather than for all messges that have been handled on that connection (within a given time-interval), but the status of other messages in other queues would be different ( because the dialog may not be complete ..because the application is waiting for a response to arrive, while it is currently someother message on a different queue). Then we have a problem of data consistency. rgds lakshmi lakshmi, I think I understand now, you have a dialog which retrieves a message from the server under a transaction, this drives a dialog and when the dialog is complete you want to send a response and commit the whole as a transaction. This seems reasonable, however, if you are acting on behalf of multiple dialogs and messages can arrive on the server at any time then I would have throught you'd have to do this as a multithreaded application anyway. You can't, sadly, wait on an MQGET and on, say, a semaphore at the same time. Is there any particular reason why you want to restrict yourself to a single thread ? Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: opening multiple connections from C program on solaris
Hi, THanks for your response. We are using MQ 5.2 on all our dev/test/production platforms. We can migrate to MQ 5.3 only when it has tested in our DEV. env. I have two choices now either to upgrade to MQ 5.3 or to make application multi/threaded. We are unable to install MQ 5.3 since our dev. is still under Solris 2.6 (for dependencies from other s/w residing on the server). Right now except for the MQ part - all other events in the program are driven by a Semaphore. For the MQ part - polling on MQGET is done. Looks like i have to do some re-design with mutli-threading, under the given circumstances. thanks and regards lakshmi -Original Message- From: Paul Clarke [SMTP:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 1:47 PM To: [EMAIL PROTECTED] Subject: Re: opening multiple connections from C program on solaris Hi, The reason for requiring multiple connections - is the application is designed as a gateway to two other applicatins. Hence there is a possiblity of getting messages from either interfaces asynchronously. further the async. processing is based on a dialog. Unless the dialog is complete, messages that are retreived or put cannot be commited. If there is an error in completing the dialog, then it should be rolled-back for the particular message in question, rather than for all messges that have been handled on that connection (within a given time-interval), but the status of other messages in other queues would be different ( because the dialog may not be complete ..because the application is waiting for a response to arrive, while it is currently someother message on a different queue). Then we have a problem of data consistency. rgds lakshmi lakshmi, I think I understand now, you have a dialog which retrieves a message from the server under a transaction, this drives a dialog and when the dialog is complete you want to send a response and commit the whole as a transaction. This seems reasonable, however, if you are acting on behalf of multiple dialogs and messages can arrive on the server at any time then I would have throught you'd have to do this as a multithreaded application anyway. You can't, sadly, wait on an MQGET and on, say, a semaphore at the same time. Is there any particular reason why you want to restrict yourself to a single thread ? Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive The content of this e-mail is intended only for the confidential use of the person addressed. If you have received this message in error, please notify us immediately by electronic mail, by telephone or by fax at the above num- bers. E-mail communications are not secure and therefore we do not accept any res- ponsibility for the confidentiality or altered contents of this message. Please be aware that SIS Group and its subsidiary companies cannot accept any orders or other legally binding correspondence with a participant as part of an E-mail. The views expressed above are not necessarily those held by SIS Group and its subsidiary companies and not binding for them. exfe Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: opening multiple connections from C program on solaris
Try using MQCONNX and link your program with the client libraries. Example
MQCONNX related code follows.
MQCNO connectOpts = {MQCNO_DEFAULT};
MQCDclientDef = {MQCD_CLIENT_CONN_DEFAULT};
strncpy(clientDef.ConnectionName, connNameStr, MQ_CONN_NAME_LENGTH);
strncpy(clientDef.ChannelName, channelNameStr, MQ_CHANNEL_NAME_LENGTH);
connectOpts.ClientConnPtr = clientDef;
connectOpts.Version = MQCNO_VERSION_2;
MQCONNX(qMgrNameStr,connectOpts,hConn,compCode,reasonCode);
Good luck.
Tim A
Lakshmi, Saraswathi
[EMAIL PROTECTED]To: [EMAIL PROTECTED]
SCLEAR.COM cc:
Sent by: MQSeries ListSubject: opening multiple
connections from C program on solaris
[EMAIL PROTECTED]
AT
28/05/2003 18:15
Please respond to
MQSeries List
Hi,
Is it possible to set-up multiple MQ connections from a program in Solaris
env. I tired to set-up multiple connections, but the connection handle is
the same for all of them. Is it possible to get unique connection-handles
for each connection.
The reason for this requirement is that the program has to handle multiple
queues, and the application has to issue MQCMIT based on the data received
in the queues. The program is designed for a real-time asynchronous
communication. The application is up-running all the time and keeps
polling it other interfaces to check if data has arrived. Based n the data
received from other interfaces, it has to PUT the message into an MQ Queue
and commit it. It is also a single -threaded application.
mfg
lakshmi
The content of this e-mail is intended only for the confidential use of the
person addressed. If you have received this message in error, please notify
us immediately by electronic mail, by telephone or by fax at the above num-
bers.
E-mail communications are not secure and therefore we do not accept any
res-
ponsibility for the confidentiality or altered contents of this message.
Please be aware that SIS Group and its subsidiary companies cannot accept
any orders or other legally binding correspondence with a participant as
part of an E-mail. The views expressed above are not necessarily those held
by SIS Group and its subsidiary companies and not binding for them.
exfe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
opening multiple connections from C program on solaris
Hi, Is it possible to set-up multiple MQ connections from a program in Solaris env. I tired to set-up multiple connections, but the connection handle is the same for all of them. Is it possible to get unique connection-handles for each connection. The reason for this requirement is that the program has to handle multiple queues, and the application has to issue MQCMIT based on the data received in the queues. The program is designed for a real-time asynchronous communication. The application is up-running all the time and keeps polling it other interfaces to check if data has arrived. Based n the data received from other interfaces, it has to PUT the message into an MQ Queue and commit it. It is also a single -threaded application. mfg lakshmi The content of this e-mail is intended only for the confidential use of the person addressed. If you have received this message in error, please notify us immediately by electronic mail, by telephone or by fax at the above num- bers. E-mail communications are not secure and therefore we do not accept any res- ponsibility for the confidentiality or altered contents of this message. Please be aware that SIS Group and its subsidiary companies cannot accept any orders or other legally binding correspondence with a participant as part of an E-mail. The views expressed above are not necessarily those held by SIS Group and its subsidiary companies and not binding for them. exfe Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: opening multiple connections from C program on solaris
Hi, Is it possible to set-up multiple MQ connections from a program in Solaris env. I tired to set-up multiple connections, but the connection handle is the same for all of them. Is it possible to get unique connection-handles for each connection. The reason for this requirement is that the program has to handle multiple queues, and the application has to issue MQCMIT based on the data received in the queues. The program is designed for a real-time asynchronous communication. The application is up-running all the time and keeps polling it other interfaces to check if data has arrived. Based n the data received from other interfaces, it has to PUT the message into an MQ Queue and commit it. It is also a single -threaded application. mfg lakshmi Prior to 5.3 you could only have one connection to one Queue Manager in each thread. Since your application is single threaded then you can only have one connection. I would expect you to get back reason code MQRC_ALREADY_CONNECTED on your subsequent attempts to connect. In 5.3 you can ask for 'shared' connection when you issue MQCONNX. This connection can be used across threads and you can issue MQCONN multiple times on the same thread. What I don't quite understand is why, in a single threaded application that seems to be issuing one MQPUT, you need to have multiple connections to the Queue Manager anyway. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: opening multiple connections from C program on solaris
Hi, The reason for requiring multiple connections - is the application is designed as a gateway to two other applicatins. Hence there is a possiblity of getting messages from either interfaces asynchronously. further the async. processing is based on a dialog. Unless the dialog is complete, messages that are retreived or put cannot be commited. If there is an error in completing the dialog, then it should be rolled-back for the particular message in question, rather than for all messges that have been handled on that connection (within a given time-interval), but the status of other messages in other queues would be different ( because the dialog may not be complete ..because the application is waiting for a response to arrive, while it is currently someother message on a different queue). Then we have a problem of data consistency. rgds lakshmi -Original Message- From: Paul Clarke [SMTP:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 11:21 AM To: [EMAIL PROTECTED] Subject: Re: opening multiple connections from C program on solaris Hi, Is it possible to set-up multiple MQ connections from a program in Solaris env. I tired to set-up multiple connections, but the connection handle is the same for all of them. Is it possible to get unique connection-handles for each connection. The reason for this requirement is that the program has to handle multiple queues, and the application has to issue MQCMIT based on the data received in the queues. The program is designed for a real-time asynchronous communication. The application is up-running all the time and keeps polling it other interfaces to check if data has arrived. Based n the data received from other interfaces, it has to PUT the message into an MQ Queue and commit it. It is also a single -threaded application. mfg lakshmi Prior to 5.3 you could only have one connection to one Queue Manager in each thread. Since your application is single threaded then you can only have one connection. I would expect you to get back reason code MQRC_ALREADY_CONNECTED on your subsequent attempts to connect. In 5.3 you can ask for 'shared' connection when you issue MQCONNX. This connection can be used across threads and you can issue MQCONN multiple times on the same thread. What I don't quite understand is why, in a single threaded application that seems to be issuing one MQPUT, you need to have multiple connections to the Queue Manager anyway. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive The content of this e-mail is intended only for the confidential use of the person addressed. If you have received this message in error, please notify us immediately by electronic mail, by telephone or by fax at the above num- bers. E-mail communications are not secure and therefore we do not accept any res- ponsibility for the confidentiality or altered contents of this message. Please be aware that SIS Group and its subsidiary companies cannot accept any orders or other legally binding correspondence with a participant as part of an E-mail. The views expressed above are not necessarily those held by SIS Group and its subsidiary companies and not binding for them. exfe Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Client IP connections direct to an OS/390
Ole Den Boy brings up a VERY gud point. Adding to that. It is easier and cheaper to scale a UNIX/NT concentrator than a zOS box. If the need occurs you can certainly add additional concentrators to support additional client connections if your connectivity solution is not zOS. Plus you don't have to do battle with the Dark Lord of security and his sister the Queen of MQ administration on the Mainframe!! bobbee From: Miller, Dennis [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Client IP connections direct to an OS/390 Date: Thu, 13 Mar 2003 08:01:21 -0800 TCP in, SNA out? Now I'm confused. I thought you were replacing TCP client connections to the NT gateway/concentrators with TCP client connections directly to OS/390. My point about performance is mostly from the standpoint of the OS/390. If you have message channels coming in from another qmgr, you get a significant performance gain from the batching of messages (especially with high volumes like what you mention). On the other hand, if you have MQI (client) channels coming in, there is no batching whatsoever. Each MQI request comes in as one (or more) individual messages on a channel dedicated to that MQI request. Furthermore, the return path for that channel is blocked until the MQI request is satisfied. Batchsize and interval do not pertain to those kind of channels. As for client channels recyling, either the application is disconnecting or TCP is. The qmgr doesn't have much control of it--another reason you may be happier with message channels inbound from the concentrator. -Original Message- From: Dave Corbett [SMTP:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 6:52 AM To: [EMAIL PROTECTED] Subject: Re: Client IP connections direct to an OS/390 Dennis. Thanks for your thoughts on this. I'm not sure that batching of messages really matters, especially since we are TCP in and SNA out. Our batch size is set to 50 and the batch interval set 100. We did some extensive tuning with the VTAM settings to make sure it worked as well as possible (setting RU sizes, pacing, and other NCP parameters). It just seems that skipping a box in between the app server and mainframe should increase performance by itself. My real outstanding question is, why do we get thousands of messages showing channels starting and going inactive in the CHIN log? We had an occasion last Sunday where we had between 6 and 7 thousand messages in the space of an hour. I don't understand what it is that drives MQ to be bouncing these connections like this. We have also sent this question to IBM for a better understanding. We'll discuss your thoughts on putting the QMGRs on the app servers, but we were originally told (in 1998) that we needed the MQ servers to be on their own boxes. Thanks, David Corbett Work: 651-205-2714 Pager: 651-610-3842 |-+--- | | Miller, Dennis| | | [EMAIL PROTECTED]| | | COM| | | Sent by:| | | MQSeries List | | | [EMAIL PROTECTED]| | | en.AC.AT | | | | | | | | | 03/11/2003 09:37| | | AM | | | Please respond | | | to MQSeries| | | List | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Re: Client IP connections direct to an OS/390 | ---| Dave, With the workload you describe, I think the 390 would be better optimised and easier to manage with the NT concentrators. I mean sender channels can batch dozens of messages together, whilst the client channels go one-at-a time. You also minimze the overhead of channel pooling and avoid (at least from the 390 perspective) avoid the headaches implicit in one end of the channel not controlled by the qmgr. In my mind, the tougher question is whether to forgo the NT concentrators and put qmgrs directily on the webshere servers, which in effect are already acting as concentrators. I'm skeptical about the advantage gained by having 4 inound qmgrs rather than 11. -Original Message
Re: Client IP connections direct to an OS/390
If you wish to suppress certain messages (such as channel started/disconnected, etc.) on z/OS then we document how to do this, using the z/OS message processing facility list, in the 'System Setup Guide' at the end of the 'Customizing your queue managers' chapter. There is also a provided sample (CSQ4MPFL in SCSQPROC) which shows the settings for some common messages you are recommended to suppress on busy systems (including CSQX500I and CSQX501I). Neil Johnston. WebSphere MQ for z/OS Development Service. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Connections
Have MaxChannels and MaxActiveChannels set at 2000, the MaxInitiators defaults to 3 and the ListenerBacklog at 1024. Getting Java.Channel connection rejections even though there is no indication that at any given moment in time, there are so many connections to the server. Anyone help here? Much appreciated. BB. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Connections
You are probably running into a situation where you have many stale/broken connections, but you haven't purged them because you don't know they are stale or broken. If you are talking about TCP client connections, you need to be aware of your TCPKEEPALIVE settings. By setting this value to a meaningful number (one that allows lengthy calls to occur, but not too long so that stale connections can be deleted), old stale connections will be removed and the MaxChannels won't be reached. A reaonable value is probably somewhere between 2 and 5 minutes. Thanks, David Corbett IBM Certified MQSeries Solutions Expert, Developer Specialist |-+--- | | Bruce Barclay | | | [EMAIL PROTECTED]| | | ES.GC.CA | | | Sent by:| | | MQSeries List | | | [EMAIL PROTECTED]| | | en.AC.AT | | | | | | | | | 03/13/2003 11:09| | | AM | | | Please respond | | | to MQSeries| | | List | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Connections | ---| Have MaxChannels and MaxActiveChannels set at 2000, the MaxInitiators defaults to 3 and the ListenerBacklog at 1024. Getting Java.Channel connection rejections even though there is no indication that at any given moment in time, there are so many connections to the server. Anyone help here? Much appreciated. BB. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Connections
Thanx for your help. Will try it. Cheers. BB. -Original Message- From: Dave Corbett [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 2:53 PM To: [EMAIL PROTECTED] Subject: Re: Connections You are probably running into a situation where you have many stale/broken connections, but you haven't purged them because you don't know they are stale or broken. If you are talking about TCP client connections, you need to be aware of your TCPKEEPALIVE settings. By setting this value to a meaningful number (one that allows lengthy calls to occur, but not too long so that stale connections can be deleted), old stale connections will be removed and the MaxChannels won't be reached. A reaonable value is probably somewhere between 2 and 5 minutes. Thanks, David Corbett IBM Certified MQSeries Solutions Expert, Developer Specialist |-+--- | | Bruce Barclay | | | [EMAIL PROTECTED]| | | ES.GC.CA | | | Sent by:| | | MQSeries List | | | [EMAIL PROTECTED]| | | en.AC.AT | | | | | | | | | 03/13/2003 11:09| | | AM | | | Please respond | | | to MQSeries| | | List | | | | |-+--- --- | | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Connections | --- | Have MaxChannels and MaxActiveChannels set at 2000, the MaxInitiators defaults to 3 and the ListenerBacklog at 1024. Getting Java.Channel connection rejections even though there is no indication that at any given moment in time, there are so many connections to the server. Anyone help here? Much appreciated. BB. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Connections
There's also the HBINT field of the SVRCONN defintion. The default is 300 seconds, you may want to change this to 30 seconds or less. it assumes the application using the SVRCONN is issuing an MQGET. Bruce Barclay [EMAIL PROTECTED]To: [EMAIL PROTECTED] S.GC.CA cc: Sent by: MQSeriesSubject: Re: Connections List [EMAIL PROTECTED] n.AC.AT 03/13/2003 03:23 PM Please respond to MQSeries List Thanx for your help. Will try it. Cheers. BB. -Original Message- From: Dave Corbett [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 2:53 PM To: [EMAIL PROTECTED] Subject: Re: Connections You are probably running into a situation where you have many stale/broken connections, but you haven't purged them because you don't know they are stale or broken. If you are talking about TCP client connections, you need to be aware of your TCPKEEPALIVE settings. By setting this value to a meaningful number (one that allows lengthy calls to occur, but not too long so that stale connections can be deleted), old stale connections will be removed and the MaxChannels won't be reached. A reaonable value is probably somewhere between 2 and 5 minutes. Thanks, David Corbett IBM Certified MQSeries Solutions Expert, Developer Specialist |-+--- | | Bruce Barclay | | | [EMAIL PROTECTED]| | | ES.GC.CA | | | Sent by:| | | MQSeries List | | | [EMAIL PROTECTED]| | | en.AC.AT | | | | | | | | | 03/13/2003 11:09| | | AM | | | Please respond | | | to MQSeries| | | List | | | | |-+--- --- | | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Connections | --- | Have MaxChannels and MaxActiveChannels set at 2000, the MaxInitiators defaults to 3 and the ListenerBacklog at 1024. Getting Java.Channel connection rejections even though there is no indication that at any given moment in time, there are so many connections to the server. Anyone help here? Much appreciated. BB. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase Co., its subsidiaries and affiliates. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Client IP connections direct to an OS/390
Dennis. Thanks for your thoughts on this. I'm not sure that batching of messages really matters, especially since we are TCP in and SNA out. Our batch size is set to 50 and the batch interval set 100. We did some extensive tuning with the VTAM settings to make sure it worked as well as possible (setting RU sizes, pacing, and other NCP parameters). It just seems that skipping a box in between the app server and mainframe should increase performance by itself. My real outstanding question is, why do we get thousands of messages showing channels starting and going inactive in the CHIN log? We had an occasion last Sunday where we had between 6 and 7 thousand messages in the space of an hour. I don't understand what it is that drives MQ to be bouncing these connections like this. We have also sent this question to IBM for a better understanding. We'll discuss your thoughts on putting the QMGRs on the app servers, but we were originally told (in 1998) that we needed the MQ servers to be on their own boxes. Thanks, David Corbett Work: 651-205-2714 Pager: 651-610-3842 |-+--- | | Miller, Dennis| | | [EMAIL PROTECTED]| | | COM| | | Sent by:| | | MQSeries List | | | [EMAIL PROTECTED]| | | en.AC.AT | | | | | | | | | 03/11/2003 09:37| | | AM | | | Please respond | | | to MQSeries| | | List | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Re: Client IP connections direct to an OS/390 | ---| Dave, With the workload you describe, I think the 390 would be better optimised and easier to manage with the NT concentrators. I mean sender channels can batch dozens of messages together, whilst the client channels go one-at-a time. You also minimze the overhead of channel pooling and avoid (at least from the 390 perspective) avoid the headaches implicit in one end of the channel not controlled by the qmgr. In my mind, the tougher question is whether to forgo the NT concentrators and put qmgrs directily on the webshere servers, which in effect are already acting as concentrators. I'm skeptical about the advantage gained by having 4 inound qmgrs rather than 11. -Original Message- From: Dave Corbett [SMTP:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 9:01 AM To: [EMAIL PROTECTED] Subject: Client IP connections direct to an OS/390 Since nobody has replied to this, I am assuming that we are the only ones making extensive use of client connections direct to an OS/390 platform. So, in the hopes that someone else besides us has some experience with this architectural model, I am resending it to entice anyone with thoughts on this to respond. Thanks, David Corbett IBM MQSeries Certified Solutions Expert IBM MQSeries Certified Developer IBM MQSeries Certified Specialist - Forwarded by David P Corbett/MN/USB on 03/10/2003 10:55 AM - |-+--- | | David P Corbett | | | | | | 03/06/2003 11:14| | | AM | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Client IP connections direct to an OS/390 | ---| To anyone with experience, We originally had three NT MQ servers that would handle MQ connections from 11 websphere app servers and then had SNA channels defined to our OS/390 environment. The 11 app servers are spread across three mainframe LPARS in 4x4x3 configuration. The NT boxes served for the most part as a protocol converter from IP
Re: Client IP connections direct to an OS/390
Dave, The messages could be from the Disconnect Interval on the channels. You may want to check those and possibly set them to zero. Glen Shubert Dave Corbett [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 03/12/2003 09:52 AM Please respond to MQSeries List To:[EMAIL PROTECTED] cc: Subject:Re: Client IP connections direct to an OS/390 Dennis. Thanks for your thoughts on this. I'm not sure that batching of messages really matters, especially since we are TCP in and SNA out. Our batch size is set to 50 and the batch interval set 100. We did some extensive tuning with the VTAM settings to make sure it worked as well as possible (setting RU sizes, pacing, and other NCP parameters). It just seems that skipping a box in between the app server and mainframe should increase performance by itself. My real outstanding question is, why do we get thousands of messages showing channels starting and going inactive in the CHIN log? We had an occasion last Sunday where we had between 6 and 7 thousand messages in the space of an hour. I don't understand what it is that drives MQ to be bouncing these connections like this. We have also sent this question to IBM for a better understanding. We'll discuss your thoughts on putting the QMGRs on the app servers, but we were originally told (in 1998) that we needed the MQ servers to be on their own boxes. Thanks, David Corbett Work: 651-205-2714 Pager: 651-610-3842 |-+--- | | Miller, Dennis| | | [EMAIL PROTECTED]| | | COM | | | Sent by:| | | MQSeries List | | | [EMAIL PROTECTED]| | | en.AC.AT| | | | | | | | | 03/11/2003 09:37| | | AM | | | Please respond | | | to MQSeries | | | List | | | | |-+--- ---| || |To: [EMAIL PROTECTED]| |cc: | |Subject: Re: Client IP connections direct to an OS/390 | ---| Dave, With the workload you describe, I think the 390 would be better optimised and easier to manage with the NT concentrators. I mean sender channels can batch dozens of messages together, whilst the client channels go one-at-a time. You also minimze the overhead of channel pooling and avoid (at least from the 390 perspective) avoid the headaches implicit in one end of the channel not controlled by the qmgr. In my mind, the tougher question is whether to forgo the NT concentrators and put qmgrs directily on the webshere servers, which in effect are already acting as concentrators. I'm skeptical about the advantage gained by having 4 inound qmgrs rather than 11. -Original Message- From: Dave Corbett [SMTP:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 9:01 AM To: [EMAIL PROTECTED] Subject: Client IP connections direct to an OS/390 Since nobody has replied to this, I am assuming that we are the only ones making extensive use of client connections direct to an OS/390 platform. So, in the hopes that someone else besides us has some experience with this architectural model, I am resending it to entice anyone with thoughts on this to respond. Thanks, David Corbett IBM MQSeries Certified Solutions Expert IBM MQSeries Certified Developer IBM MQSeries Certified Specialist - Forwarded by David P Corbett/MN/USB on 03/10/2003 10:55 AM - |-+--- | | David P Corbett | | | | | | 03/06/2003 11:14| | | AM | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Client IP connections direct to an OS/390 | ---| To anyone with experience, We originally had three NT MQ servers that would handle MQ connections from 11 websphere app servers and then had SNA channels defined to our OS/390 environment. The 11 app servers are spread across three mainframe LPARS in 4x4x3 configuration. The NT boxes served for the most part as a protocol converter from IP to SNA. Since our OS/390 platform's tcp stack has become more robust, we have been migrating towards direct client channel
Re: Client IP connections direct to an OS/390
Glen, This sounds good in theory, but client channels don't have options like disconnect interval, heartbeat interval etc on the OS/390. I don't even think they have them on other platfoms either. I think these are controlled via global TCP setting like TCPKEEPALIVE. Since we are using a vendor package on the client side, we don't have a lot of control over the options specified at channel connection time. Thanks, David Corbett Work: 651-205-2714 Pager: 651-610-3842 |-+--- | | Glen Shubert | | | [EMAIL PROTECTED]| | | OM | | | Sent by:| | | MQSeries List | | | [EMAIL PROTECTED]| | | en.AC.AT | | | | | | | | | 03/12/2003 09:17| | | AM | | | Please respond | | | to MQSeries| | | List | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Re: Client IP connections direct to an OS/390 | ---| Dave, The messages could be from the Disconnect Interval on the channels. You may want to check those and possibly set them to zero. Glen Shubert Dave Corbett [EMAIL PROTECTED] To: Sent by: MQSeries List [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Subject:Re: Client IP connections direct to an OS/390 03/12/2003 09:52 AM Please respond to MQSeries List Dennis. Thanks for your thoughts on this. I'm not sure that batching of messages really matters, especially since we are TCP in and SNA out. Our batch size is set to 50 and the batch interval set 100. We did some extensive tuning with the VTAM settings to make sure it worked as well as possible (setting RU sizes, pacing, and other NCP parameters). It just seems that skipping a box in between the app server and mainframe should increase performance by itself. My real outstanding question is, why do we get thousands of messages showing channels starting and going inactive in the CHIN log? We had an occasion last Sunday where we had between 6 and 7 thousand messages in the space of an hour. I don't understand what it is that drives MQ to be bouncing these connections like this. We have also sent this question to IBM for a better understanding. We'll discuss your thoughts on putting the QMGRs on the app servers, but we were originally told (in 1998) that we needed the MQ servers to be on their own boxes. Thanks, David Corbett Work: 651-205-2714 Pager: 651-610-3842 |-+--- | | Miller, Dennis| | | [EMAIL PROTECTED]| | | COM| | | Sent by:| | | MQSeries List | | | [EMAIL PROTECTED]| | | en.AC.AT | | | | | | | | | 03/11/2003 09:37| | | AM | | | Please respond | | | to MQSeries| | | List | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Re: Client IP connections direct to an OS/390 | ---| Dave, With the workload you describe, I think the 390 would be better optimised and easier to manage with the NT concentrators. I mean sender channels can batch dozens of messages together, whilst the client channels go one-at-a time. You also minimze the overhead of channel pooling and avoid (at least from the 390 perspective) avoid the headaches implicit in one end
Re: Client IP connections direct to an OS/390
Hi Dave, If you are referring to messages like the following then you are seeing an application connecting to and then disconnecting from your queue manager as a client. CSQX500I MQD7 CSQXRESP Channel TEST.NOEXIT started CSQX501I MQD7 CSQXRESP Channel TEST.NOEXIT is no longer active Regards Tim A Dave Corbett [EMAIL PROTECTED]To: [EMAIL PROTECTED] BANK.COMcc: Sent by: MQSeriesSubject: Re: Client IP connections direct to an OS/390 List [EMAIL PROTECTED] N.AC.AT 13/03/2003 06:26 Please respond to MQSeries List Glen, This sounds good in theory, but client channels don't have options like disconnect interval, heartbeat interval etc on the OS/390. I don't even think they have them on other platfoms either. I think these are controlled via global TCP setting like TCPKEEPALIVE. Since we are using a vendor package on the client side, we don't have a lot of control over the options specified at channel connection time. Thanks, David Corbett Work: 651-205-2714 Pager: 651-610-3842 |-+--- | | Glen Shubert | | | [EMAIL PROTECTED]| | | OM | | | Sent by:| | | MQSeries List | | | [EMAIL PROTECTED]| | | en.AC.AT | | | | | | | | | 03/12/2003 09:17| | | AM | | | Please respond | | | to MQSeries| | | List | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Re: Client IP connections direct to an OS/390 | ---| Dave, The messages could be from the Disconnect Interval on the channels. You may want to check those and possibly set them to zero. Glen Shubert Dave Corbett [EMAIL PROTECTED] To: Sent by: MQSeries List [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Subject:Re: Client IP connections direct to an OS/390 03/12/2003 09:52 AM Please respond to MQSeries List Dennis. Thanks for your thoughts on this. I'm not sure that batching of messages really matters, especially since we are TCP in and SNA out. Our batch size is set to 50 and the batch interval set 100. We did some extensive tuning with the VTAM settings to make sure it worked as well as possible (setting RU sizes, pacing, and other NCP parameters). It just seems that skipping a box in between the app server and mainframe should increase performance by itself. My real outstanding question is, why do we get thousands of messages showing channels starting and going inactive in the CHIN log? We had an occasion last Sunday where we had between 6 and 7 thousand messages in the space of an hour. I don't understand what it is that drives MQ to be bouncing these connections like this. We have also sent this question to IBM for a better understanding. We'll discuss your thoughts on putting the QMGRs on the app servers, but we were originally told (in 1998) that we needed the MQ servers to be on their own boxes. Thanks, David Corbett Work: 651-205-2714 Pager: 651-610-3842 |-+--- | | Miller, Dennis| | | [EMAIL PROTECTED]| | | COM| | | Sent by:| | | MQSeries List | | | [EMAIL PROTECTED]| | | en.AC.AT | | | | | | | | | 03/11/2003 09:37| | | AM | | | Please respond | | | to MQSeries| | | List | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Re: Client IP connections direct to an OS/390
Re: Client IP connections direct to an OS/390
Dave, With the workload you describe, I think the 390 would be better optimised and easier to manage with the NT concentrators. I mean sender channels can batch dozens of messages together, whilst the client channels go one-at-a time. You also minimze the overhead of channel pooling and avoid (at least from the 390 perspective) avoid the headaches implicit in one end of the channel not controlled by the qmgr. In my mind, the tougher question is whether to forgo the NT concentrators and put qmgrs directily on the webshere servers, which in effect are already acting as concentrators. I'm skeptical about the advantage gained by having 4 inound qmgrs rather than 11. -Original Message- From: Dave Corbett [SMTP:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 9:01 AM To: [EMAIL PROTECTED] Subject: Client IP connections direct to an OS/390 Since nobody has replied to this, I am assuming that we are the only ones making extensive use of client connections direct to an OS/390 platform. So, in the hopes that someone else besides us has some experience with this architectural model, I am resending it to entice anyone with thoughts on this to respond. Thanks, David Corbett IBM MQSeries Certified Solutions Expert IBM MQSeries Certified Developer IBM MQSeries Certified Specialist - Forwarded by David P Corbett/MN/USB on 03/10/2003 10:55 AM - |-+--- | | David P Corbett | | | | | | 03/06/2003 11:14| | | AM | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Client IP connections direct to an OS/390 | ---| To anyone with experience, We originally had three NT MQ servers that would handle MQ connections from 11 websphere app servers and then had SNA channels defined to our OS/390 environment. The 11 app servers are spread across three mainframe LPARS in 4x4x3 configuration. The NT boxes served for the most part as a protocol converter from IP to SNA. Since our OS/390 platform's tcp stack has become more robust, we have been migrating towards direct client channel connections to the 390. We have an application that runs on websphere (3.5x) that makes connections to the 390 on an as needed basis. If a request comes in, it searches for the first available connection, and if it doesn't find any it creates a new one. We maintain the state of these connections such that 30-40 per websphere app server seems to handle our needs most of the time. However, when an influx of requests occurs in a short span of time (say 3-5 seconds), and the mainframe is slightly slow in responding, we tend to spin through these connections creating many in a short time frame. We only allow 100 per app server and have 4 app servers pointed at a specific LPAR on the 390. We seem to have issues some times where connections go inactive, then new channels are started, more connections go inactive, more are started and this goes on for a few minutes where several hundred connections seem to get started and dropped. It's basically impossible to determine if it's only old connections that are being dropped. Some of the settings such as HBINT are left at the default of 300 and the TCPKEEPALIVE settings are also at default which I think is set pretty high to reduce network traffic. Is anyone else out there trying anything similar to this? Would I be better off keeping the NT MQ servers and defining server channels as TCP between NT * the 390 thereby allowing the NT boxes to function as a concentrator? We currently have a problem where one of the OS/390 QMGRs CHIN application crashes during a cycle of intense channel creation. I'm just looking for someone who may be able to help with a relatively high volume MQ message application (approx. 3MM messages per day) who may have run into something that explains the channel starts and stops a little better (I realize it may just be the way our application is written, but the application never specifically shuts down connections unless the application itself shuts down). Thanks, David
Client IP connections direct to an OS/390
Since nobody has replied to this, I am assuming that we are the only ones making extensive use of client connections direct to an OS/390 platform. So, in the hopes that someone else besides us has some experience with this architectural model, I am resending it to entice anyone with thoughts on this to respond. Thanks, David Corbett IBM MQSeries Certified Solutions Expert IBM MQSeries Certified Developer IBM MQSeries Certified Specialist - Forwarded by David P Corbett/MN/USB on 03/10/2003 10:55 AM - |-+--- | | David P Corbett | | | | | | 03/06/2003 11:14| | | AM | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Client IP connections direct to an OS/390 | ---| To anyone with experience, We originally had three NT MQ servers that would handle MQ connections from 11 websphere app servers and then had SNA channels defined to our OS/390 environment. The 11 app servers are spread across three mainframe LPARS in 4x4x3 configuration. The NT boxes served for the most part as a protocol converter from IP to SNA. Since our OS/390 platform's tcp stack has become more robust, we have been migrating towards direct client channel connections to the 390. We have an application that runs on websphere (3.5x) that makes connections to the 390 on an as needed basis. If a request comes in, it searches for the first available connection, and if it doesn't find any it creates a new one. We maintain the state of these connections such that 30-40 per websphere app server seems to handle our needs most of the time. However, when an influx of requests occurs in a short span of time (say 3-5 seconds), and the mainframe is slightly slow in responding, we tend to spin through these connections creating many in a short time frame. We only allow 100 per app server and have 4 app servers pointed at a specific LPAR on the 390. We seem to have issues some times where connections go inactive, then new channels are started, more connections go inactive, more are started and this goes on for a few minutes where several hundred connections seem to get started and dropped. It's basically impossible to determine if it's only old connections that are being dropped. Some of the settings such as HBINT are left at the default of 300 and the TCPKEEPALIVE settings are also at default which I think is set pretty high to reduce network traffic. Is anyone else out there trying anything similar to this? Would I be better off keeping the NT MQ servers and defining server channels as TCP between NT * the 390 thereby allowing the NT boxes to function as a concentrator? We currently have a problem where one of the OS/390 QMGRs CHIN application crashes during a cycle of intense channel creation. I'm just looking for someone who may be able to help with a relatively high volume MQ message application (approx. 3MM messages per day) who may have run into something that explains the channel starts and stops a little better (I realize it may just be the way our application is written, but the application never specifically shuts down connections unless the application itself shuts down). Thanks, David Corbett Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Client IP connections direct to an OS/390
To anyone with experience, We originally had three NT MQ servers that would handle MQ connections from 11 websphere app servers and then had SNA channels defined to our OS/390 environment. The 11 app servers are spread across three mainframe LPARS in 4x4x3 configuration. The NT boxes served for the most part as a protocol converter from IP to SNA. Since our OS/390 platform's tcp stack has become more robust, we have been migrating towards direct client channel connections to the 390. We have an application that runs on websphere (3.5x) that makes connections to the 390 on an as needed basis. If a request comes in, it searches for the first available connection, and if it doesn't find any it creates a new one. We maintain the state of these connections such that 30-40 per websphere app server seems to handle our needs most of the time. However, when an influx of requests occurs in a short span of time (say 3-5 seconds), and the mainframe is slightly slow in responding, we tend to spin through these connections creating many in a short time frame. We only allow 100 per app server and have 4 app servers pointed at a specific LPAR on the 390. We seem to have issues some times where connections go inactive, then new channels are started, more connections go inactive, more are started and this goes on for a few minutes where several hundred connections seem to get started and dropped. It's basically impossible to determine if it's only old connections that are being dropped. Some of the settings such as HBINT are left at the default of 300 and the TCPKEEPALIVE settings are also at default which I think is set pretty high to reduce network traffic. Is anyone else out there trying anything similar to this? Would I be better off keeping the NT MQ servers and defining server channels as TCP between NT * the 390 thereby allowing the NT boxes to function as a concentrator? We currently have a problem where one of the OS/390 QMGRs CHIN application crashes during a cycle of intense channel creation. I'm just looking for someone who may be able to help with a relatively high volume MQ message application (approx. 3MM messages per day) who may have run into something that explains the channel starts and stops a little better (I realize it may just be the way our application is written, but the application never specifically shuts down connections unless the application itself shuts down). Thanks, David Corbett Work: 651-205-2714 Pager: 651-610-3842 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Handling invalid connections
Hi List, We have a Java application running on a machine which has MQ series thin client installed. This application uses server connection channels to connect to MQ series 3.5 which is running on a separate AIX server. When the Java Application (JVM running it) is abruptly brought down, the Ipprocs and Opprocs of the Queue to which we have connected does not reflect the recent change. The time taken for these parameters to be refreshed is unpredictable. What could be the reason for this? We also would like to know how MQ times-out or disconnects invalid connections. Thanks and regards, Elango. Be kind, for everyone you meet is fighting a harder battle - Plato This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com
Re: Listing number of channel connections made to queues in a Queue Manager on a AIX box
This is an interesting question. Doing a runmqsc QMGR_NAME dischl | grep -c RUNNING where dischl contains a one line connamd dis chs(*) will return the number of running channels it may not give you the results you need. Sender channels will have one and only one XMIT queue associated with it. But receiver channels are another story. What happens if the sender is sending data to more than one queue. each queue will be opened for a put for that particular receiver channle. Is there possibly an agent spawned for each queue that is opened on a put for a receiver channle. Sounds like a NOT So while the above command will give you some sort of number I don't believe the 'dis chs(*)' will give you what you are looking for. I'm not sure if there is a way to extract that information.PC??? Any input bobbee From: Kadhirvel,Elango ( Cognizant) [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Listing number of channel connections made to queues in a Queue Manager on a AIX box Date: Mon, 3 Feb 2003 12:48:51 +0530 Hi List, How do we list the number of channel connections made to queues in a Queue Manager in MQSeries 5.2 on a AIX box? Thanks and regards, Elango. Be kind, for everyone you meet is fighting a harder battle - Plato InterScan_Disclaimer.txt _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Listing number of channel connections made to queues in a Que ue Manager on a AIX box
Bobbee, Another way to do this without the need of a file is:echo display chs(*)|runmqsc|grep -c RUNNING Regards, John Dawson -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 7:17 AM To: [EMAIL PROTECTED] Subject:Re: Listing number of channel connections made to queues in a Queue Manager on a AIX box This is an interesting question. Doing a runmqsc QMGR_NAME dischl | grep -c RUNNING where dischl contains a one line connamd dis chs(*) will return the number of running channels it may not give you the results you need. Sender channels will have one and only one XMIT queue associated with it. But receiver channels are another story. What happens if the sender is sending data to more than one queue. each queue will be opened for a put for that particular receiver channle. Is there possibly an agent spawned for each queue that is opened on a put for a receiver channle. Sounds like a NOT So while the above command will give you some sort of number I don't believe the 'dis chs(*)' will give you what you are looking for. I'm not sure if there is a way to extract that information.PC??? Any input bobbee From: Kadhirvel,Elango ( Cognizant) [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Listing number of channel connections made to queues in a Queue Manager on a AIX box Date: Mon, 3 Feb 2003 12:48:51 +0530 Hi List, How do we list the number of channel connections made to queues in a Queue Manager in MQSeries 5.2 on a AIX box? Thanks and regards, Elango. Be kind, for everyone you meet is fighting a harder battle - Plato InterScan_Disclaimer.txt _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Listing number of channel connections made to queues in a Queue Manager on a AIX box
How do we list the number of channel connections made to queues in a Queue Manager in MQSeries 5.2 on a AIX box? This is an interesting question. Doing a runmqsc QMGR_NAME dischl | grep -c RUNNING where dischl contains a one line connamd dis chs(*) will return the number of running channels it may not give you the results you need. Sender channels will have one and only one XMIT queue associated with it. But receiver channels are another story. What happens if the sender is sending data to more than one queue. each queue will be opened for a put for that particular receiver channle. Is there possibly an agent spawned for each queue that is opened on a put for a receiver channle. Sounds like a NOT So while the above command will give you some sort of number I don't believe the 'dis chs(*)' will give you what you are looking for. I'm not sure if there is a way to extract that information.PC??? Any input bobbee, I'm assuming that by PC you're talking to me ? If not then I apologise. I didn't put any answer to the original question becasue I'm not sure I understood it. What does 'channel connections to queues' mean ? Are we asking how many queues a particular channel has open at any one time ? If so then you.re not really in much luck on 5.2 I'm afraid. On 5.3 then you can issue DIS QSTATUS(*) TYPE(HANDLE) and you will see the channel names (if any) if they've opened a queue. This will work for both clients and QM-QM Channels. If you've got a problem then you could try using 'amqrdbgm'. Type 'q' to see the queue cache in use for the current channel. '?' will show the list of commands. This is a service tool and should not really be used while there is no problem since it is not guaranteed to be 100% safe. In fact I shouldn't be telling you about it at all so I'll shut up now. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
