Re: 2035 and Client connection
They are likely using a different userid. Check your MQ log on the server for the corresponding 8077 message which will give you the details of the security failure. It will tell you the userid they are using. Nick -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wesley Shaw Sent: Friday, August 20, 2004 9:58 AM To: [EMAIL PROTECTED] Subject: 2035 and Client connection We are running MQ on a pair of Solaris servers.(V5.3). I have set security to a set of queues using setmqaut. If I on the client server attempt to connect to these queues and put messages using the sample amqsputc program, the security works fine. Message is put. When the application team using a modified version of the amqsput source code attemps a put to the same queue using the same client channel, the 2035 return code results. How could this be ? 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
2035 and Client connection
We are running MQ on a pair of Solaris servers.(V5.3). I have set security to a set of queues using setmqaut. If I on the client server attempt to connect to these queues and put messages using the sample amqsputc program, the security works fine. Message is put. When the application team using a modified version of the amqsput source code attemps a put to the same queue using the same client channel, the 2035 return code results. How could this be ? 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: ZOS client connection
Visu, >>>We are having issues with java client connection from Windows 2000 >>>server to Queue Manager in main frame. Can somebody let us know >>>what needs to be done in the Windows and mainframe to establish >>>the connection. You probably do not have the "Client Attachment Feature" installed on z/OS. Regards, Christopher Frank Certified I/T Specialist - WebSphere Software IBM Certified Solutions Expert - Websphere MQ & MQ Integrator -- Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] 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
ZOS client connection
All, We are having issues with java client connection from Windows 2000 server to Queue Manager in main frame. Can somebody let us know what needs to be done in the Windows and mainframe to establish the connection. Thanks in advance. Visu. _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail 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: MQ Client connection
1. You cannot use MQServer as a client to connect to another MQServer however, you can configure one MQServer to talk to another MQServer. 2. Yes. 3. With the product itself. You can also download them from IBM site as MA88 support pac. 4. Comes the product installation. you can also have them at IBM web site. -Arvind Sharath H V <[EMAIL PROTECTED] To: [EMAIL PROTECTED] UTIONS.COM> cc: (bcc: arvind.chaudhary/Polaris) Sent by: MQSeriesSubject: MQ Client connection List <[EMAIL PROTECTED] C.AT> 04/27/04 04:19 PM Please respond to MQSeries List Hi , I am just started working on IBM MQ series . I have the following doubts * Can I use a MQserver as a MQclient to connect to another MQ Server ? If so , can i get some material on how to do the same . * Can the server and client exists on the smae m/c ? * Where do i get the Java API for the MQI and MQ java ? * Where do we get the documentation for MQ version 5.3 Windows and AIX platform ? rgds Sharath H V 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 proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit Us at http://www.polaris.co.in
MQ Client connection
Hi , I am just started working on IBM MQ series . I have the following doubts * Can I use a MQserver as a MQclient to connect to another MQ Server ? If so , can i get some material on how to do the same . * Can the server and client exists on the smae m/c ? * Where do i get the Java API for the MQI and MQ java ? * Where do we get the documentation for MQ version 5.3 Windows and AIX platform ? rgds Sharath H V 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
MQ client connection channel
It is probably a mq objects set up issue but I need help on how to resolve it. Hope I explained my problem clearly === I am using the AMQSCNXC C sample program which demonstrates how to specify client connection information on MQCONNX. I got error at run time with reason code 2059 (MQRC_Q_MGR_NOT_AVAILABLE). Followings are snapshots of eventlog from both client and server machine when rc 2059 returned to the sample program. Client machine (has serveral local q mgrs) and the client connection channel , namely "TEST_CH", is defined under the default queue manager.There is no MQSERVER environment variable defined on the client machine. Server machine ( has several local q mgrs) and the server connection channel "TEST_CH" is defined under the default local queue manager. Eventlog on Client machine.Description:Channel not defined remotely. There is no definition of channel 'TEST_CH' at the remote location. Add an appropriate definition to the remote hosts list of defined channels and retry the operation. Eventlog on remote Server machine...Description:Channel 'TEST_CH' not found. The requested operation failed because the program could not find a definition of channel 'TEST_CH'. Check that the name is specified correctly and the channel definition is available. = Thanks,TC Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it!
Re: Broken Client Connection
I made a typo, in my original post. I didn't mean to say the qmgr backs out anything that was committed. I meant to say it doesn't back out anything that was committed. Sorry for the confusion and thanks to those that posted replies. Your responses were still very helpful. Thanks! Gary === Gary Klos Online Systems - PSC United States Steel Corporation 412-433-1225 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: Broken Client Connection
Gary, The queue will not only "technically" remain open, it will "actually" remain open! :-) Only when the client wakes up, whether that is due to expiring wait interval, keepalive, hbint or fail if quiescing notice, will the queue handle be released. Now, about your backout assumption...maybe, maybe not. First, with a client, do EVERYTHING under syncpoint. I assume you are doing that based on your question. Now suppose you get a 2009 on the COMMIT call. Did the connection break before or after the call reached the QMgr? No way to tell. Your COMMIT may or may not have been executed. If you had executed several GETs under syncpoint and the connection fails BEFORE it reaches the QMgr, the records will remain under syncpoint, unavailable to any process, until the client channel agent exits. Depending on your channel tuning, that may be quite a long time. Let's hope you have lots of log space and a high MAXUMSGS. If you have done several PUTs under syncpoint and get a 2009 AFTER the QMgr receives the call, your PUTs were successful but you have no way to know that via MQ. Your application will either need to tolerate dupes or give you a way to resynchronize it's state. -- T.Rob -Original Message- From: Gary P. Klos [mailto:[EMAIL PROTECTED] Sent: Friday, January 09, 2004 2:49 PM To: [EMAIL PROTECTED] Subject: Broken Client Connection I'm curious - what exactly happens if we are connected to a qmgr via a client, doing MQGETs. Now what happens if the connection is broken due to a tcpip error? Obviously the client is no longer there. I assume the queue manager backs anything out that was committed. But actually I was more concerned about cleanup. Does the queue manager immediately close the queue? Or is the queue left open until the heartbeat interval is executed. So if there was a very large heartbeat interval, then would the queue "technically" remain open till the queue manager executes the heartbeat and notices the connection is no longer there? Gary === Gary Klos Online Systems - PSC United States Steel Corporation 412-433-1225 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
Broken Client Connection
I'm curious - what exactly happens if we are connected to a qmgr via a client, doing MQGETs. Now what happens if the connection is broken due to a tcpip error? Obviously the client is no longer there. I assume the queue manager backs anything out that was committed. But actually I was more concerned about cleanup. Does the queue manager immediately close the queue? Or is the queue left open until the heartbeat interval is executed. So if there was a very large heartbeat interval, then would the queue "technically" remain open till the queue manager executes the heartbeat and notices the connection is no longer there? Gary === Gary Klos Online Systems - PSC United States Steel Corporation 412-433-1225 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: Client Connection
You have to teach me that trick some dayREADING Thanks John. That little trick will do exactly what I wanted to do. You are a god among mortals!! bobbee From: "Dawson, John" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Client Connection Date: Wed, 17 Dec 2003 14:37:57 -0600 Bobbee, It connects to the channel listed in the queue manager field. Where did I get the ideal? Simple, RTM. "In any case, regardless of whether the MQSERVER variable is set or a channel table exists, the necessary channel information can be entered in lieu of a queue manager name, using the format of the MQSERVER variable." Hope this helps, John -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 2:23 PM To: [EMAIL PROTECTED] Subject:Re: Client Connection Does that connect to the SYSTEM.DEF.SVRCONN channel or does it connect to the channel nmed in the name field of the Client Connection. ANDmore important What ever gave you the idea to put that in there?? >From: "Dawson, John" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Client Connection >Date: Wed, 17 Dec 2003 14:09:43 -0600 > >Bobbee, > > You could also put the MQSERVER variable in the queue manager field, >'SYSTEM.DEF.SVRCONN\TCP\123.123.456.78(1414)'. This works as I have just >done this. > > >Regards, > >John > > > -Original Message- >From: Robert Broderick [mailto:[EMAIL PROTECTED] >Sent: Wednesday, December 17, 2003 1:54 PM >To: [EMAIL PROTECTED] >Subject:Re: Client Connection > >Thank You, Thank You, Thank You! and to all a good night!!! > >I did just that. I created QMGR.CLIENT connections and then SVRCONNs on the >QMGRS moved the TAB file to my desktop and RFHUTILC works as expected. I >noticed in >MQSeries.NET that somebody said the QMGR does not do garbage collection on >the TAB file. IS this still true of 5.3?? > >ANYWAY. it works and I will look like a hero again!!! >(hahahahahahahaha) >(The problem with heros is they are always having GUNS pointed at >them!!!) > > >bee-oh-dubble-bee-dubble-h > :-) > > > >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: Client Connection > >Date: Wed, 17 Dec 2003 14:13:54 -0500 > > > >"What I believe is going on here is that I need to define a > >separate named SVRCONN channel on each QMGR (eg QMGR1.CLIENT, >QMGR2.CLIENT, > >QMGR3.CLIENT) and then create the Client Channels with the same names." > > > >Correct. Name them alphabetically in the order you want to use them in > >failover scenarios. If you create them all with a blank QM name, and all > >the > >QMs are defaults, and you specify a blank name in the MQCONN call, your >app > >will automatically connect to the 1st available QM whenever there is a > >failure of the primary QM. > > > >If you want to specify which QM you want in the app, by coding the QM >name > >in the MQCONN call, just do the same as above but include the QM name in > >the > >creation of each differently named CLNTCONN channel. > > > > > > > > > > > >-Original Message- > >From: Robert Broderick [mailto:[EMAIL PROTECTED] > >Sent: Wednesday, December 17, 2003 2:05 PM > >To: [EMAIL PROTECTED] > >Subject: Re: Client Connection > > > > > >What I have tried, just in case this was missed, is to go to MQ Explorer > >and > >I go to Client Connections under Advanced. I then try to create a > >SYSTEM.ADMIN.SVRCONN client connection for ALL my QMGRS (QMGR1, QMGR2 and > >QMGR3). The first one works but the second one does not because the name > >exist already. What I believe is going on here is that I need to define a > >seperate named SVRCONN channel on each QMGR (eg QMGR1.CLIENT, >QMGR2.CLIENT, > >QMGR3.CLIENT) and then create the Client Channels with the same names. SO > >what I am seeing here, and somebody please correct me if I am wrong, >while > >I > >can go to the MQSERVER environment variable and JUST change the >connection > >name and REUSE the same channel on each QMGR (eg SYSTEM.ADMIN.SVRCONN) > >using > >the client channel tables I must define seperate named SVRCONN channels >to > >get the individual entries into the channel table because
Re: Client Connection
Bobbee, It connects to the channel listed in the queue manager field. Where did I get the ideal? Simple, RTM. "In any case, regardless of whether the MQSERVER variable is set or a channel table exists, the necessary channel information can be entered in lieu of a queue manager name, using the format of the MQSERVER variable." Hope this helps, John -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 2:23 PM To: [EMAIL PROTECTED] Subject: Re: Client Connection Does that connect to the SYSTEM.DEF.SVRCONN channel or does it connect to the channel nmed in the name field of the Client Connection. ANDmore important What ever gave you the idea to put that in there?? >From: "Dawson, John" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Client Connection >Date: Wed, 17 Dec 2003 14:09:43 -0600 > >Bobbee, > > You could also put the MQSERVER variable in the queue manager field, >'SYSTEM.DEF.SVRCONN\TCP\123.123.456.78(1414)'. This works as I have just >done this. > > >Regards, > >John > > > -Original Message- >From: Robert Broderick [mailto:[EMAIL PROTECTED] >Sent: Wednesday, December 17, 2003 1:54 PM >To: [EMAIL PROTECTED] >Subject:Re: Client Connection > >Thank You, Thank You, Thank You! and to all a good night!!! > >I did just that. I created QMGR.CLIENT connections and then SVRCONNs on the >QMGRS moved the TAB file to my desktop and RFHUTILC works as expected. I >noticed in >MQSeries.NET that somebody said the QMGR does not do garbage collection on >the TAB file. IS this still true of 5.3?? > >ANYWAY. it works and I will look like a hero again!!! >(hahahahahahahaha) >(The problem with heros is they are always having GUNS pointed at >them!!!) > > >bee-oh-dubble-bee-dubble-h > :-) > > > >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: Client Connection > >Date: Wed, 17 Dec 2003 14:13:54 -0500 > > > >"What I believe is going on here is that I need to define a > >separate named SVRCONN channel on each QMGR (eg QMGR1.CLIENT, >QMGR2.CLIENT, > >QMGR3.CLIENT) and then create the Client Channels with the same names." > > > >Correct. Name them alphabetically in the order you want to use them in > >failover scenarios. If you create them all with a blank QM name, and all > >the > >QMs are defaults, and you specify a blank name in the MQCONN call, your >app > >will automatically connect to the 1st available QM whenever there is a > >failure of the primary QM. > > > >If you want to specify which QM you want in the app, by coding the QM >name > >in the MQCONN call, just do the same as above but include the QM name in > >the > >creation of each differently named CLNTCONN channel. > > > > > > > > > > > >-----Original Message- > >From: Robert Broderick [mailto:[EMAIL PROTECTED] > >Sent: Wednesday, December 17, 2003 2:05 PM > >To: [EMAIL PROTECTED] > >Subject: Re: Client Connection > > > > > >What I have tried, just in case this was missed, is to go to MQ Explorer > >and > >I go to Client Connections under Advanced. I then try to create a > >SYSTEM.ADMIN.SVRCONN client connection for ALL my QMGRS (QMGR1, QMGR2 and > >QMGR3). The first one works but the second one does not because the name > >exist already. What I believe is going on here is that I need to define a > >seperate named SVRCONN channel on each QMGR (eg QMGR1.CLIENT, >QMGR2.CLIENT, > >QMGR3.CLIENT) and then create the Client Channels with the same names. SO > >what I am seeing here, and somebody please correct me if I am wrong, >while > >I > >can go to the MQSERVER environment variable and JUST change the >connection > >name and REUSE the same channel on each QMGR (eg SYSTEM.ADMIN.SVRCONN) > >using > >the client channel tables I must define seperate named SVRCONN channels >to > >get the individual entries into the channel table because the table is > >KEYED > >off the name field. If I got this right then permit me to stick my neck > >out. > >THIS SUCKS!! (Sorry if I am echoing past experiences) > > > > > > bobbee > > > > > > >From: Ruzi R <[EMAIL PROTECTED]> > > >Reply-To: MQSeries List <[EMAIL PROTECTED]
Re: Client Connection
Does that connect to the SYSTEM.DEF.SVRCONN channel or does it connect to the channel nmed in the name field of the Client Connection. ANDmore important What ever gave you the idea to put that in there?? From: "Dawson, John" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Client Connection Date: Wed, 17 Dec 2003 14:09:43 -0600 Bobbee, You could also put the MQSERVER variable in the queue manager field, 'SYSTEM.DEF.SVRCONN\TCP\123.123.456.78(1414)'. This works as I have just done this. Regards, John -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 1:54 PM To: [EMAIL PROTECTED] Subject:Re: Client Connection Thank You, Thank You, Thank You! and to all a good night!!! I did just that. I created QMGR.CLIENT connections and then SVRCONNs on the QMGRS moved the TAB file to my desktop and RFHUTILC works as expected. I noticed in MQSeries.NET that somebody said the QMGR does not do garbage collection on the TAB file. IS this still true of 5.3?? ANYWAY. it works and I will look like a hero again!!! (hahahahahahahaha) (The problem with heros is they are always having GUNS pointed at them!!!) bee-oh-dubble-bee-dubble-h :-) >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Client Connection >Date: Wed, 17 Dec 2003 14:13:54 -0500 > >"What I believe is going on here is that I need to define a >separate named SVRCONN channel on each QMGR (eg QMGR1.CLIENT, QMGR2.CLIENT, >QMGR3.CLIENT) and then create the Client Channels with the same names." > >Correct. Name them alphabetically in the order you want to use them in >failover scenarios. If you create them all with a blank QM name, and all >the >QMs are defaults, and you specify a blank name in the MQCONN call, your app >will automatically connect to the 1st available QM whenever there is a >failure of the primary QM. > >If you want to specify which QM you want in the app, by coding the QM name >in the MQCONN call, just do the same as above but include the QM name in >the >creation of each differently named CLNTCONN channel. > > > > > >-Original Message- >From: Robert Broderick [mailto:[EMAIL PROTECTED] >Sent: Wednesday, December 17, 2003 2:05 PM >To: [EMAIL PROTECTED] >Subject: Re: Client Connection > > >What I have tried, just in case this was missed, is to go to MQ Explorer >and >I go to Client Connections under Advanced. I then try to create a >SYSTEM.ADMIN.SVRCONN client connection for ALL my QMGRS (QMGR1, QMGR2 and >QMGR3). The first one works but the second one does not because the name >exist already. What I believe is going on here is that I need to define a >seperate named SVRCONN channel on each QMGR (eg QMGR1.CLIENT, QMGR2.CLIENT, >QMGR3.CLIENT) and then create the Client Channels with the same names. SO >what I am seeing here, and somebody please correct me if I am wrong, while >I >can go to the MQSERVER environment variable and JUST change the connection >name and REUSE the same channel on each QMGR (eg SYSTEM.ADMIN.SVRCONN) >using >the client channel tables I must define seperate named SVRCONN channels to >get the individual entries into the channel table because the table is >KEYED >off the name field. If I got this right then permit me to stick my neck >out. >THIS SUCKS!! (Sorry if I am echoing past experiences) > > > bobbee > > > >From: Ruzi R <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: Client Connection > >Date: Wed, 17 Dec 2003 10:38:29 -0800 > > > >Bobbee, > > > >In addition to what has been already said, we define > >all the client connection channels (same or different > >name) on the same queue manager in mainframe. Then we > >run a CSQUTIL job with the MAKECLNT option...to > >extract the CLNTCONN channel definitons (you can be > >specific here as to which ones you want), and download > >this file to any server we want. This file becomes > >your channel table. Make sure that you define the > >corresponding SVRCONN channels on the server. > > > >Best regards, > > > >Ruzi > > > > > >--- Gary Ward <[EMAIL PROTECTED]> wrote: > > > Bobbee, > > > > > > Make all the CLNTCONN definitions on ONE qmgr and > > > specify the QMNAME > > > parameter on each definition with one of your 3 > > > qmgrs and their
Re: Client Connection
Bobbee, You could also put the MQSERVER variable in the queue manager field, 'SYSTEM.DEF.SVRCONN\TCP\123.123.456.78(1414)'. This works as I have just done this. Regards, John -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 1:54 PM To: [EMAIL PROTECTED] Subject: Re: Client Connection Thank You, Thank You, Thank You! and to all a good night!!! I did just that. I created QMGR.CLIENT connections and then SVRCONNs on the QMGRS moved the TAB file to my desktop and RFHUTILC works as expected. I noticed in MQSeries.NET that somebody said the QMGR does not do garbage collection on the TAB file. IS this still true of 5.3?? ANYWAY. it works and I will look like a hero again!!! (hahahahahahahaha) (The problem with heros is they are always having GUNS pointed at them!!!) bee-oh-dubble-bee-dubble-h :-) >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Client Connection >Date: Wed, 17 Dec 2003 14:13:54 -0500 > >"What I believe is going on here is that I need to define a >separate named SVRCONN channel on each QMGR (eg QMGR1.CLIENT, QMGR2.CLIENT, >QMGR3.CLIENT) and then create the Client Channels with the same names." > >Correct. Name them alphabetically in the order you want to use them in >failover scenarios. If you create them all with a blank QM name, and all >the >QMs are defaults, and you specify a blank name in the MQCONN call, your app >will automatically connect to the 1st available QM whenever there is a >failure of the primary QM. > >If you want to specify which QM you want in the app, by coding the QM name >in the MQCONN call, just do the same as above but include the QM name in >the >creation of each differently named CLNTCONN channel. > > > > > >-Original Message- >From: Robert Broderick [mailto:[EMAIL PROTECTED] >Sent: Wednesday, December 17, 2003 2:05 PM >To: [EMAIL PROTECTED] >Subject: Re: Client Connection > > >What I have tried, just in case this was missed, is to go to MQ Explorer >and >I go to Client Connections under Advanced. I then try to create a >SYSTEM.ADMIN.SVRCONN client connection for ALL my QMGRS (QMGR1, QMGR2 and >QMGR3). The first one works but the second one does not because the name >exist already. What I believe is going on here is that I need to define a >seperate named SVRCONN channel on each QMGR (eg QMGR1.CLIENT, QMGR2.CLIENT, >QMGR3.CLIENT) and then create the Client Channels with the same names. SO >what I am seeing here, and somebody please correct me if I am wrong, while >I >can go to the MQSERVER environment variable and JUST change the connection >name and REUSE the same channel on each QMGR (eg SYSTEM.ADMIN.SVRCONN) >using >the client channel tables I must define seperate named SVRCONN channels to >get the individual entries into the channel table because the table is >KEYED >off the name field. If I got this right then permit me to stick my neck >out. >THIS SUCKS!!!!!! (Sorry if I am echoing past experiences) > > > bobbee > > > >From: Ruzi R <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: Client Connection > >Date: Wed, 17 Dec 2003 10:38:29 -0800 > > > >Bobbee, > > > >In addition to what has been already said, we define > >all the client connection channels (same or different > >name) on the same queue manager in mainframe. Then we > >run a CSQUTIL job with the MAKECLNT option...to > >extract the CLNTCONN channel definitons (you can be > >specific here as to which ones you want), and download > >this file to any server we want. This file becomes > >your channel table. Make sure that you define the > >corresponding SVRCONN channels on the server. > > > >Best regards, > > > >Ruzi > > > > > >--- Gary Ward <[EMAIL PROTECTED]> wrote: > > > Bobbee, > > > > > > Make all the CLNTCONN definitions on ONE qmgr and > > > specify the QMNAME > > > parameter on each definition with one of your 3 > > > qmgrs and their particular > > > IP address/port in the CONNAME. This will place all > > > 3 definitions in the > > > table on that queue manager's server. Then place a > > > SVRCONN on each of your > > > 3 qmgrs using the same name (CLIENTCONN.CHANNEL). > > > > > > This requires that your application use a qmgr name > > > in the MQCONN... > > &g
Re: Client Connection
Thank You, Thank You, Thank You! and to all a good night!!! I did just that. I created QMGR.CLIENT connections and then SVRCONNs on the QMGRS moved the TAB file to my desktop and RFHUTILC works as expected. I noticed in MQSeries.NET that somebody said the QMGR does not do garbage collection on the TAB file. IS this still true of 5.3?? ANYWAY. it works and I will look like a hero again!!! (hahahahahahahaha) (The problem with heros is they are always having GUNS pointed at them!!!) bee-oh-dubble-bee-dubble-h :-) From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Client Connection Date: Wed, 17 Dec 2003 14:13:54 -0500 "What I believe is going on here is that I need to define a separate named SVRCONN channel on each QMGR (eg QMGR1.CLIENT, QMGR2.CLIENT, QMGR3.CLIENT) and then create the Client Channels with the same names." Correct. Name them alphabetically in the order you want to use them in failover scenarios. If you create them all with a blank QM name, and all the QMs are defaults, and you specify a blank name in the MQCONN call, your app will automatically connect to the 1st available QM whenever there is a failure of the primary QM. If you want to specify which QM you want in the app, by coding the QM name in the MQCONN call, just do the same as above but include the QM name in the creation of each differently named CLNTCONN channel. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 2:05 PM To: [EMAIL PROTECTED] Subject: Re: Client Connection What I have tried, just in case this was missed, is to go to MQ Explorer and I go to Client Connections under Advanced. I then try to create a SYSTEM.ADMIN.SVRCONN client connection for ALL my QMGRS (QMGR1, QMGR2 and QMGR3). The first one works but the second one does not because the name exist already. What I believe is going on here is that I need to define a seperate named SVRCONN channel on each QMGR (eg QMGR1.CLIENT, QMGR2.CLIENT, QMGR3.CLIENT) and then create the Client Channels with the same names. SO what I am seeing here, and somebody please correct me if I am wrong, while I can go to the MQSERVER environment variable and JUST change the connection name and REUSE the same channel on each QMGR (eg SYSTEM.ADMIN.SVRCONN) using the client channel tables I must define seperate named SVRCONN channels to get the individual entries into the channel table because the table is KEYED off the name field. If I got this right then permit me to stick my neck out. THIS SUCKS!! (Sorry if I am echoing past experiences) bobbee >From: Ruzi R <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Client Connection >Date: Wed, 17 Dec 2003 10:38:29 -0800 > >Bobbee, > >In addition to what has been already said, we define >all the client connection channels (same or different >name) on the same queue manager in mainframe. Then we >run a CSQUTIL job with the MAKECLNT option...to >extract the CLNTCONN channel definitons (you can be >specific here as to which ones you want), and download >this file to any server we want. This file becomes >your channel table. Make sure that you define the >corresponding SVRCONN channels on the server. > >Best regards, > >Ruzi > > >--- Gary Ward <[EMAIL PROTECTED]> wrote: > > Bobbee, > > > > Make all the CLNTCONN definitions on ONE qmgr and > > specify the QMNAME > > parameter on each definition with one of your 3 > > qmgrs and their particular > > IP address/port in the CONNAME. This will place all > > 3 definitions in the > > table on that queue manager's server. Then place a > > SVRCONN on each of your > > 3 qmgrs using the same name (CLIENTCONN.CHANNEL). > > > > This requires that your application use a qmgr name > > in the MQCONN... > > > > Happy Holidays.. Make sure you take some days off! > > Gary > > > > -Original Message- > > From: MQSeries List > > [mailto:[EMAIL PROTECTED] Behalf Of Robert > > Broderick > > Sent: Wednesday, December 17, 2003 12:19 PM > > To: [EMAIL PROTECTED] > > Subject: Client Connection > > > > > > Using the MQSERVER variable and a generic named > > channel all I have to do is > > change the connection information to achieve a > > connection to a new server if > > I wanted one. > > > > Using a Client Channel Table how would I get a > > client to connect throught > > say a channel named CLIENTCONN.CHANNEL to either > > QMGR1 or QMGR2 or QMGR3. > > How do you make those
Re: Client Connection
"What I believe is going on here is that I need to define a separate named SVRCONN channel on each QMGR (eg QMGR1.CLIENT, QMGR2.CLIENT, QMGR3.CLIENT) and then create the Client Channels with the same names." Correct. Name them alphabetically in the order you want to use them in failover scenarios. If you create them all with a blank QM name, and all the QMs are defaults, and you specify a blank name in the MQCONN call, your app will automatically connect to the 1st available QM whenever there is a failure of the primary QM. If you want to specify which QM you want in the app, by coding the QM name in the MQCONN call, just do the same as above but include the QM name in the creation of each differently named CLNTCONN channel. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 2:05 PM To: [EMAIL PROTECTED] Subject: Re: Client Connection What I have tried, just in case this was missed, is to go to MQ Explorer and I go to Client Connections under Advanced. I then try to create a SYSTEM.ADMIN.SVRCONN client connection for ALL my QMGRS (QMGR1, QMGR2 and QMGR3). The first one works but the second one does not because the name exist already. What I believe is going on here is that I need to define a seperate named SVRCONN channel on each QMGR (eg QMGR1.CLIENT, QMGR2.CLIENT, QMGR3.CLIENT) and then create the Client Channels with the same names. SO what I am seeing here, and somebody please correct me if I am wrong, while I can go to the MQSERVER environment variable and JUST change the connection name and REUSE the same channel on each QMGR (eg SYSTEM.ADMIN.SVRCONN) using the client channel tables I must define seperate named SVRCONN channels to get the individual entries into the channel table because the table is KEYED off the name field. If I got this right then permit me to stick my neck out. THIS SUCKS!! (Sorry if I am echoing past experiences) bobbee >From: Ruzi R <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Client Connection >Date: Wed, 17 Dec 2003 10:38:29 -0800 > >Bobbee, > >In addition to what has been already said, we define >all the client connection channels (same or different >name) on the same queue manager in mainframe. Then we >run a CSQUTIL job with the MAKECLNT option...to >extract the CLNTCONN channel definitons (you can be >specific here as to which ones you want), and download >this file to any server we want. This file becomes >your channel table. Make sure that you define the >corresponding SVRCONN channels on the server. > >Best regards, > >Ruzi > > >--- Gary Ward <[EMAIL PROTECTED]> wrote: > > Bobbee, > > > > Make all the CLNTCONN definitions on ONE qmgr and > > specify the QMNAME > > parameter on each definition with one of your 3 > > qmgrs and their particular > > IP address/port in the CONNAME. This will place all > > 3 definitions in the > > table on that queue manager's server. Then place a > > SVRCONN on each of your > > 3 qmgrs using the same name (CLIENTCONN.CHANNEL). > > > > This requires that your application use a qmgr name > > in the MQCONN... > > > > Happy Holidays.. Make sure you take some days off! > > Gary > > > > -Original Message- > > From: MQSeries List > > [mailto:[EMAIL PROTECTED] Behalf Of Robert > > Broderick > > Sent: Wednesday, December 17, 2003 12:19 PM > > To: [EMAIL PROTECTED] > > Subject: Client Connection > > > > > > Using the MQSERVER variable and a generic named > > channel all I have to do is > > change the connection information to achieve a > > connection to a new server if > > I wanted one. > > > > Using a Client Channel Table how would I get a > > client to connect throught > > say a channel named CLIENTCONN.CHANNEL to either > > QMGR1 or QMGR2 or QMGR3. > > How do you make those definations on a QMGR so they > > get into the Channel > > Table Or do I need to define a seperate named > > channel on each QMGR?? > > > > > > bobbee > > > > >_ > > Have fun customizing MSN Messenger learn how here! > > >http://www.msnmessenger-download.com/tracking/reach_customize > > > > 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
Re: Client Connection
Its looking for a SVRCONN channel called ETQARAS1 when you make a MQCONN call to a QM called ETQARAS1. Change the Client Connection Name parameter to the channel you actually want to use. Bobbee, send an email to [EMAIL PROTECTED] with your phone# if you want to talk. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 1:38 PM To: [EMAIL PROTECTED] Subject: Re: Client Connection What I did was define on my laptop was bunch of "Client Connections" using MQ Explorer here is one. Client Connection Name - ETQARAS1 Description - Transmission Protocol - TCP/IP Queue Manager Name - ETQARAS1 Max Message Length - 4194304 Heartbeat Interval - 300 Local Communication - I the copied the AMQCLCHL.TAB file from my Windows laptop to my desktop. I then set the two environment variables for the path and file and deleted the MQSERVER environment variable. I then brought up the RFHUTILC.exe utility and specified ETQARAS1 as the QMGR I wanted to get the message from and specified the SYSTEM.DEFAULT.LOCAL.QUEUE as the queue. 2059 How does this thing know I want to connect to SYSTEM.ADMIN.SVRCONN >From: Gary Ward <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Client Connection >Date: Wed, 17 Dec 2003 12:29:29 -0500 > >Bobbee, > >Make all the CLNTCONN definitions on ONE qmgr and specify the QMNAME >parameter on each definition with one of your 3 qmgrs and their particular >IP address/port in the CONNAME. This will place all 3 definitions in the >table on that queue manager's server. Then place a SVRCONN on each of your >3 qmgrs using the same name (CLIENTCONN.CHANNEL). > >This requires that your application use a qmgr name in the MQCONN... > >Happy Holidays.. Make sure you take some days off! >Gary > >-Original Message- >From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Robert >Broderick >Sent: Wednesday, December 17, 2003 12:19 PM >To: [EMAIL PROTECTED] >Subject: Client Connection > > >Using the MQSERVER variable and a generic named channel all I have to do is >change the connection information to achieve a connection to a new server >if >I wanted one. > >Using a Client Channel Table how would I get a client to connect throught >say a channel named CLIENTCONN.CHANNEL to either QMGR1 or QMGR2 or QMGR3. >How do you make those definations on a QMGR so they get into the Channel >Table Or do I need to define a seperate named channel on each QMGR?? > > >bobbee > >_ >Have fun customizing MSN Messenger learn how here! >http://www.msnmessenger-download.com/tracking/reach_customize > >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 _ Enjoy the holiday season with great tips from MSN. http://special.msn.com/network/happyholidays.armx Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Client Connection
What I have tried, just in case this was missed, is to go to MQ Explorer and I go to Client Connections under Advanced. I then try to create a SYSTEM.ADMIN.SVRCONN client connection for ALL my QMGRS (QMGR1, QMGR2 and QMGR3). The first one works but the second one does not because the name exist already. What I believe is going on here is that I need to define a seperate named SVRCONN channel on each QMGR (eg QMGR1.CLIENT, QMGR2.CLIENT, QMGR3.CLIENT) and then create the Client Channels with the same names. SO what I am seeing here, and somebody please correct me if I am wrong, while I can go to the MQSERVER environment variable and JUST change the connection name and REUSE the same channel on each QMGR (eg SYSTEM.ADMIN.SVRCONN) using the client channel tables I must define seperate named SVRCONN channels to get the individual entries into the channel table because the table is KEYED off the name field. If I got this right then permit me to stick my neck out. THIS SUCKS!! (Sorry if I am echoing past experiences) bobbee From: Ruzi R <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Client Connection Date: Wed, 17 Dec 2003 10:38:29 -0800 Bobbee, In addition to what has been already said, we define all the client connection channels (same or different name) on the same queue manager in mainframe. Then we run a CSQUTIL job with the MAKECLNT option...to extract the CLNTCONN channel definitons (you can be specific here as to which ones you want), and download this file to any server we want. This file becomes your channel table. Make sure that you define the corresponding SVRCONN channels on the server. Best regards, Ruzi --- Gary Ward <[EMAIL PROTECTED]> wrote: > Bobbee, > > Make all the CLNTCONN definitions on ONE qmgr and > specify the QMNAME > parameter on each definition with one of your 3 > qmgrs and their particular > IP address/port in the CONNAME. This will place all > 3 definitions in the > table on that queue manager's server. Then place a > SVRCONN on each of your > 3 qmgrs using the same name (CLIENTCONN.CHANNEL). > > This requires that your application use a qmgr name > in the MQCONN... > > Happy Holidays.. Make sure you take some days off! > Gary > > -Original Message- > From: MQSeries List > [mailto:[EMAIL PROTECTED] Behalf Of Robert > Broderick > Sent: Wednesday, December 17, 2003 12:19 PM > To: [EMAIL PROTECTED] > Subject: Client Connection > > > Using the MQSERVER variable and a generic named > channel all I have to do is > change the connection information to achieve a > connection to a new server if > I wanted one. > > Using a Client Channel Table how would I get a > client to connect throught > say a channel named CLIENTCONN.CHANNEL to either > QMGR1 or QMGR2 or QMGR3. > How do you make those definations on a QMGR so they > get into the Channel > Table Or do I need to define a seperate named > channel on each QMGR?? > > > bobbee > > _ > Have fun customizing MSN Messenger learn how here! > http://www.msnmessenger-download.com/tracking/reach_customize > > 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 _ Enjoy the holiday season with great tips from MSN. http://special.msn.com/network/happyholidays.armx 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: Client Connection
Bobbee, In addition to what has been already said, we define all the client connection channels (same or different name) on the same queue manager in mainframe. Then we run a CSQUTIL job with the MAKECLNT option...to extract the CLNTCONN channel definitons (you can be specific here as to which ones you want), and download this file to any server we want. This file becomes your channel table. Make sure that you define the corresponding SVRCONN channels on the server. Best regards, Ruzi --- Gary Ward <[EMAIL PROTECTED]> wrote: > Bobbee, > > Make all the CLNTCONN definitions on ONE qmgr and > specify the QMNAME > parameter on each definition with one of your 3 > qmgrs and their particular > IP address/port in the CONNAME. This will place all > 3 definitions in the > table on that queue manager's server. Then place a > SVRCONN on each of your > 3 qmgrs using the same name (CLIENTCONN.CHANNEL). > > This requires that your application use a qmgr name > in the MQCONN... > > Happy Holidays.. Make sure you take some days off! > Gary > > -Original Message- > From: MQSeries List > [mailto:[EMAIL PROTECTED] Behalf Of Robert > Broderick > Sent: Wednesday, December 17, 2003 12:19 PM > To: [EMAIL PROTECTED] > Subject: Client Connection > > > Using the MQSERVER variable and a generic named > channel all I have to do is > change the connection information to achieve a > connection to a new server if > I wanted one. > > Using a Client Channel Table how would I get a > client to connect throught > say a channel named CLIENTCONN.CHANNEL to either > QMGR1 or QMGR2 or QMGR3. > How do you make those definations on a QMGR so they > get into the Channel > Table Or do I need to define a seperate named > channel on each QMGR?? > > > bobbee > > _ > Have fun customizing MSN Messenger learn how here! > http://www.msnmessenger-download.com/tracking/reach_customize > > 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: Client Connection
What I did was define on my laptop was bunch of "Client Connections" using MQ Explorer here is one. Client Connection Name - ETQARAS1 Description - Transmission Protocol - TCP/IP Queue Manager Name - ETQARAS1 Max Message Length - 4194304 Heartbeat Interval - 300 Local Communication - I the copied the AMQCLCHL.TAB file from my Windows laptop to my desktop. I then set the two environment variables for the path and file and deleted the MQSERVER environment variable. I then brought up the RFHUTILC.exe utility and specified ETQARAS1 as the QMGR I wanted to get the message from and specified the SYSTEM.DEFAULT.LOCAL.QUEUE as the queue. 2059 How does this thing know I want to connect to SYSTEM.ADMIN.SVRCONN From: Gary Ward <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Client Connection Date: Wed, 17 Dec 2003 12:29:29 -0500 Bobbee, Make all the CLNTCONN definitions on ONE qmgr and specify the QMNAME parameter on each definition with one of your 3 qmgrs and their particular IP address/port in the CONNAME. This will place all 3 definitions in the table on that queue manager's server. Then place a SVRCONN on each of your 3 qmgrs using the same name (CLIENTCONN.CHANNEL). This requires that your application use a qmgr name in the MQCONN... Happy Holidays.. Make sure you take some days off! Gary -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Robert Broderick Sent: Wednesday, December 17, 2003 12:19 PM To: [EMAIL PROTECTED] Subject: Client Connection Using the MQSERVER variable and a generic named channel all I have to do is change the connection information to achieve a connection to a new server if I wanted one. Using a Client Channel Table how would I get a client to connect throught say a channel named CLIENTCONN.CHANNEL to either QMGR1 or QMGR2 or QMGR3. How do you make those definations on a QMGR so they get into the Channel Table Or do I need to define a seperate named channel on each QMGR?? bobbee _ Have fun customizing MSN Messenger learn how here! http://www.msnmessenger-download.com/tracking/reach_customize 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 _ Enjoy the holiday season with great tips from MSN. http://special.msn.com/network/happyholidays.armx 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: Client Connection
Bobbee, I actually ended up making a call to IBM on this one the first time I encountered it. The deal is that you pick a QMgr to build your client table on and then define ALL your CLNTCONN definitions there. You can then use the generated Channel Table file at your client machines. Once you have the table file in place on the client, set your MQCHLLIB and MQCHLTAB env vars to point to the directory and file. After that, just specify QMgr name when you connect and MQ will parse the table file looking for the first entry with that name. For what it's worth, the Perl MQSeries module has classes for the Table Files that make it trivial to generate (or decode) them without a QMgr. And table files generated on one platform are portable to other platforms regardless of whether you used MQ or Perl to create them. The docs in the Perl module are quite enlightening. For example, they reveal that IBM does not do any garbage collection in the table file. If you do a lot of table file maintenance, it is best to either use the Perl module or delete the table file and use the QMgr to rebuild it from scratch (including redefining the SYSTEM.DEF.CLTCONN). HTH -- T.Rob -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 12:19 PM To: [EMAIL PROTECTED] Subject: Client Connection Using the MQSERVER variable and a generic named channel all I have to do is change the connection information to achieve a connection to a new server if I wanted one. Using a Client Channel Table how would I get a client to connect throught say a channel named CLIENTCONN.CHANNEL to either QMGR1 or QMGR2 or QMGR3. How do you make those definations on a QMGR so they get into the Channel Table Or do I need to define a seperate named channel on each QMGR?? bobbee _ Have fun customizing MSN Messenger learn how here! http://www.msnmessenger-download.com/tracking/reach_customize 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: Client Connection
http://www.mqseries.net/phpBB2/viewtopic.php?t=1732&highlight=channel+table One of my first posts to MQSeries.net when I was just an MQ baby! Let me know if there are still any questions that are not covered in this post. 2 very important details that you should not overlook (they are covered in the post). A.) Channel tables are searched alphabetically by channel name. B.) Make sure you use the same QMNAME in your MQCONN call that you used to create the CLNTCONN channels if you expect to get a match in your channel tables. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 12:19 PM To: [EMAIL PROTECTED] Subject: Client Connection Using the MQSERVER variable and a generic named channel all I have to do is change the connection information to achieve a connection to a new server if I wanted one. Using a Client Channel Table how would I get a client to connect throught say a channel named CLIENTCONN.CHANNEL to either QMGR1 or QMGR2 or QMGR3. How do you make those definations on a QMGR so they get into the Channel Table Or do I need to define a seperate named channel on each QMGR?? bobbee _ Have fun customizing MSN Messenger learn how here! http://www.msnmessenger-download.com/tracking/reach_customize Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Client Connection
Bobbee, Make all the CLNTCONN definitions on ONE qmgr and specify the QMNAME parameter on each definition with one of your 3 qmgrs and their particular IP address/port in the CONNAME. This will place all 3 definitions in the table on that queue manager's server. Then place a SVRCONN on each of your 3 qmgrs using the same name (CLIENTCONN.CHANNEL). This requires that your application use a qmgr name in the MQCONN... Happy Holidays.. Make sure you take some days off! Gary -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Robert Broderick Sent: Wednesday, December 17, 2003 12:19 PM To: [EMAIL PROTECTED] Subject: Client Connection Using the MQSERVER variable and a generic named channel all I have to do is change the connection information to achieve a connection to a new server if I wanted one. Using a Client Channel Table how would I get a client to connect throught say a channel named CLIENTCONN.CHANNEL to either QMGR1 or QMGR2 or QMGR3. How do you make those definations on a QMGR so they get into the Channel Table Or do I need to define a seperate named channel on each QMGR?? bobbee _ Have fun customizing MSN Messenger learn how here! http://www.msnmessenger-download.com/tracking/reach_customize 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
Client Connection
Using the MQSERVER variable and a generic named channel all I have to do is change the connection information to achieve a connection to a new server if I wanted one. Using a Client Channel Table how would I get a client to connect throught say a channel named CLIENTCONN.CHANNEL to either QMGR1 or QMGR2 or QMGR3. How do you make those definations on a QMGR so they get into the Channel Table Or do I need to define a seperate named channel on each QMGR?? bobbee _ Have fun customizing MSN Messenger learn how here! http://www.msnmessenger-download.com/tracking/reach_customize 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
Client connection on UNIX
I have a VB application running that is getting a 2059 error when trying to client connect to UNIX - MQV5.3 CSD05. This same app works fine when connecting to UNIX - MQV5.1 CSD05. Also we are NOT using Socket Security. The MQ version installed was NOGSKIT. Thanks, Dennis Bryngelson Phone: (763) 765-4224 Fax: (763) 765-3820 mailto:[EMAIL PROTECTED] * PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Heartbeat, Keepalive and Client Connection Timeouts
Stuart, I have an application that runs on a web server and uses PCF commands over client channels to talk with my MQ servers. When the user clicks a button or link, the web server receives the request passes to CGI, starts a process, connects to the QMgr, creates a dynamic queue, sends and receives several PCF commands, disconnects and finally paints a screen and delivers it to the user. Typically this happens in under 2 seconds. We also use Reconda's AppWatch extensively. It is architected in much the same way but uses Java and XSLT and even with those layers of overhead typically achieves 2~3 second response times. The benefit of this is that my app does not need any sophisticated logic to keep it's session alive or to recover from lost sessions. The user clicks and success or failure is reported back. It is an event-driven asynchronous model that meshes nicely with MQ's asynchronous architecture. Contrast this with the application you describe. I'm assuming you are keeping the connection open for the sake of reduced response time? But look at what you have to deal with - the connection is vulnerable to any number of network events, not the least of which is your firewall. You need to write code to detect and recover from lost connections, broken handles, etc. Your QMgr has to deal with orphaned SVRCONN channels when the sessions are killed or lost. You are working real hard to maintain a synchronous connection to an asynchronous transport layer. Then when it proves unreliable (in very predictable and expected ways), you have to try to fix it by tuning the channels, tuning the network, running traces, injecting traffic to artificially keep the session open, etc. People tend not to trust that making just-in-time connections will be reliable but the very act of keeping an idle session open for hours exposes it to all the vulnerabilities inherent in the network. This results in a net loss of reliability and requires much more sophisticated error handling in the code. Could you perhaps create the session on demand and then hold it open for only 5 or 10 minutes? This would reduce the response time during peak times but allow the channels to go idle and survive the firewall (and any other network event) during slow periods. -- T.Rob -Original Message- From: Stuart Bourne [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 09, 2003 9:53 PM To: [EMAIL PROTECTED] Subject: Heartbeat, Keepalive and Cleint Connection Timeouts Hello all, I am running MQ 5.3 on HP-UX 11i. A VB/MQ client front end on NT communicates with the qmgr via a Server Connection channel to a permanent local queue while replies to the client are via temporary dynamic queues. A process on the server sits and waits for a message with an MQGET after establishing a connection to the qmgr and opening the local queue. The client process establishes a connection to the qmgr, opens a dynamic reply queue and will then sit and wait for the operator to initiate a transaction. At this point there is no application generated traffic between client and server. The HBINT on the channel is defaulted to 300 and I have included the TCP:, KeepAlive=Yes section in the qmgr's qm.ini file. There is a firewall between the client and the server and this firewall has a one hour timeout on idle connections. Client connections are being killed by the firewall after this one hour timeout period. I do not want these sessions to be killed and thought that the HBINT and KeepAlive settings would generate traffic between client and server that would prevent the connections being deemed idle by the firewall. The comms people have put a trace on traffic between client and server and tell me that there is none. Obviously my understanding of HBINT and KeepAlive is incorrect. Can anyone first of all tell me how I can prevent my idle connections being terminated by the firewall and secondly explain exactly what HBINT and KeepAlive parameters achieve. Thanks in advance. MQ newbie. Stuart Bourne. Hansen Technologies. Australia. 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: Heartbeat, Keepalive and Client Connection Timeouts
I agree with Rick. There is no bug that I can see. Unless you do a get with
Unlimited wait during your idle times, there will be no heartbeats.
The only other way is to generate the traffic yourself, maybe by doing an
MQINQ call or something every minute. But then you are truly not idle are
you? ;-)
-Original Message-
From: Richard Brunette [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 10, 2003 10:00 AM
To: [EMAIL PROTECTED]
Subject: Re: Heartbeat, Keepalive and Client Connection Timeouts
Stuart
Correct me if I'm wrong. Your server application (whose connection is not
in question) is actively sitting on an MQGET waiting for work (as server
applications do). Your client application is going through the firewall
with a CLNTCONN/SVRCONN connection that is being broken. This client
application has already connected and has opened/created a reply queue, but
is doing no MQ work because it is waiting for an operator initiated
transaction. Correct?
It doesn't sound like a Heartbeat issue, has heartbeat cannot help your
idle CLNTCONN/SVRCONN connection for the reason Neil and Paul mention
(specifically that it will only help while your client application is in a
get with wait so that there is an active MQI call that can respond to the
heartbeat). Doesn't sound like a bug to me.
How do you fix this? I'm not sure. Maybe KeepAlive can help (I've never
fully understood Keepalive), maybe changes to your design. Certainly the
application should be prepared to deal with broken connections as Emile
suggests, but keeping it from breaking or maintaining the connection
through idle times may require additional tactics.
Rick
|-+--->
| | Neil Casey |
| | <[EMAIL PROTECTED]>|
| | |
| | Sent by: MQSeries List |
| | <[EMAIL PROTECTED]> |
| | |
| | |
| | |
| | Wednesday September 10, 2003 01:11 |
| | AM |
| | Please respond to MQSeries List |
| | |
|-+--->
>---
-|
|
|
| To:
[EMAIL PROTECTED] |
| cc:
|
| Subject: Re: Heartbeat, Keepalive and Client Connection Timeouts
|
>---
-|
It's a nice solution that only applies with Queue manager to Queue manager
channels. You can't do this sort of thing with a server connection channel,
because there is no queue manager at the other end (also no transmission
queue etc etc). It also shouldn't be necessary to do this to keep a
firewall open. Heartbeat should be able to achieve this.
Unfortunately, you look like you are having problems with Client
connections. I would have expected that you should be able to define the
HBINT on the Client connection channel and the server connection channel.
The manual says:
For channels with a channel type (CHLTYPE) of SVRCONN or
CLNTCONN, this is the time, in seconds, between heartbeat flows
passed from the server MCA when that MCA has issued an MQGET
with WAIT on behalf of a client application. This allows the
server to handle situations where the client connection fails
during an MQGET with WAIT. This type of heartbeat is valid only
for AIX, Compaq OpenVMS, HP-UX, Linux, OS/2 Warp, OS/400,
Solaris, and Windows.
So you only get heartbeats when your application is in a MQGET with wait
condition.
This is exactly what you describe for your application, so it is possible
that you are experiencing a bug (shock, horror), for which you would need
to go to IBM for support.
Regards,
Neil Casey.
|-+>
| | [EMAIL PROTECTED]|
| | .AU |
| | Sent by: MQSeries|
| | List |
| | <[EMAIL PROTECTED]|
| | n.AC.AT> |
| ||
| ||
| | 10/09/2003 13:24 |
| | Please respond to|
| | MQSeries List|
| ||
|-+>
>
--|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
Re: Heartbeat, Keepalive and Client Connection Timeouts
Stuart
Correct me if I'm wrong. Your server application (whose connection is not
in question) is actively sitting on an MQGET waiting for work (as server
applications do). Your client application is going through the firewall
with a CLNTCONN/SVRCONN connection that is being broken. This client
application has already connected and has opened/created a reply queue, but
is doing no MQ work because it is waiting for an operator initiated
transaction. Correct?
It doesn't sound like a Heartbeat issue, has heartbeat cannot help your
idle CLNTCONN/SVRCONN connection for the reason Neil and Paul mention
(specifically that it will only help while your client application is in a
get with wait so that there is an active MQI call that can respond to the
heartbeat). Doesn't sound like a bug to me.
How do you fix this? I'm not sure. Maybe KeepAlive can help (I've never
fully understood Keepalive), maybe changes to your design. Certainly the
application should be prepared to deal with broken connections as Emile
suggests, but keeping it from breaking or maintaining the connection
through idle times may require additional tactics.
Rick
|-+--->
| | Neil Casey |
| | <[EMAIL PROTECTED]>|
| | |
| | Sent by: MQSeries List |
| | <[EMAIL PROTECTED]> |
| | |
| | |
| | |
| | Wednesday September 10, 2003 01:11 |
| | AM |
| | Please respond to MQSeries List |
| | |
|-+--->
>|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Heartbeat, Keepalive and Client Connection Timeouts
|
>|
It's a nice solution that only applies with Queue manager to Queue manager
channels. You can't do this sort of thing with a server connection channel,
because there is no queue manager at the other end (also no transmission
queue etc etc). It also shouldn't be necessary to do this to keep a
firewall open. Heartbeat should be able to achieve this.
Unfortunately, you look like you are having problems with Client
connections. I would have expected that you should be able to define the
HBINT on the Client connection channel and the server connection channel.
The manual says:
For channels with a channel type (CHLTYPE) of SVRCONN or
CLNTCONN, this is the time, in seconds, between heartbeat flows
passed from the server MCA when that MCA has issued an MQGET
with WAIT on behalf of a client application. This allows the
server to handle situations where the client connection fails
during an MQGET with WAIT. This type of heartbeat is valid only
for AIX, Compaq OpenVMS, HP-UX, Linux, OS/2 Warp, OS/400,
Solaris, and Windows.
So you only get heartbeats when your application is in a MQGET with wait
condition.
This is exactly what you describe for your application, so it is possible
that you are experiencing a bug (shock, horror), for which you would need
to go to IBM for support.
Regards,
Neil Casey.
|-+>
| | [EMAIL PROTECTED]|
| | .AU |
| | Sent by: MQSeries|
| | List |
| | <[EMAIL PROTECTED]|
| | n.AC.AT> |
| ||
| ||
| | 10/09/2003 13:24 |
| | Please respond to|
| | MQSeries List|
| ||
|-+>
>
--|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Heartbeat, Keepalive and Client Connection Timeouts
|
>
--|
Nice solution.
Sid
-Original Message-
Re: Heartbeat, Keepalive and Client Connection Timeouts
As Neil has said, maybe it is a bug, HBINT should do the trick.
In the mean time, code the application so that when you get a 2009, do a
re-connect to the QMGR in that way you can re-establish a connection again,
I think that may work as a work around.
But I would take it up with IBM.
-Original Message-
From: Neil Casey [mailto:[EMAIL PROTECTED]
Sent: 10 September 2003 08:11 AM
To: [EMAIL PROTECTED]
Subject: Re: Heartbeat, Keepalive and Client Connection Timeouts
It's a nice solution that only applies with Queue manager to Queue manager
channels. You can't do this sort of thing with a server connection channel,
because there is no queue manager at the other end (also no transmission
queue etc etc). It also shouldn't be necessary to do this to keep a
firewall open. Heartbeat should be able to achieve this.
Unfortunately, you look like you are having problems with Client
connections. I would have expected that you should be able to define the
HBINT on the Client connection channel and the server connection channel.
The manual says:
For channels with a channel type (CHLTYPE) of SVRCONN or
CLNTCONN, this is the time, in seconds, between heartbeat flows
passed from the server MCA when that MCA has issued an MQGET
with WAIT on behalf of a client application. This allows the
server to handle situations where the client connection fails
during an MQGET with WAIT. This type of heartbeat is valid only
for AIX, Compaq OpenVMS, HP-UX, Linux, OS/2 Warp, OS/400,
Solaris, and Windows.
So you only get heartbeats when your application is in a MQGET with wait
condition.
This is exactly what you describe for your application, so it is possible
that you are experiencing a bug (shock, horror), for which you would need
to go to IBM for support.
Regards,
Neil Casey.
|-+>
| | [EMAIL PROTECTED]|
| | .AU |
| | Sent by: MQSeries|
| | List |
| | <[EMAIL PROTECTED]|
| | n.AC.AT> |
| ||
| ||
| | 10/09/2003 13:24 |
| | Please respond to|
| | MQSeries List|
| ||
|-+>
>---
---|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Heartbeat, Keepalive and Client Connection Timeouts
|
>---
---|
Nice solution.
Sid
-Original Message-
From: McCarty, Brian [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 10 September 2003 12:24 PM
To: [EMAIL PROTECTED]
Subject: Re: Heartbeat, Keepalive and Client Connection Timeouts
Is there a reply q back to your local queue manager? If so, just create a
remote q definition on your server that points to a queue on the remote
server that does not actually exist. Make the message a request message
with the discard option set asking for a report message. The report
message
will keep their/sender - your/receiver running. If that's not needed, just
take off the report message option. In Java it would look like this:
message = new MQMessage();
pmo.options = MQC.MQPMO_FAIL_IF_QUIESCING
| MQC.MQPER_NOT_PERSISTENT;
byte b[] = new byte[24];
Random r = new Random();
r.nextBytes(b);
message.correlationId = (b);
message.expiry = 5;
message.report = MQC.MQRO_EXCEPTION_WITH_FULL_DATA
| MQC.MQRO_PASS_MSG_ID
| MQC.MQRO_PASS_CORREL_ID
| MQC.MQRO_DISCARD_MSG; message.replyToQueueManagerName =
"SOME_OTHER_QUEUE_MANAGER"; message.replyToQueueName = "SOME_OTHER_QUEUE";
message.messageType = MQC.MQMT_REQUEST; try {
request_queue.put(message, pmo);
}
If you want to route the report message elsewhere, just set the
replyToQueue* fields also.
B
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 09, 2003 9:00 PM
To: [EMAIL PROTECTED]
Subject: Re: Heartbeat, Keepalive and Cleint Connection Timeouts
Pump data to another queue and have a process to drop it somewhere.
Sid
-Original Message-
From: Stuart Bourne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 10 September 2003 11:53 AM
To: [EMAIL PROTECTED]
Subject: Heartbeat, Keepalive and Cleint Connection Timeouts
Hello all,
I am running MQ 5.3 on HP-UX 11i. A VB/MQ client front end on NT
communicates with the qmgr via a Server Connection channel to a permanent
local queue while replies to the client are via temporary dynamic queues. A
process on t
Re: Heartbeat, Keepalive and Client Connection Timeouts
It's a nice solution that only applies with Queue manager to Queue manager
channels. You can't do this sort of thing with a server connection channel,
because there is no queue manager at the other end (also no transmission
queue etc etc). It also shouldn't be necessary to do this to keep a
firewall open. Heartbeat should be able to achieve this.
Unfortunately, you look like you are having problems with Client
connections. I would have expected that you should be able to define the
HBINT on the Client connection channel and the server connection channel.
The manual says:
For channels with a channel type (CHLTYPE) of SVRCONN or
CLNTCONN, this is the time, in seconds, between heartbeat flows
passed from the server MCA when that MCA has issued an MQGET
with WAIT on behalf of a client application. This allows the
server to handle situations where the client connection fails
during an MQGET with WAIT. This type of heartbeat is valid only
for AIX, Compaq OpenVMS, HP-UX, Linux, OS/2 Warp, OS/400,
Solaris, and Windows.
So you only get heartbeats when your application is in a MQGET with wait
condition.
This is exactly what you describe for your application, so it is possible
that you are experiencing a bug (shock, horror), for which you would need
to go to IBM for support.
Regards,
Neil Casey.
|-+>
| | [EMAIL PROTECTED]|
| | .AU |
| | Sent by: MQSeries|
| | List |
| | <[EMAIL PROTECTED]|
| | n.AC.AT> |
| ||
| ||
| | 10/09/2003 13:24 |
| | Please respond to|
| | MQSeries List|
| ||
|-+>
>--|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Heartbeat, Keepalive and Client Connection Timeouts
|
>--|
Nice solution.
Sid
-Original Message-
From: McCarty, Brian [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 10 September 2003 12:24 PM
To: [EMAIL PROTECTED]
Subject: Re: Heartbeat, Keepalive and Client Connection Timeouts
Is there a reply q back to your local queue manager? If so, just create a
remote q definition on your server that points to a queue on the remote
server that does not actually exist. Make the message a request message
with the discard option set asking for a report message. The report
message
will keep their/sender - your/receiver running. If that's not needed, just
take off the report message option. In Java it would look like this:
message = new MQMessage();
pmo.options = MQC.MQPMO_FAIL_IF_QUIESCING
| MQC.MQPER_NOT_PERSISTENT;
byte b[] = new byte[24];
Random r = new Random();
r.nextBytes(b);
message.correlationId = (b);
message.expiry = 5;
message.report = MQC.MQRO_EXCEPTION_WITH_FULL_DATA
| MQC.MQRO_PASS_MSG_ID
| MQC.MQRO_PASS_CORREL_ID
| MQC.MQRO_DISCARD_MSG; message.replyToQueueManagerName =
"SOME_OTHER_QUEUE_MANAGER"; message.replyToQueueName = "SOME_OTHER_QUEUE";
message.messageType = MQC.MQMT_REQUEST; try {
request_queue.put(message, pmo);
}
If you want to route the report message elsewhere, just set the
replyToQueue* fields also.
B
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 09, 2003 9:00 PM
To: [EMAIL PROTECTED]
Subject: Re: Heartbeat, Keepalive and Cleint Connection Timeouts
Pump data to another queue and have a process to drop it somewhere.
Sid
-Original Message-
From: Stuart Bourne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 10 September 2003 11:53 AM
To: [EMAIL PROTECTED]
Subject: Heartbeat, Keepalive and Cleint Connection Timeouts
Hello all,
I am running MQ 5.3 on HP-UX 11i. A VB/MQ client front end on NT
communicates with the qmgr via a Server Connection channel to a permanent
local queue while replies to the client are via temporary dynamic queues. A
process on the server sits and waits for a message with an MQGET after
establishing a connection to the qmgr and opening the local queue. The
client process establishes a co
Re: Heartbeat, Keepalive and Client Connection Timeouts
Nice solution.
Sid
-Original Message-
From: McCarty, Brian [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 10 September 2003 12:24 PM
To: [EMAIL PROTECTED]
Subject: Re: Heartbeat, Keepalive and Client Connection Timeouts
Is there a reply q back to your local queue manager? If so, just create a
remote q definition on your server that points to a queue on the remote
server that does not actually exist. Make the message a request message
with the discard option set asking for a report message. The report message
will keep their/sender - your/receiver running. If that's not needed, just
take off the report message option. In Java it would look like this:
message = new MQMessage();
pmo.options = MQC.MQPMO_FAIL_IF_QUIESCING
| MQC.MQPER_NOT_PERSISTENT;
byte b[] = new byte[24];
Random r = new Random();
r.nextBytes(b);
message.correlationId = (b);
message.expiry = 5;
message.report = MQC.MQRO_EXCEPTION_WITH_FULL_DATA
| MQC.MQRO_PASS_MSG_ID
| MQC.MQRO_PASS_CORREL_ID
| MQC.MQRO_DISCARD_MSG; message.replyToQueueManagerName =
"SOME_OTHER_QUEUE_MANAGER"; message.replyToQueueName = "SOME_OTHER_QUEUE";
message.messageType = MQC.MQMT_REQUEST; try {
request_queue.put(message, pmo);
}
If you want to route the report message elsewhere, just set the
replyToQueue* fields also.
B
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 09, 2003 9:00 PM
To: [EMAIL PROTECTED]
Subject: Re: Heartbeat, Keepalive and Cleint Connection Timeouts
Pump data to another queue and have a process to drop it somewhere.
Sid
-Original Message-
From: Stuart Bourne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 10 September 2003 11:53 AM
To: [EMAIL PROTECTED]
Subject: Heartbeat, Keepalive and Cleint Connection Timeouts
Hello all,
I am running MQ 5.3 on HP-UX 11i. A VB/MQ client front end on NT
communicates with the qmgr via a Server Connection channel to a permanent
local queue while replies to the client are via temporary dynamic queues. A
process on the server sits and waits for a message with an MQGET after
establishing a connection to the qmgr and opening the local queue. The
client process establishes a connection to the qmgr, opens a dynamic reply
queue and will then sit and wait for the operator to initiate a transaction.
At this point there is no application generated traffic between client and
server. The HBINT on the channel is defaulted to 300 and I have included the
TCP:, KeepAlive=Yes section in the qmgr's qm.ini file. There is a firewall
between the client and the server and this firewall has a one hour timeout
on idle connections. Client connections are being killed by the firewall
after this one hour timeout period. I do not want these sessions to be
killed and thought that the HBINT and KeepAlive settings would generate
traffic between client and server that would prevent the connections being
deemed idle by the firewall. The comms people have put a trace on traffic
between client and server and tell me that there is none. Obviously my
understanding of HBINT and KeepAlive is incorrect. Can anyone first of all
tell me how I can prevent my idle connections being terminated by the
firewall and secondly explain exactly what HBINT and KeepAlive parameters
achieve. Thanks in advance. MQ newbie. Stuart Bourne. Hansen Technologies.
Australia.
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
Re: Heartbeat, Keepalive and Client Connection Timeouts
Is there a reply q back to your local queue manager? If so, just create a remote q
definition on your server that points to a queue on the remote server that does not
actually exist. Make the message a request message with the discard option set asking
for a report message. The report message will keep their/sender - your/receiver
running. If that's not needed, just take off the report message option. In Java it
would look like this:
message = new MQMessage();
pmo.options = MQC.MQPMO_FAIL_IF_QUIESCING
| MQC.MQPER_NOT_PERSISTENT;
byte b[] = new byte[24];
Random r = new Random();
r.nextBytes(b);
message.correlationId = (b);
message.expiry = 5;
message.report = MQC.MQRO_EXCEPTION_WITH_FULL_DATA
| MQC.MQRO_PASS_MSG_ID
| MQC.MQRO_PASS_CORREL_ID
| MQC.MQRO_DISCARD_MSG;
message.replyToQueueManagerName = "SOME_OTHER_QUEUE_MANAGER";
message.replyToQueueName = "SOME_OTHER_QUEUE";
message.messageType = MQC.MQMT_REQUEST;
try
{
request_queue.put(message, pmo);
}
If you want to route the report message elsewhere, just set the replyToQueue* fields
also.
B
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 09, 2003 9:00 PM
To: [EMAIL PROTECTED]
Subject: Re: Heartbeat, Keepalive and Cleint Connection Timeouts
Pump data to another queue and have a process to drop it somewhere.
Sid
-Original Message-
From: Stuart Bourne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 10 September 2003 11:53 AM
To: [EMAIL PROTECTED]
Subject: Heartbeat, Keepalive and Cleint Connection Timeouts
Hello all,
I am running MQ 5.3 on HP-UX 11i. A VB/MQ client front end on NT
communicates with the qmgr via a Server Connection channel to a permanent
local queue while replies to the client are via temporary dynamic queues. A
process on the server sits and waits for a message with an MQGET after
establishing a connection to the qmgr and opening the local queue. The
client process establishes a connection to the qmgr, opens a dynamic reply
queue and will then sit and wait for the operator to initiate a transaction.
At this point there is no application generated traffic between client and
server. The HBINT on the channel is defaulted to 300 and I have included the
TCP:, KeepAlive=Yes section in the qmgr's qm.ini file. There is a firewall
between the client and the server and this firewall has a one hour timeout
on idle connections. Client connections are being killed by the firewall
after this one hour timeout period. I do not want these sessions to be
killed and thought that the HBINT and KeepAlive settings would generate
traffic between client and server that would prevent the connections being
deemed idle by the firewall. The comms people have put a trace on traffic
between client and server and tell me that there is none. Obviously my
understanding of HBINT and KeepAlive is incorrect. Can anyone first of all
tell me how I can prevent my idle connections being terminated by the
firewall and secondly explain exactly what HBINT and KeepAlive parameters
achieve. Thanks in advance. MQ newbie. Stuart Bourne. Hansen Technologies.
Australia.
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
Why cannot use Client connection?
Hi all, We are using MQ JMS to to communicate with PeopleSoft. The JMS connectors/PeopleSoft and Queue manager are all on the same server. So I thought the JMS Connecters should use "BIND" connection instead of "CLIENT" that they were using. So, I created the ".bindigs" file with TRANSPORT(BIND). But the JMS developers claim that (in their own words) "Peoplesoft JMS connector cannot handle the BIND type connection." Is this a JMS limitation? Or is there something else that we are missing in the set up. Your help would be much appreciated. Thanks, Ruzi 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: Why got RC 2035 from a client connection after a setmqaut +al lmqi
Check on the server for an 8077 message. It will tell you what userid was rejected. Maybe the USER1 userID has to be qualified with additional info. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 10:41 AM To: [EMAIL PROTECTED] Subject: Why got RC 2035 from a client connection after a setmqaut +allmqi Platform is MQ 5.3 CSD 03 on NT. Qmgr QM1 exists on a remote machine (Mac1) and it has the local queue MYQUEUE. I am trying some testing with a new userid called USER1. I did not put it in the mqm group, because I don t want it to have access to everything. Here is the sequence of steps I did: 1. I set the MQSERVER env. Variable (on the Advanced tab of System folder ): SET MQSERVER= MY.SVRCONN/TCP/Mac1(1414) 2- I signed on to the machine Mac1 3- Defined a svrconn channel: MY.SVRCONN ( with MCAUSER set to blanks) 4- Issued Setmqaut m QM1 t queue n MYQUEU p USER1 +allmqi 5- runmqsc QM1 REFRESH SECURITY 6- dspmqaut m QM1 t queue n MYQUEU p USER1 This displayed all the authorized MQI calls for this userid 7- I signed on to my machine as USER1 8- amqsputc MYQUEUE QM1 I got 2035 error (MQRC_Not_Authorized error ). How come? Since the MCAUSER attrib of the SVRCONN is blank I tought it would use the NT sign on userid which is USER1 which is given the individualized authority as shown in step 4. How could this be explained? Of course, if I put the USER1 in the mqm group it works. But, why do I have to put USER1 in the mqm group if I don t want it to have full authority over all the MQ resources? I would appreciate your input. Thanks, Ruzi 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: Why got RC 2035 from a client connection after a setmqaut +allmqi-RESOLVED
You were forced to issue "REFRESH SECURITY" because the userid that you added on the remote end was added for the first time. Once you added this, you would NEVER need to issue "REFRESH SECURITY" if you issue setmqaut commands on this qm for this particular principal/userid. Cheers Kumar ---Original Message--- From: MQSeries List Date: Wednesday, July 02, 2003 04:36:46 PM To: [EMAIL PROTECTED] Subject: Re: Why got RC 2035 from a client connection after a setmqaut +allmqi-RESOLVED I did, and it has "connect"... However, I did "REFRESH SECURITY" to refresh the cach again and it worked. I vaguely remember that if a userid gets a 2035, it will be cached and stay until a "refresh security" is issued. That would explain my problem... Thanks, Ruzi --- Jim Ford <[EMAIL PROTECTED]> wrote: > Did you authorize USER1 to connect to the queue > manager? Do a > > dspmqaut -t qmgr -m QM1 -p USER1 > > and let us know what you see. > > > > > Ruzi R > <[EMAIL PROTECTED] To: > [EMAIL PROTECTED] > M> cc: > Sent by: MQSeries > Subject: Why got RC 2035 from a client connection > after a setmqaut > List > +allmqi > <[EMAIL PROTECTED] > N.AC.AT> > > > 07/02/2003 12:40 > PM > Please respond to > MQSeries List > > > > > > > Platform is MQ 5.3 CSD 03 on NT. Qmgr QM1 exists on > a > remote machine (Mac1) and it has the local queue > MYQUEUE. > > I am trying some testing with a new userid called > USER1. I did not put it in the mqm group, because I > don t want it to have access to everything. > > Here is the sequence of steps I did: > 1. I set the MQSERVER env. Variable (on the > Advanced > tab of System folder ): > SET MQSERVER= MY.SVRCONN/TCP/Mac1(1414) > > 2- I signed on to the machine Mac1 > > 3- Defined a svrconn channel: MY.SVRCONN ( with > MCAUSER set to blanks) > > 4- Issued Setmqaut m QM1 t queue n MYQUEU p > USER1 > +allmqi > > 5- runmqsc QM1 > REFRESH SECURITY > > 6- dspmqaut m QM1 t queue n MYQUEU p USER1 > This displayed all the authorized MQI calls for > this userid > > 7- I signed on to my machine as USER1 > > 8- amqsputc MYQUEUE QM1 > > I got 2035 error (MQRC_Not_Authorized error ). How > come? Since the MCAUSER attrib of the SVRCONN is > blank > I tought it would use the NT sign on userid which is > USER1 which is given the individualized authority as > shown in step 4. How could this be explained? Of > course, if I put the USER1 in the mqm group it > works. > But, why do I have to put USER1 in the mqm group if > I > don t want it to have full authority over all the MQ > resources? > > I would appreciate your input. > > Thanks, > > Ruzi > > 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 . IncrediMail - Email has finally evolved - Click Here
Re: Why got RC 2035 from a client connection after a setmqaut +allmqi-RESOLVED
I did, and it has "connect"... However, I did "REFRESH SECURITY" to refresh the cach again and it worked. I vaguely remember that if a userid gets a 2035, it will be cached and stay until a "refresh security" is issued. That would explain my problem... Thanks, Ruzi --- Jim Ford <[EMAIL PROTECTED]> wrote: > Did you authorize USER1 to connect to the queue > manager? Do a > > dspmqaut -t qmgr -m QM1 -p USER1 > > and let us know what you see. > > > > > Ruzi R > <[EMAIL PROTECTED]To: > [EMAIL PROTECTED] > M> cc: > Sent by: MQSeries > Subject: Why got RC 2035 from a client connection > after a setmqaut > List > +allmqi > <[EMAIL PROTECTED] > N.AC.AT> > > > 07/02/2003 12:40 > PM > Please respond to > MQSeries List > > > > > > > Platform is MQ 5.3 CSD 03 on NT. Qmgr QM1 exists on > a > remote machine (Mac1) and it has the local queue > MYQUEUE. > > I am trying some testing with a new userid called > USER1. I did not put it in the mqm group, because I > don t want it to have access to everything. > > Here is the sequence of steps I did: > 1. I set the MQSERVER env. Variable (on the > Advanced > tab of System folder ): > SET MQSERVER= MY.SVRCONN/TCP/Mac1(1414) > > 2- I signed on to the machine Mac1 > > 3- Defined a svrconn channel: MY.SVRCONN ( with > MCAUSER set to blanks) > > 4- Issued Setmqaut m QM1 t queue n MYQUEU p > USER1 > +allmqi > > 5- runmqsc QM1 > REFRESH SECURITY > > 6- dspmqaut m QM1 t queue n MYQUEU p USER1 >This displayed all the authorized MQI calls for > this userid > > 7- I signed on to my machine as USER1 > > 8- amqsputc MYQUEUE QM1 > > I got 2035 error (MQRC_Not_Authorized error ). How > come? Since the MCAUSER attrib of the SVRCONN is > blank > I tought it would use the NT sign on userid which is > USER1 which is given the individualized authority as > shown in step 4. How could this be explained? Of > course, if I put the USER1 in the mqm group it > works. > But, why do I have to put USER1 in the mqm group if > I > don t want it to have full authority over all the MQ > resources? > > I would appreciate your input. > > Thanks, > > Ruzi > > 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: Why got RC 2035 from a client connection after a setmqaut +allmqi
Did you authorize USER1 to connect to the queue manager? Do a dspmqaut -t qmgr -m QM1 -p USER1 and let us know what you see. Ruzi R <[EMAIL PROTECTED]To: [EMAIL PROTECTED] M> cc: Sent by: MQSeriesSubject: Why got RC 2035 from a client connection after a setmqaut List +allmqi <[EMAIL PROTECTED] N.AC.AT> 07/02/2003 12:40 PM Please respond to MQSeries List Platform is MQ 5.3 CSD 03 on NT. Qmgr QM1 exists on a remote machine (Mac1) and it has the local queue MYQUEUE. I am trying some testing with a new userid called USER1. I did not put it in the mqm group, because I don t want it to have access to everything. Here is the sequence of steps I did: 1. I set the MQSERVER env. Variable (on the Advanced tab of System folder ): SET MQSERVER= MY.SVRCONN/TCP/Mac1(1414) 2- I signed on to the machine Mac1 3- Defined a svrconn channel: MY.SVRCONN ( with MCAUSER set to blanks) 4- Issued Setmqaut m QM1 t queue n MYQUEU p USER1 +allmqi 5- runmqsc QM1 REFRESH SECURITY 6- dspmqaut m QM1 t queue n MYQUEU p USER1 This displayed all the authorized MQI calls for this userid 7- I signed on to my machine as USER1 8- amqsputc MYQUEUE QM1 I got 2035 error (MQRC_Not_Authorized error ). How come? Since the MCAUSER attrib of the SVRCONN is blank I tought it would use the NT sign on userid which is USER1 which is given the individualized authority as shown in step 4. How could this be explained? Of course, if I put the USER1 in the mqm group it works. But, why do I have to put USER1 in the mqm group if I don t want it to have full authority over all the MQ resources? I would appreciate your input. Thanks, Ruzi 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
Why got RC 2035 from a client connection after a setmqaut +allmqi
Platform is MQ 5.3 CSD 03 on NT. Qmgr QM1 exists on a remote machine (Mac1) and it has the local queue MYQUEUE. I am trying some testing with a new userid called USER1. I did not put it in the mqm group, because I don t want it to have access to everything. Here is the sequence of steps I did: 1. I set the MQSERVER env. Variable (on the Advanced tab of System folder ): SET MQSERVER= MY.SVRCONN/TCP/Mac1(1414) 2- I signed on to the machine Mac1 3- Defined a svrconn channel: MY.SVRCONN ( with MCAUSER set to blanks) 4- Issued Setmqaut m QM1 t queue n MYQUEU p USER1 +allmqi 5- runmqsc QM1 REFRESH SECURITY 6- dspmqaut m QM1 t queue n MYQUEU p USER1 This displayed all the authorized MQI calls for this userid 7- I signed on to my machine as USER1 8- amqsputc MYQUEUE QM1 I got 2035 error (MQRC_Not_Authorized error ). How come? Since the MCAUSER attrib of the SVRCONN is blank I tought it would use the NT sign on userid which is USER1 which is given the individualized authority as shown in step 4. How could this be explained? Of course, if I put the USER1 in the mqm group it works. But, why do I have to put USER1 in the mqm group if I don t want it to have full authority over all the MQ resources? I would appreciate your input. Thanks, Ruzi 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: Client Connection changed to Server Connection
Thanks Stefan and Ruzi for your answer, but the problem here is , if the application which has ALREADY SUCCESFULLY connected as a client, wants to now connect as a server , will it cause an error and what type of error Regards, Franklin Hi Franklin, In addition to what Stefan said... Since you want the program "to connect as a server", all you have to do is compile your program with the server libraries. Ruzi --- Stefan Sievert <[EMAIL PROTECTED]> wrote: > Franklin, > if your application is compiled code that is linked > with the MQ client > libraries, it may run without any error locally to a > queue manager if either > MQSERVER or MQCHLTAB is defined and available. If > they are not, I assume it > will just return a reason code of 2059 during MQCONN > processing, just like > it would on a remote client that isn't set up > properly. > HTH, > Stefan > > >From: franklin dcosta <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Client Connection changed to Server > Connection > >Date: Wed, 28 May 2003 14:58:15 +0100 > > > >HI Friends, > > A small question for you all, if an application > >connected as a client , is moved , to connect as a > >server, will it give an error and what type of > error? > >Regards, > >Franklin > > > >__ > >Yahoo! Plus - For a better Internet experience > >http://uk.promotions.yahoo.com/yplus/yoffer.html > > > >Instructions for managing your mailing list > subscription are provided in > >the Listserv General Users Guide available at > http://www.lsoft.com > >Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > _ > Tired of spam? Get advanced junk mail protection > with MSN 8. > http://join.msn.com/?page=features/junkmail > > 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 __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html 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: Client Connection changed to Server Connection
Hi Franklin, In addition to what Stefan said... Since you want the program "to connect as a server", all you have to do is compile your program with the server libraries. Ruzi --- Stefan Sievert <[EMAIL PROTECTED]> wrote: > Franklin, > if your application is compiled code that is linked > with the MQ client > libraries, it may run without any error locally to a > queue manager if either > MQSERVER or MQCHLTAB is defined and available. If > they are not, I assume it > will just return a reason code of 2059 during MQCONN > processing, just like > it would on a remote client that isn't set up > properly. > HTH, > Stefan > > >From: franklin dcosta <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Client Connection changed to Server > Connection > >Date: Wed, 28 May 2003 14:58:15 +0100 > > > >HI Friends, > > A small question for you all, if an application > >connected as a client , is moved , to connect as a > >server, will it give an error and what type of > error? > >Regards, > >Franklin > > > >__ > >Yahoo! Plus - For a better Internet experience > >http://uk.promotions.yahoo.com/yplus/yoffer.html > > > >Instructions for managing your mailing list > subscription are provided in > >the Listserv General Users Guide available at > http://www.lsoft.com > >Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > _ > Tired of spam? Get advanced junk mail protection > with MSN 8. > http://join.msn.com/?page=features/junkmail > > 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: Client Connection changed to Server Connection
Franklin, if your application is compiled code that is linked with the MQ client libraries, it may run without any error locally to a queue manager if either MQSERVER or MQCHLTAB is defined and available. If they are not, I assume it will just return a reason code of 2059 during MQCONN processing, just like it would on a remote client that isn't set up properly. HTH, Stefan From: franklin dcosta <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Client Connection changed to Server Connection Date: Wed, 28 May 2003 14:58:15 +0100 HI Friends, A small question for you all, if an application connected as a client , is moved , to connect as a server, will it give an error and what type of error? Regards, Franklin __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail 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: Client Connection changed to Server Connection
For a c/c++ application you must re-link the application if you want to change access from client to server. If you move a client to a server machine where the client portion is not installed you will get an error. Francois van der Merwe Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert & Developer IBM, Cape Town, South Africa +27 (0)82 556 9467 / +27 (0)21 402 5597 [EMAIL PROTECTED] franklin dcosta <[EMAIL PROTECTED]To: [EMAIL PROTECTED] M> cc: Sent by: MQSeriesSubject: Client Connection changed to Server Connection List <[EMAIL PROTECTED] N.AC.AT> 28/05/2003 15:58 Please respond to MQSeries List HI Friends, A small question for you all, if an application connected as a client , is moved , to connect as a server, will it give an error and what type of error? Regards, Franklin __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html 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
Client Connection changed to Server Connection
HI Friends, A small question for you all, if an application connected as a client , is moved , to connect as a server, will it give an error and what type of error? Regards, Franklin __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html 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: Client connection Table question
Use a couple of gateway machines into a cluster as per my reply to Frank Laurijssens about clustering assuming any one gateway machine can handle the message redirection you dont need to worry about disconnecting. Overall load will rebalance slowly but surely as clients disconnect and reconnect through normal operations. Regards Tim A Francois van der MerweTo: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: BM.COM> Subject: Client connection Table question Sent by: MQSeries List <[EMAIL PROTECTED] N.AC.AT> 27/03/2003 16:30 Please respond to MQSeries List Scenario description: Two MQ servers, MQ1 & MQ2, both with the same queues to act as a backup for each other and load balancing. Two client connection tables, one with MQ1 in first row and MQ2 in second row, and the second CCT with MQ2 in the first row and MQ1 in the second row. By default the CCTs get equal share between MQ client machines, so that when the clients connect to its "closest" queue manager, then about half of the clients will connect to MQ1 and the other half will connect to MQ2. This setup works ok for when any one of the queue manager boxes fails, because the client will get an error, redo the connect and then use the "backup" queue manager. Question 1: When there was a failure on QM2 and all the clients are now connected to QM1, what is the best way of "reconnecting" to original queue manager when QM2 is alive again if client applications are long running and high volume? Option 1: Disconnect from time to time so that if there was a failover it will be fixed after a while. Option 2: Try and connect from time to time and when qmgr names are different from 2 connections, disconnect both and reconnect. Option 3: Some control message that all clients must watch out for to tell them to disconnect and reconnect. Option 4: Other Question 2: Same scenario as above, just that many clients are now running on the same machine, but connecting to different queue managers (maybe in a cluster). Option 1 to Option 4 the same. Option 5: A trigger monitor to help with the client starts and stops. Thanks a lot. Francois van der Merwe Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert & Developer 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: HP CLIENT CONNECTION to Mainframe
Tim,
Thank you so much for the information. I truly
appriciate it. I am going to try it.
--- Tim Armstrong <[EMAIL PROTECTED]> wrote:
> To check the availability of the MQSERVER variable
> do a getenv() call in
> your program if its C.
>
> You can use MQCONNX instead of MQCONN and fill out
> the MQCD and MQCON
> structures as shown in the following code excerpt.
>
> MQCNO connectOpts = {MQCNO_DEFAULT};
> MQCDclientDef =
> {MQCD_CLIENT_CONN_DEFAULT};
>
> strncpy(clientDef.ConnectionName, connName,
> MQ_CONN_NAME_LENGTH);
> strncpy(clientDef.ChannelName, channelName,
> MQ_CHANNEL_NAME_LENGTH);
>
> connectOpts.ClientConnPtr = &clientDef;
> connectOpts.Version = MQCNO_VERSION_2;
>
>
>
MQCONNX(qMgrName,&connectOpts,&hConn,&compCode,&reasonCode);
>
> Regards
> Tim A
>
>
>
> nushin mehran
> <[EMAIL PROTECTED]>To:
> [EMAIL PROTECTED]
> Sent by: MQSeriescc:
> List
> Subject: HP CLIENT CONNECTION to Mainframe
> <[EMAIL PROTECTED]
> N.AC.AT>
>
>
> 25/03/2003 11:23
> Please respond to
> MQSeries List
>
>
>
>
>
> Can any body tell me why an standalone MQ program
> in a HP v11 enviroment connects successfully to
> mainframe using MQSERVER, but as soon as I include
> it
> in another program and use it as procedure call
> stops at MQCONN and returns error 2058(Queue Manager
> not known). Can we have the MQSERVER coded in the
> program ?. It looks like that can not find the
> MQSERVER parms. Any clue ?
>
>
> __
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness,
> live on your desktop!
> http://platinum.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! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.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
Client connection Table question
Scenario description: Two MQ servers, MQ1 & MQ2, both with the same queues to act as a backup for each other and load balancing. Two client connection tables, one with MQ1 in first row and MQ2 in second row, and the second CCT with MQ2 in the first row and MQ1 in the second row. By default the CCTs get equal share between MQ client machines, so that when the clients connect to its "closest" queue manager, then about half of the clients will connect to MQ1 and the other half will connect to MQ2. This setup works ok for when any one of the queue manager boxes fails, because the client will get an error, redo the connect and then use the "backup" queue manager. Question 1: When there was a failure on QM2 and all the clients are now connected to QM1, what is the best way of "reconnecting" to original queue manager when QM2 is alive again if client applications are long running and high volume? Option 1: Disconnect from time to time so that if there was a failover it will be fixed after a while. Option 2: Try and connect from time to time and when qmgr names are different from 2 connections, disconnect both and reconnect. Option 3: Some control message that all clients must watch out for to tell them to disconnect and reconnect. Option 4: Other Question 2: Same scenario as above, just that many clients are now running on the same machine, but connecting to different queue managers (maybe in a cluster). Option 1 to Option 4 the same. Option 5: A trigger monitor to help with the client starts and stops. Thanks a lot. Francois van der Merwe Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert & Developer 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: HP CLIENT CONNECTION to Mainframe
Nushin I am not familiar with HP but from my knowledge on AIX and Windows you must link your program using the MQ client libraries and not the server libaries if you want to use the client connection. Check the documenation on creating programs using a client connection. Also, to connect to the mainframe as a client you must also have the "Client attachment feature" installed on the mainframe. This is quite expensive so you may not have it installed. Ask your MVS sysprog he should tell you whether that has been installed or not. Most sites don't install this because this can achieved other ways. For example on your HP machine you define a remote queue that resides on the mainframe. You then connect to the HP using the server connection and put the message on your local definition of the remote queue and bingo your message is on the mainframe. Similarly you can define a remote queue on the mainfram pointing to the q on the HP. If you want more info let me know. I hope this helped. Cheers Pierre From: nushin mehran <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: HP CLIENT CONNECTION to Mainframe Date: Mon, 24 Mar 2003 16:23:35 -0800 Can any body tell me why an standalone MQ program in a HP v11 enviroment connects successfully to mainframe using MQSERVER, but as soon as I include it in another program and use it as procedure call stops at MQCONN and returns error 2058(Queue Manager not known). Can we have the MQSERVER coded in the program ?. It looks like that can not find the MQSERVER parms. Any clue ? __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.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 _ MSN Instant Messenger now available on Australian mobile phones. Go to http://ninemsn.com.au/mobilecentral/hotmail_messenger.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: HP CLIENT CONNECTION to Mainframe - TYPO
Sorry about the typo thats MQCNO not MQCON
Regards
Tim A
Tim
Armstrong/AustraliTo: [EMAIL PROTECTED]
a/[EMAIL PROTECTED] cc:
Sent by: MQSeries Subject: Re: HP CLIENT CONNECTION to
Mainframe
List
<[EMAIL PROTECTED]
.AC.AT>
25/03/2003 12:20
Please respond to
MQSeries List
To check the availability of the MQSERVER variable do a getenv() call in
your program if its C.
You can use MQCONNX instead of MQCONN and fill out the MQCD and MQCON
structures as shown in the following code excerpt.
MQCNO connectOpts = {MQCNO_DEFAULT};
MQCDclientDef = {MQCD_CLIENT_CONN_DEFAULT};
strncpy(clientDef.ConnectionName, connName, MQ_CONN_NAME_LENGTH);
strncpy(clientDef.ChannelName, channelName, MQ_CHANNEL_NAME_LENGTH);
connectOpts.ClientConnPtr = &clientDef;
connectOpts.Version = MQCNO_VERSION_2;
MQCONNX(qMgrName,&connectOpts,&hConn,&compCode,&reasonCode);
Regards
Tim A
nushin mehran
<[EMAIL PROTECTED]>To:
[EMAIL PROTECTED]
Sent by: MQSeriescc:
List Subject: HP CLIENT
CONNECTION to Mainframe
<[EMAIL PROTECTED]
N.AC.AT>
25/03/2003 11:23
Please respond to
MQSeries List
Can any body tell me why an standalone MQ program
in a HP v11 enviroment connects successfully to
mainframe using MQSERVER, but as soon as I include it
in another program and use it as procedure call
stops at MQCONN and returns error 2058(Queue Manager
not known). Can we have the MQSERVER coded in the
program ?. It looks like that can not find the
MQSERVER parms. Any clue ?
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.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
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: HP CLIENT CONNECTION to Mainframe
To check the availability of the MQSERVER variable do a getenv() call in
your program if its C.
You can use MQCONNX instead of MQCONN and fill out the MQCD and MQCON
structures as shown in the following code excerpt.
MQCNO connectOpts = {MQCNO_DEFAULT};
MQCDclientDef = {MQCD_CLIENT_CONN_DEFAULT};
strncpy(clientDef.ConnectionName, connName, MQ_CONN_NAME_LENGTH);
strncpy(clientDef.ChannelName, channelName, MQ_CHANNEL_NAME_LENGTH);
connectOpts.ClientConnPtr = &clientDef;
connectOpts.Version = MQCNO_VERSION_2;
MQCONNX(qMgrName,&connectOpts,&hConn,&compCode,&reasonCode);
Regards
Tim A
nushin mehran
<[EMAIL PROTECTED]>To: [EMAIL PROTECTED]
Sent by: MQSeriescc:
List Subject: HP CLIENT CONNECTION to
Mainframe
<[EMAIL PROTECTED]
N.AC.AT>
25/03/2003 11:23
Please respond to
MQSeries List
Can any body tell me why an standalone MQ program
in a HP v11 enviroment connects successfully to
mainframe using MQSERVER, but as soon as I include it
in another program and use it as procedure call
stops at MQCONN and returns error 2058(Queue Manager
not known). Can we have the MQSERVER coded in the
program ?. It looks like that can not find the
MQSERVER parms. Any clue ?
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.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
HP CLIENT CONNECTION to Mainframe
Can any body tell me why an standalone MQ program in a HP v11 enviroment connects successfully to mainframe using MQSERVER, but as soon as I include it in another program and use it as procedure call stops at MQCONN and returns error 2058(Queue Manager not known). Can we have the MQSERVER coded in the program ?. It looks like that can not find the MQSERVER parms. Any clue ? __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.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: Sporatic AMQ9208 errors on Client connection
Frank, Yes if these were occuing on the Server, but these are occuring on the client side. Since we know the server is not going down, and these are not reported by other clients, that eliminates(i believe) the MQServer, and node. glen "Bright, Frank" <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 03/19/2003 02:38:04 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Sporatic AMQ9208 errors on Client connection These type of errors have been posted or discussed on the listserv before. Here is an extract from one of the exchanges I saved that could be of some help for you: 10054 error - "connection was reset by peer" I'm thinking they occur when the client disconnects without doing an MQCLOSE on the queue. BTW, if any messages were under syncpoint, an implicit rollback was(is) performed as the server side assumes the worse - that you crashed and died. Good Luck Frank -Original Message- From: Glen Larson [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2003 3:23 PM To: [EMAIL PROTECTED] Subject: Sporatic AMQ9208 errors on Client connection Hello, MQ Client V5.2 csd04, on NT (6a) MQ Server V5.2 csd04 on NT (6a) We have not done any recent updates to the MQ software (we are working on 5.3 and have frozen all 5.2 maint) Web Application server running on NT node using MQClient to get data from background systems in a request/reply model. We have been getting sporatic AMQ9208 errors with tcp error code: 10054. These are abends are being reported on the Client side, of a client connection to an MQServer on NT. The errors have started to occure more frequently in the last month, averaging about 1 per week, (with 2 so far this week). Prior to this the application has been running since October without problem. Our network guys tell us that they do not see any unusual problems in the network. Their sampling occurs at 5 min intervals. The network is too busy, and the error to random to use a sniffer trace. And there does not appear to be any unusual work done in the application. Fingers are pointing at MQ, even though MQ is just mirroring an error it receives from the TCP stack. The network folks want to know about the MQ's timeout and retry values. Fingers are pointing at MQ, even though MQ is just reporting on an error it receives from the TCP stack. AMQ9208: Error on receive from host USZx1 (xxx.xxx.xxx.xxx). EXPLANATION: An error occurred receiving data from USZx1 (xxx.xxx.xxx.xxx) over TCP/IP. This may be due to a communications failure. ACTION: The return code from the TCP/IP (recv) call was 10054 (X'2746'). Record these values and tell the systems administrator. Fingers are pointing at MQ, even though MQ is just mirroring an error it receives from the TCP stack. Thank for any help, in pinpointing the error glen larson Zurich north america *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. 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: Sporatic AMQ9208 errors on Client connection
These type of errors have been posted or discussed on the listserv before. Here is an extract from one of the exchanges I saved that could be of some help for you: 10054 error - "connection was reset by peer" I'm thinking they occur when the client disconnects without doing an MQCLOSE on the queue. BTW, if any messages were under syncpoint, an implicit rollback was(is) performed as the server side assumes the worse - that you crashed and died. Good Luck Frank -Original Message- From: Glen Larson [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2003 3:23 PM To: [EMAIL PROTECTED] Subject: Sporatic AMQ9208 errors on Client connection Hello, MQ Client V5.2 csd04, on NT (6a) MQ Server V5.2 csd04 on NT (6a) We have not done any recent updates to the MQ software (we are working on 5.3 and have frozen all 5.2 maint) Web Application server running on NT node using MQClient to get data from background systems in a request/reply model. We have been getting sporatic AMQ9208 errors with tcp error code: 10054. These are abends are being reported on the Client side, of a client connection to an MQServer on NT. The errors have started to occure more frequently in the last month, averaging about 1 per week, (with 2 so far this week). Prior to this the application has been running since October without problem. Our network guys tell us that they do not see any unusual problems in the network. Their sampling occurs at 5 min intervals. The network is too busy, and the error to random to use a sniffer trace. And there does not appear to be any unusual work done in the application. Fingers are pointing at MQ, even though MQ is just mirroring an error it receives from the TCP stack. The network folks want to know about the MQ's timeout and retry values. Fingers are pointing at MQ, even though MQ is just reporting on an error it receives from the TCP stack. AMQ9208: Error on receive from host USZx1 (xxx.xxx.xxx.xxx). EXPLANATION: An error occurred receiving data from USZx1 (xxx.xxx.xxx.xxx) over TCP/IP. This may be due to a communications failure. ACTION: The return code from the TCP/IP (recv) call was 10054 (X'2746'). Record these values and tell the systems administrator. Fingers are pointing at MQ, even though MQ is just mirroring an error it receives from the TCP stack. Thank for any help, in pinpointing the error glen larson Zurich north america *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. 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
Sporatic AMQ9208 errors on Client connection
Hello, MQ Client V5.2 csd04, on NT (6a) MQ Server V5.2 csd04 on NT (6a) We have not done any recent updates to the MQ software (we are working on 5.3 and have frozen all 5.2 maint) Web Application server running on NT node using MQClient to get data from background systems in a request/reply model. We have been getting sporatic AMQ9208 errors with tcp error code: 10054. These are abends are being reported on the Client side, of a client connection to an MQServer on NT. The errors have started to occure more frequently in the last month, averaging about 1 per week, (with 2 so far this week). Prior to this the application has been running since October without problem. Our network guys tell us that they do not see any unusual problems in the network. Their sampling occurs at 5 min intervals. The network is too busy, and the error to random to use a sniffer trace. And there does not appear to be any unusual work done in the application. Fingers are pointing at MQ, even though MQ is just mirroring an error it receives from the TCP stack. The network folks want to know about the MQ's timeout and retry values. Fingers are pointing at MQ, even though MQ is just reporting on an error it receives from the TCP stack. AMQ9208: Error on receive from host USZx1 (xxx.xxx.xxx.xxx). EXPLANATION: An error occurred receiving data from USZx1 (xxx.xxx.xxx.xxx) over TCP/IP. This may be due to a communications failure. ACTION: The return code from the TCP/IP (recv) call was 10054 (X'2746'). Record these values and tell the systems administrator. Fingers are pointing at MQ, even though MQ is just mirroring an error it receives from the TCP stack. Thank for any help, in pinpointing the error glen larson Zurich north america *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. 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
MQ Java Client Connection with 2009 Error: Solved
All: I asked a question on Monday or so on MQ Java Client connection error 2009 for Win 2k platform with MQ 5.3.0.1. I got some responses (thanks). The solution was found through MQ PMR. 1. On my laptop, set a system environment variable called MQNOREMPOOL to anything (I used 'abc'). 2. Restart your machine after setting this variable and it will work. Then it worked. My previous recipe for setting up MQ was perfectly ok. Thanks. Jerry 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: Client Connection from Java on Laptop with Error 2009
Roger: Yes, the runmqlsr -m wsad_testserver -t TCP was used to start. (My qmgr is wsad_testserver). Any new ideas? Thanks. Jerry |-+---> | | Roger Lacroix | | || | | | | | 01/21/2003 02:37 PM | | | | |-+---> >---| | | | To: MQSeries List <[EMAIL PROTECTED]> | | cc: Jiede J Yang/Santa Monica/IBM@IBMUS | | Subject: Re: Client Connection from Java on Laptop with Error 2009 | | | | | >---| Did you start the listener process (runmqlsr)? You can start runmqlsr from a Command Prompt or from the MQ Services panel (not MQ Explorer!). Make sure Java program connects on the same port # that the listener is listening on (i.e. 1414). later Roger... Quoting Jiede J Yang <[EMAIL PROTECTED]>: > All: > > I have MQ running on my laptop (no fixed TCP IP). When I used java MQIVP > to check my binding connection, it is a success. > However, when I used java MQIVP to check my client connection, I got an > error 2009. Before the check, I have created a SVRCONN channel and started > the listener (like the Java MQ pdf file indicated). This is on my laptop > which does not have a fixed TCP/IP address. and the host name is 127.0.0.1 > or a short host name like YangJJ. > > Any clue? > > Thanks. > > Jerry > > 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: Client Connection from Java on Laptop with Error 2009
Did you start the listener process (runmqlsr)? You can start runmqlsr from a Command Prompt or from the MQ Services panel (not MQ Explorer!). Make sure Java program connects on the same port # that the listener is listening on (i.e. 1414). later Roger... Quoting Jiede J Yang <[EMAIL PROTECTED]>: > All: > > I have MQ running on my laptop (no fixed TCP IP). When I used java MQIVP > to check my binding connection, it is a success. > However, when I used java MQIVP to check my client connection, I got an > error 2009. Before the check, I have created a SVRCONN channel and started > the listener (like the Java MQ pdf file indicated). This is on my laptop > which does not have a fixed TCP/IP address. and the host name is 127.0.0.1 > or a short host name like YangJJ. > > Any clue? > > Thanks. > > Jerry > > 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
Client Connection from Java on Laptop with Error 2009
All: I have MQ running on my laptop (no fixed TCP IP). When I used java MQIVP to check my binding connection, it is a success. However, when I used java MQIVP to check my client connection, I got an error 2009. Before the check, I have created a SVRCONN channel and started the listener (like the Java MQ pdf file indicated). This is on my laptop which does not have a fixed TCP/IP address. and the host name is 127.0.0.1 or a short host name like YangJJ. Any clue? Thanks. Jerry Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Error 2009 connection broken for a client connection channel
Hi MQers, in our test environment, one of our application programmers has a strange occurence of 2009: Client: Win NT 4.0 SP6 with MQS Client 5.1 Server: OS/390 V2.10 with MQS Server 2.1 This channel is an often-used one both in the test and the production environment (there up to 500 clients) and had never any connection errors. Now the new application has to make a get with wait (about 5-10 minutes) for one message with about 2.3 MB . Elder applications never had such message sizes, most times 1 KB. The 2009 occurs very randomly - about ever 2 to 3 times it is tested. Such problems were formerly discussed, and a solution seemed to be the hbint - but this cannot be used on OS/390 . So, what to do ? Norbert Pfister IT DB/DC-Systemtechnik ITELLIUM Systems & Services GmbH N - Bau V, Zi. 113 Fürther Strasse 205 D-90429 Nürnberg, Germany Tel.: (+49) 0911/14-26548 Fax: (+49) 0911/14-23390 Mobil: (+49) 0151/14265011 mailto:[EMAIL PROTECTED] 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
Client Connection errors
Title: Client Connection errors I am having an issue with a 5.3 client connections, wherein i am getting mQ INTERNAL ERROR messages. I have forwarded the trace and FDC's to IGS but have not got much help. MQ Version 5.3 Desc: We are using an EDI conversion software called VITRIA. VITRIA uses mq client connections to get messages from a Q. These client connections are called connectors. The connectors are always connected to the Q which is a local q and the client connection exists on the same machine i.e both the client connection and the q are local. Since the past few days we are getting internal mq series errors very frequently when the connectors go down. The connectors go down with an error 2009 which says connection broken and then we get get errors 2019, get errors because the handles are invalid. At the same instant i get FDC files. Vitria is certified for mq v5.2. Would you think that issue could be because of any lib. mismatch, if so where can i get that information and what libs are used for client connection. Any suggestions to debug would be welcome. We have run a similar connector program to see if we are getting connection broken errors. Can anyone send me a good set of kernel params. Thanks,
Client connection failover with JMS
Hello all, in order to achieve 'automatic' MQ client failover in case of a queue manager failure, one can define multiple channels in a client channel table file and handle 2009 return codes by just re-connecting to the next entry with the same queue manager (alias) name in the table file. Now, my question is: How would you do this in a JMS environment, where you don't have a client channel table, but JNDI entries for your connections to queue managers? Is there a similar feature to define multiple entries in that way, which the provider classes can iterate through during connection to a queue manager? Any input on this is much appreciated. Thanks and have a nice day, Stefan _ 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
Re: How to detect client connection
Jessie - I had this problem once. The only way that I could think of to find out who was attempting to make the connection was to actually create the server-conn channel with a security exit that logged the attributes from the Channel Descriptor. It also denied the connection. - Steve Gies -Original Message- From: Jessie Yau [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 11, 2002 10:01 AM To: [EMAIL PROTECTED] Subject: How to detect client connection Hi, How to detect which clients are connecting to QM with invalid channel name ? I'm currently getting "+CSQX519E +T CSQXRESP Channel CLIENT.TO.MQSP not defined" error and no one is admitted to this problem. Is there a way to track down ip address who tried to connect but failed ? Or any idea how to troubleshoot ? Thanks, Jessie Yau The Capital Group Companies, Inc. 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: How to detect client connection
Good question -- I have the same thing on a Unix system (although, of course, the message number is different). I know it's coming from another site and what site that is, but not which machine there is doing the dirty deed. -- Rebecca -Original Message- From: Jessie Yau [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 11, 2002 1:01 PM To: [EMAIL PROTECTED] Subject: How to detect client connection Hi, How to detect which clients are connecting to QM with invalid channel name ? I'm currently getting "+CSQX519E +T CSQXRESP Channel CLIENT.TO.MQSP not defined" error and no one is admitted to this problem. Is there a way to track down ip address who tried to connect but failed ? Or any idea how to troubleshoot ? Thanks, Jessie Yau The Capital Group Companies, Inc. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
How to detect client connection
Hi, How to detect which clients are connecting to QM with invalid channel name ? I'm currently getting "+CSQX519E +T CSQXRESP Channel CLIENT.TO.MQSP not defined" error and no one is admitted to this problem. Is there a way to track down ip address who tried to connect but failed ? Or any idea how to troubleshoot ? Thanks, Jessie Yau The Capital Group Companies, Inc. 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: client connection/authority problem
Actually, I'm logged in as 'mollicfr' on the client and I'm a member of the mqm group (among other duties, I'm an administrator for MQ, but I'm not coding any apps). I shouldn't need to explicitly authorize myself for anything, should I? This leads to a few general questions (forgive me if they're rudimentary)... 1) As a member of the mqm group, is it even possible to have any authorizations revoked? 2) What is the default state of a qmgr - NO access or WIDE-OPEN access?? The environment I walked into here has quite a few qmgrs in production, with little or no security implemented. It would seem, and certainly the few tests I've run have supported this, that the default is for qmgrs to be WIDE-OPEN. People are beginning to use security exits to validate client IPs, but no one is implementing object authorities - although internal audits suggest that demand for this is coming soon. Basically, I just want to make sure I understand this whole mess before I start making recommendations. I've read a good deal of the documentation on this, but I'd like some corroboration from the experts who are actually doing it. Thanks again, Frank PS. All of this is on Sun Solaris. -Original Message- From: Glen Larson [mailto:[EMAIL PROTECTED]] Sent: Friday, May 10, 2002 9:29 AM To: [EMAIL PROTECTED] Subject: Re: client connection/authority problem Frank If you are using a 5.1 client or later the userid of the process (typically the logged on userid on NT) is passed. Use the strmqtrc command on the client side to start the client trace. Try to connect, then look in the directory: mqclient_root\ERRORS, and find the AMQ*.TRC file.This trace file will tell you the userid that is failing. On AIX, that userid must be given explicit authority to the resources, or be made a member of a group that has authority to the queue manager and queues ect. (SMITTY USER) not /etc/group. Id advise against using the mqm group unless the user is an mq administrator. Glen Larson Zurich North America "Frank Mollica." <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 05/09/2002 05:04:40 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: client connection/authority problem Hi, I'm trying to connect remotely to a qmgr (on solaris) and getting what I perceive as strange results. On the client machine, I'm logged in as a member of the mqm group and I'm running amqsputc to test the connection. When MCAUSER on the channel is left blank, I get a 2035 error. When MCAUSER is set to any valid member of mqm, the connection attempt is successful. This says to me that the authorities are fine for the qmgr and the queue, but that the qmgr is having trouble identifying the logged in user as a member of the mqm group. The /etc/group file was initially not set up properly to read from the global NIS map, but even after this was fixed, the results are the same. Can anyone offer some advice as to what might be happening here? Thanks, Frank 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 *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. 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 Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
Re: client connection/authority problem
Frank If you are using a 5.1 client or later the userid of the process (typically the logged on userid on NT) is passed. Use the strmqtrc command on the client side to start the client trace. Try to connect, then look in the directory: mqclient_root\ERRORS, and find the AMQ*.TRC file.This trace file will tell you the userid that is failing. On AIX, that userid must be given explicit authority to the resources, or be made a member of a group that has authority to the queue manager and queues ect. (SMITTY USER) not /etc/group. Id advise against using the mqm group unless the user is an mq administrator. Glen Larson Zurich North America "Frank Mollica." <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 05/09/2002 05:04:40 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: client connection/authority problem Hi, I'm trying to connect remotely to a qmgr (on solaris) and getting what I perceive as strange results. On the client machine, I'm logged in as a member of the mqm group and I'm running amqsputc to test the connection. When MCAUSER on the channel is left blank, I get a 2035 error. When MCAUSER is set to any valid member of mqm, the connection attempt is successful. This says to me that the authorities are fine for the qmgr and the queue, but that the qmgr is having trouble identifying the logged in user as a member of the mqm group. The /etc/group file was initially not set up properly to read from the global NIS map, but even after this was fixed, the results are the same. Can anyone offer some advice as to what might be happening here? Thanks, Frank 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 *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. 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: client connection/authority problem
Frank - I believe that if you leave the MCAUSER blank, then the currently logged on userid on the client side 'flows' to the server. It is this userid that needs to be defined on the server (i.e. Sun Solaris) and be a member of the mqm group. I have experienced this when I've run a 'C' client on Windows 2000 connecting to MQ on Unix. The story is different if you have a Java client - leaving the MCAUSER blank could mean that the userid used is 'root' !. Regards ... Ruud -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Frank Mollica. Sent: 09 May 2002 23:05 To: [EMAIL PROTECTED] Subject: client connection/authority problem Hi, I'm trying to connect remotely to a qmgr (on solaris) and getting what I perceive as strange results. On the client machine, I'm logged in as a member of the mqm group and I'm running amqsputc to test the connection. When MCAUSER on the channel is left blank, I get a 2035 error. When MCAUSER is set to any valid member of mqm, the connection attempt is successful. This says to me that the authorities are fine for the qmgr and the queue, but that the qmgr is having trouble identifying the logged in user as a member of the mqm group. The /etc/group file was initially not set up properly to read from the global NIS map, but even after this was fixed, the results are the same. Can anyone offer some advice as to what might be happening here? Thanks, Frank 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
client connection/authority problem
Hi, I'm trying to connect remotely to a qmgr (on solaris) and getting what I perceive as strange results. On the client machine, I'm logged in as a member of the mqm group and I'm running amqsputc to test the connection. When MCAUSER on the channel is left blank, I get a 2035 error. When MCAUSER is set to any valid member of mqm, the connection attempt is successful. This says to me that the authorities are fine for the qmgr and the queue, but that the qmgr is having trouble identifying the logged in user as a member of the mqm group. The /etc/group file was initially not set up properly to read from the global NIS map, but even after this was fixed, the results are the same. Can anyone offer some advice as to what might be happening here? Thanks, Frank 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
