Connectivitye from Client to Server : error 2035: URGENT !!!
Hi All,
I am having connectivity problem from client to
server.
I have created two channels channel1 and channel2.
1. I am able to connect the local queue
(ORANGE.LOCAL.QUEUE) using channel2 with any user
and from any client O/S becaue in I have given
MCAUSER('mqm')
2. But I am not able to connect the local
queue(ORANGE.LOCAL.QUEUE) using channel1, I tried all
options like MCAUSER (' ') or MCAUSER('prakash')or
MCSUSER('NTACCOUNT'). I created the local unix account
same as nt account, but still it's not working.
3. Can some one help me with Examples.
4. MQSeries V5.2 Server running on Solaris 2.8, and
NT, windows 2000, Solaris 2.8
5. Below is my setup
=
1. I have created the Queue Manager as
crtmqm -q saturn.queue.manager
strmqm saturn.queue.manager
2. define qlocal (ORANGE.LOCAL.QUEUE)
3. define channel (CHANNEL1) +
chltype (SVRCONN) +
MCAUSER (' ') +
TRPTYPE (TCP)
4. I have modified the inetd and services file as per
document.
5. Started command Server and started listner and
channel (from runmqsc prompt)
6. On sun solaris I have set the environment as
MQSERVER=CHANNEL1/TCP/'199.221.81.102'
from solaris system I am able put the message as
amqsputc ORANGE.LOCAL.QUEUE saturn.manager.queue
and no problem in receive message using amqsgetc
7. On windows NT system I have set the MQSERVER
environment as
SET MQSERVER=CHANNEL1/TCP/199.221.81.102
amqsputc ORANGE.LOCAL.QUEUE saturn.queue.manager
===
I am getting MCONN ended the connection reason
2035
I don't know what I am missing or doing wrong. I
request some one to correct my mistake with example or
guide me.
I appreciate you help.
Thanks
Prakash
__
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
Re: Questions on Windows, S/390 connectivity
Hi Dennis, 1. No, just SNA 2. Yup 3. Yup. The waiting time is a parameter, can be any value 0 4. From web client. Please advise. Thanks, Louie - Original Message - From: Miller, Dennis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 24, 2002 6:26 AM Subject: Re: Questions on Windows, S/390 connectivity 1. Do you have TCP/IP on S/390? 2. Is your S/390 application CICS? 3. Does your web application wait for a reply? If so, how long can it wait? 4. Does your message originate from the web client (browser), application client(web server), or application server? -Original Message- From: Louie Ma [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, May 21, 2002 11:55 PM To: [EMAIL PROTECTED] Subject: Re: Questions on Windows, S/390 connectivity Importance: High Hi Ian and folks, At our client site, the existing configuration is as follows: 3270 dumb terminal - SNA server (Unix) - S/390 (in remote location) I expect the following to happen after we introduce our web app running on NT: (message passing) web app on NT - SNA server (Unix) - S/390 (in remote location) I was told that for our web app to generate message in ISC Pinnacle format, we need to use LU2.0 but I wonder whether LU2.0 is sufficient cause we need an application-to-application communication. We won't use the dumb terminal to communicate with S/390 via the Unix SNA server. I visualize that we just need to develop an NT service which will be called by our web app to generate message. But my next question is that how we can put the message on the queue and how our message can be listened by the S/390? Pls advise. Thanks a lot. Louie - Original Message - From: Louie Ma [EMAIL PROTECTED] To: MQSeries List [EMAIL PROTECTED] Sent: Thursday, May 16, 2002 3:43 PM Subject: Re: Re: Questions on Windows, S/390 connectivity Ian, Thanks for the info. I have scheduled to go to the location tomorrow. After seeing the hardware and software I will have more info. The user is not able to tell the current configuration. Regards, Louie - Original Message - From: Chan, Ian M [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 16, 2002 10:08 AM Subject: Re: Questions on Windows, S/390 connectivity Louie, It's still not that clear of what you want. There are lots of way to send/receive data between NT and S/390 and MQ is one of that. It all depends on what you want to achieve and the business/application processes. Say for batch you can simply using the upload/download function. For the dumb term, I have no idea on what you mean as it's impossible to do PC file transfer without a PC. Regards, Ian -Original Message- From: Louie Ma [mailto:[EMAIL PROTECTED]] Sent: Thursday, 16 May 2002 11:36 AM To: [EMAIL PROTECTED] Subject: Re: Questions on Windows, S/390 connectivity Importance: High Hi Guys, Sorry for the confusion. Currently, there's a dumb terminal (say in Hong Kong) which has been used to access an accounting system running on S/390 in another country. The connection uses SNA. Users use the terminal to credit accounts. Recently we developed another web application running in Hong Kong. Our webserver is Websphere 3.5. We decided to build an interface to link up the web app and the remote accounting system. With the interface, the web app should send messages to the accounting system to credit accounts. Therefore I researched and found things like MQ. As per the IBM guy I can achieve our goal using the existing configuration without MQ. That's the whole story. Please advise me further. Thanks a lot. Louie - Original Message - From: Rick Tsujimoto [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 15, 2002 9:43 PM Subject: Re: Questions on Windows, S/390 connectivity Louie, I'm a little confused. I thought you had to send messages from a websphere app running on NT to OS/390. Where did the dumb terminal come into the picture? I think you have to give a clearer picture of the message flow/requirements. Louie Ma louie.ma@ALLPROFITo: [EMAIL PROTECTED] TS.COM.HKcc: Sent by: MQSeries Subject: Re: Questions on Windows, S/390 List connectivity MQSERIES@AKH-Wien .AC.AT 05/15/2002 05:27 AM Please respond to MQSeries List
Re: Client user name and domain on WinNT/2k
Hi, I think that you've encountered a feature in NT security that allows: A user on a machine to act on another machine/domain if there is a identical match on userid and password in both places. IOW if you have a local user MUSR_MQADMIN on machine A with password QWERTY and on machine B you also have user MUSR_MQADMIN with password QWERTY. When logged on to machine A as user MUSR_MQADMIN you can access resources on machine B as user MUSR_MQADMIN on machine B via the network. This is how NT Networking security works and the only way I know to get around it is to have different passwords. Regards, Peter Larsson Moish Carmon wrote - Hello all. We have mqclients, v5.2 running on WinNT connecting to a queue manager, v5.2 on Win2K. According to the documentation, you can grant authority with setmqaut command, using the domain to which the user belongs, in the form [EMAIL PROTECTED] But what we see is that any client connecting with this userid, doesn't matter to which domain this user belongs, gets the authority of this userid as specified on the setmqaut. for example, local user id MUSR_MQADMIN on machine A, can connect as client to queue manager on machine B, and get mq administrator security to this queue manager. Ofcourse, this is not what we want. Any ideas how to avoid this problem ? TIA, Moish Carmon. 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
mqlength
Hello, I'm testing the put of a large message. I have a message of 1,2 M from an external partner. I can do a get (i write it to a txt file). I then try to do a put of a same message to the remote queue, my maximumlength of queue and queuemanager is large enough but i still get 2030 (message to big for queue). The put is in java, do i have to use a special put-option, must i user a special bufferlength parameter, how can i do this...? Thanks, Johan Bruyneel Securex - Belgium Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Problem receiving messages from a restarted client application.
Andy Your example is one way that I've been testing this. We actually ran into the problem with a terminated JAVA client. The client was using the get method in which the application does not specify the buffer size. For messages larger that 4096 this is going to cause a 2080 that gets retried. If the application terminates its the client's surrogate at the queue manager that is getting the 2080 and its not going to turn around and issue another get, likewise neither is the client that has long since stopped going to issues the proper get. Dennis, I wondered about that as well. This problem has made me question a few things I thought I knew. But my testing has demonstrated what Andy is saying, the message is not locked. I can issue a GET just after the put and it will retrieve the message. It just doesn't work if the get is already waiting. Dennis as for your request for comments on fixing the queue manager to wake up another waiting MQGET, here is my two cents. Any application that is dependant on a guarantee that a 2080 message is still there already has problems, because there is no such guarantee. To the best of my knowledge IBM's manuals make no such promise. And in fact as long as the other client's get happens after the put, or another messages is put to wake up the sleeping task the message will be delivered (or attempted to be delivered) to the other task(s). Furthermore the first message, the failed message, is the first message retrieved by the sleeping task if a new message wakes up the task. So in keeping with the assured delivery promises that have actually been made, I think you wake up the waiting thread and give it the message before it expires or becomes pointless instead of trying to preserve a behavior that is not promised or even reliable (like a 2080 maybe still being there). A client's get should not hang just because it was already waiting. Rick |-+--- | | Andrew Hickson | | | [EMAIL PROTECTED] | | | | | | Sent by: MQSeries List | | | [EMAIL PROTECTED] | | | | | | | | | | | | Thursday May 30, 2002 02:26 AM | | | Please respond to MQSeries List | | | | |-+--- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Problem receiving messages from a restarted client applicatio n. | | MQCC_FAILED/MQRC_TRUNCATED_MSG_FAILED does not result in the message being explicitly locked. I'm not sure if If I'm interpretting this discussion correctly, are we discussing the following situation: App1 issues MQGET+wait with buffer length X App2 issues MQGET +wait with buffer length Y App3 issues MQPUT for message of length Z where X Z Y As a result of the MQPUT App1 is woken with MQRC_TRUNCATED_MSG_FAILED, but does not reissue the MQGET with a bigger buffer. App2 is now waiting when the message it's waiting for is already sitting on the queue. I would agree that this doesn't seem like a completely correct implementation, although it does improve the chances of the message being available if/when App1 reissues the MQGET with a correctly sized buffer, and I think it is in accordance with the documentation of MQGMO_WAIT in the APRM. I'd be concerned that if I fixed the queue manager to wake up another waiting MQGET under these circumstances then some existing apps could break. Any comments ? Andy. Miller, Dennis [EMAIL PROTECTED]@AKH-WIEN.AC.AT on 05/30/2002 01:38:13 AM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. Actually I don't see why the larger messages that cause this problem, should ever have been locked or need a back-out as the get would be failing on a 2080. When the client is not terminated and the surrogate can return the 2080, it does not prevent a new get from another client from getting the message. You raise an interesting question. If a get under syncpoint fails, does the candidate message become available to other processes immediately or is it reserved
Re: Problem receiving messages from a restarted client application.
Richard, Again, I have to say it is all my guess (or very humble opinion). What I meant in my last eMail is that the channel agent (surrogate) might not get notified about the message backed out to the queue manager if it issued MQGET before the message was really backed out. I am not sure why it can happen. Does the application poll MQGET with MQGMO_WAIT and some finite WaitInterval for indefinite waiting you mentioned in your 1st post or it uses MQWI_UNLIMITED? If the 2nd approach is used, switching to the 1st one might solve the problem. For the reasons why even the message causing 2080 gets locked in the unit of work, please see the answer of Dennis: MQSeries must really start reading the message before discovering it is too big for the provided buffer size. Pavel Message History From: Richard Brunette [EMAIL PROTECTED]@AKH-Wien.AC.AT on 05/29/2002 01:30 PM Please respond to MQSeries List [EMAIL PROTECTED] DELEGATED - Sent by:MQSeries [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client application. Pavel I'm not sure that I understand what your saying. From everything I've seen the syncpoint processing performs exactly as I would suspect and as documented in this usage note from the APR manual. Without syncpointing successful gets do lose the message when the 'surrogate' can't return them. And with syncpointing they are backed out and available for another program to browse or get. 3. If the application issuing the MQGET call is running as an MQ client, it is possible for the message retrieved to be lost if during the processing of the MQGET call the MQ client terminates abnormally or the client connection is severed. This arises because the surrogate that is running on the queue-manager's platform and which issues the MQGET call on the client's behalf cannot detect the loss of the client until the surrogate is about to return the message to the client; this is after the message has been removed from the queue. This can occur for both persistent messages and nonpersistent messages. The risk of losing messages in this way can be eliminated by always retrieving messages within units of work (that is, by specifying the MQGMO_SYNCPOINT option on the MQGET call, and using the MQCMIT or MQBACK calls to commit or back out the unit of work when processing of the message is complete). If MQGMO_SYNCPOINT is specified, and the client terminates abnormally or the connection is severed, the surrogate backs out the unit of work on the queue manager and the message is reinstated on the queue. I don't know that I've ever read anything to suggest that fully backed-out message would under any circumstances not be available to another client that was already waiting on a get (let alone an open). In fact if I use a smaller message in the test the already waiting client does get the message. Actually I don't see why the larger messages that cause this problem, should ever have been locked or need a back-out as the get would be failing on a 2080. When the client is not terminated and the surrogate can return the 2080, it does not prevent a new get from another client from getting the message. It appears as though there is nothing to trigger the queue manger to check for the any outstanding gets that may be satisfied by this message. A new get returns the message immediately. If the first client is successful but backs the message out, then the second client's surrogate is given the message. The same is true if the first client's surrogate does the back-out. Why should if be different if the first client's surrogate fails to take the message? Rick 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 may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 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
sample RPG code for MQ
Hello, My client is looking at enhancements to a vendor package that will use MQSeries on the AS/400. The vendors package allow calls to C, COBOL, and RPG, which happen to be the three languages supported by MQ on that platform. There are RPG programmers in house, and while they are able to understand the discussions on RPG and MQSeries in the online documents, they would like a chance to review the sample code. I hope someone with the RPG support installed on an AS/400 can send me the sample programs for us to look at. Please email it to [EMAIL PROTECTED] Thanks, Dave Awerbuch = David A. Awerbuch, IBM Certified MQSeries Specialist APC Consulting Services, Inc. Providing Automated Solutions to Business Challenges West Hempstead, NY(516) 481-6440 [EMAIL PROTECTED] __ 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
Re: Problem receiving messages from a restarted client application.
This application was simply using an indefinite wait. As I said we have convinced the application developers to make a number of changes that with provide a better design for their business problem. These changes have greatly reduced the frequency that the application will be exposed to this problem. However the problem still exists and is the type of issue that is going to hit you and not necessarily be easily identified. The exposure risk is going up with more java development with unspecified message lengths. As Andy says (and testing proves) the message isn't locked or considered part of a unit of work. It is available to any get that comes along. It just will not be delivered to a get that is already waiting for it, unless there is another message that becomes available to tell the queue manager to wake up the get that is waiting. I'm well aware of receiving the portion of the message that fits in the buffer as Dennis mentions and even questioned the idea of the message being locked myself, but its just not the case. It sounds like Andy understands both the issue and why the internals of the queue manager code is causing this behavior. I'm assuming, from your many past posts to this list Andy, that your one of the IBMers on this list with detailed knowledge of the internal code-base of the mainframe queue managers. Thanks Pavel, Dennis, and Mike for you comments. Andy I'd like to hear any further information on what will be done or what is to the expected behavior of the queue manager and the surrogates in this situation. In addition a co-worker here has sent IBM and ETR on this issue. Rick 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
ActiveX Object in VB
Title: ActiveX Object in VB Hi I'm trying to display list of messages with their PutDateTime in a List Box in VB using following code. Code Begin Do If Counter = 0 Then mqgmo.Options = MQGMO_BROWSE_FIRST Else mqgmo.Options = MQGMO_BROWSE_NEXT End If mqq.Get mqmsg, mqgmo, 0 Counter = Counter + 1 If mqgmo.CompletionCode = MQCC_OK Then lstMessages.AddItem Counter vbTab mqmsg.PutDateTime Else Done = True End If Loop Until Done Code End However, I get error when loop iterates second time. PutDateTime of first message is read correctly. Any ideas? Thanks in Advance == De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. == The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. ==
Re: Problem receiving messages from a restarted client application.
Rick, I've discussed this with the mainframe developers (I'm one of the developers on the MQ distributed products) and understand they have fixed a number of problems in this area recently (I assume 5.3). The 390 product has a couple of additional complications in this area (mark skip backout get with signal), and I think that all that might be required on the distributed platforms is to avoid only waking a single waiter if the waiters buffer is too small and doesn't want to accept a truncated message. It might be sensible to awaken a waiter with a big enough buffer in preference to waking both the waiter with a small buffer and the waiter with a big buffer in my earlier example, but I'll make that decision when I look at the code in detail. It's now too late for this change to get in the first distributed 5.3 deliverable and I'd expect it to appear in the first 5.3 CSD. If you want the fix earlier then you'll need to raise a problem with the support center and the service team should be able to port the fix back to 5.2. Andy. Richard Brunette [EMAIL PROTECTED]@AKH-WIEN.AC.AT on 05/30/2002 04:03:32 PM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client application. This application was simply using an indefinite wait. As I said we have convinced the application developers to make a number of changes that with provide a better design for their business problem. These changes have greatly reduced the frequency that the application will be exposed to this problem. However the problem still exists and is the type of issue that is going to hit you and not necessarily be easily identified. The exposure risk is going up with more java development with unspecified message lengths. As Andy says (and testing proves) the message isn't locked or considered part of a unit of work. It is available to any get that comes along. It just will not be delivered to a get that is already waiting for it, unless there is another message that becomes available to tell the queue manager to wake up the get that is waiting. I'm well aware of receiving the portion of the message that fits in the buffer as Dennis mentions and even questioned the idea of the message being locked myself, but its just not the case. It sounds like Andy understands both the issue and why the internals of the queue manager code is causing this behavior. I'm assuming, from your many past posts to this list Andy, that your one of the IBMers on this list with detailed knowledge of the internal code-base of the mainframe queue managers. Thanks Pavel, Dennis, and Mike for you comments. Andy I'd like to hear any further information on what will be done or what is to the expected behavior of the queue manager and the surrogates in this situation. In addition a co-worker here has sent IBM and ETR on this issue. Rick 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
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
Re: Backed out msg retains its old positon on the Q?
It preserves its original position. Andy. steve muller [EMAIL PROTECTED]@AKH-WIEN.AC.AT on 05/30/2002 04:32:18 PM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: 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 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
win2k terminal server
Has anyone gotten MQSeries to work correctly when accessing the queue manager through windows 2000 terminal server ? I know that it is possible to register the executables to global memory I am curious to see if anyone has done this or found another work around. The PDF describes this process. http://www.developer.ibm.com/library/netfinity/tr293165.pdf Greg Mabrito I/T Aprntc Sys Anlst IMS and MQ Software Support (210)913-3985 D-03-E IBM Certified Specialist - Websphere MQ The opinions herein are solely Greg's and are not necessarily the opinion of USAA. 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: ActiveX Object in VB
Title: ActiveX Object in VB It may be becasue you are using the same message object. Try setting the mqmsg.Messageid to null after the Get. Andy. -Original Message-From: Joshi, A (Anant) [mailto:[EMAIL PROTECTED]]Sent: 30 May 2002 16:11To: [EMAIL PROTECTED]Subject: ActiveX Object in VB Hi I'm trying to display list of messages with their PutDateTime in a List Box in VB using following code. Code Begin Do If Counter = 0 Then mqgmo.Options = MQGMO_BROWSE_FIRST Else mqgmo.Options = MQGMO_BROWSE_NEXT End If mqq.Get mqmsg, mqgmo, 0 Counter = Counter + 1 If mqgmo.CompletionCode = MQCC_OK Then lstMessages.AddItem Counter vbTab mqmsg.PutDateTime Else Done = True End If Loop Until Done Code End However, I get error when loop iterates second time. PutDateTime of first message is read correctly. Any ideas? Thanks in Advance ==De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. ==The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail.== --- This e-mail is intended only for the above addressee. It may contain privileged information. If you are not the addressee you must not copy, distribute, disclose or use any of the information in it. If you have received it in error please delete it and immediately notify the sender. evolvebank.com is a division of Lloyds TSB Bank plc. Lloyds TSB Bank plc, 71 Lombard Street, London EC3P 3BS. Registered in England, number 2065. Telephone No: 020 7626 1500 Lloyds TSB Scotland plc, Henry Duncan House, 120 George Street, Edinburgh EH2 4LH. Registered in Scotland, number 95237. Telephone No: 0131 225 4555 Lloyds TSB Bank plc and Lloyds TSB Scotland plc are regulated by the Financial Services Authority and represent only the Scottish Widows and Lloyds TSB Marketing Group for life assurance, pensions and investment business. Signatories to the Banking Codes. ---
Re: Problem receiving messages from a restarted client application.
Andy Please keep in mind when you are deciding what to wake, that in the original problem both applications had the same size buffer. Both where surrogates of two instances of the same Java application. Both start their gets with a 4096 buffer and when it/if fails the Java internals come back to the surrogate with a larger buffer. The difference between the two is one had crashed so only the surrogate was left around. The instance that was started to replace it was waiting with the same initial buffer. As this is common in the object interfaces, we would like to see a solution that with let a waiting second client process even if at first glance this client does not appear any more capable of handling the message. In reality it was. Thanks, Rick 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: win2k terminal server
You need to be at version 5.2 or better. Jon Shearer Farmers New World Life [EMAIL PROTECTED] 206-236-6587 Mabrito, Greg [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 05/30/2002 08:46 AM Please respond to MQSeries List To:[EMAIL PROTECTED] cc: Subject:win2k terminal server Has anyone gotten MQSeries to work correctly when accessing the queue manager through windows 2000 terminal server ? I know that it is possible to register the executables to global memory I am curious to see if anyone has done this or found another work around. The PDF describes this process. http://www.developer.ibm.com/library/netfinity/tr293165.pdf Greg Mabrito I/T Aprntc Sys Anlst IMS and MQ Software Support (210)913-3985 D-03-E IBM Certified Specialist - Websphere MQ The opinions herein are solely Greg's and are not necessarily the opinion of USAA. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Problem receiving messages from a restarted client applicatio n.
Dennis, Truncated msg failed doesn't change the queue state and so there's no backout action for this hConn (typically the UOW won't even have been created). As there's no backout action we don't consider waking up another MQGET when we discover that the first client ends. rgds Andy. Miller, Dennis [EMAIL PROTECTED]@AKH-WIEN.AC.AT on 05/30/2002 06:02:56 PM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. Thank you for the clarification. In doing more reading last night, I came to the same conclusion, but it's always nice to get confirmation from the source. Quite annoyingly, I believe it's MQCC_WARNING/MQRC_TRUNCATED_MSG_FAILED, which may add to the confusion. I understand the scenario to be that this sequence, with an adequate buffer size, works as expected: App1 agent issues MQGET+wait+syncpoint App2 agent issues MQGET+wait+syncpoint App1 client crashes Message arrives Message is delivered to App1 agent with RC=0 MQ discovers that client is gone App1 agent disconnects and rolls back message Message is delivered to App2 agent with RC=0 However, when the buffer is too small, the following is observed: App1 agent issues MQGET+wait+syncpoint App2 agent issues MQGET+wait+syncpoint App1 client crashes Message arrives Message is not delivered to App1 agent because RC=2080 MQ discovers that client is gone App1 agent disconnects and rolls back (exactly what, if anything, get's rolled back is interesting) App2 agent does not see message ==why is this??? App3 agent issues MQGET+wait+syncpoint App3 agent's MQGET returns with RC=2080 -Original Message- From: Andrew Hickson [SMTP:[EMAIL PROTECTED]] Sent: Thursday, May 30, 2002 12:27 AM To: [EMAIL PROTECTED] Subject: Re: Problem receiving messages from a restarted client applicatio n. MQCC_FAILED/MQRC_TRUNCATED_MSG_FAILED does not result in the message being explicitly locked. I'm not sure if If I'm interpretting this discussion correctly, are we discussing the following situation: App1 issues MQGET+wait with buffer length X App2 issues MQGET +wait with buffer length Y App3 issues MQPUT for message of length Z where X Z Y As a result of the MQPUT App1 is woken with MQRC_TRUNCATED_MSG_FAILED, but does not reissue the MQGET with a bigger buffer. App2 is now waiting when the message it's waiting for is already sitting on the queue. I would agree that this doesn't seem like a completely correct implementation, although it does improve the chances of the message being available if/when App1 reissues the MQGET with a correctly sized buffer, and I think it is in accordance with the documentation of MQGMO_WAIT in the APRM. I'd be concerned that if I fixed the queue manager to wake up another waiting MQGET under these circumstances then some existing apps could break. Any comments ? Andy. Miller, Dennis [EMAIL PROTECTED]@AKH-WIEN.AC.AT on 05/30/2002 01:38:13 AM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. Actually I don't see why the larger messages that cause this problem, should ever have been locked or need a back-out as the get would be failing on a 2080. When the client is not terminated and the surrogate can return the 2080, it does not prevent a new get from another client from getting the message. You raise an interesting question. If a get under syncpoint fails, does the candidate message become available to other processes immediately or is it reserved until completion of the UOW. (By candidate, I mean whatever message would be returned if the MQGET had been successful). In the case of a RC=2080, at least, the MD gets filled out and you get part of the message back, despite the failure. Since, it's common place to obtain a larger buffer and try the read again, I expect MQ withholds that message from other processes until it's freed by completion of the UOW. Honestly, this is conjecture on my part, but it does explain part of the behavior you are seeing. Also, I am curious, is your client MQGET a browse or destructive? -Original Message- From: Richard Brunette [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 11:31 AM To: [EMAIL PROTECTED] Subject: Re: Problem receiving messages from a restarted client application. Pavel I'm not sure that I understand what your saying. From everything I've seen the syncpoint processing performs exactly as I would suspect and as documented in this usage note from the APR manual. Without syncpointing successful gets do lose the message when the 'surrogate' can't return them. And with syncpointing they are
Re: win2k terminal server
I amat 5.2.1 CSD04. Greg Mabrito I/T Aprntc Sys Anlst IMS and MQ Software Support (210)913-3985 D-03-E IBM Certified Specialist - Websphere MQ The opinions herein are solely Greg's and are not necessarily the opinion of USAA. -Original Message-From: Jon Shearer [mailto:[EMAIL PROTECTED]]Sent: Thursday, May 30, 2002 11:46 AMTo: [EMAIL PROTECTED]Subject: Re: win2k terminal serverYou need to be at version 5.2 or better. Jon ShearerFarmers New World Life[EMAIL PROTECTED]206-236-6587 "Mabrito, Greg" [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 05/30/2002 08:46 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject:win2k terminal serverHas anyone gotten MQSeries to work correctly when accessing the queuemanager through windows 2000 terminal server ? I know that it is possibleto register the executables to global memory I am curious to see if anyonehas done this or found another work around. The PDF describes this process.http://www.developer.ibm.com/library/netfinity/tr293165.pdfGreg MabritoI/T Aprntc Sys AnlstIMS and MQ Software Support(210)913-3985 D-03-EIBM Certified Specialist - Websphere MQThe opinions herein are solely Greg's and are not necessarily the opinion ofUSAA.Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Problem receiving messages from a restarted client applicatio n.
Couple more guesses, If we add Queue is getting locked for App1's unit of work after App1 agent issues MQGET+wait+syncpoint for both scenarios. Then the App1 agent disconnects and rolls back (exactly what, if anything, get's rolled back is interesting) changes to App1 agent disconnects and its UOW rolls back unlocking the queue. The question remains. Somehow App2 is getting notified on unlocking in scenario 1 but not in scenario 2. 2 more cents Pavel Message History From: Miller, Dennis [EMAIL PROTECTED]@AKH-Wien.AC.AT on 05/30/2002 10:02 AM MST Please respond to MQSeries List [EMAIL PROTECTED] DELEGATED - Sent by:MQSeries [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. Thank you for the clarification. In doing more reading last night, I came to the same conclusion, but it's always nice to get confirmation from the source. Quite annoyingly, I believe it's MQCC_WARNING/MQRC_TRUNCATED_MSG_FAILED, which may add to the confusion. I understand the scenario to be that this sequence, with an adequate buffer size, works as expected: App1 agent issues MQGET+wait+syncpoint App2 agent issues MQGET+wait+syncpoint App1 client crashes Message arrives Message is delivered to App1 agent with RC=0 MQ discovers that client is gone App1 agent disconnects and rolls back message Message is delivered to App2 agent with RC=0 However, when the buffer is too small, the following is observed: App1 agent issues MQGET+wait+syncpoint App2 agent issues MQGET+wait+syncpoint App1 client crashes Message arrives Message is not delivered to App1 agent because RC=2080 MQ discovers that client is gone App1 agent disconnects and rolls back (exactly what, if anything, get's rolled back is interesting) App2 agent does not see message ==why is this??? App3 agent issues MQGET+wait+syncpoint App3 agent's MQGET returns with RC=2080 -Original Message- From: Andrew Hickson [SMTP:[EMAIL PROTECTED]] Sent: Thursday, May 30, 2002 12:27 AM To: [EMAIL PROTECTED] Subject: Re: Problem receiving messages from a restarted client applicatio n. MQCC_FAILED/MQRC_TRUNCATED_MSG_FAILED does not result in the message being explicitly locked. I'm not sure if If I'm interpretting this discussion correctly, are we discussing the following situation: App1 issues MQGET+wait with buffer length X App2 issues MQGET +wait with buffer length Y App3 issues MQPUT for message of length Z where X Z Y As a result of the MQPUT App1 is woken with MQRC_TRUNCATED_MSG_FAILED, but does not reissue the MQGET with a bigger buffer. App2 is now waiting when the message it's waiting for is already sitting on the queue. I would agree that this doesn't seem like a completely correct implementation, although it does improve the chances of the message being available if/when App1 reissues the MQGET with a correctly sized buffer, and I think it is in accordance with the documentation of MQGMO_WAIT in the APRM. I'd be concerned that if I fixed the queue manager to wake up another waiting MQGET under these circumstances then some existing apps could break. Any comments ? Andy. Miller, Dennis [EMAIL PROTECTED]@AKH-WIEN.AC.AT on 05/30/2002 01:38:13 AM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. Actually I don't see why the larger messages that cause this problem, should ever have been locked or need a back-out as the get would be failing on a 2080. When the client is not terminated and the surrogate can return the 2080, it does not prevent a new get from another client from getting the message. You raise an interesting question. If a get under syncpoint fails, does the candidate message become available to other processes immediately or is it reserved until completion of the UOW. (By candidate, I mean whatever message would be returned if the MQGET had been successful). In the case of a RC=2080, at least, the MD gets filled out and you get part of the message back, despite the failure. Since, it's common place to obtain a larger buffer and try the read again, I expect MQ withholds that message from other processes until it's freed by completion of the UOW. Honestly, this is conjecture on my part, but it does explain part of the behavior you are seeing. Also, I am curious, is your client MQGET a browse or destructive? -Original Message- From: Richard Brunette [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 11:31 AM To: [EMAIL PROTECTED] Subject: Re: Problem receiving messages from a restarted client application. Pavel I'm not sure that I understand what your
Re: ActiveX Object in VB
What error are you getting? Is it a VB error or an MQ error? Ryan [EMAIL PROTECTED] 05/30/02 10:11AM Hi I'm trying to display list of messages with their PutDateTime in a List Box in VB using following code. Code Begin Do If Counter = 0 Then mqgmo.Options = MQGMO_BROWSE_FIRST Else mqgmo.Options = MQGMO_BROWSE_NEXT End If mqq.Get mqmsg, mqgmo, 0 Counter = Counter + 1 If mqgmo.CompletionCode = MQCC_OK Then lstMessages.AddItem Counter vbTab mqmsg.PutDateTime Else Done = True End If Loop Until Done Code End However, I get error when loop iterates second time. PutDateTime of first message is read correctly. Any ideas? Thanks in Advance == De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. == The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. == Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Problem in MQDISC SOC-4 Abend
Hi!, I am using two different HCONN variables one with name HCONN-PUT and another with HCONN-GET. After doing get I see that both HCONN-PUT and HCONN-GET have exactly the same values. I am doing MQCONN using HCONN-GET to connect to QMA and MQCONN using HCONN-PUT to connect to QMB. For testing purpose I have kept both QMA and QMB name same i,e both Get and Put queue manager names are same. I was wondering if from the same program if I issue MQCONN twice to the same queue manager, will I get the same value for the connection handles and if I disconnect using one connection handle will the other be also destroyed. I can guess that whenever I am closing the first connection handle say HCONN-GET, it somehow marks HCONN-PUT also closed.I can't understand why it is happening. Is it because I am connecting to same queue manager (with two different calls) using HCONN-GET and HCONN-PUT. Thanks Shailesh --- John M Hammond [EMAIL PROTECTED] wrote: Shailesh, You need to disconnect from both queue managers. Check your program and look at what you are doing with the variables you are storing your HConns in. You have 2 separate HConns and need 2 separate variables to store them in (if you want to be connected to both queue managers simultaneously). My guess is that you are corrupting the HConn somehow. The HConn is just a storage address, so if you corrupt it MQ will end up referencing bad addresses and 0C4's are likely. John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 shailesh To: [EMAIL PROTECTED] bhaskaran cc: shailesh_mqserie Subject:Problem in MQDISC SOC-4 Abend [EMAIL PROTECTED] Sent by: MQSeries List MQSERIES@AKH-Wie n.AC.AT 05/30/2002 11:51 AM Please respond to MQSeries List Hi! All, I am facing a strange problem. I am running a batch application in which I am connecting to one queue manager say QMA and opening the queue to MQGET the message and also connecting to another queue manager say QMB and opening another queue to MQPUT the message read from the previous queue. Everything goes fine, At the end,I am disconnecting from QMA and QMB. The disconnect from first queue manager QMA goes fine but when it performs the para to disconnect from queue manager QMB, I get a SOC4 abend. I tried to do reverse also i,e first disconnecting from QMB (which goes fine) and then QMA again I get SOC4. I am using different connection handle to connect to two different queue manager. Can any one think of why it might be happening? Does disconnecting from any one queue manager is enough? Thanks Shailesh __ 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 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! - 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
Re: Problem in MQDISC SOC-4 Abend
first of all why are we connecting to two QM's? To PUT to QMB just create remote queue definition on QMA and connect to ONLY ONE QM. I am wondering if you understand what MQ is for... connecting to two QM's is new a dfifferent approach to putting data to a ?remote? QM... Sometimes things just make me say Humm and shake my head. shailesh bhaskaran [EMAIL PROTECTED]@AKH-WIEN.AC.AT on 05/30/2002 11:58:43 AM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Problem in MQDISC SOC-4 Abend Hi!, I am using two different HCONN variables one with name HCONN-PUT and another with HCONN-GET. After doing get I see that both HCONN-PUT and HCONN-GET have exactly the same values. I am doing MQCONN using HCONN-GET to connect to QMA and MQCONN using HCONN-PUT to connect to QMB. For testing purpose I have kept both QMA and QMB name same i,e both Get and Put queue manager names are same. I was wondering if from the same program if I issue MQCONN twice to the same queue manager, will I get the same value for the connection handles and if I disconnect using one connection handle will the other be also destroyed. I can guess that whenever I am closing the first connection handle say HCONN-GET, it somehow marks HCONN-PUT also closed.I can't understand why it is happening. Is it because I am connecting to same queue manager (with two different calls) using HCONN-GET and HCONN-PUT. Thanks Shailesh --- John M Hammond [EMAIL PROTECTED] wrote: Shailesh, You need to disconnect from both queue managers. Check your program and look at what you are doing with the variables you are storing your HConns in. You have 2 separate HConns and need 2 separate variables to store them in (if you want to be connected to both queue managers simultaneously). My guess is that you are corrupting the HConn somehow. The HConn is just a storage address, so if you corrupt it MQ will end up referencing bad addresses and 0C4's are likely. John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 shailesh To: [EMAIL PROTECTED] bhaskaran cc: shailesh_mqserie Subject:Problem in MQDISC SOC-4 Abend [EMAIL PROTECTED] Sent by: MQSeries List MQSERIES@AKH-Wie n.AC.AT 05/30/2002 11:51 AM Please respond to MQSeries List Hi! All, I am facing a strange problem. I am running a batch application in which I am connecting to one queue manager say QMA and opening the queue to MQGET the message and also connecting to another queue manager say QMB and opening another queue to MQPUT the message read from the previous queue. Everything goes fine, At the end,I am disconnecting from QMA and QMB. The disconnect from first queue manager QMA goes fine but when it performs the para to disconnect from queue manager QMB, I get a SOC4 abend. I tried to do reverse also i,e first disconnecting from QMB (which goes fine) and then QMA again I get SOC4. I am using different connection handle to connect to two different queue manager. Can any one think of why it might be happening? Does disconnecting from any one queue manager is enough? Thanks Shailesh __ 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 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! - 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 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Problem in MQDISC SOC-4 Abend
Something is amis with your app. I had a utility program, in batch MVS, that did a data move. You specified two QMGRS and two Queues. Usually from QA to System test. It opened both queue managers at the same time, moved the messages and disconnected from both. No problem, no system abend. bobbee From: shailesh bhaskaran [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Problem in MQDISC SOC-4 Abend Date: Thu, 30 May 2002 09:51:55 -0700 Hi! All, I am facing a strange problem. I am running a batch application in which I am connecting to one queue manager say QMA and opening the queue to MQGET the message and also connecting to another queue manager say QMB and opening another queue to MQPUT the message read from the previous queue. Everything goes fine, At the end,I am disconnecting from QMA and QMB. The disconnect from first queue manager QMA goes fine but when it performs the para to disconnect from queue manager QMB, I get a SOC4 abend. I tried to do reverse also i,e first disconnecting from QMB (which goes fine) and then QMA again I get SOC4. I am using different connection handle to connect to two different queue manager. Can any one think of why it might be happening? Does disconnecting from any one queue manager is enough? Thanks Shailesh __ 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 _ Send and receive Hotmail on your mobile device: http://mobile.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: Problem receiving messages from a restarted client applicatio n.
Truncated msg failed doesn't change the queue state and so there's no backout action for this hConn (typically the UOW won't even have been created). As there's no backout action we don't consider waking up another MQGET when we discover that the first client ends. I understand, now, there is no backout action. But, then app2's MQGET should be serviced even sooner--perhaps even before you discover the client is gone. Still fishing for the reason app2 doesn't wake up. Do I interpret you correctly, that after a 2080, MQ does not service another waiting MQGET if its buffer is also too short? Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Problem receiving messages from a restarted client applicatio n.
Dennis I believe its worse than that. They don't wake up one with a large buffer either. They simply don't look further. So without a new stimulus such as a new message arriving or some other UOW message being backed out there is nothing to wake the other waiting gets. Is that correct Andy? Rick |-+--- | | Miller, Dennis| | | [EMAIL PROTECTED]| | | | | | Sent by: MQSeries List | | | [EMAIL PROTECTED] | | | | | | | | | | | | Thursday May 30, 2002 02:48 PM | | | Please respond to MQSeries List | | | | |-+--- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Problem receiving messages from a restarted client applicatio n. | | Truncated msg failed doesn't change the queue state and so there's no backout action for this hConn (typically the UOW won't even have been created). As there's no backout action we don't consider waking up another MQGET when we discover that the first client ends. I understand, now, there is no backout action. But, then app2's MQGET should be serviced even sooner--perhaps even before you discover the client is gone. Still fishing for the reason app2 doesn't wake up. Do I interpret you correctly, that after a 2080, MQ does not service another waiting MQGET if its buffer is also too short? 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: Problem in MQDISC SOC-4 Abend
Randy, Thanks for your advise, I have been working on MQ for 2 years now. There are some requirements which I don't think is of any use explaining. Sometimes you need to do things on which others might shake their head as it is not very clear to them. Besides that MQ doesn't prohibit you from doing that and if it is not happening then there has to be some logical explaination. Shailesh --- Randy J Clark [EMAIL PROTECTED] wrote: first of all why are we connecting to two QM's? To PUT to QMB just create remote queue definition on QMA and connect to ONLY ONE QM. I am wondering if you understand what MQ is for... connecting to two QM's is new a dfifferent approach to putting data to a ?remote? QM... Sometimes things just make me say Humm and shake my head. shailesh bhaskaran [EMAIL PROTECTED]@AKH-WIEN.AC.AT on 05/30/2002 11:58:43 AM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Problem in MQDISC SOC-4 Abend Hi!, I am using two different HCONN variables one with name HCONN-PUT and another with HCONN-GET. After doing get I see that both HCONN-PUT and HCONN-GET have exactly the same values. I am doing MQCONN using HCONN-GET to connect to QMA and MQCONN using HCONN-PUT to connect to QMB. For testing purpose I have kept both QMA and QMB name same i,e both Get and Put queue manager names are same. I was wondering if from the same program if I issue MQCONN twice to the same queue manager, will I get the same value for the connection handles and if I disconnect using one connection handle will the other be also destroyed. I can guess that whenever I am closing the first connection handle say HCONN-GET, it somehow marks HCONN-PUT also closed.I can't understand why it is happening. Is it because I am connecting to same queue manager (with two different calls) using HCONN-GET and HCONN-PUT. Thanks Shailesh --- John M Hammond [EMAIL PROTECTED] wrote: Shailesh, You need to disconnect from both queue managers. Check your program and look at what you are doing with the variables you are storing your HConns in. You have 2 separate HConns and need 2 separate variables to store them in (if you want to be connected to both queue managers simultaneously). My guess is that you are corrupting the HConn somehow. The HConn is just a storage address, so if you corrupt it MQ will end up referencing bad addresses and 0C4's are likely. John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 shailesh To: [EMAIL PROTECTED] bhaskaran cc: shailesh_mqserie Subject:Problem in MQDISC SOC-4 Abend [EMAIL PROTECTED] Sent by: MQSeries List MQSERIES@AKH-Wie n.AC.AT 05/30/2002 11:51 AM Please respond to MQSeries List Hi! All, I am facing a strange problem. I am running a batch application in which I am connecting to one queue manager say QMA and opening the queue to MQGET the message and also connecting to another queue manager say QMB and opening another queue to MQPUT the message read from the previous queue. Everything goes fine, At the end,I am disconnecting from QMA and QMB. The disconnect from first queue manager QMA goes fine but when it performs the para to disconnect from queue manager QMB, I get a SOC4 abend. I tried to do reverse also i,e first disconnecting from QMB (which goes fine) and then QMA again I get SOC4. I am using different connection handle to connect to two different queue manager. Can any one think of why it might be happening? Does disconnecting from any one queue manager is enough? Thanks Shailesh __ 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 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! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv
Re: XML to MRM transformation
Belinda,
Attached is a message flow with a sample of what I think you are trying to
do.
To move the data in an XML message to the MRM fields with the same name as
the XML tag attributes.
I hope this helps,
(See attached file: EAI_Test.xml)
DECLARE Ix INTEGER;
SET Ix = 1;
WHILE Ix = CARDINALITY(InputBody.*[1].*[]) DO
EVAL('SET OutputRoot.MRM.TESTMSG.' || fieldname(InputBody.*[1].*[Ix]) ||
' = ''' || InputBody.*[1].*[Ix] || ''';');
SET Ix=Ix+1;
END WHILE;
Raul L. Acevedo
IBM Global Services, EAI Industrial/Distribution
IT Architect
818-539-3203 Office (TL 396-3203) Glendale, CA
818-599-6626 Mobile
[EMAIL PROTECTED]
Belinda
Edwards/Bethesda/To: [EMAIL PROTECTED]
IBM@IBMUScc:
Sent by: MQSeriesSubject: XML to MRM transformation
List
MQSERIES@AKH-WIE
N.AC.AT
05/29/2002 01:16
PM
Please respond to
MQSeries List
Hello Everyone.
Has anyone tried to transform an input XML message into an output MRM
message where you do not know which element(s) will be sent upon input and
will have to create the output from the XML tag attributes?
i.e. an input XML message contains
INPUTNAMEsomething/NAME/INPUT
The OutputRoot.MRM.OutputMsg.??? must be set to InputRoot.XML.INPUT.XML
attr.
Is this possible?
Thanks in advance for the information.
Belinda
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
EAI_Test.xml
Description: Binary data
Re: Problem receiving messages from a restarted client applicatio n.
Dennis/Rick, As stated in the APRM, when an MQPUT occurs we try and wake up one qualifying destructive MQGET (we explicitly do not specify which of multiple waiters would be woken). The problem here is that we haven't recognized that this waiter isn't really a destructive MQGET and from there on it all awry. Andy. Richard Brunette [EMAIL PROTECTED]@AKH-WIEN.AC.AT on 30/05/2002 21:08:57 Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. Dennis I believe its worse than that. They don't wake up one with a large buffer either. They simply don't look further. So without a new stimulus such as a new message arriving or some other UOW message being backed out there is nothing to wake the other waiting gets. Is that correct Andy? Rick |-+--- | | Miller, Dennis| | | [EMAIL PROTECTED]| | | | | | Sent by: MQSeries List | | | [EMAIL PROTECTED] | | | | | | | | | | | | Thursday May 30, 2002 02:48 PM | | | Please respond to MQSeries List | | | | |-+--- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Problem receiving messages from a restarted client applicatio n. | | Truncated msg failed doesn't change the queue state and so there's no backout action for this hConn (typically the UOW won't even have been created). As there's no backout action we don't consider waking up another MQGET when we discover that the first client ends. I understand, now, there is no backout action. But, then app2's MQGET should be serviced even sooner--perhaps even before you discover the client is gone. Still fishing for the reason app2 doesn't wake up. Do I interpret you correctly, that after a 2080, MQ does not service another waiting MQGET if its buffer is also too short? Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Problem in MQDISC SOC-4 Abend
Shailesh, You cannot connect to the same queue manager twice from the same thread. You're second MQCONN will have returned MQRC_ALREADY_CONNECTED. If you need to be connected to two queue managers from one program, you will have to have two different queue managers. John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 shailesh To:[EMAIL PROTECTED] bhaskaran cc: shailesh_mqserie Subject:Re: Problem in MQDISC SOC-4 Abend [EMAIL PROTECTED] Sent by: MQSeries List MQSERIES@AKH-Wie n.AC.AT 05/30/2002 01:58 PM Please respond to MQSeries List Hi!, I am using two different HCONN variables one with name HCONN-PUT and another with HCONN-GET. After doing get I see that both HCONN-PUT and HCONN-GET have exactly the same values. I am doing MQCONN using HCONN-GET to connect to QMA and MQCONN using HCONN-PUT to connect to QMB. For testing purpose I have kept both QMA and QMB name same i,e both Get and Put queue manager names are same. I was wondering if from the same program if I issue MQCONN twice to the same queue manager, will I get the same value for the connection handles and if I disconnect using one connection handle will the other be also destroyed. I can guess that whenever I am closing the first connection handle say HCONN-GET, it somehow marks HCONN-PUT also closed.I can't understand why it is happening. Is it because I am connecting to same queue manager (with two different calls) using HCONN-GET and HCONN-PUT. Thanks Shailesh --- John M Hammond [EMAIL PROTECTED] wrote: Shailesh, You need to disconnect from both queue managers. Check your program and look at what you are doing with the variables you are storing your HConns in. You have 2 separate HConns and need 2 separate variables to store them in (if you want to be connected to both queue managers simultaneously). My guess is that you are corrupting the HConn somehow. The HConn is just a storage address, so if you corrupt it MQ will end up referencing bad addresses and 0C4's are likely. John John M Hammond - Middleware Support Team Household International 100 Mittel Drive Wood Dale, IL 60191 Phone: (630) 521-4339; Pager: (866) 237-0985 shailesh To: [EMAIL PROTECTED] bhaskaran cc: shailesh_mqserie Subject:Problem in MQDISC SOC-4 Abend [EMAIL PROTECTED] Sent by: MQSeries List MQSERIES@AKH-Wie n.AC.AT 05/30/2002 11:51 AM Please respond to MQSeries List Hi! All, I am facing a strange problem. I am running a batch application in which I am connecting to one queue manager say QMA and opening the queue to MQGET the message and also connecting to another queue manager say QMB and opening another queue to MQPUT the message read from the previous queue. Everything goes fine, At the end,I am disconnecting from QMA and QMB. The disconnect from first queue manager QMA goes fine but when it performs the para to disconnect from queue manager QMB, I get a SOC4 abend. I tried to do reverse also i,e first disconnecting from QMB (which goes fine) and then QMA again I get SOC4. I am using different connection handle to connect to two different queue manager. Can any one think of why it might be happening? Does disconnecting from any one queue manager is enough? Thanks Shailesh __ 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 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! - 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 Instructions for managing your mailing list subscription are provided in the Listserv General Users
Re: Problem receiving messages from a restarted client applicatio n.
Robert, I forgot to mention I meant internal MQSeries locks implementing the transactional operations, not browsing with MQGMO_LOCK option. If your browsing application use the latter, there is no surprise that App2 cannot see the message, but why would it be used if you just wanted to check if the message is on the queue? Pavel -- Forwarded by Pavel Tolkachev on 05/30/2002 06:15 PM --- From: Pavel Tolkachev on 05/30/2002 06:11 PM To:MQSeries List [EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. (Document link: Pavel Tolkachev) Robert, First of all, according to the MQGMO_SYNCPOINT docs, you cannot use MQGMO_SYNCPOINT and BROWSE_.. at the same MQGET. So browse as it is always running out of UOW should (again IMHO!) see the message without problems until it is deleted with MQCMIT after another (destructive) transactional MQGET or with non-transactional destructive MQGET. All other transactional operations (puts, gets) should block as soon as they try to use locked object (I am not sure if MQ locks UOW resources on message or queue level, my guess it is message) until locking UOW is finished. Pavel Message History From: Robert Broderick [EMAIL PROTECTED]@AKH-Wien.AC.AT on 05/30/2002 03:31 PM AST Please respond to MQSeries List [EMAIL PROTECTED] DELEGATED - Sent by:MQSeries [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. What if you do a browse with a lock and then do a get-msg-under-cursor??? From: Pavel Tolkachev [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Problem receiving messages from a restarted client applicatio n. Date: Thu, 30 May 2002 14:06:52 -0400 Andy: But don't you lock the queue at the moment you start reading the message while you still do not know the length and whether the message would be truncated or not? Even for MQGET which is in UOW? That would mean that you first check the length and only then lock the queue. If so, what if some other application (say, non-transactionally) steals the message before the transactional one can get it? Then you might have inconsistent information (the length from the 1st message while getting the 2nd one)? I do not understand how it works then. Or do you perform the double check? Sorry for asking about the internals but so far I beleived I understood how it works.. now I don't. :-( Thank you, Pavel Message History From: Andrew Hickson [EMAIL PROTECTED]@AKH-Wien.AC.AT on 05/30/2002 06:26 PM CET Please respond to MQSeries List [EMAIL PROTECTED] DELEGATED - Sent by:MQSeries [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. Dennis, Truncated msg failed doesn't change the queue state and so there's no backout action for this hConn (typically the UOW won't even have been created). As there's no backout action we don't consider waking up another MQGET when we discover that the first client ends. rgds Andy. Miller, Dennis [EMAIL PROTECTED]@AKH-WIEN.AC.AT on 05/30/2002 06:02:56 PM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. Thank you for the clarification. In doing more reading last night, I came to the same conclusion, but it's always nice to get confirmation from the source. Quite annoyingly, I believe it's MQCC_WARNING/MQRC_TRUNCATED_MSG_FAILED, which may add to the confusion. I understand the scenario to be that this sequence, with an adequate buffer size, works as expected: App1 agent issues MQGET+wait+syncpoint App2 agent issues MQGET+wait+syncpoint App1 client crashes Message arrives Message is delivered to App1 agent with RC=0 MQ discovers that client is gone App1 agent disconnects and rolls back message Message is delivered to App2 agent with RC=0 However, when the buffer is too small, the following is observed: App1 agent issues MQGET+wait+syncpoint App2 agent issues MQGET+wait+syncpoint App1 client crashes Message arrives Message is not delivered to App1 agent because RC=2080 MQ discovers that client is gone App1 agent disconnects and rolls back (exactly what, if anything, get's rolled back is interesting) App2 agent does not see message ==why is this??? App3 agent issues MQGET+wait+syncpoint App3 agent's MQGET returns with RC=2080 -Original Message- From: Andrew Hickson [SMTP:[EMAIL PROTECTED]] Sent: Thursday, May 30, 2002 12:27 AM To: [EMAIL PROTECTED]
Re: ActiveX Object in VB
Joshi - Couple of things. First, by not setting the mqgmo.Options = MQGMO_BROWSE_NEXT anymore you are doing destructive gets against your queue not browse gets. Secondly, you are checking the CompletionCode of your mqgmo object. I think you want to check the mqq object. This is the object that will contain the CC from the get method. - Steve -Original Message- From: Joshi, A (Anant) [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 30, 2002 12:08 PM To: [EMAIL PROTECTED] Subject: Re: ActiveX Object in VB I was getting MQ Error. MQRC_NO_MSG_AVAILABLE. I modified the code to set the MatchOption. Now I do not get error but only first 3 iterations bring in distinct message IDs. From there, I keep getting third message in an infinite loop. Thanks for help. Code Begin Done = False Set mqmsg = Nothing Set mqgmo = Nothing Set mqmsg = New MQMessage Set mqgmo = New MQGetMessageOptions mqgmo.MatchOptions = MQMO_NONE Do mqq.Get mqmsg, mqgmo, 0 Counter = Counter + 1 If mqgmo.CompletionCode = MQCC_OK Then lstMessages.AddItem Counter vbTab mqmsg.MessageId 'lstMessages.AddItem Counter vbTab mqmsg.PutDateTime Else Done = True End If mqmsg.MessageId = mqgmo.ClearErrorCodes Loop Until Done == Code End -Original Message- From: Ryan Parmenter [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 30, 2002 3:03 PM To: [EMAIL PROTECTED] Subject: Re: ActiveX Object in VB What error are you getting? Is it a VB error or an MQ error? Ryan [EMAIL PROTECTED] 05/30/02 10:11AM Hi I'm trying to display list of messages with their PutDateTime in a List Box in VB using following code. Code Begin Do If Counter = 0 Then mqgmo.Options = MQGMO_BROWSE_FIRST Else mqgmo.Options = MQGMO_BROWSE_NEXT End If mqq.Get mqmsg, mqgmo, 0 Counter = Counter + 1 If mqgmo.CompletionCode = MQCC_OK Then lstMessages.AddItem Counter vbTab mqmsg.PutDateTime Else Done = True End If Loop Until Done Code End However, I get error when loop iterates second time. PutDateTime of first message is read correctly. Any ideas? Thanks in Advance == De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. == The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. == 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 == De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. == The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. == 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: Problem receiving messages from a restarted client applicatio n.
Andy: Does this mean that, if that woken destructive MQGET fails for any reason, you do not attempt to look for the next qualifying candidate? Thank you, Pavel Message History From: Andrew Hickson [EMAIL PROTECTED]@AKH-Wien.AC.AT on 05/30/2002 10:54 PM CET Please respond to MQSeries List [EMAIL PROTECTED] DELEGATED - Sent by:MQSeries [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. Dennis/Rick, As stated in the APRM, when an MQPUT occurs we try and wake up one qualifying destructive MQGET (we explicitly do not specify which of multiple waiters would be woken). The problem here is that we haven't recognized that this waiter isn't really a destructive MQGET and from there on it all awry. Andy. Richard Brunette [EMAIL PROTECTED]@AKH-WIEN.AC.AT on 30/05/2002 21:08:57 Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. Dennis I believe its worse than that. They don't wake up one with a large buffer either. They simply don't look further. So without a new stimulus such as a new message arriving or some other UOW message being backed out there is nothing to wake the other waiting gets. Is that correct Andy? Rick |-+--- | | Miller, Dennis| | | [EMAIL PROTECTED]| | | | | | Sent by: MQSeries List | | | [EMAIL PROTECTED] | | | | | | | | | | | | Thursday May 30, 2002 02:48 PM | | | Please respond to MQSeries List | | | | |-+--- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Problem receiving messages from a restarted client applicatio n. | | Truncated msg failed doesn't change the queue state and so there's no backout action for this hConn (typically the UOW won't even have been created). As there's no backout action we don't consider waking up another MQGET when we discover that the first client ends. I understand, now, there is no backout action. But, then app2's MQGET should be serviced even sooner--perhaps even before you discover the client is gone. Still fishing for the reason app2 doesn't wake up. Do I interpret you correctly, that after a 2080, MQ does not service another waiting MQGET if its buffer is also too short? Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 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: alias queues vs hard-coded names
Just to add my two cents. (being stuck in the office till 9PM doing a cluster failover test.) I teach. And for those of my students that have taken my advice and gotten on the the listserv to gain the knowledge from it that I have will remember this simple two rules from my class. ALWAYS code your programs so they are instantaneously recompile able and use any automatic feature available and Always design your architecture so you can blame someone else!! simple, sweet and stops the calls at 3AM bobbee From: Stefan Sievert [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: alias queues vs hard-coded names Date: Thu, 30 May 2002 17:11:06 -0700 Hi Allan, I am most likely not be representative for the general view, but here it is anyway. :-) The first rule I follow (and recommend to anybody who wants to hear it) is to *never* hardcode *any* MQ object names in any program, but to instead read them during startup from a file or a database, or passing them in as command line arguments. This will allow you to use the same program for many different queue names if you wish to. It also isolates your application from infrastructure changes. Additionally, it often makes a lot of sense to use aliases as another level of isolation, or to implement certain security models. As you know, security checks are performed against the name in the MQOPEN call. So, you can define a local queue that nobody has permission to put/get from, but allow access through an alias queue. It depends on the specific requirements of every installation, though. If you do use alias queues as a company standard, your infrastructure team can change physical queue names (and location) without any impact on existing application code. Considering that even a simple name change in an application with a re-compile or the change of a configuration file usually requires re-testing of the application, using alias queues can save a lot of pain (and money). The administrative overhead of creating alias queues has to be weighed against the advantages it will have for the shop. So, never hardcode, use alias queues where sensible would be my view. I'm looking forward to hear the philosophies/experiences of others... :-) Hope that helps, Stefan From: Alan Turnbull [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: alias queues vs hard-coded names Date: Fri, 31 May 2002 09:24:07 +1000 hi Just wondering what the general view is of using queue aliases as opposed to hard coding queue names. I guess i am asking, if you are developing a new mq application would you always use aliases as a matter of course (or the reverse, just hard code names provided that those names are queue manager independant) thanks alan Alan Turnbull Senior Developer IITS Direct: (02) 9701 7333 Fax (02) 9701 7501 [EMAIL PROTECTED] Visit us on the web at http://www.qbe.com.au 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 _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx 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 _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. 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: alias queues vs hard-coded names
Alan, I think there are two subjects in your note. One) is hardcoding queue names in the application and Two) is using aliases versus just using the true local queue name. On One, I don't recommend hard coding things that may change, including queue names. This makes it easier to move an application between environments without recompiling each time. Using aliases I think depends on the situation. If you have a local queue that is serviced by an application that provides a service that many can benefit from, you may want to name the local queue to describe the service it provides. Then you can create aliases that make sense to the application that point to the real queue. This way the one real queue can be maintained by the owner of the servicing application while some parameters can be customized on the alias for the application like whether it is in a cluster, default persistence, and such and such. This way you don't have applicat ion owners fighting over how the queue is set up. Never mind that the application should always specify these things.that would be a dream. Something I experienced that caused some confusion is an application group needed a service, lets say from CICS. They create a local queue that is serviced by the CICS application and they call the local queue something that makes sense like MYDEPT.MYAPP.INPUT. Later, two more application groups need to same service from CICS. One is from YOURDEPT and one from SOMEOTHERDEPT. So does it make sense to use this queue with MYDEPT in the name? No, and it is confusing. I recommend the local queue defines the service being provided, then if MYDEPT wants to name the queue this way, give them an alias. My preference is everyone uses aliases or everyone does not. I don't like mixed environments because then you have to remember that Jack likes this and Sally likes that. Standards will save lots of time and money. If you are lucky enough that everyone is OK with a queue name like QL.CICS.QUERY and all applications specify any queue options like persistence and the like, you can get away with just using local queues. Otherwise, you should use aliases. Mike Murphy Sr. Middleware Consultant MQ Solutions, LLC http://www.mqsolutions.com Alan Turnbull [EMAIL PROTECTED] wrote: Date Recieved: 05/30/2002 04:24:07 PM To: [EMAIL PROTECTED] cc: Bcc Subject: alias queues vs hard-coded names hi Just wondering what the general view is of using queue aliases as opposed to hard coding queue names. I guess i am asking, if you are developing a new mq application would you always use aliases as a matter of course (or the reverse, just hard code names provided that those names are queue manager independant) thanks alan Alan Turnbull Senior Developer IITS Direct: (02) 9701 7333 Fax (02) 9701 7501 [EMAIL PROTECTED] Visit us on the web at http://www.qbe.com.au 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
SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: JMS-JDBC-XA transaction coordianation
Hi Graham , I did not concentrate on the subject line of the mail I had only gone through the mail message which does not specify JMS etc ... I was talking about a solution using IBM MQSeries Java API not JMS. But I am sure it be possible using JMS classes also , but we have not implemented it till now. .. Any way thanks for pointing out Cheers, Navin -Original Message- From: Graham French [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 30, 2002 6:50 PM To: [EMAIL PROTECTED] Subject: Re: JMS-JDBC-XA transaction coordianation Navin, For clarity can you confirm you can use Java JMS Classes for XA control. I know you can use the MQ classes for XA control, but the subject field of this email indicated JMS. Graham French MQSolutions +44 (0)7973 821288 mailto:[EMAIL PROTECTED] -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Navin Vali Sent: 30 May 2002 05:51 To: [EMAIL PROTECTED] Subject: Re: JMS-JDBC-XA transaction coordianation Hi Ferenc, Sorry for the delayed reply, I really don't agree with replies you have got till now. You can have MQ Series Queue Manager Acting as a Transaction monitor to control MQ Series resources as well as external resource managers (Some Database DB2 in your case). I have successfully tried out this with DB2 , so you need not actually need App server for this. Any help req pls get in touch on [EMAIL PROTECTED] Regards Navin -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 7:30 PM To: [EMAIL PROTECTED] Subject: Re: JMS-JDBC-XA transaction coordianation Ferenc, If you do not want to use WebSphere, you may use Weblogic instead :-). Seriously, you will need some XA-capable JTA provider (Java library and server). They are included in WebLogic and Websphere and some other expensive application servers. I have not ever heard someone successfully used the free ones but there is at least one (see http://tyrex.exolab.org/). You will have to figure out how to configure MQ JMS to use its connection factories (the documentation only explains how to do that with Websphere). Again, I never tried that Tyrex myself. Hope this will help Pavel Message History From: Graham French [EMAIL PROTECTED]@AKH-Wien.AC.AT on 05/29/2002 01:36 PM CET Please respond to MQSeries List [EMAIL PROTECTED] DELEGATED - Sent by:MQSeries [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: JMS-JDBC-XA transaction coordianation Configuring it is in the MQSeries Systems Administration Guide, Chapter 14, Transaction Support. Coding is in the MQSeries Application Programming Guide, Chapter 13, Committing and Backing out Units of Work You may have to use the Java MQ Classes rather than JMS if you're not using an app server, but I'll let someone else comment on that who knows more about what they're talking about! Regards Graham French MQSolutions +44 (0)7973 821288 mailto:[EMAIL PROTECTED] -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Ferenc Door Sent: 29 May 2002 10:48 To: [EMAIL PROTECTED] Subject: JMS-JDBC-XA transaction coordianation Hi, A question is : Are there any solution to build an java application which use globally coordinated transaction? I not intend to use WebShere. Where can I find a good dokumentation which decribes: how should set up MQSeries-DB2-Java environment to gain access this feature? Best regard, Ferenc Door -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Broker could not send publication to subscriber queue.
Title: Broker could not send publication to subscriber queue. Hi , I am facing the following error. I am not able to understand it. Could u pls. help me with the Reason 2053. Thanks, Vivek. Event Type: Warning Event Source: MQSeries Event Category: None Event ID: 5858 Date: 5/30/2002 Time: 2:46:59 PM User: N/A Computer: MQSERVER Description: Broker could not send publication to subscriber queue. A failure has occurred sending a publication to subscriber queue (SYSTEM.JMS.D.CC.SUBSCRIBER.QUEUE ) at queue manager (CashinQManager ) for reason 2053. The broker configuration options prevent it from recovering from this failure by discarding the publication or by sending it to the dead-letter queue. Instead the broker will back out the unit of work under which the publication is being sent and retry the failing command message a fixed number of times. If the problem still persists, the broker will then attempt to recover by failing the command message with a negative reply message. If the issuer of the command did not request negative replies, the broker will either discard or send to the dead-letter queue the failing command message. If the broker configuration options prevent this, the broker will restart the affected stream, which will reprocess the failing command message again. This behavior will be repeated until such time as the failure is resolved. During this time the stream will be unable to process further publications or subscriptions. Usually the failure will be due to a transient resource problem, for example, the subscriber queue, or an intermediate transmission queue, becoming full. Use reason code 2053 to determine what remedial action is required. If the problem persists for a long time, you will notice the stream being continually restarted by the broker. Evidence of this occurring will be a large number of AMQ5820 messages, indicating stream restart, being written to the error logs. In such circumstances, manual intervention will be required to allow the broker to dispose of the failing publication. To do this, you will need to end the broker using the endmqbrk command and restart it with appropriate disposition options. This will allow the publication to be sent to the rest of the subscribers, while allowing the broker to discard or send to the dead-letter queue the publication that could not be sent.
