Re: MO71 question - viaQM-monitored QM stays green very short
Ben, It is not true to say that if you get commands to work, then monitoring will also work. You do have to configure your monitor queue correctly as well. Please read the section in the manual about monitoring. You can click on the location monitor button and see where the monitor messages go. If you still have problems perhaps you'd better contact me offline. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Benjamin F. | | | Zhou| | | [EMAIL PROTECTED]| | | USA.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 18/03/2004 16:02 | | | Please respond to| | | MQSeries List| |-+ -| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MO71 question - viaQM-monitored QM stays green very short | | | | | -| Hi Paul, I'm pretty sure the viaQM-monitored QM already has all the right configuration needed for the monitor. Otherwise I won't get the correct result on the screen when I double click on that QM. My challenge now is how to set the definition to keep it green, not just for a few seconds. I actually set monitor interval to 3, 6 seconds. But it still stays red until I double-click it, when all the qmgr info is shown and the icon turns green, only for a few seconds. thanks, Ben Paul Clarke [EMAIL PROTECTED] To: [EMAIL PROTECTED] .IBM.COMcc: Sent by: Subject: Re: MO71 question MQSeries List [EMAIL PROTECTED] en.AC.AT 03/17/2004 11:15 AM Please respond to MQSeries List Ben, Monitoring a location that you are directly connected to (either locally or via a client) is simple since the application need only be able to issue an API call. When you're going to a remote Queue Manager *via* another then you actually need to send a message and have it returned. So, yes, going via another queue manager is more complicated. I've just tried it though and it still seems to work fine so I recommend you read the manual and use loopback monitoring. ie. define a remote queue on your remote QM that 'points' back to the QM your MO71 is actually connected to. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Benjamin F. | | | Zhou| | | [EMAIL PROTECTED]| | | USA.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 12/03/2004 16:15 | | | Please respond to| | | MQSeries List| |-+ -| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MO71 question | | | | | -| Hi Paul, I still try to use viaQM because it may take weeks before it can be installed on the MF. Just to compare, I added another location whose qmgr is on the same NT machine. I set it up to be viaQM-monitored. After I double-click the QM, all the query results are shown on the screen about this QM, its icon turns green, but just for a short two seconds, it
Dead Letter Queue messages not appearing?
Hi all, I have a situation whereby an external company using an MQClient are trying to send messages to our Mainframe MQ Manager (V2.1) and the messages when being sent are not arriving on the destination queue or the Dead letter Queue. In our Queue Manager channel initiator we get the message: +CSQX548E MQSB CSQXRESP Messages for KEWILL.TO.MQSB sent to local dead-letter queue I can not see any messages on the dead letter queue on the local queue manager. I have however heard from the external company and prior to us getting this message they get an MQ Error Message of '2320'. Can anybody give any ideas on this. Regards Michelle. This email and any attachments are confidential. They may contain privileged information and are intended for the named addressee(s) only. They must not be distributed without our consent. If you are not the intended recipient, please notify us immediately and do not disclose, distribute or retain this email or any part of it. Unless expressly stated, opinions in this email are those of the individual sender and not N Brown Group plc or any of its subsidiaries. You must take full responsibility for virus checking this email and any attachments. Please note that the content of this email or any of its attachments may contain data that falls within the scope of the Data Protection Acts and that you must ensure that any handling or processing of such data by you is fully compliant with the terms and provisions of the Data Protection Act 1984 and 1998. N Brown Group plc. Registered office: Griffin House, 40 Lever Street, Manchester, M60 6ES. Registered in England No.814103. 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: Need for support pac MA04
What is MA04? I can't find any reference to it. Do you mean MD04 (the visio sample stencils?) Michael -Oorspronkelijk bericht- Van: MQSeries List [mailto:[EMAIL PROTECTED] Dennis Bryngelson Verzonden: donderdag 18 maart 2004 15:15 Aan: [EMAIL PROTECTED] Onderwerp: Need for support pac MA04 Can someone please send me either a link to Support Pac MA04 or the support pac itself?? 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
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: Listeners and Priviledges on Linux
Sid, As of 5.3 the listener doesn't run the channel anymore, it just passed the connection off to the channel pooling process. So even if you could run the listener under a different ID, the MCA would still be running as mqm. Yes, the client will inherit the authorizations of either the MCAUSER attribute or, if that is empty, mqm. You can set the channel to use the ID of the client that is connecting but it is a trivial task for the client to assert any arbitrary ID. Setting the MCAUSER or running an exit (like Joergen's BlockIP2) is necessary to enforce a policy of using non-administrative IDs. -- T.Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, March 19, 2004 12:43 AM To: [EMAIL PROTECTED] Subject: Listeners and Priviledges on Linux G'Day all, This may seam like a silly question but, if I have a listener started by the mqm user on a Linux server and a client connects using a server connection channel to the server via that listener, then does the client automatically have mqm priviledges ?? Or will the mca userid be the only applicable factor. Can any user other than mqm start the queue manager and listeners ?? Sid Young 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: Dead Letter Queue messages not appearing?
Michelle, The 2320 error is from the AMI. Text below: MQRC_HBAG_ERROR A call was issued that has a parameter that is a bag handle, but the handle is not valid. For output parameters, this reason also occurs if the parameter pointer is not valid, or points to read-only storage. (It is not always possible to detect parameter pointers that are not valid; if not detected, unpredictable results occur.) Corrective action: Correct the parameter. The AMI is an administrative API for MQSeries that reads and writes PCF messages. The interesting thing here is that the external company is apparently issuing administrative PCF commands to your mainframe. Was it your intent to allow them full administrative access? For external clients we typically a) don't allow them administrative access, b) set up a hardened DMZ QMgr between us and them, and c) do not allow them to use a client channel because in addition to sending messages it allows them the full MQI interface to do things like setting queue attributes. Your vendor appears to have hit the MQ Security trifecta! Do you run a DLQ handler or anything else that monitors the DLQ? They may be setting the messages to expire in which case any browse or read attempt will remove them from the DLQ before you see them there. -- T.Rob -Original Message- From: Michelle Russell [mailto:[EMAIL PROTECTED] Sent: Friday, March 19, 2004 5:36 AM To: [EMAIL PROTECTED] Subject: Dead Letter Queue messages not appearing? Hi all, I have a situation whereby an external company using an MQClient are trying to send messages to our Mainframe MQ Manager (V2.1) and the messages when being sent are not arriving on the destination queue or the Dead letter Queue. In our Queue Manager channel initiator we get the message: +CSQX548E MQSB CSQXRESP Messages for KEWILL.TO.MQSB sent to local dead-letter queue I can not see any messages on the dead letter queue on the local queue manager. I have however heard from the external company and prior to us getting this message they get an MQ Error Message of '2320'. Can anybody give any ideas on this. Regards Michelle. This email and any attachments are confidential. They may contain privileged information and are intended for the named addressee(s) only. They must not be distributed without our consent. If you are not the intended recipient, please notify us immediately and do not disclose, distribute or retain this email or any part of it. Unless expressly stated, opinions in this email are those of the individual sender and not N Brown Group plc or any of its subsidiaries. You must take full responsibility for virus checking this email and any attachments. Please note that the content of this email or any of its attachments may contain data that falls within the scope of the Data Protection Acts and that you must ensure that any handling or processing of such data by you is fully compliant with the terms and provisions of the Data Protection Act 1984 and 1998. N Brown Group plc. Registered office: Griffin House, 40 Lever Street, Manchester, M60 6ES. Registered in England No.814103. 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 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 for that?
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 that there
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
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: MO71
Thanks, I got it to work. I am also trying to connect to a SCO Unix qmanager and I keep getting a Error connecting via client to 'VRUQMGR3' RC(2035) Not authorized. I tried defining the userid of the NT box that has mqmon running on it and then modifying that user so that it has mqm as a group but I still get the same message. Any thoughts? -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 3:50 AM To: [EMAIL PROTECTED] Subject: Re: MO71 Mike, MO71 supports two types of monitoring. 1/ Normal monitoring relies on a program at the remote Queue Manager to receive the messages and send them back to the reply fields This does therefore require a client (program) running on the remote system 2/ Loopback monitoring allows yoiu to define a remote queue on the remote system which just 'points' back to the originating queue. This does not therefore require a client (program) running on the remote system Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Ward, Mike S | | | [EMAIL PROTECTED]| | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 16/03/2004 14:32 | | | Please respond to| | | MQSeries List| |-+ --- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: MO71 | | | | | --- | Hi, is a client required at both ends in order for the monitoring to work? 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
Managing linear logs with MQ5.3 on Windows
Hi all, I am trying to find if any of the available support packs are suitable for managing linear logs on a MQ 5.3 Windows NT box. I have done a little testing, most of them rely on the qm.ini file not more present above 5.0. Even with a fake ini file on the right place, I was not able to use : - MS0L : Java exception - MS62 : Perl problems In both cases (Java Perl), I suspect NT 4 related problems. Any ideas / experiences to share ? TIA, LMD. -- Luc-Michel Demey - Freelance EAI Consultant Paris / France Tel. : +33 6 08 755 655 http://consulting.demey.org/ - lmd at demey dot org 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: MO71
Mike, it doesn't make a difference what name you give your NT userid, it will always be sent out in the format NTDOMAIN/userid. What you need is set the MCAUSER field on your SYSTEM.ADMIN.SVRCONN on the UNIX box to mqm, or an id with the appropriate right. Apparently you're not worrying about security at this point. cheers, Ward, Mike S [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Sent by: Subject: Re: MO71 MQSeries List [EMAIL PROTECTED] en.AC.AT 03/19/2004 05:20 PM Please respond to MQSeries List Thanks, I got it to work. I am also trying to connect to a SCO Unix qmanager and I keep getting a Error connecting via client to 'VRUQMGR3' RC(2035) Not authorized. I tried defining the userid of the NT box that has mqmon running on it and then modifying that user so that it has mqm as a group but I still get the same message. Any thoughts? -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 3:50 AM To: [EMAIL PROTECTED] Subject: Re: MO71 Mike, MO71 supports two types of monitoring. 1/ Normal monitoring relies on a program at the remote Queue Manager to receive the messages and send them back to the reply fields This does therefore require a client (program) running on the remote system 2/ Loopback monitoring allows yoiu to define a remote queue on the remote system which just 'points' back to the originating queue. This does not therefore require a client (program) running on the remote system Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |-+ | | Ward, Mike S | | | [EMAIL PROTECTED]| | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | N.AC.AT | | || | || | | 16/03/2004 14:32 | | | Please respond to| | | MQSeries List| |-+ --- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: MO71 | | | | | --- | Hi, is a client required at both ends in order for the monitoring to work? 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
