Re: Channel problem
Hi! Thanks for the tip, but where do I define AdoptMCA? Regards Gunilla -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Clarke Sent: den 7 maj 2004 18:14 To: [EMAIL PROTECTED] Subject: Re: Channel problem Gunilla, If I understand you correctly what you're saying is that when your channel has a network problem the sender channel tries to reconnect but the receiver channel hasn't yet realised that there is a network problem since it is still sitting in a TCP/IP recv(). The solution to this problem is to use AdoptMCA. You can configure your server to say that if a new connection is made over the same channel from the same QM and from the same IP address that the previous instance of the channel should be terminated. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Lindberg, Gunilla To: [EMAIL PROTECTED] gunilla.lindbergcc: @HP.COM Subject: Channel problem Sent by: MQSeries List [EMAIL PROTECTED] N.AC.AT 07/05/2004 15:33 Please respond to MQSeries List Hi! We have a lot of qmanagers and they are in different nets with firewalls between. When there is some problem kind of net problem we get channel problem. The receiving side don't understand that the sender side is off. So the receiver is running and when the sender tries to connect it only get in to retry state. We don't have this kind of problem with qmanagers in the same net. Someone that have any ideas? Regards Gunilla Lindberg ___ Hewlett-Packard Sverige AB SE-125 82 Stockholm Visit: Götalandsvägen 230, Älvsjö Phone no: +46 8 524 92670 Mailto: [EMAIL PROTECTED] http://www.hp.se 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: Channel problem
On windows it is found on the channels tab on the queue manager properties using mq services. On unix it would be put in the queue managers qm.ini file. -Original Message- From: Lindberg, Gunilla [mailto:[EMAIL PROTECTED] Sent: Monday, May 10, 2004 3:38 AM To: [EMAIL PROTECTED] Subject: Re: Channel problem Hi! Thanks for the tip, but where do I define AdoptMCA? Regards Gunilla -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Clarke Sent: den 7 maj 2004 18:14 To: [EMAIL PROTECTED] Subject: Re: Channel problem Gunilla, If I understand you correctly what you're saying is that when your channel has a network problem the sender channel tries to reconnect but the receiver channel hasn't yet realised that there is a network problem since it is still sitting in a TCP/IP recv(). The solution to this problem is to use AdoptMCA. You can configure your server to say that if a new connection is made over the same channel from the same QM and from the same IP address that the previous instance of the channel should be terminated. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Lindberg, Gunilla To: [EMAIL PROTECTED] gunilla.lindbergcc: @HP.COM Subject: Channel problem Sent by: MQSeries List [EMAIL PROTECTED] N.AC.AT 07/05/2004 15:33 Please respond to MQSeries List Hi! We have a lot of qmanagers and they are in different nets with firewalls between. When there is some problem kind of net problem we get channel problem. The receiving side don't understand that the sender side is off. So the receiver is running and when the sender tries to connect it only get in to retry state. We don't have this kind of problem with qmanagers in the same net. Someone that have any ideas? Regards Gunilla Lindberg ___ Hewlett-Packard Sverige AB SE-125 82 Stockholm Visit: Götalandsvägen 230, Älvsjö Phone no: +46 8 524 92670 Mailto: [EMAIL PROTECTED] http://www.hp.se Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Channel problem
Title: Channel problem Hi! We have a lot of qmanagers and they are in different nets with firewalls between. When there is some problem kind of net problem we get channel problem. The receiving side don't understand that the sender side is off. So the receiver is running and when the sender tries to connect it only get in to retry state. We don't have this kind of problem with qmanagers in the same net. Someone that have any ideas? Regards Gunilla Lindberg ___ Hewlett-Packard Sverige AB SE-125 82 Stockholm Visit: Götalandsvägen 230, Älvsjö Phone no: +46 8 524 92670 Mailto: [EMAIL PROTECTED] http://www.hp.se
Re: Channel problem
Gunilla, If I understand you correctly what you're saying is that when your channel has a network problem the sender channel tries to reconnect but the receiver channel hasn't yet realised that there is a network problem since it is still sitting in a TCP/IP recv(). The solution to this problem is to use AdoptMCA. You can configure your server to say that if a new connection is made over the same channel from the same QM and from the same IP address that the previous instance of the channel should be terminated. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Lindberg, Gunilla To: [EMAIL PROTECTED] gunilla.lindbergcc: @HP.COM Subject: Channel problem Sent by: MQSeries List [EMAIL PROTECTED] N.AC.AT 07/05/2004 15:33 Please respond to MQSeries List Hi! We have a lot of qmanagers and they are in different nets with firewalls between. When there is some problem kind of net problem we get channel problem. The receiving side don't understand that the sender side is off. So the receiver is running and when the sender tries to connect it only get in to retry state. We don't have this kind of problem with qmanagers in the same net. Someone that have any ideas? Regards Gunilla Lindberg ___ Hewlett-Packard Sverige AB SE-125 82 Stockholm Visit: Götalandsvägen 230, Älvsjö Phone no: +46 8 524 92670 Mailto: [EMAIL PROTECTED] http://www.hp.se 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 problem
Check that you have ADOPTMCA specified for your channels. Doug Lindberg, Gunilla To: [EMAIL PROTECTED] gunilla.lindber cc: [EMAIL PROTECTED]Subject: Channel problem Sent by: MQSeries List [EMAIL PROTECTED] EN.AC.AT 05/07/2004 10:33 AM Please respond to MQSeries List Hi! We have a lot of qmanagers and they are in different nets with firewalls between. When there is some problem kind of net problem we get channel problem. The receiving side don't understand that the sender side is off. So the receiver is running and when the sender tries to connect it only get in to retry state. We don't have this kind of problem with qmanagers in the same net. Someone that have any ideas? Regards Gunilla Lindberg ___ Hewlett-Packard Sverige AB SE-125 82 Stockholm Visit: Götalandsvägen 230, Älvsjö Phone no: +46 8 524 92670 Mailto: [EMAIL PROTECTED] http://www.hp.se 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 problem
Title: Channel problem Would the channels start when you issue a start channel command? Are there any entries in the AMQERR01.LOG? Have you checked if the Message Sequence Number is in sync with each other on SDR and RCVR sides? -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Lindberg, GunillaSent: Friday, May 07, 2004 10:33 AMTo: [EMAIL PROTECTED]Subject: Channel problem Hi! We have a lot of qmanagers and they are in different nets with firewalls between. When there is some problem kind of net problem we get channel problem. The receiving side don't understand that the sender side is off. So the receiver is running and when the sender tries to connect it only get in to retry state. We don't have this kind of problem with qmanagers in the same net. Someone that have any ideas? Regards Gunilla Lindberg___Hewlett-Packard Sverige ABSE-125 82 StockholmVisit: Götalandsvägen 230, ÄlvsjöPhone no: +46 8 524 92670Mailto: [EMAIL PROTECTED]http://www.hp.se
Sender channel problem
Hi all, I have a problem with a sender channel not staying up, and I cannot figure out why. QM1 = TLINKTT.QMAN, runs on W2K, MQ5.3, CSD06 QM2 = NADCRISPT.QMAN runs on HPUX, MQ5.2, CSD05 I have other HPUX queue managers with the same specs connecting fine (to QM1), so I do not think it has anything to do with the MQ5.3/MQ5.2 differences sender TLTT.TO.NADCRISPT (on QM1) starts up nicely, runs perfectly sender NADCRISPT.TO.TLTT (on QM2) keeps on giving errors It looks like it comes up long enough to start the receiver channel (NADCRISPT.TO.TLTT) on QM1, then gets some error and goes into retrying state. The receiver on QM1 stays running which explains the "channel in use" errors I see in QM2's error log Deleting all the messages from the XMIT queue on QM2 seems to fix the problem for a while(few minutes). The channel stays up long enough to let a few messages flow(numbers vary between 6 and 14)before the channel dies/goes to retry and whole problem repeats itself. The sender/receiver pair from QM1 to QM2 in the meantime is up and messages flow normally(which I assume means that it is not related to "bad connection" problems) I attach the relevant parts from both QM's error logs- hope someone can help Regards Enrico Strydom Perago FSE PS - I checked all of the parms on both senders, receivers XMit queues - no differences in BATCHSZ, DISCINT, etc . . . QM1_TLTT_error.log Description: Binary data QM2_NADCRISPT_error.log Description: Binary data
Re: Sender channel problem
Once the channel has gone into a retrying state, stop both sides, look at the backout count of the first message on the XMITQ, if it is 0, there is something wrong with the message you sending, just a stone in the bush From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Enrico Strydom Sent: 25 March 2004 01:38 PM To: [EMAIL PROTECTED] Subject: Sender channel problem Hi all, I have a problem with a sender channel not staying up, and I cannot figure out why. QM1 = TLINKTT.QMAN, runs on W2K, MQ5.3, CSD06 QM2 = NADCRISPT.QMAN runs on HPUX, MQ5.2, CSD05 I have other HPUX queue managers with the same specs connecting fine (to QM1), so I do not think it has anything to do with the MQ5.3/MQ5.2 differences sender TLTT.TO.NADCRISPT (on QM1) starts up nicely, runs perfectly sender NADCRISPT.TO.TLTT (on QM2) keeps on giving errors It looks like it comes up long enough to start the receiver channel (NADCRISPT.TO.TLTT) on QM1, then gets some error and goes into retrying state. The receiver on QM1 stays running which explains the channel in use errors I see in QM2's error log Deleting all the messages from the XMIT queue on QM2 seems to fix the problem for a while(few minutes). The channel stays up long enough to let a few messages flow(numbers vary between 6 and 14)before the channel dies/goes to retry and whole problem repeats itself. The sender/receiver pair from QM1 to QM2 in the meantime is up and messages flow normally(which I assume means that it is not related to bad connection problems) I attach the relevant parts from both QM's error logs- hope someone can help Regards Enrico Strydom Perago FSE PS - I checked all of the parms on both senders, receivers XMit queues - no differences in BATCHSZ, DISCINT, etc . . . Any views expressed in this message are those of the individual sender, and T-Systems South Africa (Pty) Ltd accepts no liability therefore, except where the sender specifically states them to be those of T-Systems South Africa (Pty) Ltd. Although this message has been scanned for the possible presence of computer viruses prior to despatch, T-Systems South Africa (Pty) Ltd cannot be held responsible for any viruses or other material transmitted with, or as part of, this message.
Re: Sender channel problem
Hi Enrico, Here is what I would do to start with (not knowing all the details about your prob): 1- On both queue managers set the ADOPT NEW MCA (ALL) 2- Stop the channels on both ends 3- Start the receiver on QM1 4- (Make sure step 3 is done first)Start the sender on QM2 5- Send some messages from QM2 Let us know what happens. Regards, Ruzi --- Enrico Strydom [EMAIL PROTECTED] wrote: Hi all, I have a problem with a sender channel not staying up, and I cannot figure out why. QM1 = TLINKTT.QMAN, runs on W2K, MQ5.3, CSD06 QM2 = NADCRISPT.QMAN runs on HPUX, MQ5.2, CSD05 I have other HPUX queue managers with the same specs connecting fine (to QM1), so I do not think it has anything to do with the MQ5.3/MQ5.2 differences sender TLTT.TO.NADCRISPT (on QM1) starts up nicely, runs perfectly sender NADCRISPT.TO.TLTT (on QM2) keeps on giving errors It looks like it comes up long enough to start the receiver channel (NADCRISPT.TO.TLTT) on QM1, then gets some error and goes into retrying state. The receiver on QM1 stays running which explains the channel in use errors I see in QM2's error log Deleting all the messages from the XMIT queue on QM2 seems to fix the problem for a while(few minutes). The channel stays up long enough to let a few messages flow(numbers vary between 6 and 14) before the channel dies/goes to retry and whole problem repeats itself. The sender/receiver pair from QM1 to QM2 in the meantime is up and messages flow normally(which I assume means that it is not related to bad connection problems) I attach the relevant parts from both QM's error logs - hope someone can help Regards Enrico Strydom Perago FSE PS - I checked all of the parms on both senders, receivers XMit queues - no differences in BATCHSZ, DISCINT, etc . . . ATTACHMENT part 2 application/octet-stream name=QM1_TLTT_error.log ATTACHMENT part 3 application/octet-stream name=QM2_NADCRISPT_error.log 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: A channel problem
I checked all other error logs and there are no additonal errors. I dont have direct access to the OS/390 system and must go through a couple of people to get information. The channel (JESTER./QUQ1) still works, the only difference besides the name if the port is 1414. The dns name is the same for both channels. If anyone has any ideas, please let me know. Jeff Tressler Jeff, Error message ... AMQ9209: Connection to host 'muqz (xxx)' closed. means that the 'other side' has closed your connection so you really need to look at the OS/390 end to find out why. On this side of the fence all we know is that someone closed the socket we were using so there's no extra information we can give in the HP error logs. The most common reason for something like this is that you've misconfigured the hostname and port and you've connected to something but it isn't being used by WMQ. I would double check that you really do have a listener started on z/OS listening on 1418. If you do then there should be some form of message in the WMQ console on 390 telling you why the connection was dropped. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
A channel problem
Hi, we are having a channel problem. It probably is something simple we are overlooking since nothing special is being done. The is an HP-UX system running MQSeries v5.1 sending to an OS/390 running WebSphere MQ v5.3. There are no channel exits and the firewalls have been opened. Here is the sender channel definition 20 : display channel (JESTER./QUQ5) all AMQ8414: Display Channel details. CHANNEL(JESTER./QUQ5) CHLTYPE(SDR) TRPTYPE(TCP)DESCR( ) XMITQ(QUQ5) MCANAME( ) MODENAME( ) TPNAME( ) BATCHSZ(50) DISCINT(6000) SHORTRTY(10)SHORTTMR(60) LONGRTY(9) LONGTMR(1200) SCYEXIT( ) SEQWRAP(9) MAXMSGL(4194304)CONVERT(NO) SCYDATA( ) USERID( ) PASSWORD( ) MCATYPE(PROCESS) CONNAME(xxx(1418)) HBINT(300) BATCHINT(0) NPMSPEED(FAST) MCAUSER( ) ALTDATE(2003-08-12) ALTTIME(12.29.19) MSGEXIT( ) SENDEXIT( ) RCVEXIT( ) MSGDATA( ) SENDDATA( ) RCVDATA( ) I attempt to execute a PING CHANNEL and I get the following: 18 : ping channel (JESTER./QUQ5) AMQ9209: Connection to host 'muqz (xxx)' closed. The channel goes into retry and the error in /var/mqm/qmgrs/*DEV36AF/errors/*1.LOG --- 08/12/03 12:41:48 AMQ9002: Channel program started. EXPLANATION: Channel program 'JESTER./QUQ5' started. ACTION: None. --- 08/12/03 12:47:49 AMQ9209: Connection to host 'muqz (xxx)' closed. EXPLANATION: An error occurred receiving data from 'muqz (xxx)' over TCP/IP. The connection to the remote host has unexpectedly terminated. ACTION: Tell the systems administrator. --- 08/12/03 12:47:49 AMQ: Channel program ended abnormally. EXPLANATION: Channel program 'JESTER./QUQ5' ended abnormally. ACTION: Look at previous error messages for channel program 'JESTER./QUQ5' in the error files to determine the cause of the failure. --- I checked all other error logs and there are no additonal errors. I dont have direct access to the OS/390 system and must go through a couple of people to get information. The channel (JESTER./QUQ1) still works, the only difference besides the name if the port is 1414. The dns name is the same for both channels. If anyone has any ideas, please let me know. Jeff Tressler 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 problem
Hello, I have a very interesting situation. One of the applications using MQ forgot to service the queue (meaning GET ing messages from the queue). Hence, the queue filled up. But instead of trying to put the excess messages in the DLQ on the receiving side, it started filling up the transmit queue. Also, one of the side effects is that other applications using the same transmit queue were temporarily out of commission. I have also seen the receiver channel on the GET ing side pause. Has anybody come across this problem? The version of MQ is 5.2 with CSD05 on Windows 2000 cluster. Most of the times in order to solve the crisis what we have done is to stop and start MQ (which drains the messages in the queue which filled up) and everything starts to work fine. What am I missing here In appreciation, Edward Pius. 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 problem
Edward, are you sure that some of the messages didn't go to the DLQ on the other end of your channel? I've seen this happen when the DLQ over there gets full; the channel stops and the messages start to build up in the transmission queue until it, too, is full. At least, I think that's what I remember happening, but it's been quite a while, so my memory may be a bit off. -- Rebecca -Original Message- From: Edward Pius [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 1:29 PM To: [EMAIL PROTECTED] Subject: Channel problem Hello, I have a very interesting situation. One of the applications using MQ forgot to service the queue (meaning GET ing messages from the queue). Hence, the queue filled up. But instead of trying to put the excess messages in the DLQ on the receiving side, it started filling up the transmit queue. Also, one of the side effects is that other applications using the same transmit queue were temporarily out of commission. I have also seen the receiver channel on the GET ing side pause. Has anybody come across this problem? The version of MQ is 5.2 with CSD05 on Windows 2000 cluster. Most of the times in order to solve the crisis what we have done is to stop and start MQ (which drains the messages in the queue which filled up) and everything starts to work fine. What am I missing here In appreciation, Edward Pius. 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: Channel problem
Also make sure that the receiving QM does in fact know that it has a DLQ. Just because a DLQ is defined in not enough. The QM DLQ attribute needs to be set. Peter Potkay IBM MQSeries Certified [EMAIL PROTECTED] X 77906 -Original Message- From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 2:18 PM To: [EMAIL PROTECTED] Subject: Re: Channel problem Edward, are you sure that some of the messages didn't go to the DLQ on the other end of your channel? I've seen this happen when the DLQ over there gets full; the channel stops and the messages start to build up in the transmission queue until it, too, is full. At least, I think that's what I remember happening, but it's been quite a while, so my memory may be a bit off. -- Rebecca -Original Message- From: Edward Pius [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 1:29 PM To: [EMAIL PROTECTED] Subject: Channel problem Hello, I have a very interesting situation. One of the applications using MQ forgot to service the queue (meaning GET ing messages from the queue). Hence, the queue filled up. But instead of trying to put the excess messages in the DLQ on the receiving side, it started filling up the transmit queue. Also, one of the side effects is that other applications using the same transmit queue were temporarily out of commission. I have also seen the receiver channel on the GET ing side pause. Has anybody come across this problem? The version of MQ is 5.2 with CSD05 on Windows 2000 cluster. Most of the times in order to solve the crisis what we have done is to stop and start MQ (which drains the messages in the queue which filled up) and everything starts to work fine. What am I missing here In appreciation, Edward Pius. 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 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: Channel problem
Yes, the messages get to the DLQ. But my question is why is it building up in the transmit queue... As far as I know the DLQ did not get full.. What if any did you do to alleviate the situation? Edward. -Original Message- From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 11:18 AM To: [EMAIL PROTECTED] Subject: Re: Channel problem Edward, are you sure that some of the messages didn't go to the DLQ on the other end of your channel? I've seen this happen when the DLQ over there gets full; the channel stops and the messages start to build up in the transmission queue until it, too, is full. At least, I think that's what I remember happening, but it's been quite a while, so my memory may be a bit off. -- Rebecca -Original Message- From: Edward Pius [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 1:29 PM To: [EMAIL PROTECTED] Subject: Channel problem Hello, I have a very interesting situation. One of the applications using MQ forgot to service the queue (meaning GET ing messages from the queue). Hence, the queue filled up. But instead of trying to put the excess messages in the DLQ on the receiving side, it started filling up the transmit queue. Also, one of the side effects is that other applications using the same transmit queue were temporarily out of commission. I have also seen the receiver channel on the GET ing side pause. Has anybody come across this problem? The version of MQ is 5.2 with CSD05 on Windows 2000 cluster. Most of the times in order to solve the crisis what we have done is to stop and start MQ (which drains the messages in the queue which filled up) and everything starts to work fine. What am I missing here In appreciation, Edward Pius. 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 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 problem
Edward My 2 cents: Do you have DLQ DEFINED on the Receiving side and is PUT ENABLED and has sufficient MAXDEPTH as in that case your channels will shut down and Xmit Queue will be filled up you mentioned Hence, the queue filled up. which queue are you talking about, one on the recv side or the Xmit queue On restart of MQ the queue probably cleans up as the mesgs are non-persistent How about the status o the SDR Channel ? Arun Makhija TCS and Boeing in AISI WORK: 425-965-6899 FAX: 425-965-6777 http://dcaca225.ca.boeing.com/~axm4256/ Never argue with an idiot. They drag you down to their level and beat you with experience -Original Message- From: Edward Pius [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 10:29 AM To: [EMAIL PROTECTED] Subject: Channel problem Hello, I have a very interesting situation. One of the applications using MQ forgot to service the queue (meaning GET ing messages from the queue). Hence, the queue filled up. But instead of trying to put the excess messages in the DLQ on the receiving side, it started filling up the transmit queue. Also, one of the side effects is that other applications using the same transmit queue were temporarily out of commission. I have also seen the receiver channel on the GET ing side pause. Has anybody come across this problem? The version of MQ is 5.2 with CSD05 on Windows 2000 cluster. Most of the times in order to solve the crisis what we have done is to stop and start MQ (which drains the messages in the queue which filled up) and everything starts to work fine. What am I missing here In appreciation, Edward Pius. 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: Channel problem
This behavior is no doubt caused by the MRRTY and MRTMR parameters on the receiver channel's definition. The channel will pause MRTMR milliseconds, and then retry. This repeats MRRTY times, or until the put is successful. I'm not sure what the defaults are for the parameters, but they are sufficiently high to cause the behavior you're seeing. We first saw this when a destination application queue was either full or put disabled, I forget which. The channel slowed done quite a bit as a result. Once we understood the parameters we decided to change all of our receiver channels to MRRTY(0), thereby disabling retrying. Edward Pius [EMAIL PROTECTED]To: [EMAIL PROTECTED] ORNE.COMcc: Sent by: MQSeriesSubject: Channel problem List [EMAIL PROTECTED] N.AC.AT 03/17/2003 12:28 PM Please respond to MQSeries List Hello, I have a very interesting situation. One of the applications using MQ forgot to service the queue (meaning GET ing messages from the queue). Hence, the queue filled up. But instead of trying to put the excess messages in the DLQ on the receiving side, it started filling up the transmit queue. Also, one of the side effects is that other applications using the same transmit queue were temporarily out of commission. I have also seen the receiver channel on the GET ing side pause. Has anybody come across this problem? The version of MQ is 5.2 with CSD05 on Windows 2000 cluster. Most of the times in order to solve the crisis what we have done is to stop and start MQ (which drains the messages in the queue which filled up) and everything starts to work fine. What am I missing here In appreciation, Edward Pius. 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: Channel problem
Edward, all I did for the immediate problem was increase the maxdepth for the DLQ and restart the channel. Then had the programmer fix the original problem (app had a typo in the REplyToQ name). But likely you've done that kind of thing already; I'd look at the suggestions from others... -Original Message- From: Edward Pius [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 2:27 PM To: [EMAIL PROTECTED] Subject: Re: Channel problem Yes, the messages get to the DLQ. But my question is why is it building up in the transmit queue... As far as I know the DLQ did not get full.. What if any did you do to alleviate the situation? Edward. -Original Message- From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 11:18 AM To: [EMAIL PROTECTED] Subject: Re: Channel problem Edward, are you sure that some of the messages didn't go to the DLQ on the other end of your channel? I've seen this happen when the DLQ over there gets full; the channel stops and the messages start to build up in the transmission queue until it, too, is full. At least, I think that's what I remember happening, but it's been quite a while, so my memory may be a bit off. -- Rebecca -Original Message- From: Edward Pius [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 1:29 PM To: [EMAIL PROTECTED] Subject: Channel problem Hello, I have a very interesting situation. One of the applications using MQ forgot to service the queue (meaning GET ing messages from the queue). Hence, the queue filled up. But instead of trying to put the excess messages in the DLQ on the receiving side, it started filling up the transmit queue. Also, one of the side effects is that other applications using the same transmit queue were temporarily out of commission. I have also seen the receiver channel on the GET ing side pause. Has anybody come across this problem? The version of MQ is 5.2 with CSD05 on Windows 2000 cluster. Most of the times in order to solve the crisis what we have done is to stop and start MQ (which drains the messages in the queue which filled up) and everything starts to work fine. What am I missing here In appreciation, Edward Pius. 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 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
Convert on channel problem
I have a remote queue definition on MVS which is pointed at a remote queue definition on a Solaris server which is then pointed to a local queue on another Solaris Server. On sender channel on MVS, I have convert set to yes. This is how we send to all of our distributed server. The sender channel going from the solaris server to the final solaris server has convert set to no. Problem: When the message gets to the third queue manager, our gets get a 2110 return code and the message is not readable. How should this be configured ? 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: Convert on channel problem
Hi Have you checked these prossible causes ? - The format name in the message is MQFMT_ NONE. - A user- written exit with the name specified by the Format field in the message cannot be found - The message contains data that is not consistent with the format definition. Cheers, Jan. I have a remote queue definition on MVS which is pointed at a remote queue definition on a Solaris server which is then pointed to a local queue on another Solaris Server. On sender channel on MVS, I have convert set to yes. This is how we send to all of our distributed server. The sender channel going from the solaris server to the final solaris server has convert set to no. Problem: When the message gets to the third queue manager, our gets get a 2110 return code and the message is not readable. How should this be configured ? 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 -/ /Jan van Kemenade \www.cressida.info -\ 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: Convert on channel problem
Sounds like you tried to do a get with convert and the message format was MQFMT_NONE David 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: Convert on channel problem
Wesley It's actually bad practice to do conversions on channels ( unless you really have to ). The best practice is receiver makes good. i.e. The receiving application specifies conversion on the get. ( MQGMO_CONVERT) By doing this- the sender can be any application on any platform and your receiving application will always correctly do the conversion ( provided it has the relevant codepage available). With regard to your problem ... do you have the relevant codepage for the solaris box installed on your MVS system? Cheers! Kevin
Re: Channel problem
Emile, Rebecca, I have not changed the expiry attribute, I mean that I am not explicitly changing the expiry attribute of the message in my application program. I think the default is unlimited expiry time. Do I have to set it to something so that messages remain ? Plus, today we changed a few attributes of the transmission queue. We set the trigger type to F and also set the inititation queue to SYSTEM.CHANNEL.INITQ so that once a message is received in the transmission queue the Channel is started from its inactive state. But still there is some problem when we stop and restart a channel. Messages just disappear. They are not found on the DLQ either. Paul, Can you explain what you mean by 'trace the channel' ? Regards Sundari -Original Message- From: Emile Kearns [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 7:41 PM To: [EMAIL PROTECTED] Subject: Re: Channel problem If the channel was stopped manually, it must be started before messages will flow between systems. Yes, persistence is used when the QMGR needs to recover the queue. If the messages had an expiry time, the QMGR will discard them when the expiry time is reached. Do you have default DLQ assigned to the QMGR? Emile Kearns SOFTWARE FUTURES the business advantage Proud member of MGX www.softwarefutures.com -Original Message- From: Ganapathy, Sundari (Cognizant) [mailto:[EMAIL PROTECTED]] Sent: 01 August 2002 03:35 To: [EMAIL PROTECTED] Subject: Re: Channel problem No channel triggering. We stopped the channel for some other purpose(test) and in the meanwhile we had placed a number of messages in the XMITQ. When we noticed the problem we re-started the channel and found that the messages were not there. The messages are not persistant. I thought message persistance was required only when the queue manager itself goes down. Correct me if I am wrong. We are checking the DLQ. Queue was inactive not stopped. Sundari -Original Message- From: Emile Kearns [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 6:37 PM To: [EMAIL PROTECTED] Subject: Re: Channel problem Three questions: 1. Are you using channel triggering and why is the channel in a stopped state? 2. Are your messages persistant and do you interrogate the expiry option on the message? 3. When you say LOST, are the message gone, have you checked the DLQ? Emile Kearns SOFTWARE FUTURES the business advantage Proud member of MGX www.softwarefutures.com -Original Message- From: Ganapathy, Sundari (Cognizant) [mailto:[EMAIL PROTECTED]] Sent: 01 August 2002 02:37 To: [EMAIL PROTECTED] Subject: Channel problem Hi We are writing COBOL API that runs on OS/390 and places messages on queues running on AIX. I had mailed the problem to the listers already yesterday and now I have the problem much more well defined. Hope someone can help. When the sender channel is running and my application program places messages in the queue all goes fine. When the sender channel is stopped and my application program places messages all the messages get accumulated in the XMITQ. When I restart the sender channel the first two messages alone are logged into the remote queue. The rest of the messages are lost. Actually someone over here suggested that the message ids of the rest of the messages are lost and that is why the messages are lost and they said the MQ administrator should be able to log message ids into some buffer area if the channel is not running. Do you have any more suggestions on this ? Regards Sundari * Work : +91 44 811 3063 Extn 2253 Vnet: 42253 * Home : +91 44 654 4396 * Mobile: +91 98410 33803 .. Think Big. Think Differently. Challenge conventional wisdom. Think long term. - Dhirubhai Ambani Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com
Re: Channel problem
Paul, Can you explain what you mean by 'trace the channel' ? Regards Sundari Sundari, All I was suggesting was that if you really want to know what the channel did you can switch on MQ trace. This goes for any MQI application. Switch trace on with a command like strmqtrc -t detail -t all. run your test and then end trace and you'll have a trace file for each process that did MQ work. One of them will be the amqcrsta channel process. The exact commands for switching trace on. formatting the files etc change depending on the platform. If you can't understand the trace files then you can send them to me if you like and I'll take a look. Hope this helps, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Channel problem
Three questions: 1. Are you using channel triggering and why is the channel in a stopped state? 2. Are your messages persistant and do you interrogate the expiry option on the message? 3. When you say LOST, are the message gone, have you checked the DLQ? Emile Kearns SOFTWARE FUTURES the business advantage Proud member of MGX www.softwarefutures.com -Original Message- From: Ganapathy, Sundari (Cognizant) [mailto:[EMAIL PROTECTED]] Sent: 01 August 2002 02:37 To: [EMAIL PROTECTED] Subject: Channel problem Hi We are writing COBOL API that runs on OS/390 and places messages on queues running on AIX. I had mailed the problem to the listers already yesterday and now I have the problem much more well defined. Hope someone can help. When the sender channel is running and my application program places messages in the queue all goes fine. When the sender channel is stopped and my application program places messages all the messages get accumulated in the XMITQ. When I restart the sender channel the first two messages alone are logged into the remote queue. The rest of the messages are lost. Actually someone over here suggested that the message ids of the rest of the messages are lost and that is why the messages are lost and they said the MQ administrator should be able to log message ids into some buffer area if the channel is not running. Do you have any more suggestions on this ? Regards Sundari * Work : +91 44 811 3063 Extn 2253 Vnet: 42253 * Home : +91 44 654 4396 * Mobile: +91 98410 33803 .. Think Big. Think Differently. Challenge conventional wisdom. Think long term. - Dhirubhai Ambani 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 problem
No channel triggering. We stopped the channel for some other purpose(test) and in the meanwhile we had placed a number of messages in the XMITQ. When we noticed the problem we re-started the channel and found that the messages were not there. The messages are not persistant. I thought message persistance was required only when the queue manager itself goes down. Correct me if I am wrong. We are checking the DLQ. Queue was inactive not stopped. Sundari -Original Message- From: Emile Kearns [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 6:37 PM To: [EMAIL PROTECTED] Subject: Re: Channel problem Three questions: 1. Are you using channel triggering and why is the channel in a stopped state? 2. Are your messages persistant and do you interrogate the expiry option on the message? 3. When you say LOST, are the message gone, have you checked the DLQ? Emile Kearns SOFTWARE FUTURES the business advantage Proud member of MGX www.softwarefutures.com -Original Message- From: Ganapathy, Sundari (Cognizant) [mailto:[EMAIL PROTECTED]] Sent: 01 August 2002 02:37 To: [EMAIL PROTECTED] Subject: Channel problem Hi We are writing COBOL API that runs on OS/390 and places messages on queues running on AIX. I had mailed the problem to the listers already yesterday and now I have the problem much more well defined. Hope someone can help. When the sender channel is running and my application program places messages in the queue all goes fine. When the sender channel is stopped and my application program places messages all the messages get accumulated in the XMITQ. When I restart the sender channel the first two messages alone are logged into the remote queue. The rest of the messages are lost. Actually someone over here suggested that the message ids of the rest of the messages are lost and that is why the messages are lost and they said the MQ administrator should be able to log message ids into some buffer area if the channel is not running. Do you have any more suggestions on this ? Regards Sundari * Work : +91 44 811 3063 Extn 2253 Vnet: 42253 * Home : +91 44 654 4396 * Mobile: +91 98410 33803 .. Think Big. Think Differently. Challenge conventional wisdom. Think long term. - Dhirubhai Ambani Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com
Re: Channel problem
If the channel was stopped manually, it must be started before messages will flow between systems. Yes, persistence is used when the QMGR needs to recover the queue. If the messages had an expiry time, the QMGR will discard them when the expiry time is reached. Do you have default DLQ assigned to the QMGR? Emile Kearns SOFTWARE FUTURES the business advantage Proud member of MGX www.softwarefutures.com -Original Message- From: Ganapathy, Sundari (Cognizant) [mailto:[EMAIL PROTECTED]] Sent: 01 August 2002 03:35 To: [EMAIL PROTECTED] Subject: Re: Channel problem No channel triggering. We stopped the channel for some other purpose(test) and in the meanwhile we had placed a number of messages in the XMITQ. When we noticed the problem we re-started the channel and found that the messages were not there. The messages are not persistant. I thought message persistance was required only when the queue manager itself goes down. Correct me if I am wrong. We are checking the DLQ. Queue was inactive not stopped. Sundari -Original Message- From: Emile Kearns [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 6:37 PM To: [EMAIL PROTECTED] Subject: Re: Channel problem Three questions: 1. Are you using channel triggering and why is the channel in a stopped state? 2. Are your messages persistant and do you interrogate the expiry option on the message? 3. When you say LOST, are the message gone, have you checked the DLQ? Emile Kearns SOFTWARE FUTURES the business advantage Proud member of MGX www.softwarefutures.com -Original Message- From: Ganapathy, Sundari (Cognizant) [mailto:[EMAIL PROTECTED]] Sent: 01 August 2002 02:37 To: [EMAIL PROTECTED] Subject: Channel problem Hi We are writing COBOL API that runs on OS/390 and places messages on queues running on AIX. I had mailed the problem to the listers already yesterday and now I have the problem much more well defined. Hope someone can help. When the sender channel is running and my application program places messages in the queue all goes fine. When the sender channel is stopped and my application program places messages all the messages get accumulated in the XMITQ. When I restart the sender channel the first two messages alone are logged into the remote queue. The rest of the messages are lost. Actually someone over here suggested that the message ids of the rest of the messages are lost and that is why the messages are lost and they said the MQ administrator should be able to log message ids into some buffer area if the channel is not running. Do you have any more suggestions on this ? Regards Sundari * Work : +91 44 811 3063 Extn 2253 Vnet: 42253 * Home : +91 44 654 4396 * Mobile: +91 98410 33803 .. Think Big. Think Differently. Challenge conventional wisdom. Think long term. - Dhirubhai Ambani 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: Channel problem
No channel triggering. We stopped the channel for some other purpose(test) and in the meanwhile we had placed a number of messages in the XMITQ. When we noticed the problem we re-started the channel and found that the messages were not there. The messages are not persistant. I thought message persistance was required only when the queue manager itself goes down. Correct me if I am wrong. We are checking the DLQ. Queue was inactive not stopped. Sundari Sundari, If the channel is NPMSPEED(FAST) then the channel will make best effort to store a non-persistent message but if it can't, for example queue full or no authority, then the message will be thrown away. You can, of course, trace the channel and see exactly what it does with each of your messages. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Channel problem
Sundari, could the missing messages have expired while on the queue? They're not actually deleted until you try to read them (and on OS/390, it takes a destructive read, not a browse). When you start the channel, the channel agent will start reading the messages and that would delete the expired messages. Just a thought -- Rebecca Rebecca Bullock Computer Sciences Corporation Educational Testing Service Account Princeton, NJ 08541 e-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -Original Message- From: Ganapathy, Sundari (Cognizant) [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 9:41 AM To: [EMAIL PROTECTED] Subject: Re: Channel problem I have checked the DLQs. Messages are not available in that either. -Original Message- From: Hill, Dave [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 7:09 PM To: [EMAIL PROTECTED] Subject: Re: Channel problem Two things here. When you say stopped do you meen inactive or stopped? Are you using persistent msgs and if you are have you cheched your DLQs? -Original Message- From: Ganapathy, Sundari (Cognizant) [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 8:37 AM To: [EMAIL PROTECTED] Subject: Channel problem Hi We are writing COBOL API that runs on OS/390 and places messages on queues running on AIX. I had mailed the problem to the listers already yesterday and now I have the problem much more well defined. Hope someone can help. When the sender channel is running and my application program places messages in the queue all goes fine. When the sender channel is stopped and my application program places messages all the messages get accumulated in the XMITQ. When I restart the sender channel the first two messages alone are logged into the remote queue. The rest of the messages are lost. Actually someone over here suggested that the message ids of the rest of the messages are lost and that is why the messages are lost and they said the MQ administrator should be able to log message ids into some buffer area if the channel is not running. Do you have any more suggestions on this ? Regards Sundari * Work : +91 44 811 3063 Extn 2253 Vnet: 42253 * Home : +91 44 654 4396 * Mobile: +91 98410 33803 .. Think Big. Think Differently. Challenge conventional wisdom. Think long term. - Dhirubhai Ambani 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
