Handle creep on Win2000 with WMQ V5.3
Title: Handle creep on Win2000 with WMQ V5.3 Hi all We're having an issue with handles increasing on Windows 2000. We are running WMQ V5.3 (with no fixpacs) and the handles for the amqmsrvn simply keep increasing. I've found the same issue for V5.2 that's fixed in CSD03. I've included the text below. Does anyone know whether this problem is fixed in any of the CSD's for V5.3 prior to CSD05, because the detail for CSD05 says nothing about this kind of error? APAR status Closed as program error. Error description Customer created a QMgr with default setting on MQ Explore. There are no setting such as custom service. After stopping the QMgr, start performance monitor and add following counter: Object: process Counter: Handle count Instance: amqmsrvn Watch the performance graph status for a while, then we can see that memory usage of the process are increasing. Local fix Problem summary The problem has been fixed. Problem conclusion This problem has been fixed and the fix will be shipped in the following PTFs: . A) MQSeries for V5.2 CSD03 . Windows NT U200148 AIX U478289 HP-UX (V10) U478290 HP-UX (V11) U478293 Linux U478292 Sun Solaris U478291 . B) MQSeries for V5.2.1 CSD01 . Windows NT/2000 U200151 Thanks very much. Kind regards Yvette Carroll MQ Support Specialist TO division Nedbank Limited South Africa +27 (0) 11 881-3754 +27 (0) 83 644-0608 This email and any accompanying attachments may contain confidential and proprietary information. This information is private and protected by law and, accordingly, if you are not the intended recipient, you are requested to delete this entire communication immediately and are notified that any disclosure, copying or distribution of or taking any action based on this information is prohibited. Emails cannot be guaranteed to be secure or free of errors or viruses. The sender does not accept any liability or responsibility for any interception, corruption, destruction, loss, late arrival or incompleteness of or tampering or interference with any of the information contained in this email or for its incorrect delivery or non-delivery for whatsoever reason or for its effect on any electronic device of the recipient. If verification of this email or any attachment is required, please request a hard-copy version.
Detected memory leak on MQM processes
Title: Detected memory leak on MQM processes Hi Below is a note from one of our developers who has found a memory leak on one of our AIX servers. We are running WMQ V5.3.4. Whilst monitoring the list of MQ processes it was noted that some of the processes are showing symptoms of memory leaks. The processes in question are amqrmppa - leaks about 4K a day. amqzxma0 - leaks about 8-12K a day. The memory leak symptoms can be described as an ever increasing memory footprint. Under normal circumstances applications allocate and free memory. In the case of a memory leak the application allocates memory but does not free all of it. As time goes by the size of the memory used by the application just tends to continue growing. For systems that 24*7*365 this could lead to a memory starvation situation where the application uses up all of the memory available on the system. The time it takes for a memory leak to become critical is dependent on the size of the leak and obviously the size of RAM/Virtual memory available on the machine. I haven't been able to find anything on this particular problem at this maintenance level. Does anyone else out there know what the problem could be? Thanks very much. Kind regards Yvette Carroll MQ Support Specialist TO division Nedbank Limited South Africa +27 (0) 11 881-3754 +27 (0) 83 644-0608 This email and any accompanying attachments may contain confidential and proprietary information. This information is private and protected by law and, accordingly, if you are not the intended recipient, you are requested to delete this entire communication immediately and are notified that any disclosure, copying or distribution of or taking any action based on this information is prohibited. Emails cannot be guaranteed to be secure or free of errors or viruses. The sender does not accept any liability or responsibility for any interception, corruption, destruction, loss, late arrival or incompleteness of or tampering or interference with any of the information contained in this email or for its incorrect delivery or non-delivery for whatsoever reason or for its effect on any electronic device of the recipient. If verification of this email or any attachment is required, please request a hard-copy version.
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Rob, thanks for the insight. However, a JMS application accesses a qmgr via a connection factory object defined in the JNDI namespace, NOT through a svrconn channel on the server, i,e. it's actually not using the MQI channel. It can be seen from the following entry in my definition script, that it actually creates a direct socket connection to the host and port: def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client) port(1415) So such a definition makes it even more dangerous since there is no more MQ level security can be activated. While writing this, it became clear to me that the above is provided as an alternative to using MQI channel to access a remote qmgr in order to avoid having to define a client channel on the client side. Certainly, the above definition can be altered to use MQI channel instead of the host propery: def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client) However, the first is a dangerous alternative. Any comment? regards, Ben Wyatt, T. Rob [EMAIL PROTECTED] To: [EMAIL PROTECTED] MERICA.COM cc: Sent by: MQSeriesSubject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List [EMAIL PROTECTED] C.AT 01/05/2004 10:50 AM Please respond to MQSeries List Benjamin, That is because the channel used by the client is using the authority of the QMgr. Unless you put an MCAUSER or a security exit that substitutes a different UserID on the channel, you will get administrative rights. This is true of all client-connections and, yes, it is dangerous. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 9:55 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Bob, that's a good point. I've opened a ticket with IBM on this misleading reason code. However, if I use client mode, the jms application needs neither +inq nor +connect to the qmgr, to put a message to a queue. It dosn't even need a +put/+get/+brose. It seems to me that in the case of MQClient, it is the local qmgr that actually does the puts/gets. So no authorization is needed at all. But this sounds too dangerous, doesn't it? regards, Benjamin F. Zhou Mercedes-Benz USA x.2474 Robert Broderick [EMAIL PROTECTED] To: [EMAIL PROTECTED] OTMAIL.COMcc: Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List [EMAIL PROTECTED] .AC.AT 01/02/2004 03:39 PM Please respond to MQSeries List Stillthe unanswered question Why the 2102 Is something looping. I cannot see why insufficient access authority would generate this type of error. It seems there is an unresolved bug. About 2 months ago there was a discussin on the +inq for the JMS stuff and if I remember correctly the person at that time was not getting a 2102. bobbee From: Wyatt, T. Rob [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Date: Fri, 2 Jan 2004 13:40:13 -0600 When this happened to us, my developers were not printing the linked JMS exception so I did not have a reason code to look at. If I had been given a 2102, it sure would have thrown me off! I like to keep the events turned on so when I was presented with the problem I very quickly found an event message showing the UserID, the QMgr INQ call and a 2035. Discussion with the user revealed that any QMgr inquiry calls were happening inside the Java classes and not in his code. We have since learned that Java will inquire on queue objects as well, to obtain values for BOQUEUE and BOTHRESH if it has to back out a GET. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Friday, January 02, 2004 2:24 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Hi Rob, Great ! Your tip on adding inq right to non-mqm users did the trick. Here is the setmqaut command: setmqaut -m QMGR -t qmgr -p wasadmin +connect +inq But how did you know that a JMS appl needs inq right to the qmgr to establish connection? I didn't find such information on the JMS manual. thanks a lot for the insight ! Ben Wyatt, T. Rob [EMAIL PROTECTED] To: [EMAIL PROTECTED] MERICA.COM cc: Sent by: MQSeriesSubject: Re: Puzzled: MQJE001,
HearbeatInterval question
Can someone kindly clarify these two questions for me: 1- HeartbeatInterval on s server-connection channel. I know that this is the interval at which the server MCA sends a heartbeat to the client. This value is on my server connection channel (on Windows 2000) is set to default 300 (5 min). Since the heartbeats flow from the server only during a blocked MQGET, if the Waitinterval on the GET is set to 10 seconds, does this mean that I may get only one heartbeat during this GET? If the application crashes after this first heartbeat and before the second (which will happen after 5 min) the queue manager will be unable to detect that the client is gone? If so, isn t it better to set the HBINT to a value lower than the waitinterval of the GET? Assume that the messages are very short 200K and, and the only processing is writing it to a file. 2- XA support: If the DB2 database is on the same serve as the queue manager, would my commit in the client code both commit the MQ and DB2? Regards. Hilde __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus 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: HearbeatInterval question
A HBINT of less than 60 will mean that the HB will be checked at 2xHBINT, so you would have to set it a really small #. At the IBM conference in Dallas, the Advanced Client seminar had a note saying the following about HB: If set to a value to small, will cause a MQRC 2009 error on non MQGET calls But no explanation as to why or what to small means. For 10 second GET with waits, I don't think you should worry about HBs. You should use KeepAlive to help QMs see if the MQClients have crashed. If you have clients with very long Get with waits, HB will also come into play. http://www.mqseries.net/phpBB2/viewtopic.php?t=6478highlight=heartbeat -Original Message- From: Hilde G [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 11:29 AM To: [EMAIL PROTECTED] Subject: HearbeatInterval question Can someone kindly clarify these two questions for me: 1- HeartbeatInterval on s server-connection channel. I know that this is the interval at which the server MCA sends a heartbeat to the client. This value is on my server connection channel (on Windows 2000) is set to default 300 (5 min). Since the heartbeats flow from the server only during a blocked MQGET, if the Waitinterval on the GET is set to 10 seconds, does this mean that I may get only one heartbeat during this GET? If the application crashes after this first heartbeat and before the second (which will happen after 5 min) the queue manager will be unable to detect that the client is gone? If so, isn t it better to set the HBINT to a value lower than the waitinterval of the GET? Assume that the messages are very short 200K and, and the only processing is writing it to a file. 2- XA support: If the DB2 database is on the same serve as the queue manager, would my commit in the client code both commit the MQ and DB2? Regards. Hilde __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus 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
Error code 20 starting QM/Command Server WebSphere MQ service.
I am seeing this error in almost all my System Error Logs. Everything seems fine, so what does the below mean? AMQ7880: Error code 20 starting QM/Command Server WebSphere MQ service. EXPLANATION: The service was unable to start QM/Command Server. The error message reported was as follows: Process could not be started - return code 20 ACTION: Use WebSphere MQ Services to investigate why the service could not begin. If recovery for this service is active, MQ will attempt to recover. Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified 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
Do go looking for FDCs when nothing is wrong?
I was just poking around on one server, and I happened to find a ton of FDCs. I went to look at the QA version of this server, and there were FDCs. The production version - FDCs. I started looking at other unrelated queue managers - about half had at least one FDC! Some had 20 or 30, some in one day, other spread out over the years. All are 5.3 CSD04. Both Solaris and Windows. The worst ones were the queue managers participating in Microsoft Clusters. Based on this, I feel like there is a ton of stuff that needs fixing. The first thing you do when you have major problem is go look for the inevitable FDC. BUT, everything seems fine! There are no issues, MQ keeps working, all application areas are happy. Do you guys generally go looking for problems by trying to debug FDCs? Maybe even have monitoring tools alert you anytime any FDC is created anywhere? Or unless there is a symptom of a problem elsewhere, should I just ignore them? Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified 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: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Benjamin, I think you're missing something. When you leave off the channel, I believe it defaults to SYSTEM.DEF.SVRCONN channel. Check your bindings file (if your using the file version) and you can see the entry. Nick -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin F. Zhou Sent: Thursday, January 08, 2004 8:07 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Rob, thanks for the insight. However, a JMS application accesses a qmgr via a connection factory object defined in the JNDI namespace, NOT through a svrconn channel on the server, i,e. it's actually not using the MQI channel. It can be seen from the following entry in my definition script, that it actually creates a direct socket connection to the host and port: def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client) port(1415) So such a definition makes it even more dangerous since there is no more MQ level security can be activated. While writing this, it became clear to me that the above is provided as an alternative to using MQI channel to access a remote qmgr in order to avoid having to define a client channel on the client side. Certainly, the above definition can be altered to use MQI channel instead of the host propery: def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client) However, the first is a dangerous alternative. Any comment? regards, Ben Wyatt, T. Rob [EMAIL PROTECTED] To: [EMAIL PROTECTED] MERICA.COM cc: Sent by: MQSeriesSubject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List [EMAIL PROTECTED] C.AT 01/05/2004 10:50 AM Please respond to MQSeries List Benjamin, That is because the channel used by the client is using the authority of the QMgr. Unless you put an MCAUSER or a security exit that substitutes a different UserID on the channel, you will get administrative rights. This is true of all client-connections and, yes, it is dangerous. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 9:55 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Bob, that's a good point. I've opened a ticket with IBM on this misleading reason code. However, if I use client mode, the jms application needs neither +inq nor +connect to the qmgr, to put a message to a queue. It dosn't even need a +put/+get/+brose. It seems to me that in the case of MQClient, it is the local qmgr that actually does the puts/gets. So no authorization is needed at all. But this sounds too dangerous, doesn't it? regards, Benjamin F. Zhou Mercedes-Benz USA x.2474 Robert Broderick [EMAIL PROTECTED] To: [EMAIL PROTECTED] OTMAIL.COMcc: Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List [EMAIL PROTECTED] .AC.AT 01/02/2004 03:39 PM Please respond to MQSeries List Stillthe unanswered question Why the 2102 Is something looping. I cannot see why insufficient access authority would generate this type of error. It seems there is an unresolved bug. About 2 months ago there was a discussin on the +inq for the JMS stuff and if I remember correctly the person at that time was not getting a 2102. bobbee From: Wyatt, T. Rob [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Date: Fri, 2 Jan 2004 13:40:13 -0600 When this happened to us, my developers were not printing the linked JMS exception so I did not have a reason code to look at. If I had been given a 2102, it sure would have thrown me off! I like to keep the events turned on so when I was presented with the problem I very quickly found an event message showing the UserID, the QMgr INQ call and a 2035. Discussion with the user revealed that any QMgr inquiry calls were happening inside the Java classes and not in his code. We have since learned that Java will inquire on queue objects as well, to obtain values for BOQUEUE and BOTHRESH if it has to back out a GET. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Friday, January 02, 2004 2:24 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Hi Rob, Great ! Your tip on adding inq right to non-mqm users did the trick. Here is the setmqaut command: setmqaut -m QMGR -t qmgr -p wasadmin
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
I may be wrong, but the following def: def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client) port(1415) will cause your QCF to default to the SYSTEM.DEF.SVRCONN channel.I have never heard of an MQClient connecting to a QM and not using a SVRCONN channel, regardless of what interface was on top of that MQClient (like JMS). def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client) Would default the QCF to the localhost, since you did not specify the hostname. An MQClient will always use a hostname and will come in through a SVRCONN channel. The building of the QCF just happens to let you leave these 2 fields blank and then gives you the default values. -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 11:07 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Rob, thanks for the insight. However, a JMS application accesses a qmgr via a connection factory object defined in the JNDI namespace, NOT through a svrconn channel on the server, i,e. it's actually not using the MQI channel. It can be seen from the following entry in my definition script, that it actually creates a direct socket connection to the host and port: def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client) port(1415) So such a definition makes it even more dangerous since there is no more MQ level security can be activated. While writing this, it became clear to me that the above is provided as an alternative to using MQI channel to access a remote qmgr in order to avoid having to define a client channel on the client side. Certainly, the above definition can be altered to use MQI channel instead of the host propery: def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client) However, the first is a dangerous alternative. Any comment? regards, Ben Wyatt, T. Rob [EMAIL PROTECTED] To: [EMAIL PROTECTED] MERICA.COM cc: Sent by: MQSeriesSubject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List [EMAIL PROTECTED] C.AT 01/05/2004 10:50 AM Please respond to MQSeries List Benjamin, That is because the channel used by the client is using the authority of the QMgr. Unless you put an MCAUSER or a security exit that substitutes a different UserID on the channel, you will get administrative rights. This is true of all client-connections and, yes, it is dangerous. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 9:55 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Bob, that's a good point. I've opened a ticket with IBM on this misleading reason code. However, if I use client mode, the jms application needs neither +inq nor +connect to the qmgr, to put a message to a queue. It dosn't even need a +put/+get/+brose. It seems to me that in the case of MQClient, it is the local qmgr that actually does the puts/gets. So no authorization is needed at all. But this sounds too dangerous, doesn't it? regards, Benjamin F. Zhou Mercedes-Benz USA x.2474 Robert Broderick [EMAIL PROTECTED] To: [EMAIL PROTECTED] OTMAIL.COMcc: Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List [EMAIL PROTECTED] .AC.AT 01/02/2004 03:39 PM Please respond to MQSeries List Stillthe unanswered question Why the 2102 Is something looping. I cannot see why insufficient access authority would generate this type of error. It seems there is an unresolved bug. About 2 months ago there was a discussin on the +inq for the JMS stuff and if I remember correctly the person at that time was not getting a 2102. bobbee From: Wyatt, T. Rob [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Date: Fri, 2 Jan 2004 13:40:13 -0600 When this happened to us, my developers were not printing the linked JMS exception so I did not have a reason code to look at. If I had been given a 2102, it sure would have thrown me off! I like to keep the events turned on so when I was presented with the problem I very quickly found an event message showing the UserID, the QMgr INQ call and a 2035. Discussion with the user revealed that any QMgr inquiry calls were happening inside the Java classes and not in his code. We have since learned that Java will inquire on queue objects as well, to obtain
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Benjamin, Attached is a JNDI bindings file which was created without the channel option. You can look at it with a text editor and see that it put in a default entry for SYSTEM.DEF.SVRCONN. If you use the channel option this entry is replaced by your channel. You can also run your appl and see that you are really running on the default channel. I don't think the qmgr really has any special processing for either JMS and Java when the client is running the Java. It's all just basic MQ from the server's point of view so there has to be a svrconn channel. Nick -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin F. Zhou Sent: Thursday, January 08, 2004 8:07 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Rob, thanks for the insight. However, a JMS application accesses a qmgr via a connection factory object defined in the JNDI namespace, NOT through a svrconn channel on the server, i,e. it's actually not using the MQI channel. It can be seen from the following entry in my definition script, that it actually creates a direct socket connection to the host and port: def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client) port(1415) So such a definition makes it even more dangerous since there is no more MQ level security can be activated. While writing this, it became clear to me that the above is provided as an alternative to using MQI channel to access a remote qmgr in order to avoid having to define a client channel on the client side. Certainly, the above definition can be altered to use MQI channel instead of the host propery: def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client) However, the first is a dangerous alternative. Any comment? regards, Ben Wyatt, T. Rob [EMAIL PROTECTED] To: [EMAIL PROTECTED] MERICA.COM cc: Sent by: MQSeriesSubject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List [EMAIL PROTECTED] C.AT 01/05/2004 10:50 AM Please respond to MQSeries List Benjamin, That is because the channel used by the client is using the authority of the QMgr. Unless you put an MCAUSER or a security exit that substitutes a different UserID on the channel, you will get administrative rights. This is true of all client-connections and, yes, it is dangerous. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 9:55 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Bob, that's a good point. I've opened a ticket with IBM on this misleading reason code. However, if I use client mode, the jms application needs neither +inq nor +connect to the qmgr, to put a message to a queue. It dosn't even need a +put/+get/+brose. It seems to me that in the case of MQClient, it is the local qmgr that actually does the puts/gets. So no authorization is needed at all. But this sounds too dangerous, doesn't it? regards, Benjamin F. Zhou Mercedes-Benz USA x.2474 Robert Broderick [EMAIL PROTECTED] To: [EMAIL PROTECTED] OTMAIL.COMcc: Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List [EMAIL PROTECTED] .AC.AT 01/02/2004 03:39 PM Please respond to MQSeries List Stillthe unanswered question Why the 2102 Is something looping. I cannot see why insufficient access authority would generate this type of error. It seems there is an unresolved bug. About 2 months ago there was a discussin on the +inq for the JMS stuff and if I remember correctly the person at that time was not getting a 2102. bobbee From: Wyatt, T. Rob [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Date: Fri, 2 Jan 2004 13:40:13 -0600 When this happened to us, my developers were not printing the linked JMS exception so I did not have a reason code to look at. If I had been given a 2102, it sure would have thrown me off! I like to keep the events turned on so when I was presented with the problem I very quickly found an event message showing the UserID, the QMgr INQ call and a 2035. Discussion with the user revealed that any QMgr inquiry calls were happening inside the Java classes and not in his code. We have since learned that Java will inquire on queue objects as well, to obtain values for BOQUEUE and BOTHRESH if it has to back out a GET. -- T.Rob
Re: Do go looking for FDCs when nothing is wrong?
I run a scheduled job that looks for FDC's, then renames them and emails me. I record the incidents in an Excel spreadsheet and, if they start to repeat, then I do research for a solution. Potkay, Peter M (PLC, IT) To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: RTFORD.COM Subject: Do go looking for FDCs when nothing is wrong? Sent by: MQSeries List [EMAIL PROTECTED] AC.AT 01/08/2004 12:03 PM Please respond to MQSeries List I was just poking around on one server, and I happened to find a ton of FDCs. I went to look at the QA version of this server, and there were FDCs. The production version - FDCs. I started looking at other unrelated queue managers - about half had at least one FDC! Some had 20 or 30, some in one day, other spread out over the years. All are 5.3 CSD04. Both Solaris and Windows. The worst ones were the queue managers participating in Microsoft Clusters. Based on this, I feel like there is a ton of stuff that needs fixing. The first thing you do when you have major problem is go look for the inevitable FDC. BUT, everything seems fine! There are no issues, MQ keeps working, all application areas are happy. Do you guys generally go looking for problems by trying to debug FDCs? Maybe even have monitoring tools alert you anytime any FDC is created anywhere? Or unless there is a symptom of a problem elsewhere, should I just ignore them? Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified 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 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: Do go looking for FDCs when nothing is wrong?
Hi Ok, add me to the list that DOES NOT go looking for trouble when there is no indication of any:) Actually, I have had many circumstances when FDC's get thrown on a regular basis but are not indicative of a real problem. For consistent ones, I would use MQSeries support to at least (hopefully!) verify the potential reasons for the FDC's. I have some systems that I have needed to run clean up scripts because the FDC's get quite annoying and take up a lot of space. The reasons vary (but are basically innocent) and with some diligence and maybe some application clean up work, you may be able to stop the causes but in our case, we threw in the towel on a few and just use the scripts to clean up. Thanks Dan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Potkay, Peter M (PLC, IT) Sent: Thursday, January 08, 2004 12:04 PM To: [EMAIL PROTECTED] Subject: Do go looking for FDCs when nothing is wrong? I was just poking around on one server, and I happened to find a ton of FDCs. I went to look at the QA version of this server, and there were FDCs. The production version - FDCs. I started looking at other unrelated queue managers - about half had at least one FDC! Some had 20 or 30, some in one day, other spread out over the years. All are 5.3 CSD04. Both Solaris and Windows. The worst ones were the queue managers participating in Microsoft Clusters. Based on this, I feel like there is a ton of stuff that needs fixing. The first thing you do when you have major problem is go look for the inevitable FDC. BUT, everything seems fine! There are no issues, MQ keeps working, all application areas are happy. Do you guys generally go looking for problems by trying to debug FDCs? Maybe even have monitoring tools alert you anytime any FDC is created anywhere? Or unless there is a symptom of a problem elsewhere, should I just ignore them? Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified 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 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: Do go looking for FDCs when nothing is wrong?
Peter, I bet you get responses all over the place on this one! Personally, while I usually only worry about looking at the FDCs right away at if there is a problem, I do have a script that runs regularly on each qmgr machine and checks for FDCs and lets me know if there are any. And then I will take a look at the them. And I have seen places that actively monitor the error directories for FDCs. --Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 12:04 PM To: [EMAIL PROTECTED] Subject: Do go looking for FDCs when nothing is wrong? I was just poking around on one server, and I happened to find a ton of FDCs. I went to look at the QA version of this server, and there were FDCs. The production version - FDCs. I started looking at other unrelated queue managers - about half had at least one FDC! Some had 20 or 30, some in one day, other spread out over the years. All are 5.3 CSD04. Both Solaris and Windows. The worst ones were the queue managers participating in Microsoft Clusters. Based on this, I feel like there is a ton of stuff that needs fixing. The first thing you do when you have major problem is go look for the inevitable FDC. BUT, everything seems fine! There are no issues, MQ keeps working, all application areas are happy. Do you guys generally go looking for problems by trying to debug FDCs? Maybe even have monitoring tools alert you anytime any FDC is created anywhere? Or unless there is a symptom of a problem elsewhere, should I just ignore them? Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified 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 ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. 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: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Benjamin, I don't believe that your example proves a socket connection. Rather I believe that it demonstrates that SYSTEM.DEF.SVRCONN is set as the default. When your application is running, do you not see an active SVRCONN instance for it? If you disable the SYSTEM.DEF.SVRCONN, does the program still work? According to the docs, only the JMS Pub/Sub interface supports socket connections and then it's only to the event broker, not to the QMgr. Anything connecting to the QMgr uses bindings or a standard MQ client interface. Ref: http://publibfp.boulder.ibm.com/epubs/html/csqzaw11/csqzaw110i.htm#HDRCSQ77G 1 -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 11:07 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Rob, thanks for the insight. However, a JMS application accesses a qmgr via a connection factory object defined in the JNDI namespace, NOT through a svrconn channel on the server, i,e. it's actually not using the MQI channel. It can be seen from the following entry in my definition script, that it actually creates a direct socket connection to the host and port: def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client) port(1415) So such a definition makes it even more dangerous since there is no more MQ level security can be activated. While writing this, it became clear to me that the above is provided as an alternative to using MQI channel to access a remote qmgr in order to avoid having to define a client channel on the client side. Certainly, the above definition can be altered to use MQI channel instead of the host propery: def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client) However, the first is a dangerous alternative. Any comment? regards, Ben Wyatt, T. Rob [EMAIL PROTECTED] To: [EMAIL PROTECTED] MERICA.COM cc: Sent by: MQSeriesSubject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List [EMAIL PROTECTED] C.AT 01/05/2004 10:50 AM Please respond to MQSeries List Benjamin, That is because the channel used by the client is using the authority of the QMgr. Unless you put an MCAUSER or a security exit that substitutes a different UserID on the channel, you will get administrative rights. This is true of all client-connections and, yes, it is dangerous. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 9:55 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Bob, that's a good point. I've opened a ticket with IBM on this misleading reason code. However, if I use client mode, the jms application needs neither +inq nor +connect to the qmgr, to put a message to a queue. It dosn't even need a +put/+get/+brose. It seems to me that in the case of MQClient, it is the local qmgr that actually does the puts/gets. So no authorization is needed at all. But this sounds too dangerous, doesn't it? regards, Benjamin F. Zhou Mercedes-Benz USA x.2474 Robert Broderick [EMAIL PROTECTED] To: [EMAIL PROTECTED] OTMAIL.COMcc: Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List [EMAIL PROTECTED] .AC.AT 01/02/2004 03:39 PM Please respond to MQSeries List Stillthe unanswered question Why the 2102 Is something looping. I cannot see why insufficient access authority would generate this type of error. It seems there is an unresolved bug. About 2 months ago there was a discussin on the +inq for the JMS stuff and if I remember correctly the person at that time was not getting a 2102. bobbee From: Wyatt, T. Rob [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Date: Fri, 2 Jan 2004 13:40:13 -0600 When this happened to us, my developers were not printing the linked JMS exception so I did not have a reason code to look at. If I had been given a 2102, it sure would have thrown me off! I like to keep the events turned on so when I was presented with the problem I very quickly found an event message showing the UserID, the QMgr INQ call and a 2035. Discussion with the user revealed that any QMgr inquiry calls were happening inside the Java classes and not in his code. We have since learned that Java will inquire on queue objects as well, to obtain values for BOQUEUE and BOTHRESH if it has to
Do go looking for FDCs when nothing is wrong?
I just had to ring in on this one. The thing is, the queue manager seems to have sort of a hair trigger in regard to what sort of problems cause it to write an FDC file. I find them often, and have no way of quickly determining why it (more commonly they) are there. If I got serious about hunting them down every time, I could make a career out of It. It doesn't help any that little or no documentation exists on how to effectively troubleshoot using one. On more than one occasion I have opened a ticket with IBM to help me solve a problem where FDC files were produced, and had a 2nd level support person tell me to send them, but they don't often contain much useful data. I do think it is wise to automate handling them. I need to find the time to write a script that not only finds them but potentially parses them and write things like the date / time stamp, program name, and probe description (just to name a few) to a log file that could be imported into a spread sheet. Then you could look for trends. If something specific continues to occur over and over, that would be justification to launch a science project to determine why, and fix it. I would love to know enough about FDC files to write a program, or Perl script that could parse hundreds of them and write a report based on some key data. But that's not likely to wind up on my project plan list any time soon! Cheers 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
Channel Exit Program
Any suggestions on a channel exit utility for doing authentication on client channels ? Any estimate on what they would cost to buy ? 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: Channel Exit Program
Wesley, There's a great example of one at http://home19.inet.tele.dk/m-invent/ . With a little modification, it can anything you want it to do. Regards, John Dawson -Original Message- From: Wesley Shaw [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 12:24 PM To: [EMAIL PROTECTED] Subject:Channel Exit Program Any suggestions on a channel exit utility for doing authentication on client channels ? Any estimate on what they would cost to buy ? 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
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: Do go looking for FDCs when nothing is wrong?
Ditto on that Nick -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Anderson Sent: Thursday, January 08, 2004 10:20 AM To: [EMAIL PROTECTED] Subject: Do go looking for FDCs when nothing is wrong? I just had to ring in on this one. The thing is, the queue manager seems to have sort of a hair trigger in regard to what sort of problems cause it to write an FDC file. I find them often, and have no way of quickly determining why it (more commonly they) are there. If I got serious about hunting them down every time, I could make a career out of It. It doesn't help any that little or no documentation exists on how to effectively troubleshoot using one. On more than one occasion I have opened a ticket with IBM to help me solve a problem where FDC files were produced, and had a 2nd level support person tell me to send them, but they don't often contain much useful data. I do think it is wise to automate handling them. I need to find the time to write a script that not only finds them but potentially parses them and write things like the date / time stamp, program name, and probe description (just to name a few) to a log file that could be imported into a spread sheet. Then you could look for trends. If something specific continues to occur over and over, that would be justification to launch a science project to determine why, and fix it. I would love to know enough about FDC files to write a program, or Perl script that could parse hundreds of them and write a report based on some key data. But that's not likely to wind up on my project plan list any time soon! Cheers 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: Do go looking for FDCs when nothing is wrong?
I don't know. I have had sites where I showed up the first day and the file systems were pretty full because of the FDC issues. But as things got under control and the environment stabilized the issue of FDC's showing up became became lees of an issue if non-existent. I don't recall being iat a site where the FDC continued to run out of hand after making the environment well. bobbee From: Bill Anderson [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Do go looking for FDCs when nothing is wrong? Date: Thu, 8 Jan 2004 13:20:17 -0500 I just had to ring in on this one. The thing is, the queue manager seems to have sort of a hair trigger in regard to what sort of problems cause it to write an FDC file. I find them often, and have no way of quickly determining why it (more commonly they) are there. If I got serious about hunting them down every time, I could make a career out of It. It doesn't help any that little or no documentation exists on how to effectively troubleshoot using one. On more than one occasion I have opened a ticket with IBM to help me solve a problem where FDC files were produced, and had a 2nd level support person tell me to send them, but they don't often contain much useful data. I do think it is wise to automate handling them. I need to find the time to write a script that not only finds them but potentially parses them and write things like the date / time stamp, program name, and probe description (just to name a few) to a log file that could be imported into a spread sheet. Then you could look for trends. If something specific continues to occur over and over, that would be justification to launch a science project to determine why, and fix it. I would love to know enough about FDC files to write a program, or Perl script that could parse hundreds of them and write a report based on some key data. But that's not likely to wind up on my project plan list any time soon! Cheers 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 _ Tired of slow downloads? Compare online deals from your local high-speed providers now. https://broadband.msn.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
Re: HearbeatInterval question
Well, I suppose you could set the HBInt to 2, which would mean the HBs would flow every 4 seconds, which would catch the problem in your case. But is 2 (or 1) the small value that Wayne Schutz of IBM warned us about in the quote from the Conferance below? If you set it to 3, then a HB will flow every 6 seconds, and already we have the possability that the HB wont catch a failure if it occurs at some point in that 10 seconds. Plus, what is more likely, that the app will fail in the middle of a 10 second wait using MQ code? Or is it more likely to fail after the GET returned the message and the app is actually doing something with that data (but still connected to the QM)? That's why for MQClients, unless they do Get With Waits for long periods of time, KeepAlive is the way to go to see if the other side went away. Yeah, it kinda stinks that there is not an MQ specific KeepAlive, instead of only a server level one. (There is on z/OS, at the channel level no less! Maybe the next version of MQ will give this to us on distributed). -Original Message- From: Hilde G [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 12:35 PM To: [EMAIL PROTECTED] Subject: Re: HearbeatInterval question Peter, For 10 second GET with waits, I don't think you should worry about HBs. You should use KeepAlive to help QMs see if the MQClients have crashed. Thanks, but I fail to see why I should not worry about 10 second GET with waits if the HBINT is set to 300 sec. If the app crashes 2 sec after the MQGET starts then the qmgr will not recognize that the client is gone. What am I missing here? TCP KeepAlive impacts the whole server though. Is it really the only way to go (alongwith using blocked GETs) for the queue manager to determine if the client is still there? Any other ideas? Hilde --- Potkay, Peter M (PLC, IT) [EMAIL PROTECTED] wrote: A HBINT of less than 60 will mean that the HB will be checked at 2xHBINT, so you would have to set it a really small #. At the IBM conference in Dallas, the Advanced Client seminar had a note saying the following about HB: If set to a value to small, will cause a MQRC 2009 error on non MQGET calls But no explanation as to why or what to small means. For 10 second GET with waits, I don't think you should worry about HBs. You should use KeepAlive to help QMs see if the MQClients have crashed. If you have clients with very long Get with waits, HB will also come into play. http://www.mqseries.net/phpBB2/viewtopic.php?t=6478highlight=heartbeat -Original Message- From: Hilde G [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 11:29 AM To: [EMAIL PROTECTED] Subject: HearbeatInterval question Can someone kindly clarify these two questions for me: 1- HeartbeatInterval on s server-connection channel. I know that this is the interval at which the server MCA sends a heartbeat to the client. This value is on my server connection channel (on Windows 2000) is set to default 300 (5 min). Since the heartbeats flow from the server only during a blocked MQGET, if the Waitinterval on the GET is set to 10 seconds, does this mean that I may get only one heartbeat during this GET? If the application crashes after this first heartbeat and before the second (which will happen after 5 min) the queue manager will be unable to detect that the client is gone? If so, isn t it better to set the HBINT to a value lower than the waitinterval of the GET? Assume that the messages are very short 200K and, and the only processing is writing it to a file. 2- XA support: If the DB2 database is on the same serve as the queue manager, would my commit in the client code both commit the MQ and DB2? Regards. Hilde __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus 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 __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus Instructions for managing your mailing list subscription are provided in the
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
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
piece of paper in a safe! one person ('safe'person) gets it out passes the
password,
notes who has it and for what, when finished makes up a new password and
puts it in the safe.
the 'safe' person is non-techie...
Michael
-Oorspronkelijk bericht-
Van: MQSeries List [mailto:[EMAIL PROTECTED] Potkay, Peter
M (PLC, IT)
Verzonden: donderdag 8 januari 2004 20:05
Aan: [EMAIL PROTECTED]
Onderwerp: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Nobody, except for MQAdmins, is allowed to use
the 'mqm' UserId (it is monitored).
Roger, how do you monitor that?
-Original Message-
From: Roger Lacroix [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 08, 2004 12:27 PM
To: [EMAIL PROTECTED]
Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi Ben,
I believe you have some misconceptions about your JMS / JNDI values.
First off, if you are using 'transport(client)' then you WILL be using a
SVRCONN channel - hence a MQI channel. Just because you did not specify it,
does NOT mean you are not using one. I believe the default SVRCONN channel
used (when none is specified) is 'SYSTEM.DEF.SVRCONN'.
Under normal circumstances, the 'MCA USER ID' field of the
'SYSTEM.DEF.SVRCONN'
is blank. This generally means that you will be connecting / opening /
getting / putting messages under the UserId of 'mqm'.
Secondly, you can implement a reasonable amount of MQ security in this
scenario
(of course, client server security exits would be better).
At my current client, developers do not have access to the JMS / JNDI tree
in
UAT / PTE / PROD (only the SysAdmins and MQAdmins have access). Therefore,
we
code the following for the QCF or XAQCF in JMS / JNDI for WebLogic apps:
def qcf(qCF) qmgr(MYQM) host(192.168.1.12) channel(MYSVRCONN) port(1415)
transport(client) ClientId(FRED)
An alternate approach that is sometimes done (not strongly recommended) is
to
allow the developer to code the UserId in their application.
i.e.
((Message)outMessage).setStringProperty(JMSXUserID, FRED);
In either case, we apply the necessary security to the UserId 'FRED' for the
queue manager of 'MYQM'. Nobody, except for MQAdmins, is allowed to use
the 'mqm' UserId (it is monitored).
We have standards that state that developers, QA people, etc are not
allowed
access to the PROD queue managers unless approved but never with the 'mqm'
UserId. We assign the appropriate authority to THEIR UserId.
Since my client is a bank / brokage-house, it is a fire-able offense to
access
PROD data if you have not been approved. Hence, generally speaking, people
do
not risk it.
Hope that helps.
Regards,
Roger Lacroix
Capitalware Inc.
http://www.capitalware.biz
Quoting Benjamin F. Zhou [EMAIL PROTECTED]:
Rob,
thanks for the insight.
However, a JMS application accesses a qmgr via a connection factory object
defined in the JNDI namespace, NOT through a svrconn channel on the
server,
i,e. it's actually not using the MQI channel. It can be seen from the
following entry in my definition script, that it actually creates a direct
socket connection to the host and port:
def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client)
port(1415)
So such a definition makes it even more dangerous since there is no more
MQ
level security can be activated.
While writing this, it became clear to me that the above is provided as an
alternative to using MQI channel to access a remote qmgr in order to avoid
having to define a client channel on the client side. Certainly, the above
definition can be altered to use MQI channel instead of the host propery:
def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client)
However, the first is a dangerous alternative. Any comment?
regards,
Ben
Wyatt, T. Rob
[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
MERICA.COM cc:
Sent by: MQSeriesSubject: Re: Puzzled:
MQJE001, MQRC 2102 for non-mqm users
List
[EMAIL PROTECTED]
C.AT
01/05/2004 10:50 AM
Please respond to
MQSeries List
Benjamin,
That is because the channel used by the client is using the authority of
the
QMgr. Unless you put an MCAUSER or a security exit that substitutes a
different UserID on the channel, you will get administrative rights. This
is true of all client-connections and, yes, it is dangerous.
-- T.Rob
-Original Message-
From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED]
Sent: Monday, January 05, 2004 9:55 AM
To: [EMAIL PROTECTED]
Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Bob, that's a good point. I've opened a ticket with IBM on this misleading
reason code.
However, if I use client mode, the jms application needs neither +inq nor
+connect to the qmgr, to put a message to a queue. It
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Thanks everyone for trying to clariy this for me. Actually, it was also my conviction that an MQI channel would be used for ANY client application to talk to a remote qmgr. I came to the last conclusion through a series of tests. my JMS program is on a local NT PC. it sends msg to MYQM on an AIX server, websvr1. As I did usual with MQclient applications , I defined a svrconn channel SVRC.MYQM on MYQM on websvr and defined a client connection channel on the NT PC, beside several other client channels to qmgrs on other servers. The environment variable MQCHLLIB has been defined to point to the file mqchltab's location. I defined all these clients channels under a single queue manager, which has nothing to do with any other queue manager, except to define all the client channels. 1. I defined a qcf this way: del qcf(qCF) def qcf(qCF) qmgr(MYQM) host(websvr1) channel(SVRC.MYQM) transport(client) port(1414) del q(reqQ) def q(reqQ) qmgr(MYQM) qu(TESTQ) end I run my jms program to put msg to the queue TESTQ on the remote MYQM, successful. 2. I removed the client channel definition on NT; run the jms program, msg successfully gets on the TESTQ on MYQM. I noticed the channel SVRC.MYQM is always inactive. 3. on websvr1's MYQM, I remove the svrconn channel SVRC.MYQM; run the program, it failed with msg: ... failed to create MQQueueManager ... 4. on MYQM, I recreated the svrconn channel SVRC.MYQM. However, I removed the property channel(SVRC.MYQM); run the program, successful. Here is the jndi setup script: del qcf(qCF) def qcf(qCF) qmgr(MYQM) host(websvr1) transport(client) port(1414) del q(reqQ) def q(reqQ) qmgr(MYQM) qu(TESTQ) end 5. on MYQM, I again removed svrconn channel SVRC.MYQM, run the program, successful. again. I checked, no svrconn channel is running, not even SYSTEM.DEF.SVRCONN . 6. on NT, I added back the property channel(SVRC.MYQM) in my jndi script, but removed host(websvr1), run the program, as Peter anticipated, I got the error message: ... failed to create MQQueueManager for 'localhost:MYQM' ... Under no circumstance did I see a svrconn channel became running except SYSTEM.ADMIN.SVRCONN, which is always running since I use remote admin. It is after all these tests did I arrive at the conclusion that JMS client doesn't use MQI channel unless we explicitly require that it use one. Even then, it is just referenced, not really used. Any IBMer out there can confirm or dis-confirm my argument? or further clarify it? best regards. Ben x.2474 Roger Lacroix [EMAIL PROTECTED] To: [EMAIL PROTECTED] ALWARE.BIZ cc: Sent by: MQSeriesSubject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List [EMAIL PROTECTED] C.AT 01/08/2004 12:26 PM Please respond to MQSeries List Hi Ben, I believe you have some misconceptions about your JMS / JNDI values. First off, if you are using 'transport(client)' then you WILL be using a SVRCONN channel - hence a MQI channel. Just because you did not specify it, does NOT mean you are not using one. I believe the default SVRCONN channel used (when none is specified) is 'SYSTEM.DEF.SVRCONN'. Under normal circumstances, the 'MCA USER ID' field of the 'SYSTEM.DEF.SVRCONN' is blank. This generally means that you will be connecting / opening / getting / putting messages under the UserId of 'mqm'. Secondly, you can implement a reasonable amount of MQ security in this scenario (of course, client server security exits would be better). At my current client, developers do not have access to the JMS / JNDI tree in UAT / PTE / PROD (only the SysAdmins and MQAdmins have access). Therefore, we code the following for the QCF or XAQCF in JMS / JNDI for WebLogic apps: def qcf(qCF) qmgr(MYQM) host(192.168.1.12) channel(MYSVRCONN) port(1415) transport(client) ClientId(FRED) An alternate approach that is sometimes done (not strongly recommended) is to allow the developer to code the UserId in their application. i.e. ((Message)outMessage).setStringProperty(JMSXUserID, FRED); In either case, we apply the necessary security to the UserId 'FRED' for the queue manager of 'MYQM'. Nobody, except for MQAdmins, is allowed to use the 'mqm' UserId (it is monitored). We have standards that state that developers, QA people, etc are not allowed access to the PROD queue managers unless approved but never with the 'mqm' UserId. We assign the appropriate authority to THEIR UserId. Since my client is a bank / brokage-house, it is a fire-able offense to access PROD data if you have not been approved. Hence, generally speaking, people do not risk it. Hope that helps. Regards, Roger Lacroix
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi Peter, How could I charge an outrageously large hourly rate if I give out my secrets. I wish grin Hint: If any message has a UserId of 'mqm' (for Unix) or MUSR_MQADMIN (for Windows) or CHIN (for OS/390 - where is the QMgr name) then you know you have a bad boy. I have created some Q sampler programs to look to at the UserId field of all messages in all queues. I run it in binding mode and it browses all messages (remember to get message of length 0 - zero) and checks the UserId field. (It is very fast!) It is setup to run 'X' times per hour (we use a random number). The other thing you should do is to add a simple server-side security channel exit to log or better verify the incoming IP address. For a PROD box, these IP addresses should be well-known and well-defined. Here is an excellent source for a sample (see LogIP or BlockIP): http://d1o111.dk.telia.net/~u149101068/index.htm?tips_and_tricks.htm Hope that helps. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Potkay, Peter M (PLC, IT) [EMAIL PROTECTED]: Nobody, except for MQAdmins, is allowed to use the 'mqm' UserId (it is monitored). Roger, how do you monitor that? -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 12:27 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Hi Ben, I believe you have some misconceptions about your JMS / JNDI values. First off, if you are using 'transport(client)' then you WILL be using a SVRCONN channel - hence a MQI channel. Just because you did not specify it, does NOT mean you are not using one. I believe the default SVRCONN channel used (when none is specified) is 'SYSTEM.DEF.SVRCONN'. Under normal circumstances, the 'MCA USER ID' field of the 'SYSTEM.DEF.SVRCONN' is blank. This generally means that you will be connecting / opening / getting / putting messages under the UserId of 'mqm'. Secondly, you can implement a reasonable amount of MQ security in this scenario (of course, client server security exits would be better). At my current client, developers do not have access to the JMS / JNDI tree in UAT / PTE / PROD (only the SysAdmins and MQAdmins have access). Therefore, we code the following for the QCF or XAQCF in JMS / JNDI for WebLogic apps: def qcf(qCF) qmgr(MYQM) host(192.168.1.12) channel(MYSVRCONN) port(1415) transport(client) ClientId(FRED) An alternate approach that is sometimes done (not strongly recommended) is to allow the developer to code the UserId in their application. i.e. ((Message)outMessage).setStringProperty(JMSXUserID, FRED); In either case, we apply the necessary security to the UserId 'FRED' for the queue manager of 'MYQM'. Nobody, except for MQAdmins, is allowed to use the 'mqm' UserId (it is monitored). We have standards that state that developers, QA people, etc are not allowed access to the PROD queue managers unless approved but never with the 'mqm' UserId. We assign the appropriate authority to THEIR UserId. Since my client is a bank / brokage-house, it is a fire-able offense to access PROD data if you have not been approved. Hence, generally speaking, people do not risk it. Hope that helps. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Benjamin F. Zhou [EMAIL PROTECTED]: Rob, thanks for the insight. However, a JMS application accesses a qmgr via a connection factory object defined in the JNDI namespace, NOT through a svrconn channel on the server, i,e. it's actually not using the MQI channel. It can be seen from the following entry in my definition script, that it actually creates a direct socket connection to the host and port: def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client) port(1415) So such a definition makes it even more dangerous since there is no more MQ level security can be activated. While writing this, it became clear to me that the above is provided as an alternative to using MQI channel to access a remote qmgr in order to avoid having to define a client channel on the client side. Certainly, the above definition can be altered to use MQI channel instead of the host propery: def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client) However, the first is a dangerous alternative. Any comment? regards, Ben Wyatt, T. Rob [EMAIL PROTECTED] To: [EMAIL PROTECTED] MERICA.COM cc: Sent by: MQSeriesSubject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List [EMAIL PROTECTED] C.AT 01/05/2004 10:50 AM Please respond to MQSeries List
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
a VERY BIG magnifying glass! From: Potkay, Peter M (PLC, IT) [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Date: Thu, 8 Jan 2004 14:04:41 -0500 Nobody, except for MQAdmins, is allowed to use the 'mqm' UserId (it is monitored). Roger, how do you monitor that? -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 12:27 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Hi Ben, I believe you have some misconceptions about your JMS / JNDI values. First off, if you are using 'transport(client)' then you WILL be using a SVRCONN channel - hence a MQI channel. Just because you did not specify it, does NOT mean you are not using one. I believe the default SVRCONN channel used (when none is specified) is 'SYSTEM.DEF.SVRCONN'. Under normal circumstances, the 'MCA USER ID' field of the 'SYSTEM.DEF.SVRCONN' is blank. This generally means that you will be connecting / opening / getting / putting messages under the UserId of 'mqm'. Secondly, you can implement a reasonable amount of MQ security in this scenario (of course, client server security exits would be better). At my current client, developers do not have access to the JMS / JNDI tree in UAT / PTE / PROD (only the SysAdmins and MQAdmins have access). Therefore, we code the following for the QCF or XAQCF in JMS / JNDI for WebLogic apps: def qcf(qCF) qmgr(MYQM) host(192.168.1.12) channel(MYSVRCONN) port(1415) transport(client) ClientId(FRED) An alternate approach that is sometimes done (not strongly recommended) is to allow the developer to code the UserId in their application. i.e. ((Message)outMessage).setStringProperty(JMSXUserID, FRED); In either case, we apply the necessary security to the UserId 'FRED' for the queue manager of 'MYQM'. Nobody, except for MQAdmins, is allowed to use the 'mqm' UserId (it is monitored). We have standards that state that developers, QA people, etc are not allowed access to the PROD queue managers unless approved but never with the 'mqm' UserId. We assign the appropriate authority to THEIR UserId. Since my client is a bank / brokage-house, it is a fire-able offense to access PROD data if you have not been approved. Hence, generally speaking, people do not risk it. Hope that helps. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Benjamin F. Zhou [EMAIL PROTECTED]: Rob, thanks for the insight. However, a JMS application accesses a qmgr via a connection factory object defined in the JNDI namespace, NOT through a svrconn channel on the server, i,e. it's actually not using the MQI channel. It can be seen from the following entry in my definition script, that it actually creates a direct socket connection to the host and port: def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client) port(1415) So such a definition makes it even more dangerous since there is no more MQ level security can be activated. While writing this, it became clear to me that the above is provided as an alternative to using MQI channel to access a remote qmgr in order to avoid having to define a client channel on the client side. Certainly, the above definition can be altered to use MQI channel instead of the host propery: def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client) However, the first is a dangerous alternative. Any comment? regards, Ben Wyatt, T. Rob [EMAIL PROTECTED] To: [EMAIL PROTECTED] MERICA.COM cc: Sent by: MQSeriesSubject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List [EMAIL PROTECTED] C.AT 01/05/2004 10:50 AM Please respond to MQSeries List Benjamin, That is because the channel used by the client is using the authority of the QMgr. Unless you put an MCAUSER or a security exit that substitutes a different UserID on the channel, you will get administrative rights. This is true of all client-connections and, yes, it is dangerous. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 9:55 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Bob, that's a good point. I've opened a ticket with IBM on this misleading reason code. However, if I use client mode, the jms application needs neither +inq nor +connect to the qmgr, to put a message to a queue. It dosn't even need a +put/+get/+brose. It seems to me that in the case of MQClient, it is the local qmgr that actually does the puts/gets. So no authorization is needed at all. But this sounds too dangerous, doesn't it?
Re: Do go looking for FDCs when nothing is wrong?
I second the motion on the new manual thing. Help me help myself, and I don't have to clog up the Passport Advantage line with yet another phone call Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Potkay, Peter M (PLC, IT) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RTFORD.COMSubject: Re: Do go looking for FDCs when nothing is wrong? Sent by: MQSeries List [EMAIL PROTECTED] AC.AT 01/08/2004 02:55 PM Please respond to MQSeries List You know, I was thinking to myself looking at these FDCs Holy cr*p, this whole place is about to fall apart right before my eyes!!!. But I went and actually looked at all my prod QMs. About 40% have no FDCs. The other 40% have some, but only at the rate of maybe 1 or 2 every 3 months. A couple here and there were weird (like 30 FDCs in a minute a year ago and nothing since). The queue managers that are running on Windows 2000 machines under control of MSCS are loaded with FDCs. Like 10 or 20 a month. I am going to focus on those, even though nothing is wrong. Maybe IBM will be able to help me flip a switch somewhere which would cause 90% of those to go away. I just hesitate to do it because nothing seems wrong, and this could turn into a full time job. Oh well, look out bullet, cuz I'm about to bite ya! If I can get it to the point where we only see 1 or 2 FDCs a month, I think an email with the servername in question when an FDC is thrown is a good idea. A great idea would be the ability to actually understand FDCs. A new manual perhaps? Please? :) -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 2:03 PM To: [EMAIL PROTECTED] Subject: Re: Do go looking for FDCs when nothing is wrong? I don't know. I have had sites where I showed up the first day and the file systems were pretty full because of the FDC issues. But as things got under control and the environment stabilized the issue of FDC's showing up became became lees of an issue if non-existent. I don't recall being iat a site where the FDC continued to run out of hand after making the environment well. bobbee From: Bill Anderson [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Do go looking for FDCs when nothing is wrong? Date: Thu, 8 Jan 2004 13:20:17 -0500 I just had to ring in on this one. The thing is, the queue manager seems to have sort of a hair trigger in regard to what sort of problems cause it to write an FDC file. I find them often, and have no way of quickly determining why it (more commonly they) are there. If I got serious about hunting them down every time, I could make a career out of It. It doesn't help any that little or no documentation exists on how to effectively troubleshoot using one. On more than one occasion I have opened a ticket with IBM to help me solve a problem where FDC files were produced, and had a 2nd level support person tell me to send them, but they don't often contain much useful data. I do think it is wise to automate handling them. I need to find the time to write a script that not only finds them but potentially parses them and write things like the date / time stamp, program name, and probe description (just to name a few) to a log file that could be imported into a spread sheet. Then you could look for trends. If something specific continues to occur over and over, that would be justification to launch a science project to determine why, and fix it. I would love to know enough about FDC files to write a program, or Perl script that could parse hundreds of them and write a report based on some key data. But that's not likely to wind up on my project plan list any time soon! Cheers 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 _ Tired of slow downloads? Compare online deals from your local high-speed providers now. https://broadband.msn.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 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi, Those client channels or MQCHLLIB environment variable will have NO effect on your JMS program. (1) Normal. (2) Channel deletion has no effect. Same as (1). (3) Normal. (4) It will use the default SVRCONN channel of 'SYSTEM.DEF.SVRCONN'. Again normal. (5) Normal. You may not be fast enough to see it be running. (6) Normal. The one thing that I have noticed with version 5.3 of WMQ is that if an application behaves well (i.e. properly closes queues and disconnects) then within a second or two, the SVRCONN channel goes to inactive (assuming all 1 connection). Therefore, to properly see a running SVRCONN channels, you will need to send a few hundred messages or put a 100ms sleep between puts. Hope that helps. Regards, Roger Lacroix Capitalware Inc. http://www.captialware.biz Quoting Benjamin F. Zhou [EMAIL PROTECTED]: Thanks everyone for trying to clariy this for me. Actually, it was also my conviction that an MQI channel would be used for ANY client application to talk to a remote qmgr. I came to the last conclusion through a series of tests. my JMS program is on a local NT PC. it sends msg to MYQM on an AIX server, websvr1. As I did usual with MQclient applications , I defined a svrconn channel SVRC.MYQM on MYQM on websvr and defined a client connection channel on the NT PC, beside several other client channels to qmgrs on other servers. The environment variable MQCHLLIB has been defined to point to the file mqchltab's location. I defined all these clients channels under a single queue manager, which has nothing to do with any other queue manager, except to define all the client channels. 1. I defined a qcf this way: del qcf(qCF) def qcf(qCF) qmgr(MYQM) host(websvr1) channel(SVRC.MYQM) transport(client) port(1414) del q(reqQ) def q(reqQ) qmgr(MYQM) qu(TESTQ) end I run my jms program to put msg to the queue TESTQ on the remote MYQM, successful. 2. I removed the client channel definition on NT; run the jms program, msg successfully gets on the TESTQ on MYQM. I noticed the channel SVRC.MYQM is always inactive. 3. on websvr1's MYQM, I remove the svrconn channel SVRC.MYQM; run the program, it failed with msg: ... failed to create MQQueueManager ... 4. on MYQM, I recreated the svrconn channel SVRC.MYQM. However, I removed the property channel(SVRC.MYQM); run the program, successful. Here is the jndi setup script: del qcf(qCF) def qcf(qCF) qmgr(MYQM) host(websvr1) transport(client) port(1414) del q(reqQ) def q(reqQ) qmgr(MYQM) qu(TESTQ) end 5. on MYQM, I again removed svrconn channel SVRC.MYQM, run the program, successful. again. I checked, no svrconn channel is running, not even SYSTEM.DEF.SVRCONN . 6. on NT, I added back the property channel(SVRC.MYQM) in my jndi script, but removed host(websvr1), run the program, as Peter anticipated, I got the error message: ... failed to create MQQueueManager for 'localhost:MYQM' ... Under no circumstance did I see a svrconn channel became running except SYSTEM.ADMIN.SVRCONN, which is always running since I use remote admin. It is after all these tests did I arrive at the conclusion that JMS client doesn't use MQI channel unless we explicitly require that it use one. Even then, it is just referenced, not really used. Any IBMer out there can confirm or dis-confirm my argument? or further clarify it? best regards. Ben x.2474 Roger Lacroix [EMAIL PROTECTED] To: [EMAIL PROTECTED] ALWARE.BIZ cc: Sent by: MQSeriesSubject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List [EMAIL PROTECTED] C.AT 01/08/2004 12:26 PM Please respond to MQSeries List Hi Ben, I believe you have some misconceptions about your JMS / JNDI values. First off, if you are using 'transport(client)' then you WILL be using a SVRCONN channel - hence a MQI channel. Just because you did not specify it, does NOT mean you are not using one. I believe the default SVRCONN channel used (when none is specified) is 'SYSTEM.DEF.SVRCONN'. Under normal circumstances, the 'MCA USER ID' field of the 'SYSTEM.DEF.SVRCONN' is blank. This generally means that you will be connecting / opening / getting / putting messages under the UserId of 'mqm'. Secondly, you can implement a reasonable amount of MQ security in this scenario (of course, client server security exits would be better). At my current client, developers do not have access to the JMS / JNDI tree in UAT / PTE / PROD (only the SysAdmins and MQAdmins have access). Therefore, we code the following for the QCF or XAQCF in JMS / JNDI for WebLogic apps: def
Re: Do go looking for FDCs when nothing is wrong?
I think there are cases where the product doesn't have a good error message to generate and defaults to an FDC file. I have had a couple instances (one I believe was when I was using incorrect SSL settings and connecting as a client) where the qmgr threw FDCs which were a result of errors in my application. That' why I sometimes ignore FDCs. I could go to IBM support for each of these, but many times they correlate to some error or problem that is obvious. Ideally mq would generate a more friendly error, but this may not always be possible. Nick -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Thursday, January 08, 2004 11:55 AM To: [EMAIL PROTECTED] Subject: Re: Do go looking for FDCs when nothing is wrong? You know, I was thinking to myself looking at these FDCs Holy cr*p, this whole place is about to fall apart right before my eyes!!!. But I went and actually looked at all my prod QMs. About 40% have no FDCs. The other 40% have some, but only at the rate of maybe 1 or 2 every 3 months. A couple here and there were weird (like 30 FDCs in a minute a year ago and nothing since). The queue managers that are running on Windows 2000 machines under control of MSCS are loaded with FDCs. Like 10 or 20 a month. I am going to focus on those, even though nothing is wrong. Maybe IBM will be able to help me flip a switch somewhere which would cause 90% of those to go away. I just hesitate to do it because nothing seems wrong, and this could turn into a full time job. Oh well, look out bullet, cuz I'm about to bite ya! If I can get it to the point where we only see 1 or 2 FDCs a month, I think an email with the servername in question when an FDC is thrown is a good idea. A great idea would be the ability to actually understand FDCs. A new manual perhaps? Please? :) -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 2:03 PM To: [EMAIL PROTECTED] Subject: Re: Do go looking for FDCs when nothing is wrong? I don't know. I have had sites where I showed up the first day and the file systems were pretty full because of the FDC issues. But as things got under control and the environment stabilized the issue of FDC's showing up became became lees of an issue if non-existent. I don't recall being iat a site where the FDC continued to run out of hand after making the environment well. bobbee From: Bill Anderson [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Do go looking for FDCs when nothing is wrong? Date: Thu, 8 Jan 2004 13:20:17 -0500 I just had to ring in on this one. The thing is, the queue manager seems to have sort of a hair trigger in regard to what sort of problems cause it to write an FDC file. I find them often, and have no way of quickly determining why it (more commonly they) are there. If I got serious about hunting them down every time, I could make a career out of It. It doesn't help any that little or no documentation exists on how to effectively troubleshoot using one. On more than one occasion I have opened a ticket with IBM to help me solve a problem where FDC files were produced, and had a 2nd level support person tell me to send them, but they don't often contain much useful data. I do think it is wise to automate handling them. I need to find the time to write a script that not only finds them but potentially parses them and write things like the date / time stamp, program name, and probe description (just to name a few) to a log file that could be imported into a spread sheet. Then you could look for trends. If something specific continues to occur over and over, that would be justification to launch a science project to determine why, and fix it. I would love to know enough about FDC files to write a program, or Perl script that could parse hundreds of them and write a report based on some key data. But that's not likely to wind up on my project plan list any time soon! Cheers 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 _ Tired of slow downloads? Compare online deals from your local high-speed providers now. https://broadband.msn.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 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,
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi, Good stuff. Client channel or MQCHLIB (or MQSERVER) environment variable is ONLY used by C/C++/COBOL/VB type programs. IBM decided, for good or bad, that when coding for MQ base Java or Java MQ JMS programs, the MQ connection framework would not use either Client channel or MQCHLIB. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Benjamin Zhou [EMAIL PROTECTED]: Hi Roger, great insight ! Following your suggestion, I let my jms program on NT send 1000 msg, now I can see the SYSTEM.DEF.SVRCONN in running state for a few seconds. Just one more question, why does client connection channel definition or MQCHLIB variable has no effect on JMS program? best regards, Ben x.2474 Roger Lacroix [EMAIL PROTECTED] To: MQSeries List [EMAIL PROTECTED] alware.biz cc: Benjamin F. Zhou [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users 01/08/2004 03:22 PM Hi, Those client channels or MQCHLLIB environment variable will have NO effect on your JMS program. (1) Normal. (2) Channel deletion has no effect. Same as (1). (3) Normal. (4) It will use the default SVRCONN channel of 'SYSTEM.DEF.SVRCONN'. Again normal. (5) Normal. You may not be fast enough to see it be running. (6) Normal. The one thing that I have noticed with version 5.3 of WMQ is that if an application behaves well (i.e. properly closes queues and disconnects) then within a second or two, the SVRCONN channel goes to inactive (assuming all 1 connection). Therefore, to properly see a running SVRCONN channels, you will need to send a few hundred messages or put a 100ms sleep between puts. Hope that helps. Regards, Roger Lacroix Capitalware Inc. http://www.captialware.biz Quoting Benjamin F. Zhou [EMAIL PROTECTED]: Thanks everyone for trying to clariy this for me. Actually, it was also my conviction that an MQI channel would be used for ANY client application to talk to a remote qmgr. I came to the last conclusion through a series of tests. my JMS program is on a local NT PC. it sends msg to MYQM on an AIX server, websvr1. As I did usual with MQclient applications , I defined a svrconn channel SVRC.MYQM on MYQM on websvr and defined a client connection channel on the NT PC, beside several other client channels to qmgrs on other servers. The environment variable MQCHLLIB has been defined to point to the file mqchltab's location. I defined all these clients channels under a single queue manager, which has nothing to do with any other queue manager, except to define all the client channels. 1. I defined a qcf this way: del qcf(qCF) def qcf(qCF) qmgr(MYQM) host(websvr1) channel(SVRC.MYQM) transport(client) port(1414) del q(reqQ) def q(reqQ) qmgr(MYQM) qu(TESTQ) end I run my jms program to put msg to the queue TESTQ on the remote MYQM, successful. 2. I removed the client channel definition on NT; run the jms program, msg successfully gets on the TESTQ on MYQM. I noticed the channel SVRC.MYQM is always inactive. 3. on websvr1's MYQM, I remove the svrconn channel SVRC.MYQM; run the program, it failed with msg: ... failed to create MQQueueManager ... 4. on MYQM, I recreated the svrconn channel SVRC.MYQM. However, I removed the property channel(SVRC.MYQM); run the program, successful. Here is the jndi setup script: del qcf(qCF) def qcf(qCF) qmgr(MYQM) host(websvr1) transport(client) port(1414) del q(reqQ) def q(reqQ) qmgr(MYQM) qu(TESTQ) end 5. on MYQM, I again removed svrconn channel SVRC.MYQM, run the program, successful. again. I checked, no svrconn channel is running, not even SYSTEM.DEF.SVRCONN . 6. on NT, I added back the property channel(SVRC.MYQM) in my jndi script, but removed host(websvr1), run the program, as Peter anticipated, I got the error message: ... failed to create MQQueueManager for 'localhost:MYQM' ... Under no circumstance did I see a svrconn channel became running except SYSTEM.ADMIN.SVRCONN, which is always running since I use remote admin. It is after all these tests did I arrive at the conclusion that JMS client doesn't use MQI channel unless we explicitly require that it use one. Even then, it is just referenced, not really used. Any IBMer out there can confirm or dis-confirm my argument? or further clarify it? best regards. Ben x.2474 Roger Lacroix [EMAIL PROTECTED] To: [EMAIL PROTECTED] ALWARE.BIZ cc: Sent by: MQSeriesSubject: Re:
More Client Channel Security - was Puzzled: MQJE001, MQRC 2102 fo r non-mqm users
I would think that the below method would work great for capturing somebody that puts messages to queues where those messages hang around for a while. But what damage serious damage could a message sitting in a queue do? The real problem I see is a user coming in as mqm can drop messages to your command queue (oh, I don't know, change all the letter Os to zeros on your connames in your SNDR channels, or delete a q or 2) and then get their replies from the temp dyn reply queue. This would not leave any trace, unless they happened to do it at the exact second that your job runs, and you browsed the message before the command server grabbed it. I think the only solution to really stop this if the MCAUSER is to be blank is to have an exit on that channel to stop this ID. If I had a magic wand, I would make it so that SVRCONN channels with blank MCAUSERs would default the userID to knucklehead if the client did not present one (instead of defaulting to mqm). Also, a new channel attribute called BlockMQM which could be turned on to reject (with no further exits or efforts) any connections coming in as mqm or MUSR_MQADMIN. Hey Paul, for Christmas 2004?!?! ;-) I was really looking forward to using that blockIp address security exit to lockdown MQExplorer access (I got static IP address for all our team members). But, the first time I logged in from home it failed. Actually it worked as designed, and blocked me, because dialing over VPN gave me a dynamic IP address, and they tell me it has to be this way. Man, do I hope the Eclipse version of MQExplorer addresses the problem of security! -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 3:04 PM To: MQSeries List Cc: Potkay, Peter M (PLC, IT) Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Hi Peter, How could I charge an outrageously large hourly rate if I give out my secrets. I wish grin Hint: If any message has a UserId of 'mqm' (for Unix) or MUSR_MQADMIN (for Windows) or CHIN (for OS/390 - where is the QMgr name) then you know you have a bad boy. I have created some Q sampler programs to look to at the UserId field of all messages in all queues. I run it in binding mode and it browses all messages (remember to get message of length 0 - zero) and checks the UserId field. (It is very fast!) It is setup to run 'X' times per hour (we use a random number). The other thing you should do is to add a simple server-side security channel exit to log or better verify the incoming IP address. For a PROD box, these IP addresses should be well-known and well-defined. Here is an excellent source for a sample (see LogIP or BlockIP): http://d1o111.dk.telia.net/~u149101068/index.htm?tips_and_tricks.htm Hope that helps. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Potkay, Peter M (PLC, IT) [EMAIL PROTECTED]: Nobody, except for MQAdmins, is allowed to use the 'mqm' UserId (it is monitored). Roger, how do you monitor that? -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 12:27 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Hi Ben, I believe you have some misconceptions about your JMS / JNDI values. First off, if you are using 'transport(client)' then you WILL be using a SVRCONN channel - hence a MQI channel. Just because you did not specify it, does NOT mean you are not using one. I believe the default SVRCONN channel used (when none is specified) is 'SYSTEM.DEF.SVRCONN'. Under normal circumstances, the 'MCA USER ID' field of the 'SYSTEM.DEF.SVRCONN' is blank. This generally means that you will be connecting / opening / getting / putting messages under the UserId of 'mqm'. Secondly, you can implement a reasonable amount of MQ security in this scenario (of course, client server security exits would be better). At my current client, developers do not have access to the JMS / JNDI tree in UAT / PTE / PROD (only the SysAdmins and MQAdmins have access). Therefore, we code the following for the QCF or XAQCF in JMS / JNDI for WebLogic apps: def qcf(qCF) qmgr(MYQM) host(192.168.1.12) channel(MYSVRCONN) port(1415) transport(client) ClientId(FRED) An alternate approach that is sometimes done (not strongly recommended) is to allow the developer to code the UserId in their application. i.e. ((Message)outMessage).setStringProperty(JMSXUserID, FRED); In either case, we apply the necessary security to the UserId 'FRED' for the queue manager of 'MYQM'. Nobody, except for MQAdmins, is allowed to use the 'mqm' UserId (it is monitored). We have standards that state that developers, QA people, etc are not allowed access to the PROD queue managers unless approved but never with the 'mqm' UserId. We assign the appropriate authority to THEIR UserId. Since my client is a bank / brokage-house, it is a fire-able
Re: More Client Channel Security - was Puzzled: MQJE001, MQRC 2102 fo r non-mqm users
Hi, Oh, I agree fully. Like I said earlier, client server-side security exits are the only way to go. This method is there only to say we are monitoring the queues, so don't be a bad boy!!! Even if a message hangs around for only a second, we may catch it (Murphy's law - the user might get burnt). Funny you should mention the knucklehead idea. I have been creating / playing around with an security exit that blocks any connection that does NOT have a UserId specified. Of course, that does not stop a user from using 'mqm' but at least it would stop blank UserIds. Also, you could enhance BlockIP to do a combo check. If the IP comes from your VPN say 10.10.10.*, you could also check the UserId to see if it is in your list of acceptable UserIds from the VPN subnet. Of course, this is not as good as a static IP check but it is better than being wide open. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz At 11:45 PM 1/8/2004, Potkay, Peter M (PLC, IT) wrote: I would think that the below method would work great for capturing somebody that puts messages to queues where those messages hang around for a while. But what damage serious damage could a message sitting in a queue do? The real problem I see is a user coming in as mqm can drop messages to your command queue (oh, I don't know, change all the letter Os to zeros on your connames in your SNDR channels, or delete a q or 2) and then get their replies from the temp dyn reply queue. This would not leave any trace, unless they happened to do it at the exact second that your job runs, and you browsed the message before the command server grabbed it. I think the only solution to really stop this if the MCAUSER is to be blank is to have an exit on that channel to stop this ID. If I had a magic wand, I would make it so that SVRCONN channels with blank MCAUSERs would default the userID to knucklehead if the client did not present one (instead of defaulting to mqm). Also, a new channel attribute called BlockMQM which could be turned on to reject (with no further exits or efforts) any connections coming in as mqm or MUSR_MQADMIN. Hey Paul, for Christmas 2004?!?! ;-) I was really looking forward to using that blockIp address security exit to lockdown MQExplorer access (I got static IP address for all our team members). But, the first time I logged in from home it failed. Actually it worked as designed, and blocked me, because dialing over VPN gave me a dynamic IP address, and they tell me it has to be this way. Man, do I hope the Eclipse version of MQExplorer addresses the problem of security! -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 3:04 PM To: MQSeries List Cc: Potkay, Peter M (PLC, IT) Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Hi Peter, How could I charge an outrageously large hourly rate if I give out my secrets. I wish grin Hint: If any message has a UserId of 'mqm' (for Unix) or MUSR_MQADMIN (for Windows) or CHIN (for OS/390 - where is the QMgr name) then you know you have a bad boy. I have created some Q sampler programs to look to at the UserId field of all messages in all queues. I run it in binding mode and it browses all messages (remember to get message of length 0 - zero) and checks the UserId field. (It is very fast!) It is setup to run 'X' times per hour (we use a random number). The other thing you should do is to add a simple server-side security channel exit to log or better verify the incoming IP address. For a PROD box, these IP addresses should be well-known and well-defined. Here is an excellent source for a sample (see LogIP or BlockIP): http://d1o111.dk.telia.net/~u149101068/index.htm?tips_and_tricks.htm Hope that helps. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Potkay, Peter M (PLC, IT) [EMAIL PROTECTED]: Nobody, except for MQAdmins, is allowed to use the 'mqm' UserId (it is monitored). Roger, how do you monitor that? -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 12:27 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Hi Ben, I believe you have some misconceptions about your JMS / JNDI values. First off, if you are using 'transport(client)' then you WILL be using a SVRCONN channel - hence a MQI channel. Just because you did not specify it, does NOT mean you are not using one. I believe the default SVRCONN channel used (when none is specified) is 'SYSTEM.DEF.SVRCONN'. Under normal circumstances, the 'MCA USER ID' field of the 'SYSTEM.DEF.SVRCONN' is blank. This generally means that you will be connecting / opening / getting / putting messages under the UserId of 'mqm'. Secondly, you can implement a reasonable amount of MQ security in this scenario (of course, client server security exits would be better). At my current client, developers do not have access
