AW: AW: Queue Manager Autostart on Windows
Hi Peter, you are right, I did some more tests today: 1. When I came into my office today, I switched on my PC, booted it and logged in. The qmgr was DOWN. 2. Then I rebooted the PC and afterwards the qmgr was UP. 3. Now I shutted down my PC, switched it off and on again. The PC booted, I logged in and the qmgr was UP! 4. The last test was, to change the recovery attributes to default (1 minute delay) and reboot the PC again. Afterwards the qmgr was UP. This looks very strange to me. I have a very stupid idea - but it's windows. Maybe the reason is, that the date changes during stopping and starting MQ? Any other idea? Regards Hubert -Ursprüngliche Nachricht- Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 22. Januar 2004 18:11 An: [EMAIL PROTECTED] Betreff: Re: AW: Queue Manager Autostart on Windows I tried altering these on the problem machine with no luck. -Original Message- From: Beinert, William [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 11:45 AM To: [EMAIL PROTECTED] Subject: Re: AW: Queue Manager Autostart on Windows Yes, Recovery is the tab, and on my machines I have 1 minute delay and 3 tries. This must be the default, because I have never played with these... Bill -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kleinmanns, Hubert Sent: Thursday, January 22, 2004 5:10 AM To: [EMAIL PROTECTED] Subject: AW: Queue Manager Autostart on Windows Hi all, I have the same problem on Win2K, running WMQ 5.3 CSD-04. The dspmq command shows ended unexpectedly. A qmgr start with WMQ services runs fine. My theory is, that some necessary Windows processes are not up, when MQ starts at reboot time. I modified the start-up of MQ services in the following way, and now it seems to work: 1. Right-click the qmgr in the MQ services and select Properties 2. Select something like Recovery (I have got a German version). 3. Now you can enter a delay for service restart and a number of tries. I modified the delay from 1 minute to 5 minutes, and now it works. Because I have only a German Win2K, maybe someone with an English version finds out and tells us the Englisch names of the menus. Regards Hubert -Ursprungliche Nachricht- Von: Chan, Ian M [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 22. Januar 2004 00:10 An: [EMAIL PROTECTED] Betreff: Re: Queue Manager Autostart on Windows and.. what log on account do you use in the MQ services under the control panel? May be try with a local Administrator account. I remember I have something similar but not the exact symptom like this one and finally found out that it's the domain id issue on the MQ services. Ian -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Rick Tsujimoto Sent: Thursday, 22 January 2004 7:02 AM To: [EMAIL PROTECTED] Subject: Re: Queue Manager Autostart on Windows How are you accessing your machine, e.g. local login, MS Terminal Services, PC Anywhere, etc.? Web Sphere [EMAIL PROTECTED] To: [EMAIL PROTECTED] .CO.UK cc: Sent by: Subject: Re: Queue Manager Autostart on Windows MQSeries List [EMAIL PROTECTED] en.AC.AT 01/21/2004 02:55 PM Please respond to MQSeries List Yes , all the services are configured to start automatically. I can see from the MQExplorer that the queue manager is unavailable. No mq processes in task manager. However, Control Panel shows IBM MQseries Service has started. When I manually start the queue manager it starts up fine. Only it doesnt start up on reboot .. Any ideas ? --- Beinert, William [EMAIL PROTECTED] wrote: Do you have all of the services configured to start automatically? I have the queue emanager, channel initiator, listener and command server... Have you looked in both MQ/Errors and MQ/QMGR/errors? Bill -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Web Sphere Sent: Wednesday, January 21, 2004 11:46 AM To: [EMAIL PROTECTED] Subject: Queue Manager Autostart on Windows Hi everyone, I've configured the a queue manager for automatic start on Windows. However after system reboot, the queue manager is an unavailable state. The event viewer does not indicate any errors. The IBM MQSeries service shows as started in the Services panel (in Control panel) Has anyone faced this before? Where do I check for errors in such a case? Thanks WS Yahoo! Messenger - Communicate instantly...Ping your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html Instructions for managing your mailing list
AW: AMQ9213 Bind failures on Solaris
tonyB, have a look at /usr/include/sys/errno.h Regards Hubert -Ursprungliche Nachricht- Von: Antony Boggis [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 23. Januar 2004 07:50 An: [EMAIL PROTECTED] Betreff: Re: AMQ9213 Bind failures on Solaris Larry, Where would one find these errors documented? Thanks, tonyB. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Larry Hendersen Sent: Thursday, January 22, 2004 11:46 AM To: [EMAIL PROTECTED] Subject: Re: AMQ9213 Bind failures on Solaris There was an error 13 in the FDC. errno 13 is EACCESS, permission denied. From: Antony Boggis [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: AMQ9213 Bind failures on Solaris Date: Wed, 21 Jan 2004 21:44:05 -0800 Some good suggestions. However, for future reference to all this turned out to be a Solaris permissions issue. Somehow permissions on /tmp had been reset and no userID (except root) was able to write files there. At one point I had a sev 1 PMR open on this. what finally clued me in (I can be slow sometimes) was that the logs were reporting files like /tmp/MQSeries.xxx.xxx and there was nothing in /tmp. Hope this helps someone else out. Even IBM support missed this one. Regards, tonyB. From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Dhavala Sent: Wednesday, January 21, 2004 4:45 PM To: [EMAIL PROTECTED] Subject: Re: AMQ9213 Bind failures on Solaris From the FFST it looks like the program is runmqlsr and which would mean that even though you believe your listener is starting and binding the port you asked for, fine enough, it sure seems to have some issues. Try using some other port or find out who is using that particular port(1414, if it is so). Cheers Kumar _ There are now three new levels of MSN Hotmail Extra Storage! Learn more. http://join.msn.com/?pgmarket=en-uspage=hotmail/es2ST=1 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
MQ connect errors
Title: MQ connect errors I am trying to simulate a problem we currently have in production. This is what happens in production: A client application on Windows starts 10 instances of itself, connects to the same QM and the same queue at the same time. It then puts a message and disconnects. Some of the instances fail with a create object error. Its not native MQI calls and does not return MQ error codes. I asume that the create object error is either the creation of the queue or queue manager object, so it either fails on MQOPEN or MQCONNECT call. I tried to simulate this by running 20 apps that write 1000 messages to the same queue. First I create the loop around the MQOPEN/PUT/CLOSE calls. ie the app stays connected to the queue manager and then opens, puts and closes the 1000 times. This finished with no errors. Then I put the loop around MQCONN/OPEN/PUT/CLOSE/DISC and a few of them failed with 2059 errors. The error logs just give the ususal AMQ9202: Remote host 'w31873079 (10.36.137.79) (1414)' not available error. There is nothing in any other error logs or FDC files created. Can anyone explain this. Does the listener just fail to start up connections? Faizel Sedick Woolworths Integration IBM MQSeries Certified Specialist, Developer Solutions Expert Email: [EMAIL PROTECTED] Phone: +27 21 407 2452 Cell: +27 83 251 9361 ---Please note: This e-mail and its contents are subject to a disclaimer which can be viewed at http://www.woolworths.co.za/disclaimer. Should you be unable to access the link please e-mail [EMAIL PROTECTED] and a copy of the disclaimer will be e-mailed to you.
AW: MQ connect errors
Title: MQ connect errors Faizel, you should have a look to the error logs and FDCs on the receiving side. They should provide you with more useful information. See the logs in (on Unix) /var/mqm/errors, /var/mqm/qmgrs/@SYSTEM/errors and /var/mqm/qmgrs/qmgr name/errors (on Windows replace /var/mqm by your MQ data path). Regards Hubert -Ursprüngliche Nachricht-Von: Faizel Sedick [mailto:[EMAIL PROTECTED]Gesendet: Freitag, 23. Januar 2004 10:07An: [EMAIL PROTECTED]Betreff: MQ connect errors I am trying to simulate a problem we currently have in production. This is what happens in production: A client application on Windows starts 10 instances of itself, connects to the same QM and the same queue at the same time. It then puts a message and disconnects. Some of the instances fail with a create object error. Its not native MQI calls and does not return MQ error codes. I asume that the create object error is either the creation of the queue or queue manager object, so it either fails on MQOPEN or MQCONNECT call. I tried to simulate this by running 20 apps that write 1000 messages to the same queue. First I create the loop around the MQOPEN/PUT/CLOSE calls. ie the app stays connected to the queue manager and then opens, puts and closes the 1000 times. This finished with no errors. Then I put the loop around MQCONN/OPEN/PUT/CLOSE/DISC and a few of them failed with 2059 errors. The error logs just give the ususal "AMQ9202: Remote host 'w31873079 (10.36.137.79) (1414)' not available" error. There is nothing in any other error logs or FDC files created. Can anyone explain this. Does the listener just fail to start up connections? Faizel Sedick Woolworths Integration IBM MQSeries Certified Specialist, Developer Solutions Expert Email: [EMAIL PROTECTED] Phone: +27 21 407 2452 Cell: +27 83 251 9361 ---Please note: This e-mail and its contents are subject to a disclaimer which can be viewed at http://www.woolworths.co.za/disclaimer. Should you be unable to access the link please e-mail [EMAIL PROTECTED] and a copy of the disclaimer will be e-mailed to you.
stackit
Anyone know how I can get hold of the shell script called stackit that IBM support ask to be used to get a stack print for running MQ processes? The reason I ask is that the version of Linux that one of our customers is running doesn't have the pstack command, and I assume that the shell script has some smarts to detect if pstack is available and use that if it is, and to invoke gdb -p pid and the bt sub-command if it isn't. Rather than re-inventing the wheel ... Regards, David C. Partridge Security and MQ Products Manager Primeur Group Tel: +44 (0)1926 511058 Mobile: +44 (0)7713 880197 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: stackit
I found an AIX version of the subject shell script written by Justin Fries that uses dbx to gather the information at ftp://testcase.boulder.ibm.com/ts/fromibm/mqseries/stackit Is there an equivalent for Linux that uses gdb? Thanks David -Original Message- From: David C. Partridge [mailto:[EMAIL PROTECTED] Sent: 23 January 2004 11:19 To: MQSeries List Subject: stackit Anyone know how I can get hold of the shell script called stackit that IBM support ask to be used to get a stack print for running MQ processes? The reason I ask is that the version of Linux that one of our customers is running doesn't have the pstack command, and I assume that the shell script has some smarts to detect if pstack is available and use that if it is, and to invoke gdb -p pid and the bt sub-command if it isn't. Rather than re-inventing the wheel ... Regards, David C. Partridge Security and MQ Products Manager Primeur Group Tel: +44 (0)1926 511058 Mobile: +44 (0)7713 880197 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: AW: Queue Manager Autostart on Windows
I didn't mention it before, but the QM did come up the first time I rebooted after I altered these settings. But that was it. It has gone back to not coming up automatically on reboots. -Original Message- From: Kleinmanns, Hubert [mailto:[EMAIL PROTECTED] Sent: Friday, January 23, 2004 2:24 AM To: [EMAIL PROTECTED] Subject: AW: AW: Queue Manager Autostart on Windows Hi Peter, you are right, I did some more tests today: 1. When I came into my office today, I switched on my PC, booted it and logged in. The qmgr was DOWN. 2. Then I rebooted the PC and afterwards the qmgr was UP. 3. Now I shutted down my PC, switched it off and on again. The PC booted, I logged in and the qmgr was UP! 4. The last test was, to change the recovery attributes to default (1 minute delay) and reboot the PC again. Afterwards the qmgr was UP. This looks very strange to me. I have a very stupid idea - but it's windows. Maybe the reason is, that the date changes during stopping and starting MQ? Any other idea? Regards Hubert -Ursprüngliche Nachricht- Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 22. Januar 2004 18:11 An: [EMAIL PROTECTED] Betreff: Re: AW: Queue Manager Autostart on Windows I tried altering these on the problem machine with no luck. -Original Message- From: Beinert, William [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 11:45 AM To: [EMAIL PROTECTED] Subject: Re: AW: Queue Manager Autostart on Windows Yes, Recovery is the tab, and on my machines I have 1 minute delay and 3 tries. This must be the default, because I have never played with these... Bill -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kleinmanns, Hubert Sent: Thursday, January 22, 2004 5:10 AM To: [EMAIL PROTECTED] Subject: AW: Queue Manager Autostart on Windows Hi all, I have the same problem on Win2K, running WMQ 5.3 CSD-04. The dspmq command shows ended unexpectedly. A qmgr start with WMQ services runs fine. My theory is, that some necessary Windows processes are not up, when MQ starts at reboot time. I modified the start-up of MQ services in the following way, and now it seems to work: 1. Right-click the qmgr in the MQ services and select Properties 2. Select something like Recovery (I have got a German version). 3. Now you can enter a delay for service restart and a number of tries. I modified the delay from 1 minute to 5 minutes, and now it works. Because I have only a German Win2K, maybe someone with an English version finds out and tells us the Englisch names of the menus. Regards Hubert -Ursprungliche Nachricht- Von: Chan, Ian M [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 22. Januar 2004 00:10 An: [EMAIL PROTECTED] Betreff: Re: Queue Manager Autostart on Windows and.. what log on account do you use in the MQ services under the control panel? May be try with a local Administrator account. I remember I have something similar but not the exact symptom like this one and finally found out that it's the domain id issue on the MQ services. Ian -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Rick Tsujimoto Sent: Thursday, 22 January 2004 7:02 AM To: [EMAIL PROTECTED] Subject: Re: Queue Manager Autostart on Windows How are you accessing your machine, e.g. local login, MS Terminal Services, PC Anywhere, etc.? Web Sphere [EMAIL PROTECTED] To: [EMAIL PROTECTED] .CO.UK cc: Sent by: Subject: Re: Queue Manager Autostart on Windows MQSeries List [EMAIL PROTECTED] en.AC.AT 01/21/2004 02:55 PM Please respond to MQSeries List Yes , all the services are configured to start automatically. I can see from the MQExplorer that the queue manager is unavailable. No mq processes in task manager. However, Control Panel shows IBM MQseries Service has started. When I manually start the queue manager it starts up fine. Only it doesnt start up on reboot .. Any ideas ? --- Beinert, William [EMAIL PROTECTED] wrote: Do you have all of the services configured to start automatically? I have the queue emanager, channel initiator, listener and command server... Have you looked in both MQ/Errors and MQ/QMGR/errors? Bill -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Web Sphere Sent: Wednesday, January 21, 2004 11:46 AM To: [EMAIL PROTECTED] Subject: Queue Manager Autostart on Windows Hi everyone, I've configured the a queue manager for automatic start on Windows. However after system reboot, the queue manager is an unavailable state. The event viewer does not indicate any errors. The IBM MQSeries service shows as started in the Services
AW: AW: Queue Manager Autostart on Windows
Peter, what do you think about my date theory (see below)? Did you try a reboot today again? Hubert -Ursprüngliche Nachricht- Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 23. Januar 2004 14:00 An: [EMAIL PROTECTED] Betreff: Re: AW: Queue Manager Autostart on Windows I didn't mention it before, but the QM did come up the first time I rebooted after I altered these settings. But that was it. It has gone back to not coming up automatically on reboots. -Original Message- From: Kleinmanns, Hubert [mailto:[EMAIL PROTECTED] Sent: Friday, January 23, 2004 2:24 AM To: [EMAIL PROTECTED] Subject: AW: AW: Queue Manager Autostart on Windows Hi Peter, you are right, I did some more tests today: 1. When I came into my office today, I switched on my PC, booted it and logged in. The qmgr was DOWN. 2. Then I rebooted the PC and afterwards the qmgr was UP. 3. Now I shutted down my PC, switched it off and on again. The PC booted, I logged in and the qmgr was UP! 4. The last test was, to change the recovery attributes to default (1 minute delay) and reboot the PC again. Afterwards the qmgr was UP. This looks very strange to me. I have a very stupid idea - but it's windows. Maybe the reason is, that the date changes during stopping and starting MQ? Any other idea? Regards Hubert -Ursprüngliche Nachricht- Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 22. Januar 2004 18:11 An: [EMAIL PROTECTED] Betreff: Re: AW: Queue Manager Autostart on Windows I tried altering these on the problem machine with no luck. -Original Message- From: Beinert, William [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 11:45 AM To: [EMAIL PROTECTED] Subject: Re: AW: Queue Manager Autostart on Windows Yes, Recovery is the tab, and on my machines I have 1 minute delay and 3 tries. This must be the default, because I have never played with these... Bill -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kleinmanns, Hubert Sent: Thursday, January 22, 2004 5:10 AM To: [EMAIL PROTECTED] Subject: AW: Queue Manager Autostart on Windows Hi all, I have the same problem on Win2K, running WMQ 5.3 CSD-04. The dspmq command shows ended unexpectedly. A qmgr start with WMQ services runs fine. My theory is, that some necessary Windows processes are not up, when MQ starts at reboot time. I modified the start-up of MQ services in the following way, and now it seems to work: 1. Right-click the qmgr in the MQ services and select Properties 2. Select something like Recovery (I have got a German version). 3. Now you can enter a delay for service restart and a number of tries. I modified the delay from 1 minute to 5 minutes, and now it works. Because I have only a German Win2K, maybe someone with an English version finds out and tells us the Englisch names of the menus. Regards Hubert -Ursprungliche Nachricht- Von: Chan, Ian M [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 22. Januar 2004 00:10 An: [EMAIL PROTECTED] Betreff: Re: Queue Manager Autostart on Windows and.. what log on account do you use in the MQ services under the control panel? May be try with a local Administrator account. I remember I have something similar but not the exact symptom like this one and finally found out that it's the domain id issue on the MQ services. Ian -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Rick Tsujimoto Sent: Thursday, 22 January 2004 7:02 AM To: [EMAIL PROTECTED] Subject: Re: Queue Manager Autostart on Windows How are you accessing your machine, e.g. local login, MS Terminal Services, PC Anywhere, etc.? Web Sphere [EMAIL PROTECTED] To: [EMAIL PROTECTED] .CO.UK cc: Sent by: Subject: Re: Queue Manager Autostart on Windows MQSeries List [EMAIL PROTECTED] en.AC.AT 01/21/2004 02:55 PM Please respond to MQSeries List Yes , all the services are configured to start automatically. I can see from the MQExplorer that the queue manager is unavailable. No mq processes in task manager. However, Control Panel shows IBM MQseries Service has started. When I manually start the queue manager it starts up fine. Only it doesnt start up on reboot .. Any ideas ? --- Beinert, William [EMAIL PROTECTED] wrote: Do you have all of the services configured to start automatically? I have the queue emanager, channel initiator, listener and command server... Have you looked in both MQ/Errors and MQ/QMGR/errors? Bill -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Web Sphere Sent: Wednesday, January 21, 2004 11:46 AM To: [EMAIL PROTECTED]
Re: AW: Queue Manager Autostart on Windows
Yeah, its been like this for a week. Its not my PC so I can't really fool around with as much as I like. Since its not happening on any servers or anyone else's PC, this is kinda low priority, but annoying as heck either way. -Original Message- From: Kleinmanns, Hubert [mailto:[EMAIL PROTECTED] Sent: Friday, January 23, 2004 8:40 AM To: [EMAIL PROTECTED] Subject: AW: AW: Queue Manager Autostart on Windows Peter, what do you think about my date theory (see below)? Did you try a reboot today again? Hubert -Ursprüngliche Nachricht- Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 23. Januar 2004 14:00 An: [EMAIL PROTECTED] Betreff: Re: AW: Queue Manager Autostart on Windows I didn't mention it before, but the QM did come up the first time I rebooted after I altered these settings. But that was it. It has gone back to not coming up automatically on reboots. -Original Message- From: Kleinmanns, Hubert [mailto:[EMAIL PROTECTED] Sent: Friday, January 23, 2004 2:24 AM To: [EMAIL PROTECTED] Subject: AW: AW: Queue Manager Autostart on Windows Hi Peter, you are right, I did some more tests today: 1. When I came into my office today, I switched on my PC, booted it and logged in. The qmgr was DOWN. 2. Then I rebooted the PC and afterwards the qmgr was UP. 3. Now I shutted down my PC, switched it off and on again. The PC booted, I logged in and the qmgr was UP! 4. The last test was, to change the recovery attributes to default (1 minute delay) and reboot the PC again. Afterwards the qmgr was UP. This looks very strange to me. I have a very stupid idea - but it's windows. Maybe the reason is, that the date changes during stopping and starting MQ? Any other idea? Regards Hubert -Ursprüngliche Nachricht- Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 22. Januar 2004 18:11 An: [EMAIL PROTECTED] Betreff: Re: AW: Queue Manager Autostart on Windows I tried altering these on the problem machine with no luck. -Original Message- From: Beinert, William [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 11:45 AM To: [EMAIL PROTECTED] Subject: Re: AW: Queue Manager Autostart on Windows Yes, Recovery is the tab, and on my machines I have 1 minute delay and 3 tries. This must be the default, because I have never played with these... Bill -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Kleinmanns, Hubert Sent: Thursday, January 22, 2004 5:10 AM To: [EMAIL PROTECTED] Subject: AW: Queue Manager Autostart on Windows Hi all, I have the same problem on Win2K, running WMQ 5.3 CSD-04. The dspmq command shows ended unexpectedly. A qmgr start with WMQ services runs fine. My theory is, that some necessary Windows processes are not up, when MQ starts at reboot time. I modified the start-up of MQ services in the following way, and now it seems to work: 1. Right-click the qmgr in the MQ services and select Properties 2. Select something like Recovery (I have got a German version). 3. Now you can enter a delay for service restart and a number of tries. I modified the delay from 1 minute to 5 minutes, and now it works. Because I have only a German Win2K, maybe someone with an English version finds out and tells us the Englisch names of the menus. Regards Hubert -Ursprungliche Nachricht- Von: Chan, Ian M [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 22. Januar 2004 00:10 An: [EMAIL PROTECTED] Betreff: Re: Queue Manager Autostart on Windows and.. what log on account do you use in the MQ services under the control panel? May be try with a local Administrator account. I remember I have something similar but not the exact symptom like this one and finally found out that it's the domain id issue on the MQ services. Ian -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Rick Tsujimoto Sent: Thursday, 22 January 2004 7:02 AM To: [EMAIL PROTECTED] Subject: Re: Queue Manager Autostart on Windows How are you accessing your machine, e.g. local login, MS Terminal Services, PC Anywhere, etc.? Web Sphere [EMAIL PROTECTED] To: [EMAIL PROTECTED] .CO.UK cc: Sent by: Subject: Re: Queue Manager Autostart on Windows MQSeries List [EMAIL PROTECTED] en.AC.AT 01/21/2004 02:55 PM Please respond to MQSeries List Yes , all the services are configured to start automatically. I can see from the MQExplorer that the queue manager is unavailable. No mq processes in task manager. However, Control Panel shows IBM MQseries Service has started. When I manually start the queue manager it starts up fine. Only it doesnt start up on reboot .. Any ideas ? ---
Re: MQ connect errors
Title: MQ connect errors Hi there, If your application does not use native MQI calls, then what is it? All of the Java-basedAPIs supplied by IBM provide access to the MQ Reason and Completion codes. I would think that the VB API would as well but I don't use it and don't know. Have you turned on all your event types? Sometimes this can be quite helpful in discovering exactly what call failed and on which object. Is that log entry from the host or the client? -- T.Rob -Original Message-From: Faizel Sedick [mailto:[EMAIL PROTECTED]Sent: Friday, January 23, 2004 4:07 AMTo: [EMAIL PROTECTED]Subject: MQ connect errors I am trying to simulate a problem we currently have in production. This is what happens in production: A client application on Windows starts 10 instances of itself, connects to the same QM and the same queue at the same time. It then puts a message and disconnects. Some of the instances fail with a create object error. Its not native MQI calls and does not return MQ error codes. I asume that the create object error is either the creation of the queue or queue manager object, so it either fails on MQOPEN or MQCONNECT call. I tried to simulate this by running 20 apps that write 1000 messages to the same queue. First I create the loop around the MQOPEN/PUT/CLOSE calls. ie the app stays connected to the queue manager and then opens, puts and closes the 1000 times. This finished with no errors. Then I put the loop around MQCONN/OPEN/PUT/CLOSE/DISC and a few of them failed with 2059 errors. The error logs just give the ususal "AMQ9202: Remote host 'w31873079 (10.36.137.79) (1414)' not available" error. There is nothing in any other error logs or FDC files created. Can anyone explain this. Does the listener just fail to start up connections? Faizel Sedick Woolworths Integration IBM MQSeries Certified Specialist, Developer Solutions Expert Email: [EMAIL PROTECTED] Phone: +27 21 407 2452 Cell: +27 83 251 9361 ---Please note: This e-mail and its contents are subject to a disclaimer which can be viewed at http://www.woolworths.co.za/disclaimer. Should you be unable to access the link please e-mail [EMAIL PROTECTED] and a copy of the disclaimer will be e-mailed to you.
Re: stackit
David: I personally haven't used stackit, but if you are a little savy you should be able to convert the dbx with gdb (I believe) which is on Linux. Chris |-+- | | David C. | | | Partridge| | | [EMAIL PROTECTED]| | | RIMEUR.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | .AC.AT | | | | | | | | | 01/23/2004 05:37 | | | AM| | | Please respond to | | | MQSeries List | | | | |-+- --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: stackit | | | --| I found an AIX version of the subject shell script written by Justin Fries that uses dbx to gather the information at ftp://testcase.boulder.ibm.com/ts/fromibm/mqseries/stackit Is there an equivalent for Linux that uses gdb? Thanks David -Original Message- From: David C. Partridge [mailto:[EMAIL PROTECTED] Sent: 23 January 2004 11:19 To: MQSeries List Subject: stackit Anyone know how I can get hold of the shell script called stackit that IBM support ask to be used to get a stack print for running MQ processes? The reason I ask is that the version of Linux that one of our customers is running doesn't have the pstack command, and I assume that the shell script has some smarts to detect if pstack is available and use that if it is, and to invoke gdb -p pid and the bt sub-command if it isn't. Rather than re-inventing the wheel ... Regards, David C. Partridge Security and MQ Products Manager Primeur Group Tel: +44 (0)1926 511058 Mobile: +44 (0)7713 880197 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: MQ connect errors
Have you checked the ListenerBacklog parameter for your platform? 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 connect errors
Title: MQ connect errors What I meant was that the actual app does not return MQ error codes. It only states that the operation as a whole failed. When I try to recreate the behaviour of the app using C code I get and error when doing similtaneous MQCONN calls. ie I run 50 instances of an app so there is potentialy 50 client connect calls which seems to generate the 2059 error.Strange. I have advised the application team not to do the continuous connect/disconnect, but to stay connected as they do constantly write to queues. That will fix their problem, but I am still can't accept this behavour. Cheers Faizel -Original Message-From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED]Sent: Friday, 23 January 2004 15:56To: [EMAIL PROTECTED]Subject: Re: MQ connect errors Hi there, If your application does not use native MQI calls, then what is it? All of the Java-basedAPIs supplied by IBM provide access to the MQ Reason and Completion codes. I would think that the VB API would as well but I don't use it and don't know. Have you turned on all your event types? Sometimes this can be quite helpful in discovering exactly what call failed and on which object. Is that log entry from the host or the client? -- T.Rob -Original Message-From: Faizel Sedick [mailto:[EMAIL PROTECTED]Sent: Friday, January 23, 2004 4:07 AMTo: [EMAIL PROTECTED]Subject: MQ connect errors I am trying to simulate a problem we currently have in production. This is what happens in production: A client application on Windows starts 10 instances of itself, connects to the same QM and the same queue at the same time. It then puts a message and disconnects. Some of the instances fail with a create object error. Its not native MQI calls and does not return MQ error codes. I asume that the create object error is either the creation of the queue or queue manager object, so it either fails on MQOPEN or MQCONNECT call. I tried to simulate this by running 20 apps that write 1000 messages to the same queue. First I create the loop around the MQOPEN/PUT/CLOSE calls. ie the app stays connected to the queue manager and then opens, puts and closes the 1000 times. This finished with no errors. Then I put the loop around MQCONN/OPEN/PUT/CLOSE/DISC and a few of them failed with 2059 errors. The error logs just give the ususal "AMQ9202: Remote host 'w31873079 (10.36.137.79) (1414)' not available" error. There is nothing in any other error logs or FDC files created. Can anyone explain this. Does the listener just fail to start up connections? Faizel Sedick Woolworths Integration IBM MQSeries Certified Specialist, Developer Solutions Expert Email: [EMAIL PROTECTED] Phone: +27 21 407 2452 Cell: +27 83 251 9361 ---Please note: This e-mail and its contents are subject to a disclaimer which can be viewed at http://www.woolworths.co.za/disclaimer. Should you be unable to access the link please e-mail [EMAIL PROTECTED] and a copy of the disclaimer will be e-mailed to you. ---Please note: This e-mail and its contents are subject to a disclaimer which can be viewed at http://www.woolworths.co.za/disclaimer. Should you be unable to access the link please e-mail [EMAIL PROTECTED] and a copy of the disclaimer will be e-mailed to you.
Re: AW: MQ connect errors
Title: MQ connect errors I've checked all error logs - Client and Server. - Nothing besides the AMQ9202 error below. -Original Message-From: Kleinmanns, Hubert [mailto:[EMAIL PROTECTED]Sent: Friday, 23 January 2004 11:53To: [EMAIL PROTECTED]Subject: AW: MQ connect errors Faizel, you should have a look to the error logs and FDCs on the receiving side. They should provide you with more useful information. See the logs in (on Unix) /var/mqm/errors, /var/mqm/qmgrs/@SYSTEM/errors and /var/mqm/qmgrs/qmgr name/errors (on Windows replace /var/mqm by your MQ data path). Regards Hubert -Ursprüngliche Nachricht-Von: Faizel Sedick [mailto:[EMAIL PROTECTED]Gesendet: Freitag, 23. Januar 2004 10:07An: [EMAIL PROTECTED]Betreff: MQ connect errors I am trying to simulate a problem we currently have in production. This is what happens in production: A client application on Windows starts 10 instances of itself, connects to the same QM and the same queue at the same time. It then puts a message and disconnects. Some of the instances fail with a create object error. Its not native MQI calls and does not return MQ error codes. I asume that the create object error is either the creation of the queue or queue manager object, so it either fails on MQOPEN or MQCONNECT call. I tried to simulate this by running 20 apps that write 1000 messages to the same queue. First I create the loop around the MQOPEN/PUT/CLOSE calls. ie the app stays connected to the queue manager and then opens, puts and closes the 1000 times. This finished with no errors. Then I put the loop around MQCONN/OPEN/PUT/CLOSE/DISC and a few of them failed with 2059 errors. The error logs just give the ususal "AMQ9202: Remote host 'w31873079 (10.36.137.79) (1414)' not available" error. There is nothing in any other error logs or FDC files created. Can anyone explain this. Does the listener just fail to start up connections? Faizel Sedick Woolworths Integration IBM MQSeries Certified Specialist, Developer Solutions Expert Email: [EMAIL PROTECTED] Phone: +27 21 407 2452 Cell: +27 83 251 9361 ---Please note: This e-mail and its contents are subject to a disclaimer which can be viewed at http://www.woolworths.co.za/disclaimer. Should you be unable to access the link please e-mail [EMAIL PROTECTED] and a copy of the disclaimer will be e-mailed to you. ---Please note: This e-mail and its contents are subject to a disclaimer which can be viewed at http://www.woolworths.co.za/disclaimer. Should you be unable to access the link please e-mail [EMAIL PROTECTED] and a copy of the disclaimer will be e-mailed to you.
Re: MQ connect errors
I have seen this when the load on the queue manager/server is at a high level because of the instances of the applications. When running a number of instances I have seen a potential possibility of a failure. Especially in a MCONN, MQOPEN, MQPUT, MQCLOSE, MQDISC. Also, depending on whether the instances are threads or process there could be an issue when each thread is doing a connection. Although its rare I have seen more problems with processes than threads. As for it stating a 'create object error' I don't recall getting that error, but then again it has been a while since I put a system under duress. One option you mention is a positive one. The second is to stagger each instance of an app, unless there is an actual need to create 50 instances of the application. Another is to verify that you have configured your client instances allowed for the queue manager. Unless the applications require a constant connection what you may want to do is create a pool of connections via a thread pool. It's simple, well not for everyone, and based on the number of instances required they can use the existing connections or if required additional connections within the pool can be made. One other suggestion is to put a timestamp before the MQCONN and one at MQDISC. Kick off 20-50 instances of the application at once and see where the delay is. If the applications are in a wait state to long it will actually fail. That I do know because I have reproduced that a number of times when doing high volume/client connections for WMQ. This is a bugger to track down, but you may need to try different configurations in order to determine the best route for application process, system load, thread or process, and so forth. Chris |-+--- | | Faizel Sedick | | | [EMAIL PROTECTED]| | | RTHS.CO.ZA | | | Sent by: MQSeries | | | List | | | [EMAIL PROTECTED]| | | C.AT | | | | | | | | | 01/23/2004 09:01 AM | | | Please respond to | | | MQSeries List | | | | |-+--- --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MQ connect errors | | | --| What I meant was that the actual app does not return MQ error codes. It only states that the operation as a whole failed. When I try to recreate the behaviour of the app using C code I get and error when doing similtaneous MQCONN calls. ie I run 50 instances of an app so there is potentialy 50 client connect calls which seems to generate the 2059 error. Strange. I have advised the application team not to do the continuous connect/disconnect, but to stay connected as they do constantly write to queues. That will fix their problem, but I am still can't accept this behavour. Cheers Faizel -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Friday, 23 January 2004 15:56 To: [EMAIL PROTECTED] Subject: Re: MQ connect errors Hi there, If your application does not use native MQI calls, then what is it? All of the Java-based APIs supplied by IBM provide access to the MQ Reason and Completion codes. I would think that the VB API would as well but I don't use it and don't know. Have you turned on all your event types? Sometimes this can be quite helpful in discovering exactly what call failed and on which object. Is that log entry from the host or the client? -- T.Rob -Original Message- From: Faizel Sedick [mailto:[EMAIL PROTECTED] Sent: Friday, January 23, 2004 4:07 AM To: [EMAIL PROTECTED] Subject: MQ connect errors I am trying to simulate a problem we currently have in production. This is what happens in production: A client
Re: MQ connect errors
Are these JAVA JMS apps? Are they doing DB work?? If you do not disconnect from the DB and MQ in the correct order the disconnect from MQ does not complete. So you could be accumulating your open connections to the point that you run out. Do a dis chs and see how many outstanding connections you have as the apps are running. See if they are growing. Maybe and probably your apps have a coding error and are not init-ing something in the connection loop. bobbee From: Faizel Sedick [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: MQ connect errors Date: Fri, 23 Jan 2004 17:01:14 +0200 What I meant was that the actual app does not return MQ error codes. It only states that the operation as a whole failed. When I try to recreate the behaviour of the app using C code I get and error when doing similtaneous MQCONN calls. ie I run 50 instances of an app so there is potentialy 50 client connect calls which seems to generate the 2059 error. Strange. I have advised the application team not to do the continuous connect/disconnect, but to stay connected as they do constantly write to queues. That will fix their problem, but I am still can't accept this behavour. Cheers Faizel -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Friday, 23 January 2004 15:56 To: [EMAIL PROTECTED] Subject: Re: MQ connect errors Hi there, If your application does not use native MQI calls, then what is it? All of the Java-based APIs supplied by IBM provide access to the MQ Reason and Completion codes. I would think that the VB API would as well but I don't use it and don't know. Have you turned on all your event types? Sometimes this can be quite helpful in discovering exactly what call failed and on which object. Is that log entry from the host or the client? -- T.Rob -Original Message- From: Faizel Sedick [mailto:[EMAIL PROTECTED] Sent: Friday, January 23, 2004 4:07 AM To: [EMAIL PROTECTED] Subject: MQ connect errors I am trying to simulate a problem we currently have in production. This is what happens in production: A client application on Windows starts 10 instances of itself, connects to the same QM and the same queue at the same time. It then puts a message and disconnects. Some of the instances fail with a create object error. Its not native MQI calls and does not return MQ error codes. I asume that the create object error is either the creation of the queue or queue manager object, so it either fails on MQOPEN or MQCONNECT call. I tried to simulate this by running 20 apps that write 1000 messages to the same queue. First I create the loop around the MQOPEN/PUT/CLOSE calls. ie the app stays connected to the queue manager and then opens, puts and closes the 1000 times. This finished with no errors. Then I put the loop around MQCONN/OPEN/PUT/CLOSE/DISC and a few of them failed with 2059 errors. The error logs just give the ususal AMQ9202: Remote host 'w31873079 (10.36.137.79) (1414)' not available error. There is nothing in any other error logs or FDC files created. Can anyone explain this. Does the listener just fail to start up connections? Faizel Sedick Woolworths Integration IBM MQSeries Certified Specialist, Developer Solutions Expert Email: [EMAIL PROTECTED] Phone: +27 21 407 2452 Cell: +27 83 251 9361 --- Please note: This e-mail and its contents are subject to a disclaimer which can be viewed at http://www.woolworths.co.za/disclaimer http://www.woolworths.co.za/disclaimer. Should you be unable to access the link please e-mail mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] and a copy of the disclaimer will be e-mailed to you. Please note: This e-mail and its contents are subject to a disclaimer which can be viewed at http://www.woolworths.co.za/disclaimer. Should you be unable to access the link please e-mail [EMAIL PROTECTED] and a copy of the disclaimer will be e-mailed to you. _ Scope out the new MSN Plus Internet Software optimizes dial-up to the max! http://join.msn.com/?pgmarket=en-uspage=byoa/plusST=1 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 connect errors
It's simple, well not for everyone, I take personal offense to that statement Chris It may be personally TRUE! But I still take offense bee-oh-dubble-bee-dubble-egh ;~) From: Christopher Fryett [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: MQ connect errors Date: Fri, 23 Jan 2004 09:22:20 -0600 I have seen this when the load on the queue manager/server is at a high level because of the instances of the applications. When running a number of instances I have seen a potential possibility of a failure. Especially in a MCONN, MQOPEN, MQPUT, MQCLOSE, MQDISC. Also, depending on whether the instances are threads or process there could be an issue when each thread is doing a connection. Although its rare I have seen more problems with processes than threads. As for it stating a 'create object error' I don't recall getting that error, but then again it has been a while since I put a system under duress. One option you mention is a positive one. The second is to stagger each instance of an app, unless there is an actual need to create 50 instances of the application. Another is to verify that you have configured your client instances allowed for the queue manager. Unless the applications require a constant connection what you may want to do is create a pool of connections via a thread pool. It's simple, well not for everyone, and based on the number of instances required they can use the existing connections or if required additional connections within the pool can be made. One other suggestion is to put a timestamp before the MQCONN and one at MQDISC. Kick off 20-50 instances of the application at once and see where the delay is. If the applications are in a wait state to long it will actually fail. That I do know because I have reproduced that a number of times when doing high volume/client connections for WMQ. This is a bugger to track down, but you may need to try different configurations in order to determine the best route for application process, system load, thread or process, and so forth. Chris |-+--- | | Faizel Sedick | | | [EMAIL PROTECTED]| | | RTHS.CO.ZA | | | Sent by: MQSeries | | | List | | | [EMAIL PROTECTED]| | | C.AT | | | | | | | | | 01/23/2004 09:01 AM | | | Please respond to | | | MQSeries List | | | | |-+--- --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MQ connect errors | | | --| What I meant was that the actual app does not return MQ error codes. It only states that the operation as a whole failed. When I try to recreate the behaviour of the app using C code I get and error when doing similtaneous MQCONN calls. ie I run 50 instances of an app so there is potentialy 50 client connect calls which seems to generate the 2059 error. Strange. I have advised the application team not to do the continuous connect/disconnect, but to stay connected as they do constantly write to queues. That will fix their problem, but I am still can't accept this behavour. Cheers Faizel -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Friday, 23 January 2004 15:56 To: [EMAIL PROTECTED] Subject: Re: MQ connect errors Hi there, If your application does not use native MQI calls, then what is it? All of the Java-based APIs supplied by IBM provide access to the MQ Reason and Completion codes. I would think that the VB API would as well but I don't use it and don't know. Have you turned on all your event types? Sometimes this can be quite helpful in discovering exactly what call failed and on which object. Is that log entry from the host or the client? -- T.Rob -Original Message- From: Faizel Sedick [mailto:[EMAIL PROTECTED] Sent: Friday, January 23, 2004 4:07 AM To: [EMAIL PROTECTED]
Re: MQ connect errors
I am sorry to offend you! Not ;-) Anyway sometimes thread pooling is not for everyone, so keeping it simple may be the option. Chris |-+- | | Robert Broderick| | | [EMAIL PROTECTED]| | | OTMAIL.COM | | | Sent by: MQSeries| | | List | | | [EMAIL PROTECTED]| | | .AC.AT | | | | | | | | | 01/23/2004 10:41 | | | AM| | | Please respond to | | | MQSeries List | | | | |-+- --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MQ connect errors | | | --| It's simple, well not for everyone, I take personal offense to that statement Chris It may be personally TRUE! But I still take offense bee-oh-dubble-bee-dubble-egh ;~) From: Christopher Fryett [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: MQ connect errors Date: Fri, 23 Jan 2004 09:22:20 -0600 I have seen this when the load on the queue manager/server is at a high level because of the instances of the applications. When running a number of instances I have seen a potential possibility of a failure. Especially in a MCONN, MQOPEN, MQPUT, MQCLOSE, MQDISC. Also, depending on whether the instances are threads or process there could be an issue when each thread is doing a connection. Although its rare I have seen more problems with processes than threads. As for it stating a 'create object error' I don't recall getting that error, but then again it has been a while since I put a system under duress. One option you mention is a positive one. The second is to stagger each instance of an app, unless there is an actual need to create 50 instances of the application. Another is to verify that you have configured your client instances allowed for the queue manager. Unless the applications require a constant connection what you may want to do is create a pool of connections via a thread pool. It's simple, well not for everyone, and based on the number of instances required they can use the existing connections or if required additional connections within the pool can be made. One other suggestion is to put a timestamp before the MQCONN and one at MQDISC. Kick off 20-50 instances of the application at once and see where the delay is. If the applications are in a wait state to long it will actually fail. That I do know because I have reproduced that a number of times when doing high volume/client connections for WMQ. This is a bugger to track down, but you may need to try different configurations in order to determine the best route for application process, system load, thread or process, and so forth. Chris |-+--- | | Faizel Sedick | | | [EMAIL PROTECTED]| | | RTHS.CO.ZA | | | Sent by: MQSeries | | | List | | | [EMAIL PROTECTED]| | | C.AT | | | | | | | | | 01/23/2004 09:01 AM | | | Please respond to | | | MQSeries List | | | | |-+--- --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re:
Clustering question regarding communications (MQ 5.3 on z/OS 1.2)
I've come across an issue regarding the CONNAME that is made 'public' in the CLUSRCVR definition. As you all know, the value will be stored in the repositories and used by any qmgr's joining the cluster to create an auto-defined CLUSSDR channel as needed. We have internal (inside of our firewall) qmgrs in the cluster, as well as external (outside of our firewall) qmgrs in the cluster. Here's my concern: The IP address specified in the CONNAME of the CLUSRCVR definition needs to serve: qmgrs inside the firewall, who use an internal un'NAT'd address AND qmgrs outside of the firewall who need to use an external NAT'd address In a nutshell, I have one place to specify 2 addresses. I know using the DNS name would be a possible remedy, however, certain external clients are reluctant to use the DNS name - they require an actual IP address. I'm assuming someone else has run into this scenario - clustering with qmgrs in the cluster that are internal and external... Thanks in advance. Mike Davidson TSYS MQ Tech Support [EMAIL PROTECTED] The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
Re: Clustering question regarding communications (MQ 5.3 on z/OS 1.2)
Mike, Since we don't have a really good cluster channel exit, we don't let external vendors into our main cluster. Too much ability to send cluster definitions down the pipeline and get them implemented automagically. We also don't like to setup a firewall rule that allows them to access multiple QMgrs on our side. Tootough to have to harden all those QMgrs. Instead, we set them upwith point-to-point channelsto a gateway server that is in the cluster but does not house the cluster queues. A cluster alias then insures the messages get round-robined as expected. But if you are going to play with clusters through the firewall, whatever you use in the CONNAME MUST resolve on both sides. -- T.Rob -Original Message-From: Mike Davidson [mailto:[EMAIL PROTECTED]Sent: Friday, January 23, 2004 1:09 PMTo: [EMAIL PROTECTED]Subject: Clustering question regarding communications (MQ 5.3 on z/OS 1.2)I've come across an issue regarding the CONNAME that is made 'public' in the CLUSRCVR definition. As you all know, the value will be stored in the repositories and used by any qmgr's joining the cluster to create an auto-defined CLUSSDR channel as needed. We have internal (inside of our firewall) qmgrs in the cluster, as well as external (outside of our firewall) qmgrs in the cluster. Here's my concern: The IP address specified in the CONNAME of the CLUSRCVR definition needs to serve: qmgrs inside the firewall, who use an internal un'NAT'd address AND qmgrs outside of the firewall who need to use an external NAT'd address In a nutshell, I have one place to specify 2 addresses. I know using the DNS name would be a possible remedy, however, certain external clients are reluctant to use the DNS name - they require an actual IP address. I'm assuming someone else has run into this scenario - clustering with qmgrs in the cluster that are internal and external... Thanks in advance. Mike DavidsonTSYS MQ Tech Support[EMAIL PROTECTED] The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
WMQI Fail / Catch queues preventing MQRCs
If you leave the CATCH / FAIL queue unwired, and the flow has a problem with putting to the Output queue, the message gets thrown to the DLQ, where you can see the Reason code. And Event Viewer shows you the info of the failure as well. But if you do the right thing, and wire the CATCH/FAIL nodes to capture your messages, there is no record of what went wrong. Messages pile up in the CATCH/FAIL queues, and you are left scratching your head as to why, since there is no MQRC anywhere, and Event Viewer stops giving useful info. Any way to get around this? Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: WMQI Fail / Catch queues preventing MQRCs
** Note: This e-mail is subject to the disclaimer contained at the bottom of this message. ** : You need to make the ExceptionList available to the Failure or Catch path and analyse it there, or write it to the output queue with the failing message. There is quite a bit of information available re generic error handling in MQSI/WMQI/WBIMB e.g. http://www-106.ibm.com/developerworks/websphere/library/techarticles/0301_brown/brown.html. : The information transmitted in this message and attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of the sender. This message has been scanned for viruses and cleared by MailMarshal. : 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
