Re: SWIFT+MQSA+MQSeries
Anand, I already replied to you personally as you requested ?!? I've attached my original response.. - Original Message - Dear Mark, Thankx for your reply and help. Even if doesn't solve the problem youve been of great help to me. :):) regards, Anand Jammi PS: Could you send me a write up of the architecture you are using for your application. - Original Message - From: Mark Lees To: 'ANAND' Sent: Wednesday, July 03, 2002 5:53 PM Subject: RE: Anand, I'm not familiar with SwiftAllianceAcess, is this another name for MQSA. I have used MQSA quite a bit and have software which is reconciling the PAN/NAN messages back to our original submissions. I have seen intermittent problems with the reports coming back with different correlation identifiers and am not convinced that MQSA is not altering the PAN/NAN's in some way under certain circumstances. I've tried speaking to Swift about this but they don't really understand the MQSeries aspect as it's fairly new (or I just haven't been able to track down the right person!). It seems to work most of the time and as you would expect the correlation ID is populated with the message ID of your original submission (The MQSeries MsgId Field) I'm not sure how your would perform the routing of the PAN/NAN's as I am no MQSA expert. It sounds as though it should be possible as I know MQSA has routing concepts built into it. I do wonder though at what level MQSA gets involved in this as this routing must by at a higher level than MQSeries and am not sure if the correlation id would be passed on through any MQSA routing code. Your architectural query appears to hinge on wether the above routing question has a satisfactory answer. Up until this gets resolved I would think your a bit stuck. Sorry. I hope this is of help. Regards Mark. -Original Message-From: ANAND [mailto:[EMAIL PROTECTED]]Sent: 03 July 2002 13:14To: Mark LeesSubject: Dear Mark, First of all let me apologise for directly sending you this mail and not via the list serv (I thought that most of the other members would not be interested in this). I have certain queries regarding the configuration of MQSeries and SwiftAlliance Access (Software ver4.1) on windows platform: 1) I have a queue where i receive PAN/NAN from MQSA component for the transmission of messages from the From_MQ_To_SAA queue (Using the MQseries Replytoqueue and report feature). How do i reconcile with this report message with the message sent to SAA system?? a) The option seems to be by using the messageID and correlation ID of the received message on the report queue (In this case should i set the message ID or should i use the message ID generated by MQSeries) 2) I also need to configure ACK/NACK coming for the sent SWIFT message to be routed to a predefined queue. Currently i have a SWIFTAlliance standalone system wherein we have a system which sends and receives messages to itself. The other issue is a bit architectural: How to configure a distributed SWIFT messaging system wherein different branches of a organisation/institution wherein each branch sends messages and the ACKS/NACKS, PAN/NAN for the sent message and the incoming message are properly routed back to them individually? If possible i need a detailed configuration (Sample) required for such a scenario.(I am attaching a file "SWIFTquery.doc") which expalins the problem in some more depth. Thankx and regards, Anand Jammi This message is confidential to the sender and addressee, and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it from your system, destroy any copies, and notify the sender immediately. Opinions stated herein are not necessarily those of BrokerTec. BrokerTec reserves the right to monitor messages that pass through its networks. BrokerTec Europe Ltd is regulated by FSA. -Original Message-From: ANAND [mailto:[EMAIL PROTECTED]]Sent: 10 July 2002 08:08To: [EMAIL PROTECTED]Subject: Re: SWIFT+MQSA+MQSeries Hi Mark, I am anxiously waiting for your reply on this. Please do respond ASAP to this mail. regards, Anand - Original Message - From: Mark Lees To: [EMAIL PROTECTED] Sent: Wednesday, July 03, 2002 4:01 PM Subject: Re: SWIFT+MQSA+MQSeries What's your problem, I'll see if I can help. We
Re: SWIFT+MQSA+MQSeries
What's your problem, I'll see if I can help. We have MQSA/MQFIN over MQSeries RegardsMark -Original Message-From: ANAND [mailto:[EMAIL PROTECTED]]Sent: 03 July 2002 10:34To: [EMAIL PROTECTED]Subject: SWIFT+MQSA+MQSeries Hi, Can anybody help me out with SWIFT+MQSA+MQSeries?? regards, Anand Jammi This message is confidential to the sender and addressee, and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it from your system, destroy any copies, and notify the sender immediately. Opinions stated herein are not necessarily those of BrokerTec. BrokerTec reserves the right to monitor messages that pass through its networks. BrokerTec Europe Ltd is regulated by FSA.
Re: Backed out msg retains its old positon on the Q?
Steve, I'm not 100% sure but I would think that it might be impossible for the queue manager to (re)place the message at it's original position in the queue if other messages have subsequently been read from the queue since the syncpointed get was backed out. Regards Mark. -Original Message- From: steve muller [mailto:[EMAIL PROTECTED]] Sent: 30 May 2002 16:32 To: [EMAIL PROTECTED] Subject: Backed out msg retains its old positon on the Q? When a message is retrieved with GET + Syncpoint and then backed out, does it preserve its original position on the queue or go to the bottom of the queue? I think it is the latter but wanted to confirm with you. Thanks for your response. SM __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This message is confidential to the sender and addressee, and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it from your system, destroy any copies, and notify the sender immediately. Opinions stated herein are not necessarily those of BrokerTec. BrokerTec reserves the right to monitor messages that pass through its networks. BrokerTec Europe Ltd is regulated by FSA. 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
[no subject]
Neil et al, Thanks for that, our KeepAlive is currently off (unticked). I'll look into getting this enabled also. I have now acquired the logs from the other machine and although the times don't match up I'm 99% certain that it corresponds to the log extract I attached earlier --- 24/05/02 07:05:12 AM AMQ9208: Error on receive from host 'btecclear (172.23.92.129)'. EXPLANATION: An error occurred receiving data from 'btecclear (172.23.92.129)' over TCP/IP. This may be due to a communications failure. ACTION: Record the TCP/IP return code 145 (X'91') and tell the systems administrator. --- Our machine, Host A is an NT4 machine running MQSeries 5.1 and Host B is a Solaris 2.6 machine running MQSeries 5.0 I've looked on one of our other solaris machines and return code 145 is ETIMEOUT. I tried setting the AdoptNewMCA settings that Mark suggested (below) and this didn't seem to have any effect. However I was only able to implement this on our machine (A) and I suspect that they will need to be enabled on both sides to be of any use, this could of course be wishful thinking on my part! This has happened about 3 times already this morning Regards Mark. -Original Message- From: Taylor, Neil [mailto:[EMAIL PROTECTED]] Sent: 24 May 2002 10:15 To: [EMAIL PROTECTED] Subject: Mark You may also want to look at TCP/IP KeepAlive. If you reach a state where Sender is in Retry state and receiver is in Running state KeepAlive allows the receiver to "detect" that it hasn't received any traffic from the sender, for a specified period of time, and so drops down to Inactive state automatically. Once done, the Sender can then connect successfully. I have used this to great effect and include it in all configurations. Regards Neil -Original Message- From: Michael F Murphy/AZ/US/MQSolutions [mailto:[EMAIL PROTECTED]] Sent: Fri 24/05/2002 02:35 To: [EMAIL PROTECTED] Cc: Subject: Mark, I have seen this many times. It would be helpful to know both the platforms because that can sometimes make a difference. I am not clear on exactly what is happening but since you say stopping and starting the receiver side as well corrects the problem, I am pretty sure I know what you are experiencing. This is very common between OS/390 and Unix or NT platforms but can happen between any platform occasionally. I think what you may notice is your sender is retrying but your corresponding receiver is in a RUNNING status still so it can't accept a new channel connection. If you look at the logs on the receiving end and see an error message stating something like a channel wants to start but there are not enough resources to start one (sorry, I don't remember the exact wording), you can use AdoptNewMCA to help correct the problem. This is done on the receiving side to correct a problem but I enable it on all queue managers. On NT it is done through the Services GUI in the queue manager properties on the Channels tab. On Unix you put it in the channels stanza in qm.ini, on OS/390 I can't tell you how, but it is available. If one side is OS/390, make sure the OS and TCP are up to date. AdoptNewMCA will cause the receiver stuck running to be dropped and "adopt" the new request to start the same channel again. This happens quickly and the drop is not really noticeable. I have been down the same road with all sorts of network engineers sniffing the network, looking at routers, but they never find a problem. Of course IBM says it is not MQSeries, it must be the network. I hope this helps. If this is completely wrong, we'll keep trying. Mike Murphy Sr. Middleware Consultant MQ Solutions, LLC http://www.mqsolutions.com Mark Lees <[EMAIL PROTECTED]> wrote: Date Recieved: 05/23/2002 11:00:09 PM To: [EMAIL PROTECTED] cc: Bcc Subject: Stefan / Ian, thanks for getting back to me. The AMQ log on host A, out machine, says that error 10054 occurred (This is an NT machine) which equates to WSAECONNRESET. The exact AMQ log entry on our machine (Host A) is as follows --- 24/05/02 06:57:35 AMQ9208: Error on receive from host 194.35.94.31. EXPLANATION: An error occurred receiving data from 194.35.94.31 over TCP/IP. This may be due to a communications failure. ACTION: The return code from the TCP/IP (recv) call was 10054 (X'2746'). Record these values and tell the systems administrator. --- I've requested the AMQ error log from their
[no subject]
Stefan / Ian, thanks for getting back to me. The AMQ log on host A, out machine, says that error 10054 occurred (This is an NT machine) which equates to WSAECONNRESET. The exact AMQ log entry on our machine (Host A) is as follows --- 24/05/02 06:57:35 AMQ9208: Error on receive from host 194.35.94.31. EXPLANATION: An error occurred receiving data from 194.35.94.31 over TCP/IP. This may be due to a communications failure. ACTION: The return code from the TCP/IP (recv) call was 10054 (X'2746'). Record these values and tell the systems administrator. --- I've requested the AMQ error log from their machine but there rather MQSeries naive I can positively rule out a network outage. Our network dept has had tracing and monitoring on for two days now and there has been not network problems for over a month now (that in itself is a cause for celebration :-/ ) I'll endeavour to get Host B's AMQ log and hopefully this will shed some light on it. Regards Mark. -Original Message- From: Chan, Ian M [mailto:[EMAIL PROTECTED]] Sent: 24 May 2002 03:05 To: [EMAIL PROTECTED] Subject: what error message displayed at host B AMQERR01.LOG (tcp/ip err? mq error? etc) ? You can't start it at host A because host B receiver is stop and obviously has to be started at host B end. Regards, Ian -----Original Message- From: Mark Lees [mailto:[EMAIL PROTECTED]] Sent: Thursday, 23 May 2002 10:29 PM To: [EMAIL PROTECTED] Subject: All, I need your help. We have two-way connection to a clients MQSeries using a sender and receiver channel on our machine (host A) and a corresponding receiver and sender channel on their machine (host B). Every now and then, and it appears to be increasing in frequency, the connection between the two machines drops. i.e. host A's sender channel starts retrying / binding the connection until it finally gives up and host B's sender channel does the same. If I stop the sender on our host A and restart it, nothing happens, the sender channel remains in retrying / binding. If however their host B's sender channel is stopped and their receiver channel is also stopped and both restarted and then our host A is subsequently restarted it all appears to work again. Both companies network staff have ran various network monitoring and can detect not untoward network loss or other activity at the connectivity level. I have had a ping session running constantly and have detected not noticeably packet loss. Has anyone ever come across this and if so what the solution is. Mark Lees Senior Technologist BrokerTec Europe This message is confidential to the sender and addressee, and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it from your system, destroy any copies, and notify the sender immediately. Opinions stated herein are not necessarily those of BrokerTec. BrokerTec reserves the right to monitor messages that pass through its networks. BrokerTec Europe Ltd is regulated by FSA. 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 message is confidential to the sender and addressee, and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it from your system, destroy any copies, and notify the sender immediately. Opinions stated herein are not necessarily those of BrokerTec. BrokerTec reserves the right to monitor messages that pass through its networks. BrokerTec Europe Ltd is regulated by FSA. 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
[no subject]
All, I need your help. We have two-way connection to a clients MQSeries using a sender and receiver channel on our machine (host A) and a corresponding receiver and sender channel on their machine (host B). Every now and then, and it appears to be increasing in frequency, the connection between the two machines drops. i.e. host A's sender channel starts retrying / binding the connection until it finally gives up and host B's sender channel does the same. If I stop the sender on our host A and restart it, nothing happens, the sender channel remains in retrying / binding. If however their host B's sender channel is stopped and their receiver channel is also stopped and both restarted and then our host A is subsequently restarted it all appears to work again. Both companies network staff have ran various network monitoring and can detect not untoward network loss or other activity at the connectivity level. I have had a ping session running constantly and have detected not noticeably packet loss. Has anyone ever come across this and if so what the solution is. Mark Lees Senior Technologist BrokerTec Europe This message is confidential to the sender and addressee, and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it from your system, destroy any copies, and notify the sender immediately. Opinions stated herein are not necessarily those of BrokerTec. BrokerTec reserves the right to monitor messages that pass through its networks. BrokerTec Europe Ltd is regulated by FSA. 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
