Processing the Euro symbol in MQSeries messages
Hi, We're trying to enable our machines to be able to process the Euro symbol within MQSeries messages. We follow a hub and spoke topology here and are unable to upgrade all machine configurations to use the correct code page configurations. We have a project that will upgrade the hub and we decided to ensure the hub is able to support the Euro for any future applications connecting to it. We changed the queue manager CCSID from 850 to 858 (recommended NT code page for the Euro) and have now hit problems. We are sending messages from a HP-UX queue manager with a code page of 1208 to the new hub and finding the messages do not come across the channel. Channel conversion is set to YES and the error messages appearing in the HP-UX queue manager logs are as follows: * 03/12/03 06:25:56 AMQ6047: Conversion not supported. EXPLANATION: MQSeries is unable to convert string data tagged in CCSID 1208 to data in CCSID 858. ACTION: Check the appropriate National Language Support publications to see if the CCSIDs are supported by your system. * Does this mean that we would need to configure all our application queue managers to use the correct code pages for this to work or is this a specific issue with just conversion between 1208 and 858 code pages? Cheers, Kulbir.
Re: 2059 trying to connect mq series 5.3 on z/os 1.4
Just throwing in my 2 cents worth. You have ftp'd the client connection definition file from z/OS tot he other platform haven't you? I use this job //CLNTMQDV EXEC PGM=CSQUTIL,COND=(0,NE,TRYMQDV),PARM='QManager name' //STEPLIB DD DSN=SYS1.SCSQLOAD,DISP=SHR // DD DSN=SYS1.SCSQANLE,DISP=SHR // DD DSN=SYS1.SCSQAUTH,DISP=SHR //OUTCLNT DD DSN=CD9P07.MQDV.CLIENTS,DISP=(,CATLG), // UNIT=SYSDA,SPACE=(TRK,(3,4),RLSE), // RECFM=U,LRECL=2048,BLKSIZE=2048 //SYSPRINT DD SYSOUT=* //SYSINDD * COMMAND DDNAME(CMDCHL) MAKECLNT(OUTCLNT) CCSID(437) //CMDCHLDD * DISPLAY CHANNEL(*) ALL TYPE(CLNTCONN) Kevin Ferguson From: javier sotela [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: 2059 trying to connect mq series 5.3 on z/os 1.4 Date: Tue, 11 Mar 2003 19:10:00 -0400 Hi everyone: There is two people asking about the client attach feature on the Z/OS, if I understand correctly this feature is used only when you try to connect from z/os to a other mq series server. In my case, I'm connecting from windows or unix to the z/os. The mq server its on z/os. In this case, is the client attach feature on the Z/OS required ??? TIA. Javier S. From: Richard Crook [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: 2059 trying to connect mq series 5.3 on z/os 1.4 Date: Wed, 12 Mar 2003 10:54:26 +1300 Javier, 2059 is QMGR_NOT_AVAILABLE. Are you getting this on the client end? I presume that you have the client attach feature on the Z/OS version of MQ? On Z/OS, client attach is a seperate, chargable feature. I believe that it's included as part of the Qmgr on all the other platforms. Richard. javier sotela [EMAIL PROTECTED]@AKH-WIEN.AC.AT on 12/03/2003 10:38:31 Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:2059 trying to connect mq series 5.3 on z/os 1.4 Hi Everyone: We are trying to connect to a mq series 5.3 on z/os 1.4 from different clients, windows, unix, etc, but we are receiving a 2059 error from the mainframe. With mq series server to server the communiaction its o.k., the only problem is trying to connect client to server (at mq level). The channel server its working and connected, any ideas TIA. Javier S. _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive The contents of this e-mail are confidential. If you have received this communication by mistake, please advise the sender immediately and delete the message and any attachments. Westpac Banking Corporation, ABN 33 007 457 141, is incorporated in Australia - The contents of this e-mail are confidential. If you have received this communication by mistake, please advise the sender immediately and delete the message and any attachments. Nothing in this email designates an information system for the purposes of Section 11(a) of the New Zealand Electronic Transactions Act 2002. Westpac Banking Corporation, ABN 33 007 457 141, is incorporated in Australia - Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Client IP connections direct to an OS/390
Dennis. Thanks for your thoughts on this. I'm not sure that batching of messages really matters, especially since we are TCP in and SNA out. Our batch size is set to 50 and the batch interval set 100. We did some extensive tuning with the VTAM settings to make sure it worked as well as possible (setting RU sizes, pacing, and other NCP parameters). It just seems that skipping a box in between the app server and mainframe should increase performance by itself. My real outstanding question is, why do we get thousands of messages showing channels starting and going inactive in the CHIN log? We had an occasion last Sunday where we had between 6 and 7 thousand messages in the space of an hour. I don't understand what it is that drives MQ to be bouncing these connections like this. We have also sent this question to IBM for a better understanding. We'll discuss your thoughts on putting the QMGRs on the app servers, but we were originally told (in 1998) that we needed the MQ servers to be on their own boxes. Thanks, David Corbett Work: 651-205-2714 Pager: 651-610-3842 |-+--- | | Miller, Dennis| | | [EMAIL PROTECTED]| | | COM| | | Sent by:| | | MQSeries List | | | [EMAIL PROTECTED]| | | en.AC.AT | | | | | | | | | 03/11/2003 09:37| | | AM | | | Please respond | | | to MQSeries| | | List | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Re: Client IP connections direct to an OS/390 | ---| Dave, With the workload you describe, I think the 390 would be better optimised and easier to manage with the NT concentrators. I mean sender channels can batch dozens of messages together, whilst the client channels go one-at-a time. You also minimze the overhead of channel pooling and avoid (at least from the 390 perspective) avoid the headaches implicit in one end of the channel not controlled by the qmgr. In my mind, the tougher question is whether to forgo the NT concentrators and put qmgrs directily on the webshere servers, which in effect are already acting as concentrators. I'm skeptical about the advantage gained by having 4 inound qmgrs rather than 11. -Original Message- From: Dave Corbett [SMTP:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 9:01 AM To: [EMAIL PROTECTED] Subject: Client IP connections direct to an OS/390 Since nobody has replied to this, I am assuming that we are the only ones making extensive use of client connections direct to an OS/390 platform. So, in the hopes that someone else besides us has some experience with this architectural model, I am resending it to entice anyone with thoughts on this to respond. Thanks, David Corbett IBM MQSeries Certified Solutions Expert IBM MQSeries Certified Developer IBM MQSeries Certified Specialist - Forwarded by David P Corbett/MN/USB on 03/10/2003 10:55 AM - |-+--- | | David P Corbett | | | | | | 03/06/2003 11:14| | | AM | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Client IP connections direct to an OS/390 | ---| To anyone with experience, We originally had three NT MQ servers that would handle MQ connections from 11 websphere app servers and then had SNA channels defined to our OS/390 environment. The 11 app servers are spread across three mainframe LPARS in 4x4x3 configuration. The NT boxes served for the most part as a protocol converter from IP to
Calculating Log Size for Persistence
Hi Looking at the Systems Management guide it states that to put a persistent message the log entry size will be: 750 bytes + message length . Now the obvious question - is the MQMD included in either the overhead or message length? Regards Neil
Re: Client IP connections direct to an OS/390
Dave, The messages could be from the Disconnect Interval on the channels. You may want to check those and possibly set them to zero. Glen Shubert Dave Corbett [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 03/12/2003 09:52 AM Please respond to MQSeries List To:[EMAIL PROTECTED] cc: Subject:Re: Client IP connections direct to an OS/390 Dennis. Thanks for your thoughts on this. I'm not sure that batching of messages really matters, especially since we are TCP in and SNA out. Our batch size is set to 50 and the batch interval set 100. We did some extensive tuning with the VTAM settings to make sure it worked as well as possible (setting RU sizes, pacing, and other NCP parameters). It just seems that skipping a box in between the app server and mainframe should increase performance by itself. My real outstanding question is, why do we get thousands of messages showing channels starting and going inactive in the CHIN log? We had an occasion last Sunday where we had between 6 and 7 thousand messages in the space of an hour. I don't understand what it is that drives MQ to be bouncing these connections like this. We have also sent this question to IBM for a better understanding. We'll discuss your thoughts on putting the QMGRs on the app servers, but we were originally told (in 1998) that we needed the MQ servers to be on their own boxes. Thanks, David Corbett Work: 651-205-2714 Pager: 651-610-3842 |-+--- | | Miller, Dennis| | | [EMAIL PROTECTED]| | | COM | | | Sent by:| | | MQSeries List | | | [EMAIL PROTECTED]| | | en.AC.AT| | | | | | | | | 03/11/2003 09:37| | | AM | | | Please respond | | | to MQSeries | | | List | | | | |-+--- ---| || |To: [EMAIL PROTECTED]| |cc: | |Subject: Re: Client IP connections direct to an OS/390 | ---| Dave, With the workload you describe, I think the 390 would be better optimised and easier to manage with the NT concentrators. I mean sender channels can batch dozens of messages together, whilst the client channels go one-at-a time. You also minimze the overhead of channel pooling and avoid (at least from the 390 perspective) avoid the headaches implicit in one end of the channel not controlled by the qmgr. In my mind, the tougher question is whether to forgo the NT concentrators and put qmgrs directily on the webshere servers, which in effect are already acting as concentrators. I'm skeptical about the advantage gained by having 4 inound qmgrs rather than 11. -Original Message- From: Dave Corbett [SMTP:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 9:01 AM To: [EMAIL PROTECTED] Subject: Client IP connections direct to an OS/390 Since nobody has replied to this, I am assuming that we are the only ones making extensive use of client connections direct to an OS/390 platform. So, in the hopes that someone else besides us has some experience with this architectural model, I am resending it to entice anyone with thoughts on this to respond. Thanks, David Corbett IBM MQSeries Certified Solutions Expert IBM MQSeries Certified Developer IBM MQSeries Certified Specialist - Forwarded by David P Corbett/MN/USB on 03/10/2003 10:55 AM - |-+--- | | David P Corbett | | | | | | 03/06/2003 11:14| | | AM | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Client IP connections direct to an OS/390 | ---| To anyone with experience, We originally had three NT MQ servers that would handle MQ connections from 11 websphere app servers and then had SNA channels defined to our OS/390 environment. The 11 app servers are spread across three mainframe LPARS in 4x4x3 configuration. The NT boxes served for the most part as a protocol converter from IP to SNA. Since our OS/390 platform's tcp stack has become more robust, we have been migrating towards direct client channel
Betreft: Re: Betreft: Re: MS Access
Hi Jim, Thanks for you information. I have found the MQAX and it works fine. I will now build it is MS Access. This make my life a lot better. [EMAIL PROTECTED] op 10-03-2003 17:26:31 Aan: [EMAIL PROTECTED] cc: bcc: Onderwerp: Re: Betreft: Re: MS Access If you look in the install folder for MQSeries (either client or server), there will be another folder called Tools. In Tools, there's a folder called MQAX which contains the ActiveX samples. We used mqaxtriv.xls as our model. It's a simple spreadsheet program that puts a message on a queue when you click a button. There's no Access samples, but if you get it to work in Excel you will be able to get it to work in Access, too. [EMAIL PROTECTED] bank.nl To: MQSeries List [EMAIL PROTECTED] cc: [EMAIL PROTECTED] 03/10/2003 10:14 Subject: Betreft: Re: MS Access AM Hi Jim, Thanks for your response. Do you have more information that can help me out start a little test? I would like to know how I could connect to a queue within VBA. I wanted to include the VB examples in VBA, but I don't know how and where. I have searched the Internet, help files and so on. But without any succes :-( Any help would be appreciated. Thanks in advantage, S el Fakih Jim Ford [EMAIL PROTECTED]@AKH-WIEN.AC.AT op 10-03-2003 16:24:21 Antwoord aub aan MQSeries List [EMAIL PROTECTED] Verzonden door: MQSeries List [EMAIL PROTECTED] Aan: [EMAIL PROTECTED] cc: bcc: Onderwerp: Re: MS Access We use the ActiveX classes to combine Office and MQSeries. We mostly use it within Excel, but we've got a couple MS Access apps, too. MQSeries comes with some sample programs that we used as a basis for our development work. Semir el Fakih [EMAIL PROTECTED]To: [EMAIL PROTECTED] LBANK.NLcc: Sent by: MQSeriesSubject: MS Access List [EMAIL PROTECTED] N.AC.AT 03/10/2003 05:54 AM Please respond to MQSeries List Hi all, I have an question about MQSeries VS MS Access. Is it possible to connect through VBA of MS Access to a MQSeries Queue. I know that it is possible with Visual Basic, but I hope it will work also with VBA. Any help will be appreciated. Thanks in advantage, S el Fakih DISCLAIMER Deze e-mail en alle daarbij meegezonden bijlagen zijn uitsluitend bestemd voor de geadresseerde(n). Verstrekking aan en gebruik door anderen is niet toegestaan. Delta Lloyd N.V. sluit iedere aansprakelijkheid uit die voortvloeit uit electronische verzending. This e-mail and any attachment sent with it are intended exclusively for the addressee(s), and may not be passed on to, or made available for use by any person other than the addressee(s). Delta Lloyd N.V. rules out any and every liability resulting from any electronic transmission. ** 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 DISCLAIMER Deze e-mail en alle daarbij meegezonden bijlagen zijn uitsluitend bestemd voor de geadresseerde(n). Verstrekking aan en gebruik door anderen is niet toegestaan. Delta Lloyd N.V. sluit iedere aansprakelijkheid uit die voortvloeit uit electronische verzending. This e-mail and any attachment sent with it are intended exclusively for the addressee(s), and may not be passed on to, or made available for use by any person other than the addressee(s). Delta Lloyd N.V. rules out any and every liability resulting from any electronic transmission. ** DISCLAIMER Deze e-mail en alle daarbij meegezonden bijlagen zijn uitsluitend bestemd voor de geadresseerde(n). Verstrekking aan en gebruik door anderen is niet toegestaan. Delta Lloyd N.V. sluit iedere aansprakelijkheid uit die voortvloeit uit electronische verzending. This e-mail and any attachment sent with it are intended exclusively for the addressee(s), and may not be passed on to, or made available for use by any person other than the addressee(s). Delta Lloyd N.V. rules out any and every
Re: CHIN with millions of lines of output
I had initially thought that a WTO exit might do what you want, but I'm not entirely sure. I've only written a user exit routine to trap on a message and do other things, but I never deleted a message or altered routecodes. I think you should post this question to the OS/390 listserver. Tim Armstrong [EMAIL PROTECTED] To: [EMAIL PROTECTED] COM cc: Sent by: Subject: CHIN with millions of lines of output MQSeries List [EMAIL PROTECTED] en.AC.AT 03/11/2003 08:12 PM Please respond to MQSeries List The problem we are having is that on some of our OS/390 systems where the MQ channel initiator and master address spaces are up and running for weeks or months at a time we get enormous amounts of output. This makes searching the job logs using SDSF a prolonged and resource intensive exercise. Has anyone come up with a way to effectively segment the output? Regards Tim A 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: Listener
Thanks everyone for responding to my questions on the listener. So far, we know the problem is coming from a Websphere application, however the user is saying that no changes have been made to his programs. Since this is not the production envirionment and it is working, no plans are being made to correct the problem. -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 8:38 AM To: [EMAIL PROTECTED] Subject: Re: Listener It is possible to start an inbound requestor channel with no listener running. I'm guessing you received those messages on a requestor and not a receiver channel. Do you have requestors defined? -- T.Rob -Original Message- From: Anderson, Lizette T. (RyTull) [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 5:33 PM To: [EMAIL PROTECTED] Subject: Re: Listener I was also able to receive the message. -Original Message- From: DePeyster, Donna [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 4:02 PM To: [EMAIL PROTECTED] Subject: Re: Listener Lizette, The sender does not use a listener. Your listener can be down and you can still send messages. Since you are a mainframer, like me, check how MQ uses ports for sending by using the NETSTAT command. Donna de P. -Original Message- From: Anderson, Lizette T. (RyTull) [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 4:15 PM To: [EMAIL PROTECTED] Subject: Re: Listener Thanks for the info. I am mostly a mainframer so excuse the question, but if the port is being used( we discovered by a websphere application) how I able to send and receive messages. Is it possible, for everything to work fine even though MQ and the Websphere application are both using the same port? -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 11:45 AM To: [EMAIL PROTECTED] Subject: Re: Listener Liz, Experience sez that some other application changed or another was installed that is using that port. There is a command called netstat -a that will give you a report on the processes that have OPEN your TCP/IP ports. rout the output to a file and search the file for your port. It SHOULD show your port and who owns it. if it sez MQ then stop the QMGR from startup at boot time and disable MQ services and reboot the box and try the process again and see if someone else has it. I had the same problem in NYCTA. I was debugging the problem over the phone with a techie that assumed I was totaly out of my head until I finally got him to start a listner on a different port and reconfigure the channels. The reply over the phone was WOW Will you look at that!!! An installed/reconfigured piece of software over the weekend did it. Just to let you know. 9 times outta 10, at least on UNIX it hoses the port with relationship to the INETD listner so a reboot is necessary when two people are punching the c.r.a.p outta each other for the same port!! Hope this is helpful bobbee From: Anderson, Lizette T. (RyTull) [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Listener Date: Mon, 10 Mar 2003 09:39:18 -0600 Thanks for the information. We bounced the Windows 2000 server and we are still getting the message. I am mostly a mainframe person so my question, will sharing a port cause problems? So far I am able to send messages. We discovered that our Websphere server is also using the ports. -Original Message- From: Luc-Michel Demey [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2003 4:45 PM To: [EMAIL PROTECTED] Subject: Re: Listener Stopping a QM often don't stop the listener. So when restart the whole QM (and listener, ...) the strmqlsr fail as the preceding listener is still alive. In some architecture (OS/400), nobody cares, the old one is same as the new listener. In Aix boxes, the old listener was unable to talk with the restarted QM. I suspect in windows there is no side effect, but ... how know ? So stopping restarting the listener should be a safe mesure HTH, Luc-Michel. Date sent: Fri, 7 Mar 2003 16:11:45 -0600 Send reply to: MQSeries List [EMAIL PROTECTED] From: Anderson, Lizette T. (RyTull) [EMAIL PROTECTED] Subject:Listener To: [EMAIL PROTECTED] Some changes were made to some DLLs by our DBAs today. The server was bounced and then the event viewer recorded the following message: The TCP/IP listener program could not bind to port number 1422. The failure could be due to another program using the same port number. The return code is 20 from this command issued by MQseries services: RUNMQLSR -mQMRT002D -tTCP -p 1422. I looked at the listener service and it is running. Any ideas? --- Legal Disclaimer: The information contained in this communication may be confidential, is intended only for
Purchasing MQSeries
Our company is currently trying to make a decision between purchasing MQSeries or WebMethods. Any information that any of you out there could give me on slanting the vote towards MQ would be greatly appreciated. Or, opinions on what you fell MQ is doing for you, etc,etc,. Thanks! June Lawton Information Systems The PMA Insurance Group [EMAIL PROTECTED] (T) 610.397.5058 (F) 610.397.5311 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: 2059 trying to connect mq series 5.3 on z/os 1.4
Javier, Your sender channel specifies the port that the receiving channel will be listening on. You have to start the listener process on that port at the receiving end in order to receive any messages. Otherwise will not get any messages! For example, on Windows NT (using TCP)you can use the runmqlsr command to start the listener like: runmqlsr -t tcp [-m qmgr] [-p portnumber] Example: runmqlsr -t tcp -m MYQMGR -p 1415 If you omit the port number it will default to 1414. And you can end the listener with the endmqlsr command. On z/OS you can use the MQ panels to start/stop the listener. Or ideally, you can automate this so that when you restart the queue manager your listener (and channels) will be started as well. To do this, you should put the appropriate START LISTENER command in the CSQINPX dataset. (If you want to automate the starting of a channel, you can put the appropriate START CHINIT command in the CSQINP2 dataset). Hope this helps. Best regards, Ruzi --- javier sotela [EMAIL PROTECTED] wrote: Alan: Maybe you can help me, when you mention listener, what do you mean ?? We have defined a server connection, could you tell me with more detail how you turn off the listener and what do you mean TIA. Javier S. From: Alan Stewart [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: 2059 trying to connect mq series 5.3 on z/os 1.4 Date: Wed, 12 Mar 2003 08:53:03 +1100 Is the listener running ? or is the listener port OK? I just did a test by turning off my listener for my one of my mq client-connected applications, and got a 2059. It also occurred when I deliberately used a wrong port as well Alan javier sotela [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 12/03/2003 08:38 AM Please respond to MQSeries List [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject 2059 trying to connect mq series 5.3 on z/os 1.4 Hi Everyone: We are trying to connect to a mq series 5.3 on z/os 1.4 from different clients, windows, unix, etc, but we are receiving a 2059 error from the mainframe. With mq series server to server the communiaction its o.k., the only problem is trying to connect client to server (at mq level). The channel server its working and connected, any ideas TIA. Javier S. _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Disclaimer.txt _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Purchasing MQSeries
If I'm not mistaken, WebMethods is an EAI product that can use MQSeries as an underlying message transport mechanism. I don't think this is a comparison of apples to apples. June Lawton [EMAIL PROTECTED] To: [EMAIL PROTECTED] GROUP.COM cc: Sent by: Subject: Purchasing MQSeries MQSeries List [EMAIL PROTECTED] en.AC.AT 03/12/2003 11:20 AM Please respond to MQSeries List Our company is currently trying to make a decision between purchasing MQSeries or WebMethods. Any information that any of you out there could give me on slanting the vote towards MQ would be greatly appreciated. Or, opinions on what you fell MQ is doing for you, etc,etc,. Thanks! June Lawton Information Systems The PMA Insurance Group [EMAIL PROTECTED] (T) 610.397.5058 (F) 610.397.5311 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Client IP connections direct to an OS/390
Glen, This sounds good in theory, but client channels don't have options like disconnect interval, heartbeat interval etc on the OS/390. I don't even think they have them on other platfoms either. I think these are controlled via global TCP setting like TCPKEEPALIVE. Since we are using a vendor package on the client side, we don't have a lot of control over the options specified at channel connection time. Thanks, David Corbett Work: 651-205-2714 Pager: 651-610-3842 |-+--- | | Glen Shubert | | | [EMAIL PROTECTED]| | | OM | | | Sent by:| | | MQSeries List | | | [EMAIL PROTECTED]| | | en.AC.AT | | | | | | | | | 03/12/2003 09:17| | | AM | | | Please respond | | | to MQSeries| | | List | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Re: Client IP connections direct to an OS/390 | ---| Dave, The messages could be from the Disconnect Interval on the channels. You may want to check those and possibly set them to zero. Glen Shubert Dave Corbett [EMAIL PROTECTED] To: Sent by: MQSeries List [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Subject:Re: Client IP connections direct to an OS/390 03/12/2003 09:52 AM Please respond to MQSeries List Dennis. Thanks for your thoughts on this. I'm not sure that batching of messages really matters, especially since we are TCP in and SNA out. Our batch size is set to 50 and the batch interval set 100. We did some extensive tuning with the VTAM settings to make sure it worked as well as possible (setting RU sizes, pacing, and other NCP parameters). It just seems that skipping a box in between the app server and mainframe should increase performance by itself. My real outstanding question is, why do we get thousands of messages showing channels starting and going inactive in the CHIN log? We had an occasion last Sunday where we had between 6 and 7 thousand messages in the space of an hour. I don't understand what it is that drives MQ to be bouncing these connections like this. We have also sent this question to IBM for a better understanding. We'll discuss your thoughts on putting the QMGRs on the app servers, but we were originally told (in 1998) that we needed the MQ servers to be on their own boxes. Thanks, David Corbett Work: 651-205-2714 Pager: 651-610-3842 |-+--- | | Miller, Dennis| | | [EMAIL PROTECTED]| | | COM| | | Sent by:| | | MQSeries List | | | [EMAIL PROTECTED]| | | en.AC.AT | | | | | | | | | 03/11/2003 09:37| | | AM | | | Please respond | | | to MQSeries| | | List | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Re: Client IP connections direct to an OS/390 | ---| Dave, With the workload you describe, I think the 390 would be better optimised and easier to manage with the NT concentrators. I mean sender channels can batch dozens of messages together, whilst the client channels go one-at-a time. You also minimze the overhead of channel pooling and avoid (at least from the 390 perspective) avoid the headaches implicit in one end of the
Re: solaris userids longer than 8 characters
We had this problem and had to alias an 8-charUserID to the same UID to make it work. Lines from /etc/passwd: 9charUser:password:2410:110:Long User ID:/home/users/9charUser:/bin/ksh --- ACTUALID 9charUse:password:2410:110:Long User ID:/home/users/9charUser:/bin/ksh --- What MQ Checks We found some references in the Solaris docs that indicated other system dependencies on 8-char UserIDs. Best thing to do is avoid them and convert long IDs to standard 8-char IDs. -- T.Rob -Original Message-From: Fred Forester [mailto:[EMAIL PROTECTED]Sent: Wednesday, March 12, 2003 3:00 PMTo: [EMAIL PROTECTED]Subject: solaris userids longer than 8 characters Hi all, the authentication fails on solaris for any user with a 9 character userid. is there a way around it?I've tried coding the MQEnvironment class in the java client but still doesn't work. Thanx in advance Fred Forester
Re: WMQ V5.3 stability?
Title: Message What OS does this Apply to? -Original Message-From: GIES, STEVE [mailto:[EMAIL PROTECTED]Sent: Friday, March 07, 2003 4:28 PMTo: [EMAIL PROTECTED]Subject: Re: WMQ V5.3 stability? We got hit by this. We never got hit in dev either (and still haven't) but we've had three incidents in the past 6 weeks were a queue was damaged. Both of the queues involved (1 has been damaged twice) have a high number of abandoned reply messages on them that get cleaned out nightly. Not by CLEARQ, but by a custom job that removes messages over N hours old. The damage always occurred sometime after this nightly job. We just got the fix and are applying it to dev this weekend. If you have any queues that might be susceptible to this, then I would recommend getting the fix. - Steve P.S. Other than this problem WMQ V5.3 CSD01 on W2K servers has been very, very stable and trouble free for us. -Original Message-From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2003 12:09 PMTo: [EMAIL PROTECTED]Subject: Re: WMQ V5.3 stability? Has anyone else hit this problem? We're putting 5.3 onto production in a few weeks and haven't seen this on the various dev and test environments we've got it on. If there is something particular that causes the symptoms then that would be useful information. Thanks Darren. - Original Message - From: Kulbir S. Thind To: [EMAIL PROTECTED] Sent: Thursday, March 06, 2003 4:54 PM Subject: Re: WMQ V5.3 stability? Hi, We've just installed it recently and you need to ensure you get the latest media. There was a big problem with the distribution of this release and the numbering used. For example 5.3 went out in June 02 and Oct 02, both releases being different although both being called 5.3. Make sure you get the latest media and then the latest CSD (there may be one on the web site). In addition to this we found a bug where MQSeries objects kept becoming damaged. IBM provided us with an e-fix, this fix is not included in the latest CSD and must be applied. APAR IC35711 is the reference IBM are using for this. Other than the above we've had no problems. Cheers, Kulbir. "Rick Tsujimoto" [EMAIL PROTECTED] Sent by: "MQSeries List" [EMAIL PROTECTED] 06-Mar-2003 14:58 Please respond to "MQSeries List" [EMAIL PROTECTED] To:MQSERIES cc: Subject:WMQ V5.3 stability?I'm probably going to install V5.3 on Windows soon and am interested tohear the experiences of others who have already implemented it inproduction. Any bloody, gory tales?Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQSeries Java classes for PCF
Arun, I suspect (meaning: I am not sure) that the MQRC_CMD_SERVER_NOT_AVAILABLE reason code will only be returned if you use the MQ Adminsitration Interface (available for C and VisualBasic applications) instead of building native PCF commands. These interfaces probably encapsulate a 2033 from the command server reply2queue and map it to the MQRC_CMD_SERVER_NOT_AVAILABLE you are expecting. Again, this is just my guess; maybe somebody can confirm!? Stefan From: EXT-Makhija, Arun [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: MQSeries Java classes for PCF Date: Wed, 12 Mar 2003 11:52:34 -0800 Hi I am using MQSeries Java classes for PCF Support Pack [MS0B] on MQSeries v5.2 on HP-UX 11.0. In my application, in try-catch-finally setup, where I catch MQException or PCFException I trap critical Reason Codes and handle them appropriately like notify support people/generate alert etc as per the requirement The critical errors like QMGR shutting down | QMGR not available | CMD SERVER stopped All other things work fine except when I stop CMD SERVER I expect a reason code 2322=MQRC_CMD_SERVER_NOT_AVAILABLE but instead I am getting 2033=MQRC_NO_MSG_AVAILABLE Any Idea why this is happening Any help will be appreciated Regards Arun Makhija Never argue with an idiot. They drag you down to their level and beat you with experience _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail 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: Processing the Euro symbol in MQSeries messages
Kulbir I think this is a specific issue with 1208, 858 and HP-UX. You are trying to do the conversion on the sender channel i.e. the HP-UX qmgr is trying to do the convert, but if you look at appendix Hin the APR you will see the following re support for MQ conversion to/from Unicode (codepages 1200, 13488, 17584 and 1208) notice that 858 is not among those listed. WebSphere MQ HP-UX support for Unicode On MQSeries for HP-UX Version 5 or later, conversion on HP to, and from, the Unicode CCSIDs is supported for the following CCSIDs: 813 819 874 912 915 916 920 932 938 950 954 964 970 1051 1089 1200 1208 1381 5050 5488 13488 33722 Regards Darren - Original Message - From: Kulbir S. Thind To: [EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 12:12 PM Subject: Processing the Euro symbol in MQSeries messages Hi, We're trying to enable our machines to be able to process the Euro symbol within MQSeries messages. We follow a hub and spoke topology here and are unable to upgrade all machine configurations to use the correct code page configurations. We have a project that will upgrade the hub and we decided to ensure the hub is able to support the Euro for any future applications connecting to it. We changed the queue manager CCSID from 850 to 858 (recommended NT code page for the Euro) and have now hit problems. We are sending messages from a HP-UX queue manager with a code page of 1208 to the new hub and finding the messages do not come across the channel. Channel conversion is set to YES and the error messages appearing in the HP-UX queue manager logs are as follows: * 03/12/03 06:25:56 AMQ6047: Conversion not supported. EXPLANATION: MQSeries is unable to convert string data tagged in CCSID 1208 to data in CCSID 858. ACTION: Check the appropriate National Language Support publications to see if the CCSIDs are supported by your system. * Does this mean that we would need to configure all our application queue managers to use the correct code pages for this to work or is this a specific issue with just conversion between 1208 and 858 code pages? Cheers, Kulbir.
Re: solaris userids longer than 8 characters
Actually, no. The ID that MQ checks is the truncated first 8 chars of the UserID. When I had "9charUse" in the first field, it was not meant symbolically. It is quite literallythe UserID "9charUser" with the "r" chopped off. So if your problem UserID is something like 'programer', aliasing it to 'programe' does the trick. If youchangeone or more of the first significant 8 chars, you might as well just put up a new ID. -- T.Rob -Original Message-From: Fred Forester [mailto:[EMAIL PROTECTED]Sent: Wednesday, March 12, 2003 3:23 PMTo: [EMAIL PROTECTED]Subject: Re: solaris userids longer than 8 characters thanx a bunch for the nice trick. I don't like 9char userids either but too late. I assume you meant 9charUser:password:2410:110:Long User ID:/home/users/9charUser:/bin/ksh --- ACTUALID -- 8charUse:password:2410:110:Long User ID:/home/users/9charUser:/bin/ksh --- What MQ Checks - Original Message - From: Wyatt, T. Rob To: [EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 3:05 PM Subject: Re: solaris userids longer than 8 characters We had this problem and had to alias an 8-charUserID to the same UID to make it work. Lines from /etc/passwd: 9charUser:password:2410:110:Long User ID:/home/users/9charUser:/bin/ksh --- ACTUALID 9charUse:password:2410:110:Long User ID:/home/users/9charUser:/bin/ksh --- What MQ Checks We found some references in the Solaris docs that indicated other system dependencies on 8-char UserIDs. Best thing to do is avoid them and convert long IDs to standard 8-char IDs. -- T.Rob -Original Message-From: Fred Forester [mailto:[EMAIL PROTECTED]Sent: Wednesday, March 12, 2003 3:00 PMTo: [EMAIL PROTECTED]Subject: solaris userids longer than 8 characters Hi all, the authentication fails on solaris for any user with a 9 character userid. is there a way around it?I've tried coding the MQEnvironment class in the java client but still doesn't work. Thanx in advance Fred Forester
Re: 2059 trying to connect mq series 5.3 on z/os 1.4 and new question ??
Thanks for all the responses, its look like we need the CAF for z/os. Does anybody know if this feature was for free in releases 2.x, and know its not free or it is still for free in mq 5.x. If so, where i can get it, is there any place on internet to download or something like that. TIA Javier S. From: Roger Lacroix [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: 2059 trying to connect mq series 5.3 on z/os 1.4 Date: Tue, 11 Mar 2003 18:50:11 -0500 Hi, Do you the Client Attachment Feature (CAF) 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. later Roger... Quoting javier sotela [EMAIL PROTECTED]: Hi Everyone: We are trying to connect to a mq series 5.3 on z/os 1.4 from different clients, windows, unix, etc, but we are receiving a 2059 error from the mainframe. With mq series server to server the communiaction its o.k., the only problem is trying to connect client to server (at mq level). The channel server its working and connected, any ideas TIA. Javier S. _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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 new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Client IP connections direct to an OS/390
Hi Dave, If you are referring to messages like the following then you are seeing an application connecting to and then disconnecting from your queue manager as a client. CSQX500I MQD7 CSQXRESP Channel TEST.NOEXIT started CSQX501I MQD7 CSQXRESP Channel TEST.NOEXIT is no longer active Regards Tim A Dave Corbett [EMAIL PROTECTED]To: [EMAIL PROTECTED] BANK.COMcc: Sent by: MQSeriesSubject: Re: Client IP connections direct to an OS/390 List [EMAIL PROTECTED] N.AC.AT 13/03/2003 06:26 Please respond to MQSeries List Glen, This sounds good in theory, but client channels don't have options like disconnect interval, heartbeat interval etc on the OS/390. I don't even think they have them on other platfoms either. I think these are controlled via global TCP setting like TCPKEEPALIVE. Since we are using a vendor package on the client side, we don't have a lot of control over the options specified at channel connection time. Thanks, David Corbett Work: 651-205-2714 Pager: 651-610-3842 |-+--- | | Glen Shubert | | | [EMAIL PROTECTED]| | | OM | | | Sent by:| | | MQSeries List | | | [EMAIL PROTECTED]| | | en.AC.AT | | | | | | | | | 03/12/2003 09:17| | | AM | | | Please respond | | | to MQSeries| | | List | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Re: Client IP connections direct to an OS/390 | ---| Dave, The messages could be from the Disconnect Interval on the channels. You may want to check those and possibly set them to zero. Glen Shubert Dave Corbett [EMAIL PROTECTED] To: Sent by: MQSeries List [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Subject:Re: Client IP connections direct to an OS/390 03/12/2003 09:52 AM Please respond to MQSeries List Dennis. Thanks for your thoughts on this. I'm not sure that batching of messages really matters, especially since we are TCP in and SNA out. Our batch size is set to 50 and the batch interval set 100. We did some extensive tuning with the VTAM settings to make sure it worked as well as possible (setting RU sizes, pacing, and other NCP parameters). It just seems that skipping a box in between the app server and mainframe should increase performance by itself. My real outstanding question is, why do we get thousands of messages showing channels starting and going inactive in the CHIN log? We had an occasion last Sunday where we had between 6 and 7 thousand messages in the space of an hour. I don't understand what it is that drives MQ to be bouncing these connections like this. We have also sent this question to IBM for a better understanding. We'll discuss your thoughts on putting the QMGRs on the app servers, but we were originally told (in 1998) that we needed the MQ servers to be on their own boxes. Thanks, David Corbett Work: 651-205-2714 Pager: 651-610-3842 |-+--- | | Miller, Dennis| | | [EMAIL PROTECTED]| | | COM| | | Sent by:| | | MQSeries List | | | [EMAIL PROTECTED]| | | en.AC.AT | | | | | | | | | 03/11/2003 09:37| | | AM | | | Please respond | | | to MQSeries| | | List | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Re: Client IP connections direct to an OS/390 |
Re: Wanted -- zOS MQ Person
Yes. Contact me at [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
Re: 2059 trying to connect mq series 5.3 on z/os 1.4 and new question ??
I DO NOT THINK IT WAS EVER FREE AND ITS ONE OF THOSE THINGS WHERE YOU PROBABLY NEED TO TALK TO YOUR IBM SALES REP. javier sotela [EMAIL PROTECTED]@AKH-WIEN.AC.AT on 03/12/2003 03:18:07 PM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: 2059 trying to connect mq series 5.3 on z/os 1.4 and new question ?? Thanks for all the responses, its look like we need the CAF for z/os. Does anybody know if this feature was for free in releases 2.x, and know its not free or it is still for free in mq 5.x. If so, where i can get it, is there any place on internet to download or something like that. TIA Javier S. From: Roger Lacroix [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: 2059 trying to connect mq series 5.3 on z/os 1.4 Date: Tue, 11 Mar 2003 18:50:11 -0500 Hi, Do you the Client Attachment Feature (CAF) 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. later Roger... Quoting javier sotela [EMAIL PROTECTED]: Hi Everyone: We are trying to connect to a mq series 5.3 on z/os 1.4 from different clients, windows, unix, etc, but we are receiving a 2059 error from the mainframe. With mq series server to server the communiaction its o.k., the only problem is trying to connect client to server (at mq level). The channel server its working and connected, any ideas TIA. Javier S. _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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 new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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
Increase size of error logs
Hi...MQ error logs (amqerr01.log..etc) are cut when they go over 256KB. MQ also keeps 3 logs. Does anyone know either how to increase the size of the logs or the number of logs. Platform if NT, v5.2 and above.Thanks Aatush
Re: 2195 Error
Paul... As a followup to an earlier posting, I experienced the same problem this weekend that Jeff made mention of in the original posting below back in Mid January. Also an AIX 4.3.3 but running wmq 5.3 base level code. The AMQERR01.LOG file had many mq AMQ6209 and AMQ6183 error messages, but as you stated in your reply,... MQ and the Qmgr in question appeared to be fine. Only problem was that clients attempting to connect to the Qmgr over the weekend were getting 2059's. The FDC file that was created was huge. 29 meg . Was filled with references to xecE_W_UNEXPECTED_ASYNC_SIGNAL. In looking at the individual entries, all the return values in the FDC dump state OK. Nothing giving me a clue as to what's the issue. MQ was taken down for a file system back up, and when restarted... all was fine. Clients could connect. I've emailed Jeff, since I knew he had an open PMR at the time to see what the resolution was with MQ support, before I attempt to open my own call. Anyone experience similar issues with MQ and AIX 4.3.3 ? jesse goode jr valero energy corporation [EMAIL PROTECTED] -- snippet from Jeff's original posting --- What I am finding in the error logs and FDC files are AMQ6209: An unexpected asynchronous signal (15) has been received and ignored. Also receiving AMQ6183: An internal MQSeries error has occurred. The FDC file also contained Major Errorcode xecE_W_UNEXPECTED_ASYNC_SIGNAL - Original Message - From: Paul Clarke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 5:13 AM Subject: Re: 2195 Error Hello Fellow MQer's, I have this weird problem with MQ V5.2, AIX 4.3.3. Our AIX Admins rebooted the machine. After the reboot I started MQ and the Client Server and connected through MQ Explorer on WIn2K. An application team that uses this particular server informed me they have been getting 2195 errors and an occasional 2059 error. I verified that they were pointing to the correct queue manager and server IP and I am at loss at what could be causing this. The application worked fine prior to this reboot. There are no error messages in the log. Has anybody seen anything like this? My thought is MQ is fine. I can do an amqsput and amqsget on the queue the application tries to access, I can navigate around the queue manager through MQ Explorer and through telnet. I'm thinking something wasn't loaded right in the reboot of the server, but I'm not sure. Of course this problem occurred late in the afternoon, so I was not able to find out, yet, how the machine was rebooted. Thanks in advance, Jeff Jeff, If you're getting 2195 errors you should see FDC files written explaining the problem. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley 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
using UDP protocol with MQSeries on windows platforms
Hi there! Any body have any idea ifthere is any option using UDP protocolbetweenMQClient-MQServer or between 2 MQ servers on windows platforms ? Regards, Matan Philipson
