Re: How to check if MQClient is installed on os/390 ? - origiina l: monitor MQ z/OS with MO71
Howzit Ben, Is the original monitoring issue still outstanding? Cheers, Kerry Swemmer T-Systems South Africa (Pty) Ltd Database Administrator Computing and Desktop Services Address: DaimlerChrysler, 7 Settlers Way, East London, South Africa Postal Address: PO Box 671, East London, 5200 Phone: +27 (43) 706 2549 Fax:+27 (43) 706 2085 Mobile: +27 (83) 657 4151 E-mail: [EMAIL PROTECTED] Internet: www.t-systems.co.za -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin F. Zhou Sent: 18 February 2004 18:46 To: [EMAIL PROTECTED] Subject: Re: How to check if MQClient is installed on os/390 ? - origiina l: monitor MQ z/OS with MO71 Hi Frank, thanks a lot for sharing this with me. Ben x.2474 Bright, Frank [EMAIL PROTECTED] To: [EMAIL PROTECTED] HEALTH.COM cc: Sent by: MQSeries Subject: Re: How to check if MQClient is installed on os/390 ? - origiina Listl: monitor MQ z/OS with MO71 [EMAIL PROTECTED] AC.AT 02/18/2004 11:03 AM Please respond to MQSeries List Extract from an old post from Roger Lacroix Sent: Tuesday, March 11, 2003 6:50 PM To: [EMAIL PROTECTED] Subject: Re: 2059 trying to connect mq series 5.3 on z/os 1.4 How to know if Client Attachment Feature (CAF) is installed on z/OS? It is separate product from WMQ. To find out if you have CAF installed on z/OS, look at CHIN started-task (on z/OS under SDSF, Display Active) for the following: +CSQX099I CSQXGIP Client attachment feature available where is the z/OS queue manager name. Thanks Frank -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin F. Zhou Sent: Wednesday, February 18, 2004 10:33 AM To: [EMAIL PROTECTED] Subject: How to check if MQClient is installed on os/390 ? - origiinal: monitor MQ z/OS with MO71 ... but how can I check if MQClient component has been installed on an os/390 platform? I'm not a mvs person. thanks, bfz Kerry Swemmer [EMAIL PROTECTED] To: [EMAIL PROTECTED] TEMS.CO.ZA cc: Sent by: MQSeriesSubject: Re: monitor MQ z/OS with MO71 ? List [EMAIL PROTECTED] C.AT 02/18/2004 03:40 AM Please respond to MQSeries List Howzit bfz, We don't have the client on OS/390 so we configure the monitoring via a Windows qmgr? RU using the client or not? Cheers, Kerry Swemmer T-Systems South Africa (Pty) Ltd Database Administrator Computing and Desktop Services Address: DaimlerChrysler, 7 Settlers Way, East London, South Africa Postal Address: PO Box 671, East London, 5200 Phone: +27 (43) 706 2549 Fax:+27 (43) 706 2085 Mobile: +27 (83) 657 4151 E-mail: [EMAIL PROTECTED] Internet: www.t-systems.co.za -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin F. Zhou Sent: 17 February 2004 21:27 To: [EMAIL PROTECTED] Subject: monitor MQ z/OS with MO71 ? has anyone successfully configured MO71 to monitor QM on z/OS ? I think MO71 should be capable of that, but I couldn't make it connect. any idea? thanks, bfz 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 Any views expressed in this message are those of the individual sender, and T-Systems South Africa (Pty) Ltd accepts no liability therefore, except where the sender specifically states them to be those of T-Systems South Africa (Pty) Ltd. Although this message has been scanned for the possible presence of computer viruses prior to despatch, T-Systems South Africa (Pty) Ltd cannot be held responsible for any viruses or other material transmitted with, or as part of, this message. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive - This e-mail message and any attachments contain confidential information from Medco Health Solutions, Inc. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you
Unexpected SRVRCONN channel behaviour on 390
We have encountered an unexpected behaviour of a SRVRCONN channel on OS/390. The channel has a security channel exit applied at the 390 end and at the client end. If the client end security exit returns with MQCXP.ExitResponse set to MQXCC_CLOSE_CHANNEL, then the channel is dropped (as expected) but the channel instance with the IP address of the client and the channel instance with no IP address at the 390 end both go into STOPPED status. This means that any further connection attempts by the client fail (I think with a 2059, but I can't remember for sure - it may have been a 2009 or something else). The only way we were able to resolve this was to delete and redefine the SRVRCONN channel which is not exactly a suitable approach when many clients are connecting to the same SRVRCONN channel. Does anyone have any suggestions as to: a) Whether this is correct behaviour? b) Whether there is a way to resolve the STOPPED state without using the delete and redefine? 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
Zero bytes FDCs on a WMQ 5.3 CSD5 Solaris
Hi folks, can anyone cast some light on the potential cause of zero bytes FDCs being generated on WMQ 5.3 CSD5? My guess is that MQ tries to write them for some reason but then it does not get further that a fopen(my.DFC, w) because some other (kernel?) resource is not available... but unfortunately I cannot investigate the real problem until I manage to have WMQ cutting FDCs properly! Any clues? F. PS: all Solaris patches and kernel settings look correct and there's plenty of diskspace available 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 check if MQClient is installed on os/390 ? - origiina l: monitor MQ z/OS with MO71
Kerry, Yes. I'm asking our mainframe person to check if we have the client component installed at all. I got Error connecting via client to 'MQSZ' RC(2059) QMgr not available. at the bottom of the monitor screen. thanks, Ben Kerry Swemmer [EMAIL PROTECTED] To: [EMAIL PROTECTED] TEMS.CO.ZA cc: Sent by: MQSeriesSubject: Re: How to check if MQClient is installed on os/390 ? - origiina List l: monitor MQ z/OS with MO71 [EMAIL PROTECTED] C.AT 02/19/2004 03:03 AM Please respond to MQSeries List Howzit Ben, Is the original monitoring issue still outstanding? Cheers, Kerry Swemmer T-Systems South Africa (Pty) Ltd Database Administrator Computing and Desktop Services Address: DaimlerChrysler, 7 Settlers Way, East London, South Africa Postal Address: PO Box 671, East London, 5200 Phone: +27 (43) 706 2549 Fax:+27 (43) 706 2085 Mobile: +27 (83) 657 4151 E-mail: [EMAIL PROTECTED] Internet: www.t-systems.co.za -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin F. Zhou Sent: 18 February 2004 18:46 To: [EMAIL PROTECTED] Subject: Re: How to check if MQClient is installed on os/390 ? - origiina l: monitor MQ z/OS with MO71 Hi Frank, thanks a lot for sharing this with me. Ben x.2474 Bright, Frank [EMAIL PROTECTED] To: [EMAIL PROTECTED] HEALTH.COM cc: Sent by: MQSeries Subject: Re: How to check if MQClient is installed on os/390 ? - origiina Listl: monitor MQ z/OS with MO71 [EMAIL PROTECTED] AC.AT 02/18/2004 11:03 AM Please respond to MQSeries List Extract from an old post from Roger Lacroix Sent: Tuesday, March 11, 2003 6:50 PM To: [EMAIL PROTECTED] Subject: Re: 2059 trying to connect mq series 5.3 on z/os 1.4 How to know if Client Attachment Feature (CAF) is installed on z/OS? It is separate product from WMQ. To find out if you have CAF installed on z/OS, look at CHIN started-task (on z/OS under SDSF, Display Active) for the following: +CSQX099I CSQXGIP Client attachment feature available where is the z/OS queue manager name. Thanks Frank -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin F. Zhou Sent: Wednesday, February 18, 2004 10:33 AM To: [EMAIL PROTECTED] Subject: How to check if MQClient is installed on os/390 ? - origiinal: monitor MQ z/OS with MO71 ... but how can I check if MQClient component has been installed on an os/390 platform? I'm not a mvs person. thanks, bfz Kerry Swemmer [EMAIL PROTECTED] To: [EMAIL PROTECTED] TEMS.CO.ZA cc: Sent by: MQSeriesSubject: Re: monitor MQ z/OS with MO71 ? List [EMAIL PROTECTED] C.AT 02/18/2004 03:40 AM Please respond to MQSeries List Howzit bfz, We don't have the client on OS/390 so we configure the monitoring via a Windows qmgr? RU using the client or not? Cheers, Kerry Swemmer T-Systems South Africa (Pty) Ltd Database Administrator Computing and Desktop Services Address: DaimlerChrysler, 7 Settlers Way, East London, South Africa Postal Address: PO Box 671, East London, 5200 Phone: +27 (43) 706 2549 Fax:+27 (43) 706 2085 Mobile: +27 (83) 657 4151 E-mail: [EMAIL PROTECTED] Internet: www.t-systems.co.za -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin F. Zhou Sent: 17 February 2004 21:27 To: [EMAIL PROTECTED] Subject: monitor MQ z/OS with MO71 ? has anyone successfully configured MO71 to monitor QM on z/OS ? I think MO71 should be capable of that, but I couldn't make it connect. any idea? thanks, bfz 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 Any views expressed in this message are those of the individual sender, and T-Systems South Africa (Pty) Ltd accepts no liability therefore, except where the sender specifically states them to be those of T-Systems South Africa (Pty) Ltd. Although this message has been scanned for the possible presence of computer viruses prior to despatch, T-Systems South Africa (Pty) Ltd cannot be held responsible for any viruses or other material transmitted
shared Q on ZOS
I realize they are not many ZOS lurkers, but this has been an experience once I got the correct DSGNAME in the ZPARM, then the group attach worked, so it is transparent but Top Secret wouldn't give us the error we needed until the combinations were correct seems like Top Secret was returning a not authorized code that MQ didn't interpret, and just aborted did find all the reason codes at the end of the manual, and they have been real accurate surprised as to the accuracy of the set up guide, we have had good luck with most everything a little weak on the DB2 parms needed for the, didn't redo the XPARM since it stated that it defaults to the QSG from the ZPARM however we are having difficulty translating the RACF to Top Secret parms what is the impact of running qsg-name.NO.SUBSYS.SECURITY Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic --
Re: Automatic Channel Restart
Brent, The only thing that occurs to me is that a hard stop was issued for that channel before the shutdown. Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Brent Ireland Sent: Wednesday, February 18, 2004 4:36 PM To: [EMAIL PROTECTED] Subject: Automatic Channel Restart I am running v5.3 with CSD05 on Win2K. I have setup the MQSeries service to automatically restart. If i reboot the server i noticed that everything starts as before except for the Server channel. The status of this channel is stopped. I then have to do a manual start to get it running. Can someone please explain this to me? :) Brent Ireland CAE 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: Unexpected SRVRCONN channel behaviour on 390
David Try : MQXCC_SUPPRESS_FUNCTION Suppress function. For the channel security exit, this indicates that the channel should be terminated. Instead of : MQXCC_CLOSE_CHANNEL Close channel. This value can be set by any type of channel exit except an auto-definition exit. It causes the message channel agent (MCA) to close the channel. Rick |-+--- | | David C. Partridge| | | [EMAIL PROTECTED] | | | | | | Sent by: MQSeries List | | | [EMAIL PROTECTED] | | | | | | | | | | | | Thursday February 19, 2004 05:07 AM | | | Please respond to MQSeries List | | | | |-+--- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Unexpected SRVRCONN channel behaviour on 390 | | We have encountered an unexpected behaviour of a SRVRCONN channel on OS/390. The channel has a security channel exit applied at the 390 end and at the client end. If the client end security exit returns with MQCXP.ExitResponse set to MQXCC_CLOSE_CHANNEL, then the channel is dropped (as expected) but the channel instance with the IP address of the client and the channel instance with no IP address at the 390 end both go into STOPPED status. This means that any further connection attempts by the client fail (I think with a 2059, but I can't remember for sure - it may have been a 2009 or something else). The only way we were able to resolve this was to delete and redefine the SRVRCONN channel which is not exactly a suitable approach when many clients are connecting to the same SRVRCONN channel. Does anyone have any suggestions as to: a) Whether this is correct behaviour? b) Whether there is a way to resolve the STOPPED state without using the delete and redefine? 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: Automatic Channel Restart
Hi Don, I do not know how a hard stop was issued. I removed CSD05 and discovered that the server channel status is now inactive after a reboot. The requestor channel on the IBM is also at an inactive status. When i start the requestor channel the server channel status changes to running. Does this make sense? -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Thomas, Don Sent: Thursday, February 19, 2004 9:00 AM To: [EMAIL PROTECTED] Subject: Re: Automatic Channel Restart Brent, The only thing that occurs to me is that a hard stop was issued for that channel before the shutdown. Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Brent Ireland Sent: Wednesday, February 18, 2004 4:36 PM To: [EMAIL PROTECTED] Subject: Automatic Channel Restart I am running v5.3 with CSD05 on Win2K. I have setup the MQSeries service to automatically restart. If i reboot the server i noticed that everything starts as before except for the Server channel. The status of this channel is stopped. I then have to do a manual start to get it running. Can someone please explain this to me? :) Brent Ireland CAE 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 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
Orphaned connection issue/keepalive HELP!!
We run MQ 2.1 on OS/390 On windows and unix boxes lives a mutant version of code that executes MQ Connects...opens...puts ect to the QMGR on the OS390. We constantly have a buildup of connections that are unused for hours and days. To our installation, these are orphaned connections and cannot be reused. The programmer who maintains the client code on the windows/unix boxes tells me that JAVA treats a connection as an object. If an object is not used for a short time(I know...not very descriptive..his words...and I am a mainframe jockey) JAVA will kill the object(connection) When the connection is thus killed, MQ on the mainframe does not know it is dead and continues to carry the connection as active. Is there something I can add to my mainframe system to determine if the connection is still active on the other end(windows/unix) and if not, drop the connection on the mainframe side? ThanksLarry Larry Murray Putnam Investments Tech Services 1-617-760-3270 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 check if MQClient is installed on os/390 ? - origiina l: monitor MQ z/OS with MO71
Howzit Ben, Location Settings for MO71 on NT Connection Queue Manager:- (name of remote os/390 qmgr) Via QM:- (name of local NT qmgr) Command Queue:- SYSTEM.COMMAND.INPUT MVS ticked Monitoring Monitor Queue:- LUMON (local on NT and remote on os/390) There must also be the necessary channels defined between the two qmgrs. HTH, Kerry Swemmer T-Systems South Africa (Pty) Ltd Database Administrator Computing and Desktop Services Address: DaimlerChrysler, 7 Settlers Way, East London, South Africa Postal Address: PO Box 671, East London, 5200 Phone: +27 (43) 706 2549 Fax:+27 (43) 706 2085 Mobile: +27 (83) 657 4151 E-mail: [EMAIL PROTECTED] Internet: www.t-systems.co.za -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin F. Zhou Sent: 19 February 2004 14:52 To: [EMAIL PROTECTED] Subject: Re: How to check if MQClient is installed on os/390 ? - origiina l: monitor MQ z/OS with MO71 Kerry, Yes. I'm asking our mainframe person to check if we have the client component installed at all. I got Error connecting via client to 'MQSZ' RC(2059) QMgr not available. at the bottom of the monitor screen. thanks, Ben Kerry Swemmer [EMAIL PROTECTED] To: [EMAIL PROTECTED] TEMS.CO.ZA cc: Sent by: MQSeriesSubject: Re: How to check if MQClient is installed on os/390 ? - origiina List l: monitor MQ z/OS with MO71 [EMAIL PROTECTED] C.AT 02/19/2004 03:03 AM Please respond to MQSeries List Howzit Ben, Is the original monitoring issue still outstanding? Cheers, Kerry Swemmer T-Systems South Africa (Pty) Ltd Database Administrator Computing and Desktop Services Address: DaimlerChrysler, 7 Settlers Way, East London, South Africa Postal Address: PO Box 671, East London, 5200 Phone: +27 (43) 706 2549 Fax:+27 (43) 706 2085 Mobile: +27 (83) 657 4151 E-mail: [EMAIL PROTECTED] Internet: www.t-systems.co.za -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin F. Zhou Sent: 18 February 2004 18:46 To: [EMAIL PROTECTED] Subject: Re: How to check if MQClient is installed on os/390 ? - origiina l: monitor MQ z/OS with MO71 Hi Frank, thanks a lot for sharing this with me. Ben x.2474 Bright, Frank [EMAIL PROTECTED] To: [EMAIL PROTECTED] HEALTH.COM cc: Sent by: MQSeries Subject: Re: How to check if MQClient is installed on os/390 ? - origiina Listl: monitor MQ z/OS with MO71 [EMAIL PROTECTED] AC.AT 02/18/2004 11:03 AM Please respond to MQSeries List Extract from an old post from Roger Lacroix Sent: Tuesday, March 11, 2003 6:50 PM To: [EMAIL PROTECTED] Subject: Re: 2059 trying to connect mq series 5.3 on z/os 1.4 How to know if Client Attachment Feature (CAF) is installed on z/OS? It is separate product from WMQ. To find out if you have CAF installed on z/OS, look at CHIN started-task (on z/OS under SDSF, Display Active) for the following: +CSQX099I CSQXGIP Client attachment feature available where is the z/OS queue manager name. Thanks Frank -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin F. Zhou Sent: Wednesday, February 18, 2004 10:33 AM To: [EMAIL PROTECTED] Subject: How to check if MQClient is installed on os/390 ? - origiinal: monitor MQ z/OS with MO71 ... but how can I check if MQClient component has been installed on an os/390 platform? I'm not a mvs person. thanks, bfz Kerry Swemmer [EMAIL PROTECTED] To: [EMAIL PROTECTED] TEMS.CO.ZA cc: Sent by: MQSeriesSubject: Re: monitor MQ z/OS with MO71 ? List [EMAIL PROTECTED] C.AT 02/18/2004 03:40 AM Please respond to MQSeries List Howzit bfz, We don't have the client on OS/390 so we configure the monitoring via a Windows qmgr? RU using the client or not? Cheers, Kerry Swemmer T-Systems South Africa (Pty) Ltd Database Administrator Computing and Desktop Services Address: DaimlerChrysler, 7 Settlers Way, East London, South Africa Postal Address: PO Box 671, East London, 5200 Phone: +27 (43) 706 2549 Fax:+27 (43) 706 2085 Mobile: +27 (83) 657 4151 E-mail: [EMAIL PROTECTED] Internet: www.t-systems.co.za -Original
MQGET error 2119
We have an application getting a MQGET reason code 2119 (X'847') MQRC-NOT-CONVERTED. The sending application is an NT client to a QMGR on a SUN UNIX box. The receiver is a MVS CICS application.The MQMD encoding is X'111' (273) and the codecharactersetid is X'1B5 (437). The MQMD-FORMAT is MQSTR. The MQ GMO is ( x'4020') GET-CONVERT + BROWSE-NEXT. The data in the buffer is the unconverted lower case ASCII characters ( I can see it via CEDF). The explanation of the code indicates a problem with either the encoding, format or ccsid fields. The only field I can not confirm as valid is the encoding X'111'. Can anyone explain the RC=2119? The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
Re: Unexpected SRVRCONN channel behaviour on 390
Richard, Thanks for the suggestion. Indeed we could change the code to use MQXCC_SUPPRESS_FUNCTION to see if that worked as we expect, and if it did and issue a PTF to our customers (after a lot of testing). However I'm trying to understand whether this is the *correct* response (even assuming that it resolves the problem). The reason I'm reluctant to get our lab to change the code is that without a clear understanding of the exact *intended* behaviour of MQ in these circumstances, we might end up changing things in a way that works for one customer and leaves another with a different (and possibly worse) position. The problem here isn't what the documentation tells you, but what it doesn't (such as side effects). Cheers Dave 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: Automatic Channel Restart
Brent, Yes it does make sense. The requestor channel is intended to start the server channel. That's the design of the requester/server channel pairing, although we do not currently use that configuration in my environment. It does seem suspicious though that the problem stops after removing the latest CSD. Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Brent Ireland Sent: Thursday, February 19, 2004 9:27 AM To: [EMAIL PROTECTED] Subject: Re: Automatic Channel Restart Hi Don, I do not know how a hard stop was issued. I removed CSD05 and discovered that the server channel status is now inactive after a reboot. The requestor channel on the IBM is also at an inactive status. When i start the requestor channel the server channel status changes to running. Does this make sense? -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Thomas, Don Sent: Thursday, February 19, 2004 9:00 AM To: [EMAIL PROTECTED] Subject: Re: Automatic Channel Restart Brent, The only thing that occurs to me is that a hard stop was issued for that channel before the shutdown. Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Brent Ireland Sent: Wednesday, February 18, 2004 4:36 PM To: [EMAIL PROTECTED] Subject: Automatic Channel Restart I am running v5.3 with CSD05 on Win2K. I have setup the MQSeries service to automatically restart. If i reboot the server i noticed that everything starts as before except for the Server channel. The status of this channel is stopped. I then have to do a manual start to get it running. Can someone please explain this to me? :) Brent Ireland CAE 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 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 5.2.1 to 5.3 -- Removal of MA88
Rao - Over the years I've seen alot of unique application programing methods. I just wanted to make sure that if in some way you were using MA88 in the support pack form, it would be best to remove it before installing WMQ v5.3. The Qmgr platforms that I currently deal with are UNIX (Solaris and HPUX) and NT Enterprise 4.0 / 6a. Our web based message service is written is Java and utilizes the MA88 libararies and jar files. We had tested JMS but found it to be too slow. The developers test the code bundle from their Windows environment. In the Solaris environment, you would execute a package remove command. In the Windows environment, use add/remove programs for IBM MQSeries Classes for Java and Java Message Service and definately remove the folders. Please let me know if I may be of further assistance. Regards, Jan Janette M. Hanchak Lead Systems Software Analyst Eaton Electrical Information Technology Office: 412-893-3579 Cell: 412-716-3168 Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Eaton Website: www.EatonElectrical.com http://www.EatonElectrical.com -Original Message- From: Adiraju, Rao [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 18, 2004 5:25 PM To: [EMAIL PROTECTED] Subject: Re: MQ 5.2.1 to 5.3 -- Removal of MA88 Jan Luckily we don't have this issue, but I am curios to know more about it: 1) First of all MA88 support pack description says it is applicable only to HP boxes and doesn't say anything about NT / WINDOWS. 2) the original question and my reply was related to migration tasks for WINDOWS platform. Please excuse me, if the doco is incorrect and out there people are using this support pack on WINDOWS platforms. 3) I have had a quick look at the manual that you mentioned, it simply states that these are now part of V5.3. But it doesn't mention about how to uninstall the support pack. 4) uninstall of support pack - does it mean deleting the folders where the exe resides and/or removing it through control panel - ADD/REMOVE programs utility. Cheers Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Wellington - New Zealand Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 -Original Message- From: Hanchak, Jan M [mailto:[EMAIL PROTECTED] Sent: 19 February 2004 10:38 AM To: [EMAIL PROTECTED] Subject: Re: MQ 5.2.1 to 5.3 -- Removal of MA88 I'm currently working with Sun Solaris, HPUX, and NT platforms that utilize MQ java library and jar files. For a clean install, the MA88 support pack was removed after the MQSeries v5.2 application was removed. If you look at the Quick Beginnings guide, under What's New ... and in Chapter 1, Planning to Install, you should find your answer. Regards, Jan Janette M. Hanchak Lead Systems Software Analyst Eaton Electrical Information Technology Office: 412-893-3579 Cell: 412-716-3168 Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Eaton Website: www.EatonElectrical.com http://www.EatonElectrical.com -Original Message- From: Joe H. Smith [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 18, 2004 4:25 PM To: [EMAIL PROTECTED] Subject: Re: MQ 5.2.1 to 5.3 -- Removal of MA88 Do you know if the removal of MA88 is required on OS/400? Any thoughts on how to completly remove MA88 on an iSeries machine? Joan Hughes Brown Shoe / Famous Footwear Technical Specialist 608-827-3523 Hanchak, Jan M [EMAIL PROTECTED]To: [EMAIL PROTECTED] N.COM cc: Sent by: MQSeriesSubject: Re: MQ 5.2.1 to 5.3 List [EMAIL PROTECTED] n.AC.AT 02/18/2004 03:10 PM Please respond to MQSeries List If I may add one more item ... If you are utilizing the support pack MA88 - MQ java library and jar files, this must be removed as well. WebSphere MQ v5.3 installation includes the MQ java library and jar files should your application need to utilize them. Regards, Jan Janette M. Hanchak Lead Systems Software Analyst Eaton Electrical Information Technology
Re: MQGET error 2119
Strange indeed. CCSID 437 (US-ASCII) is a normally supported CCSID on 390 for conversion to 037 and, or 500 (subject to a few quirks with some special characters). You've covered the usual issues (e.g. MQFMT_STRING), and anyway you would have got MQRC_FORMAT_ERROR if the format had been MQFMT_NONE. The encoding x'111' is MQENC_INTEGER_NORMAL | MQENC_DECIMAL_NORMAL | MQENC_FLOAT_IEEE_NORMAL which is the encoding I would expect from a Solaris QM which is IIRC a big-endian system. I assume that the field MQMD.CodedCharacterSetId was set by the application to MQCCSI_Q_MGR just prior to the MQGET? Is that correct or was it some other value? If it was set to MQCCSI_Q_MGR, then what is the qmgr CCSID? David Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Orphaned connection issue/keepalive HELP!!
Use the TCP Keepalive setting, assuming you are using tcp. It is a qmgr config item. Neil -Original Message- From: Larry Murray [mailto:[EMAIL PROTECTED] Sent: 19 February 2004 14:35 To: [EMAIL PROTECTED] Subject: Orphaned connection issue/keepalive HELP!! We run MQ 2.1 on OS/390 On windows and unix boxes lives a mutant version of code that executes MQ Connects...opens...puts ect to the QMGR on the OS390. We constantly have a buildup of connections that are unused for hours and days. To our installation, these are orphaned connections and cannot be reused. The programmer who maintains the client code on the windows/unix boxes tells me that JAVA treats a connection as an object. If an object is not used for a short time(I know...not very descriptive..his words...and I am a mainframe jockey) JAVA will kill the object(connection) When the connection is thus killed, MQ on the mainframe does not know it is dead and continues to carry the connection as active. Is there something I can add to my mainframe system to determine if the connection is still active on the other end(windows/unix) and if not, drop the connection on the mainframe side? ThanksLarry Larry Murray Putnam Investments Tech Services 1-617-760-3270 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: Unexpected SRVRCONN channel behaviour on 390
Hi, In my exit, I use MQXCC_SUPPRESS_FUNCTION to terminate unwanted connections. My understanding of the differences between MQXCC_SUPPRESS_FUNCTION and MQXCC_CLOSE_CHANNEL is that suppress only gets rid of the current occurrence of the connection, whereas close closes the channel (in IBM terminology close equals stop). Note: I have never tested this but from your experience that sounds right. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting David C. Partridge [EMAIL PROTECTED]: Richard, Thanks for the suggestion. Indeed we could change the code to use MQXCC_SUPPRESS_FUNCTION to see if that worked as we expect, and if it did and issue a PTF to our customers (after a lot of testing). However I'm trying to understand whether this is the *correct* response (even assuming that it resolves the problem). The reason I'm reluctant to get our lab to change the code is that without a clear understanding of the exact *intended* behaviour of MQ in these circumstances, we might end up changing things in a way that works for one customer and leaves another with a different (and possibly worse) position. The problem here isn't what the documentation tells you, but what it doesn't (such as side effects). Cheers Dave 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 5.2.1 to 5.3 -- Removal of MA88
Adiraju, 1. The MA88 doc does list the platforms it supports and it does list Windows. 2. No comment 3. MA88 can be removed using the standard mechanism for each given platform. In the case of Windows, you can go to StartSettingsControl PanelAdd/Remove Programs 4. See 3. above But, what is confusing is the description in the V5.3 Quickstart manual for defining the CLASSPATH env var vs. what the Using Java manual requires. They're not the same! Which one should be used? Adiraju, Rao [EMAIL PROTECTED] To: [EMAIL PROTECTED] Z.CO.NZ cc: Sent by: Subject: Re: MQ 5.2.1 to 5.3 -- Removal of MA88 MQSeries List [EMAIL PROTECTED] en.AC.AT 02/18/2004 05:25 PM Please respond to MQSeries List Jan Luckily we don't have this issue, but I am curios to know more about it: 1) First of all MA88 support pack description says it is applicable only to HP boxes and doesn't say anything about NT / WINDOWS. 2) the original question and my reply was related to migration tasks for WINDOWS platform. Please excuse me, if the doco is incorrect and out there people are using this support pack on WINDOWS platforms. 3) I have had a quick look at the manual that you mentioned, it simply states that these are now part of V5.3. But it doesn't mention about how to uninstall the support pack. 4) uninstall of support pack - does it mean deleting the folders where the exe resides and/or removing it through control panel - ADD/REMOVE programs utility. Cheers Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Wellington - New Zealand Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 -Original Message- From: Hanchak, Jan M [mailto:[EMAIL PROTECTED] Sent: 19 February 2004 10:38 AM To: [EMAIL PROTECTED] Subject: Re: MQ 5.2.1 to 5.3 -- Removal of MA88 I'm currently working with Sun Solaris, HPUX, and NT platforms that utilize MQ java library and jar files. For a clean install, the MA88 support pack was removed after the MQSeries v5.2 application was removed. If you look at the Quick Beginnings guide, under What's New ... and in Chapter 1, Planning to Install, you should find your answer. Regards, Jan Janette M. Hanchak Lead Systems Software Analyst Eaton Electrical Information Technology Office: 412-893-3579 Cell: 412-716-3168 Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Eaton Website: www.EatonElectrical.com http://www.EatonElectrical.com -Original Message- From: Joe H. Smith [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 18, 2004 4:25 PM To: [EMAIL PROTECTED] Subject: Re: MQ 5.2.1 to 5.3 -- Removal of MA88 Do you know if the removal of MA88 is required on OS/400? Any thoughts on how to completly remove MA88 on an iSeries machine? Joan Hughes Brown Shoe / Famous Footwear Technical Specialist 608-827-3523 Hanchak, Jan M [EMAIL PROTECTED]To: [EMAIL PROTECTED] N.COM cc: Sent by: MQSeriesSubject: Re: MQ 5.2.1 to 5.3 List [EMAIL PROTECTED] n.AC.AT 02/18/2004 03:10 PM Please respond to MQSeries List If I may add one more item ... If you are utilizing the support pack MA88 - MQ java library and jar files, this must be removed as well. WebSphere MQ v5.3 installation includes the MQ java library and jar files should your application need to utilize them. Regards, Jan Janette M. Hanchak Lead Systems Software Analyst Eaton Electrical Information Technology Office: 412-893-3579 Cell: 412-716-3168 Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Eaton Website: www.EatonElectrical.com http://www.EatonElectrical.com -Original Message- From: Adiraju, Rao [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 18, 2004 3:30 PM To: [EMAIL PROTECTED] Subject: Re: MQ 5.2.1 to
Re: MQGET error 2119
Yes, it is set to MQCCSI_Q_MGR (=X'311') prior to the MQGET. David C. Partridge [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 02/19/2004 10:21 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: MQGET error 2119 Strange indeed. CCSID 437 (US-ASCII) is a normally supported CCSID on 390 for conversion to 037 and, or 500 (subject to a few quirks with some special characters). You've covered the usual issues (e.g. MQFMT_STRING), and anyway you would have got MQRC_FORMAT_ERROR if the format had been MQFMT_NONE. The encoding x'111' is MQENC_INTEGER_NORMAL | MQENC_DECIMAL_NORMAL | MQENC_FLOAT_IEEE_NORMAL which is the encoding I would expect from a Solaris QM which is IIRC a big-endian system. I assume that the field MQMD.CodedCharacterSetId was set by the application to MQCCSI_Q_MGR just prior to the MQGET? Is that correct or was it some other value? If it was set to MQCCSI_Q_MGR, then what is the qmgr CCSID? David Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
Re: Unexpected SRVRCONN channel behaviour on 390
Interesting this.. I use MQXCC_CLOSE_CHANNEL and this just 'closes' the channel instance involved, all other active CLNTCONNs continue to run without any issue. I haven't used QXCC_SUPPRESS_FUNCTION.. perhaps I should. One other interesting/confusing aspect is that if the connection attempt is issued from a C or COBOL program the response back to the client is a 2059, whereas if JAVA is the client, the code returned, is a 2063. Roger Lacroix [EMAIL PROTECTED] To:[EMAIL PROTECTED] LWARE.BIZ cc: Sent by: MQSeries Subject: Re: Unexpected SRVRCONN channel behaviour on 390 List [EMAIL PROTECTED] .AT 02/19/04 11:08 AM Please respond to MQSeries List Hi, In my exit, I use MQXCC_SUPPRESS_FUNCTION to terminate unwanted connections. My understanding of the differences between MQXCC_SUPPRESS_FUNCTION and MQXCC_CLOSE_CHANNEL is that suppress only gets rid of the current occurrence of the connection, whereas close closes the channel (in IBM terminology close equals stop). Note: I have never tested this but from your experience that sounds right. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting David C. Partridge [EMAIL PROTECTED]: Richard, Thanks for the suggestion. Indeed we could change the code to use MQXCC_SUPPRESS_FUNCTION to see if that worked as we expect, and if it did and issue a PTF to our customers (after a lot of testing). However I'm trying to understand whether this is the *correct* response (even assuming that it resolves the problem). The reason I'm reluctant to get our lab to change the code is that without a clear understanding of the exact *intended* behaviour of MQ in these circumstances, we might end up changing things in a way that works for one customer and leaves another with a different (and possibly worse) position. The problem here isn't what the documentation tells you, but what it doesn't (such as side effects). Cheers Dave 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: MQGET error 2119
My MQ headers have #define MQCCSI_Q_MGR 0 So, if it was set to x'311' then you're asking for conversion from 437 to 785. Now my ccsid.tbl file for MQ 5.3 has never heard of CCSID 785 so I guess that's the problem. David -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Ronald Weinger Sent: 19 February 2004 16:38 To: [EMAIL PROTECTED] Subject: Re: MQGET error 2119 Yes, it is set to MQCCSI_Q_MGR (=X'311') prior to the MQGET. David C. Partridge [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 02/19/2004 10:21 AM Please respond to MQSeries List To:[EMAIL PROTECTED] cc: Subject:Re: MQGET error 2119 Strange indeed. CCSID 437 (US-ASCII) is a normally supported CCSID on 390 for conversion to 037 and, or 500 (subject to a few quirks with some special characters). You've covered the usual issues (e.g. MQFMT_STRING), and anyway you would have got MQRC_FORMAT_ERROR if the format had been MQFMT_NONE. The encoding x'111' is MQENC_INTEGER_NORMAL | MQENC_DECIMAL_NORMAL | MQENC_FLOAT_IEEE_NORMAL which is the encoding I would expect from a Solaris QM which is IIRC a big-endian system. I assume that the field MQMD.CodedCharacterSetId was set by the application to MQCCSI_Q_MGR just prior to the MQGET? Is that correct or was it some other value? If it was set to MQCCSI_Q_MGR, then what is the qmgr CCSID? David Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. 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: Automatic Channel Restart
The other advantage of a RQSTR/SDR pair is that you can start the channel from either end (assuming the other end is not in STOPPED state). Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Wyatt, T. Rob Sent: 19 February 2004 17:25 To: [EMAIL PROTECTED] Subject: Re: Automatic Channel Restart Slight clarification here...the RQSTR is intended to start *either* a SVR or a SDR channel. The difference between a SVR and a SDR is not whether they can be started remotely, but what they do when the RQSTR is not the same QMgr as provided in the SDR/SVR CONNAME. A SDR will always try to connect to the QMgr in it's CONNAME whereas a SVR will try to connect to the IP address and port of the RQSTR that called it. If a SVR is used simply because there is a RQSTR on the other side, and without understanding the difference, it may result in an unintended security exposure. In the absence of a security exit or SSL, anyone who knows the name of a SVR can create a RQSTR to start it and divert it to any arbitrary address. On the other hand, attempting the same thing with a SDR results in the SDR starting to it's intended destination. -- T.Rob -Original Message- From: Thomas, Don [mailto:[EMAIL PROTECTED] Sent: Thursday, February 19, 2004 9:59 AM To: [EMAIL PROTECTED] Subject: Re: Automatic Channel Restart Brent, Yes it does make sense. The requestor channel is intended to start the server channel. That's the design of the requester/server channel pairing, although we do not currently use that configuration in my environment. It does seem suspicious though that the problem stops after removing the latest CSD. Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * 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 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 5.2.1 to 5.3 -- Removal of MA88
Rao, Your questions only apply if you are attempting an upgrade as opposed to a complete uninstall/reinstall. Due to bad experiences we had early on in our shop we never do upgrades. Our approach is to back up the objects and authorities, then completely uninstall MQ and delete the folders where it lived, then install MQ from scratch and reapply the objects and authorities. We will apply a CSD over an existing installation but any major version upgrade we always go through the uninstall/reinstall method. This way we never have to wonder whether a problem is really an MQ problem or if it is some leftover configuration from the old install. The extra steps involved (backing up the object defs and auths, then uninstalling and deleting the QMgr) generally take much less time than fixing any problems that arise from botching an upgrade by, for instance, leaving MA88 installed. I would recommend sidestepping the whole issue and just commit to performing a complete uninstall and delete of MQ. And on Windows platforms, that includes rebooting between the uninstall and reinstall to cache the changes to the registry. And in your defense, to answer some of the replies you got referring to Windows docs for this product, the MA88 download page now has this to say about Windows and other platforms: IMPORTANT ANNOUNCEMENT It should be noted that the ability to download this SupportPac from this site for the following platforms: » AIX » HP-UX » OS/390 » Linux for iSeries » Linux for zSeries » Sun Solaris » Windows has been withdrawn, and the end of service date will be 31 December 2003 (except for iSeries and OS/390 for which it is 30 April 2004). For these platforms, the function remains available shipped with the WebSphere MQ V5.3 product. For the remaining platforms » HP Tru64 » HP OVMS Alpha » HP NSK the end of service date for this SupportPac is 30 April 2005. -- T.Rob -Original Message- From: Adiraju, Rao [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 18, 2004 5:25 PM To: [EMAIL PROTECTED] Subject: Re: MQ 5.2.1 to 5.3 -- Removal of MA88 Jan Luckily we don't have this issue, but I am curios to know more about it: 1) First of all MA88 support pack description says it is applicable only to HP boxes and doesn't say anything about NT / WINDOWS. 2) the original question and my reply was related to migration tasks for WINDOWS platform. Please excuse me, if the doco is incorrect and out there people are using this support pack on WINDOWS platforms. 3) I have had a quick look at the manual that you mentioned, it simply states that these are now part of V5.3. But it doesn't mention about how to uninstall the support pack. 4) uninstall of support pack - does it mean deleting the folders where the exe resides and/or removing it through control panel - ADD/REMOVE programs utility. Cheers Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Wellington - New Zealand Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 -Original Message- From: Hanchak, Jan M [mailto:[EMAIL PROTECTED] Sent: 19 February 2004 10:38 AM To: [EMAIL PROTECTED] Subject: Re: MQ 5.2.1 to 5.3 -- Removal of MA88 I'm currently working with Sun Solaris, HPUX, and NT platforms that utilize MQ java library and jar files. For a clean install, the MA88 support pack was removed after the MQSeries v5.2 application was removed. If you look at the Quick Beginnings guide, under What's New ... and in Chapter 1, Planning to Install, you should find your answer. Regards, Jan Janette M. Hanchak Lead Systems Software Analyst Eaton Electrical Information Technology Office: 412-893-3579 Cell: 412-716-3168 Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Eaton Website: www.EatonElectrical.com http://www.EatonElectrical.com -Original Message- From: Joe H. Smith [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 18, 2004 4:25 PM To: [EMAIL PROTECTED] Subject: Re: MQ 5.2.1 to 5.3 -- Removal of MA88 Do you know if the removal of MA88 is required on OS/400? Any thoughts on how to completly remove MA88 on an iSeries machine? Joan Hughes Brown Shoe / Famous Footwear Technical Specialist 608-827-3523 Hanchak, Jan M [EMAIL PROTECTED]To: [EMAIL PROTECTED] N.COM cc: Sent by: MQSeriesSubject: Re: MQ 5.2.1 to 5.3 List [EMAIL PROTECTED] n.AC.AT
Re: Automatic Channel Restart
Dave, That kind of implies you can't start a RQSTR/SVR pair from either side. Is that what you were saying? Because we have a few SVRs and I can start them up on the sending or receiving side just fine. -- T.Rob -Original Message- From: David C. Partridge [mailto:[EMAIL PROTECTED] Sent: Thursday, February 19, 2004 12:40 PM To: [EMAIL PROTECTED] Subject: Re: Automatic Channel Restart The other advantage of a RQSTR/SDR pair is that you can start the channel from either end (assuming the other end is not in STOPPED state). Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Wyatt, T. Rob Sent: 19 February 2004 17:25 To: [EMAIL PROTECTED] Subject: Re: Automatic Channel Restart Slight clarification here...the RQSTR is intended to start *either* a SVR or a SDR channel. The difference between a SVR and a SDR is not whether they can be started remotely, but what they do when the RQSTR is not the same QMgr as provided in the SDR/SVR CONNAME. A SDR will always try to connect to the QMgr in it's CONNAME whereas a SVR will try to connect to the IP address and port of the RQSTR that called it. If a SVR is used simply because there is a RQSTR on the other side, and without understanding the difference, it may result in an unintended security exposure. In the absence of a security exit or SSL, anyone who knows the name of a SVR can create a RQSTR to start it and divert it to any arbitrary address. On the other hand, attempting the same thing with a SDR results in the SDR starting to it's intended destination. -- T.Rob 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: MQIPT
Funny you should ask. As I write this, I am in the middle of setting up MQIPT on my LINUX workstation to test it out. It looks easy enough, but we will see. Right off the bat I got an error from an install shell script complaining that it tried to install an LDAP application that conflicted wit an already installed package. When I get it fired up, I'll let ya know how it goes. The main alternative is VPN. Because it is by nature, a secure tunnel, SSL is not required at the MQ level. But at least for an enterprise implementation with extremely sensitive data, a cheap VPN solution may not be secure enough. I have used VPN to remotely administrate MQ in the past, but I really don't know allot about it technically. One of the network security folks here told me just today that while the price range is quite wide, $10,000 + would not be unheard of to implement a VPN solution. Of course MQIPT is free, and what's a couple of servers to put it on? $5,000 ? Personally, I like the MQIPT solution better (probably because I understand it better). But on the other hand if a company has non-MQ reasons to support a VPN into there private LAN, why not use it for MQ access as well? performance possibly? Anyway, good luck I have an MQIPT server to set up Cheers Bill Anderson SITA Atlanta, GA Standard Messaging Engineering WebSphere MQ Service Owner 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Darren Douch [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: MQIPT List [EMAIL PROTECTED] N.AC.AT 02/19/2004 02:41 PM Please respond to MQSeries List Trying to save myself some digging around any views on the pros / cons of MQIPT vs. a full blown queue manager for supporting secure MQ connections over the internet? And are there any views (or documents) about the performance / scalability of MQIPT? Thanks folks. Darren. 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: runmqlsr
Set up the listener to run from inetd. You will need to have root authority to set this up initially. I copied the below information from the Quick Beginnings Manual for 5.2. You will not see runmqlsr as a running process but should see amqcrsta running. http://www-306.ibm.com/software/integration/mqfamily/library/manualsa/amqaac03/amqaac03tfrm.htm Edit the file /etc/services. If you do not have the following line in that file, add it as shown: 2. MQSeries 1414/tcp # MQSeries channel listener Note: You must be logged in as a superuser, or as root, to perform step 1 to step 3. Edit the file /etc/inetd.conf. If you do not have the following line in that file, add it as shown: 4. MQSeries stream tcp nowait mqm /usr/mqm/bin/amqcrsta amqcrsta Note: If you are not creating venus.queue.manager as the default queue manager (in step 4) on this workstation, add -m venus.queue.manager to the end of this line to specify the name of the queue manager to use. Enter the command refresh -s inetd. Polly -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Thursday, February 19, 2004 1:46 PM To: [EMAIL PROTECTED] Subject: runmqlsr On AIX, is there some setting to make runmqlsr start with the queue manager (in the same way that the channel initiator does), or does it need to be started with it via a startup script? Had a look through the manuals and haven't found anything. Thanks again. Darren.
FDC problem
All, One of my clients queue managers started getting the following FDCs today (see bottom). Specs: - Solaris 8 - MQ 5.3 CSD3 Any help would be appreciated. Note: This box is heavily used by WebLogic client applications. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz +--- | | WebSphere MQ First Failure Symptom Report | = | | Date/Time :- Thursday February 19 15:29:07 EST 2004 | Host Name :- wghapp1d (SunOS 5.8) | PIDS :- 5724B4103 | LVLS :- 530.3 CSD03 | Product Long Name :- WebSphere MQ for Sun Solaris | Vendor:- IBM | Probe Id :- AT041030 | Application Name :- MQM | Component :- atxStart | Build Date:- Mar 3 2003 | CMVC level:- p530-CSD03J | Build Type:- IKAP - (Production) | UserID:- 1051 (mqm) | Program Name :- amqzlaa0_nd | Process :- 4729 | Thread:- 0036 | QueueManager :- CIBOTSQ | Major Errorcode :- arcE_XAER_PROTO | Minor Errorcode :- OK | Probe Type:- INCORROUT | Probe Severity:- 2 | Probe Description :- AMQ6125: An internal WebSphere MQ error has occurred. | FDCSequenceNumber :- 0 | +--- MQM Function Stack zlaMainThread zlaProcessMessage zlaProcessXARequest zlaXAStart zsqXAStart kpiSyncPoint apiSyncPoint atmSyncPoint atxStart xcsFFST 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: FDC problem
Here is something with the same Major Errorcode arcE_XAER_PROTO and program amqzlaa0. http://www-306.ibm.com/software/integration/mqfamily/support/memos/sun/memo.txt IY37338 - An FDC with probe id AT048005 occurred in component amqzlaa0 from routine atxCommit. The return code was arcE_XAER_PROTO. But it was fixed in CSD03 according to the readme. Probe Id does not match. Might have to call IBM. From: Roger Lacroix [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: FDC problem Date: Thu, 19 Feb 2004 16:59:45 -0500 All, One of my clients queue managers started getting the following FDCs today (see bottom). Specs: - Solaris 8 - MQ 5.3 CSD3 Any help would be appreciated. Note: This box is heavily used by WebLogic client applications. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz +--- | | WebSphere MQ First Failure Symptom Report | = | | Date/Time :- Thursday February 19 15:29:07 EST 2004 | Host Name :- wghapp1d (SunOS 5.8) | PIDS :- 5724B4103 | LVLS :- 530.3 CSD03 | Product Long Name :- WebSphere MQ for Sun Solaris | Vendor:- IBM | Probe Id :- AT041030 | Application Name :- MQM | Component :- atxStart | Build Date:- Mar 3 2003 | CMVC level:- p530-CSD03J | Build Type:- IKAP - (Production) | UserID:- 1051 (mqm) | Program Name :- amqzlaa0_nd | Process :- 4729 | Thread:- 0036 | QueueManager :- CIBOTSQ | Major Errorcode :- arcE_XAER_PROTO | Minor Errorcode :- OK | Probe Type:- INCORROUT | Probe Severity:- 2 | Probe Description :- AMQ6125: An internal WebSphere MQ error has occurred. | FDCSequenceNumber :- 0 | +--- MQM Function Stack zlaMainThread zlaProcessMessage zlaProcessXARequest zlaXAStart zsqXAStart kpiSyncPoint apiSyncPoint atmSyncPoint atxStart xcsFFST 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 _ Take off on a romantic weekend or a family adventure to these great U.S. locations. http://special.msn.com/local/hotdestinations.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
MQ Client - amqmcert question
I searched the archive and found the appended query from over a year ago. I copy it here again because I have the same questions and an urgent need to understand this better. There appeared to be no response to the original posting. We have the need to identify different applications running from the same machine via different certificates. When we attempt to reference different keystores containing different identifying certs, neither amqmcert or the MQ client libraries (or .Net classes) can find the assigned MQ client certificate in the second keystore. (I hope this makes sense to someone on the list.) *** From a previous posting... I have noticed something strange and undocumented in the way of SSL certificates stores are handled in Windows MQ clients. Certificates are associated with a client thru amqmcert -d cert_number during configuration setup. Some (but not all) times, when I move the certificate store (.sto) to an other directory, or I rename it, the MQ client lost the certificate association and I have to amqmcert -d cert_number again. Question : where the association is stored ? in the .sto itself ? in the registry ? Any help or insight will be appreciated. Regards, -tom 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
runmqlsr -i vs BlockIP
Hi, With the new parameter -i which can specify the IP address to listen on, is it enough to replace the BlockIP exit program? I know BlockIP offers more including multiple IP addresses and filter userids, however, I think the new parameter together with the MCAUSER should be enough for internal MQ connection. Any comment? Cheers, Ian 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: runmqlsr -i vs BlockIP
Ian, The -i parameter lets you bind the listener to a specific IP address on the server, not a specific IP address of the remote node. This is similar to the LOCLADDR parameter on a channel definition. BlockIP is completely different and neither the runmqlsr -i parameter nor the LOCLADDR channel attribute replace it. -- T.Rob -Original Message- From: Chan, Ian M [mailto:[EMAIL PROTECTED] Sent: Thursday, February 19, 2004 9:47 PM To: [EMAIL PROTECTED] Subject: runmqlsr -i vs BlockIP Hi, With the new parameter -i which can specify the IP address to listen on, is it enough to replace the BlockIP exit program? I know BlockIP offers more including multiple IP addresses and filter userids, however, I think the new parameter together with the MCAUSER should be enough for internal MQ connection. Any comment? Cheers, Ian 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: runmqlsr -i vs BlockIP
Ah! I misunderstood from the descriptionso the BlockIP exit is still required. BTW, do you work round the clock? Your messages appear at anytime! :-) Thanks again for your clarifications. Cheers, Ian -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Wyatt, T. Rob Sent: Friday, 20 February 2004 3:12 PM To: [EMAIL PROTECTED] Subject: Re: runmqlsr -i vs BlockIP Ian, The -i parameter lets you bind the listener to a specific IP address on the server, not a specific IP address of the remote node. This is similar to the LOCLADDR parameter on a channel definition. BlockIP is completely different and neither the runmqlsr -i parameter nor the LOCLADDR channel attribute replace it. -- T.Rob -Original Message- From: Chan, Ian M [mailto:[EMAIL PROTECTED] Sent: Thursday, February 19, 2004 9:47 PM To: [EMAIL PROTECTED] Subject: runmqlsr -i vs BlockIP Hi, With the new parameter -i which can specify the IP address to listen on, is it enough to replace the BlockIP exit program? I know BlockIP offers more including multiple IP addresses and filter userids, however, I think the new parameter together with the MCAUSER should be enough for internal MQ connection. Any comment? Cheers, Ian 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
