Re: MQClient authorization error (2035)
Rebecca may be on the right track. Check that the NIS account is in an authorised group on the server. I would also ensure that the account number (use the command id on both servers) and group numbers are the same on both servers. Regards John. -Original Message- From: Sony Varghese [mailto:[EMAIL PROTECTED] Sent: 02 June 2003 15:51 To: [EMAIL PROTECTED] Subject: Re: MQClient authorization error (2035) Hi John, My userid is a NIS userid id .. The MCAUSER is set to blank .. Regards Sony -Original Message- From: John Scott [mailto:[EMAIL PROTECTED] Sent: 02 June 2003 17:18 To: [EMAIL PROTECTED] Subject: Re: MQClient authorization error (2035) Are you logging on using a different user name from the client? What is the MCAUSER set to for the server connection channel the client is using? Regards John. -Original Message- From: Sony Varghese [mailto:[EMAIL PROTECTED] Sent: 02 June 2003 14:58 To: [EMAIL PROTECTED] Subject: MQClient authorization error (2035) Hi , I'm getting a 2035 error when I run amqsputc (MQClient) on a UNIX box. If I log in to the UNIX box where MQSeries is installed and run amqsput (MQServer), the program works fine. If it works fine on the server, shouldn't it also work fine on the client? Any idea why this happens? Do reply Regards Sony 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 ** Click here to visit the Argos home page http://www.argos.co.uk The information contained in this message or any of its attachments may be privileged and confidential, and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you are not the intended addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using your reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail maybe accessed. ** 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
mqsi version
Hi all, How do you find the mqsi version on an aix box? including the CSDs? i've tried lslpp -l | grep wmqi but is there any standard command like mqver for mqseries? Thanks VJ. 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: MQClient thread-safe?
To all, My apologies I had read about shared connections in V5.3 and promptly forgot them again so yes you now can coordinate units of work across multiple threads. Tim, I don't wish to be picky here but I didn't mention coordination. A shared connection can be used across multiple threads but there is still only one unit of work associated with the connection. 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
Re: Client and server configuration
Yes. But if you install the MQServer onto your machine, then you must install the MQClient from the CD. You cannot use the MQClient that you download as a Support Pack. If you install ONLY MQClient on a PC, then you can use either the client from the CD or the client from the support pack download page. -Original Message-From: Teresa Cheung [mailto:[EMAIL PROTECTED]Sent: Monday, June 02, 2003 4:56 PMTo: [EMAIL PROTECTED]Subject: Client and server configuration Can both have MQSeries client and seversoftware installedon the sameoperating system?I am running Windows 2000. Thanks TC Do you Yahoo!?Free online calendar with sync to Outlook(TM). This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: Client and server configuration
YUP From: Teresa Cheung [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Client and server configuration Date: Mon, 2 Jun 2003 13:56:21 -0700 Can both have MQSeries client and sever software installed on the same operating system? I am running Windows 2000 . Thanks TC - Do you Yahoo!? Free online calendar with sync to Outlook(TM). _ 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: Production MQ abends - 2019 / 2195 / 2079 and more.
Michelle, is it possible that a new application went into production three days ago that (by accident) writes directly to the initiation queue MQPB.INITQ.PB.PCCIC? Also, the RACF message shows a queue name of MVB1.MQPB.INITQ.PB.PCCIC, which is a different name, but that might be OK. Did any RACF definitions change or is the later INITQ a new one and the RACF permissions for your started task userID(ZMQMAB1) have not been properly set? Just guessing here, it's hard to say if the error messages you see are related. Stefan From: Michelle Russell [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Production MQ abends - 2019 / 2195 / 2079 and more. Date: Tue, 3 Jun 2003 10:00:43 +0100 Hi all, MQ V2.1. OS/390 The last two mornings at exactly the same time we have experienced an issue with the connections between MQSeries and a production CICS region. The errors that are being seen in the CICS log are: +CSQC106D PCCIC CSQCTASK MQGET failure. CKTI will end. MQCC=2 MQRC=2019 (Object Handle) +CSQC110I PCCIC CSQCTASK Queue name = MQPB.INITQ.PB.PCCIC +KAD6500 ERROR ON MQCLOSE QAKE.GET.VALIDATE.CUSTOMER.DETAILS.REQUEST +KAD6500 ERROR ON MQCLOSE REASON = 2019 +CSQC111D PCCIC CSQCTASK CKTI has read a trigger message with an incorrect length of 297 As well as the above we are getting 2195 (Unexpected error) and 2079(Truncated msg) errors. In addition to the above the CICS and MQ logs are showing RACF messages: 06.53.41 STC04301 ICH408I JOB(MVB1MSTR) STEP(MVB1MSTR)--- This should be USER (ZMQMAB1) GROUP ([EMAIL PROTECTED]) MVB1.MQPB.INITQ.PB.PCCIC CL(MQQUEUE ) INSUFFICIENT ACCESS AUTHORITY FROM MVB1.MQPB.INITQ.** (G) ACCESS INTENT(UPDATE ) ACCESS ALLOWED(NONE ) Has anyone experienced any of the above ? Any help would be much appreciated Regards Michelle This email and any attachments are confidential. They may contain privileged information and are intended for the named addressee(s) only. They must not be distributed without our consent. If you are not the intended recipient, please notify us immediately and do not disclose, distribute or retain this email or any part of it. Unless expressly stated, opinions in this email are those of the individual sender and not N Brown Group plc or any of its subsidiaries. You must take full responsibility for virus checking this email and any attachments. Please note that the content of this email or any of its attachments may contain data that falls within the scope of the Data Protection Acts and that you must ensure that any handling or processing of such data by you is fully compliant with the terms and provisions of the Data Protection Act 1984 and 1998. N Brown Group plc. Registered office: 53 Dale Street, Manchester, M60 6ES. Registered in England No.814103. 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: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Production MQ abends - 2019 / 2195 / 2079 and more.
has someone deleted the STARTED profile for this region ? or perhaps changed the jcl that would cause it to select what looks like a default STARTED profile. Stephen Price Advisory IT Specialist; Database and Middleware UK SSO North Region Strategic Outsourcing, IBM Global Services Manchester, Mailpoint 2JH Tel +44(0)161 905 6675; Internal 626675 e-mail [EMAIL PROTECTED] |-+--- | | Michelle Russell| | | [EMAIL PROTECTED]| | | IAMS.CO.UK | | | Sent by: MQSeries List | | | [EMAIL PROTECTED]| | | | | | | | | | | | 03-06-03 10:00 | | | Please respond to | | | MQSeries List | | | | |-+--- -| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Production MQ abends - 2019 / 2195 / 2079 and more. | | | -| Hi all, MQ V2.1. OS/390 The last two mornings at exactly the same time we have experienced an issue with the connections between MQSeries and a production CICS region. The errors that are being seen in the CICS log are: +CSQC106D PCCIC CSQCTASK MQGET failure. CKTI will end. MQCC=2 MQRC=2019 (Object Handle) +CSQC110I PCCIC CSQCTASK Queue name = MQPB.INITQ.PB.PCCIC +KAD6500 ERROR ON MQCLOSE QAKE.GET.VALIDATE.CUSTOMER.DETAILS.REQUEST +KAD6500 ERROR ON MQCLOSE REASON = 2019 +CSQC111D PCCIC CSQCTASK CKTI has read a trigger message with an incorrect length of 297 As well as the above we are getting 2195 (Unexpected error) and 2079(Truncated msg) errors. In addition to the above the CICS and MQ logs are showing RACF messages: 06.53.41 STC04301 ICH408I JOB(MVB1MSTR) STEP(MVB1MSTR)--- This should be USER (ZMQMAB1) GROUP ([EMAIL PROTECTED]) MVB1.MQPB.INITQ.PB.PCCIC CL(MQQUEUE ) INSUFFICIENT ACCESS AUTHORITY FROM MVB1.MQPB.INITQ.** (G) ACCESS INTENT(UPDATE ) ACCESS ALLOWED(NONE ) Has anyone experienced any of the above ? Any help would be much appreciated Regards Michelle This email and any attachments are confidential. They may contain privileged information and are intended for the named addressee(s) only. They must not be distributed without our consent. If you are not the intended recipient, please notify us immediately and do not disclose, distribute or retain this email or any part of it. Unless expressly stated, opinions in this email are those of the individual sender and not N Brown Group plc or any of its subsidiaries. You must take full responsibility for virus checking this email and any attachments. Please note that the content of this email or any of its attachments may contain data that falls within the scope of the Data Protection Acts and that you must ensure that any handling or processing of such data by you is fully compliant with the terms and provisions of the Data Protection Act 1984 and 1998. N Brown Group plc. Registered office: 53 Dale Street, Manchester, M60 6ES. Registered in England No.814103. 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: mqsi version
There sould be a file call MEMO.ptf in the install directory. From: Sony Varghese [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: mqsi version Date: Tue, 3 Jun 2003 11:51:05 +0100 Hi all, How do you find the mqsi version on an aix box? including the CSDs? i've tried lslpp -l | grep wmqi but is there any standard command like mqver for mqseries? Thanks VJ. 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 _ Help STOP SPAM with the new MSN 8 and get 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 and server configuration
Just to make this a little bit more clear. You MUST install the client that is on the SERVER CD. When you start installation from the server CD, one of the options is to also install the client code - use that. Francois van der Merwe Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert Developer Potkay, Peter M (PLC, IT) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RTFORD.COMSubject: Re: Client and server configuration Sent by: MQSeries List [EMAIL PROTECTED] AC.AT 03/06/2003 14:02 Please respond to MQSeries List Yes. But if you install the MQServer onto your machine, then you must install the MQClient from the CD. You cannot use the MQClient that you download as a Support Pack. If you install ONLY MQClient on a PC, then you can use either the client from the CD or the client from the support pack download page. -Original Message- From: Teresa Cheung [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 4:56 PM To: [EMAIL PROTECTED] Subject: Client and server configuration Can both have MQSeries client and sever software installed on the same operating system? I am running Windows 2000 . Thanks TC Do you Yahoo!? Free online calendar with sync to Outlook(TM). This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Well, I think I have proved what everyone was saying. A channel speed of Normal is what is getting me here. Neil Casey and Brian McCarty provided the exact explanation as to why: non persistent messages sent over a normal speed channel cause persistent message to be written to the channel sync queue, which requires disk. I set up some tests in my lab environment. Here are the results. * Server1: SpokeQM1, Win2000 SP2, MQ 5.3 CSD03 RemoteQ called FinalQ that points to FinalQ on SpokeQM2, via transmit queue HubQM1 Server2: HubQM1, Win2000 SP2, MQ 5.2.1 CSD05 QMAlias called SpokeQM2, which sends messages to transmit queue SpokeQM2.XMITQ Server3: SpokeQM2, Win2000 SP2, MQ 5.2.1 CSD05 Local queue called FinalQ *** Test #1: Channel SpokeQM1.HubQM1 has a speed of NORMAL. Start putting 1K Non-Persistent(NP) messages every 250 milliseconds to the remote queue def on SpokeQM1. Results #1: As expected, constant disk writes on the server that houses HubQM1. Test #2: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 1K NP messages every 250 milliseconds to the remote queue def on SpokeQM1. Results #2: As expected, no disk activity at all on the server that houses HubQM1. Actually, there was disk activity when the channel started/ended, but for the whole duration while the channel was running, no I/O. Test #3: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 70,000 byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1. Results #3: No disk activity at all on the server that houses HubQM1. ??? These messages are larger than the 64K queue buffer, so why are the messages flying thru the hub with no I/O? I am happy with these results, just that it is unexpected. Could it be that the Sending MCA to SpokeQM2 has the XMIT queue open ready for messages, with an outstanding GET? But I thought this was a feature new to 5.3 only. Test #4: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 5000 byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1. Every 45 seconds or so, I send over a Persistent 5000 byte message on the same channel. Results #4: As expected, no disk activity at all on the server that houses HubQM1, except every 45 seconds when the P message comes over. Test #5: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 5000 byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1. As the messages are flowing, yank the 2 cables that connect this server to the SAN (Veritas was disabled so it would not try and fail over). Results #5: No effect at all. Even though the server had no hard disk, these messages still kept flying thru the server as if nothing at all was wrong. Test #6: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 5000 byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1. At the same time, start putting 5000 byte P messages over the same channel. As the messages are flowing, yank the 2 cables that connect this server to the SAN (Veritas was disabled so it would not try and fail over). Results #6: Everything backs up. Both NP and P messages are backed up in the XMITQ on SPOKEQM1. As soon as the cables are plugged back in, the messages start flowing again. Test #7: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 5000 byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1. At the same time, start putting 5000 byte P messages over A DIFFERENT CHANNEL between SpokeQM1 and HubQM1. As the messages are flowing, yank the 2 cables that connect this server to the SAN (Veritas was disabled so it would not try and fail over). Results #7: Everything backs up on the channel that was dealing with P messages. The channel that had only NP messages was not effected at all. As soon as the cables are plugged back in, the messages start flowing again on the secondary channel. The primary channel that had NP messages never blinked. So now I am kinda stuck. Back in the production environment, what to do? I can set the channel between SpokeQM1 and the HUB to fast, as it is a dedicated channel for this application anyway. I'll just let them know of the possibility (very remote) that the channel may lose their message. SAN blips are a lot more frequent than MQ losing NP messages over a FAST channel. But what do I do with the CLUSRCVR channels? They are a shared resource for the whole company. Do I let this one application dictate that these channels get switched to FAST, at the risk of other apps having NP message lost. Granted, we have a pretty reliable network here, but man, what a waste of time trying to hunt for messages that get lost over the fast channel. (For anyone just jumping into the thread now, please don't suggest that I just make the messages persistent. That is not the
Re: Production MQ abends - 2019 / 2195 / 2079 and more.
I have checked all production applications that use MQSeries and searched on MQGET and MQPUT and MQPUT1 to the Initiation queue. Nothing is displayed. I have spoken with the developers and checked the implementation records and nothing has been implemented in the last three days. The RACF msg is prefixed with the MQSubsystem name, i.e MVB1. This is the standard RACF practise here. No RACF changes have been made for at least two months. No new definitions to the INITQ's in production. If you can think of anything else please let me know. Regards Michelle Stefan Sievert [EMAIL PROTECTED]@AKH-Wien.AC.AT on 03/06/2003 15:08:38 Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Production MQ abends - 2019 / 2195 / 2079 and more. Michelle, is it possible that a new application went into production three days ago that (by accident) writes directly to the initiation queue MQPB.INITQ.PB.PCCIC? Also, the RACF message shows a queue name of MVB1.MQPB.INITQ.PB.PCCIC, which is a different name, but that might be OK. Did any RACF definitions change or is the later INITQ a new one and the RACF permissions for your started task userID(ZMQMAB1) have not been properly set? Just guessing here, it's hard to say if the error messages you see are related. Stefan From: Michelle Russell [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Production MQ abends - 2019 / 2195 / 2079 and more. Date: Tue, 3 Jun 2003 10:00:43 +0100 Hi all, MQ V2.1. OS/390 The last two mornings at exactly the same time we have experienced an issue with the connections between MQSeries and a production CICS region. The errors that are being seen in the CICS log are: +CSQC106D PCCIC CSQCTASK MQGET failure. CKTI will end. MQCC=2 MQRC=2019 (Object Handle) +CSQC110I PCCIC CSQCTASK Queue name = MQPB.INITQ.PB.PCCIC +KAD6500 ERROR ON MQCLOSE QAKE.GET.VALIDATE.CUSTOMER.DETAILS.REQUEST +KAD6500 ERROR ON MQCLOSE REASON = 2019 +CSQC111D PCCIC CSQCTASK CKTI has read a trigger message with an incorrect length of 297 As well as the above we are getting 2195 (Unexpected error) and 2079(Truncated msg) errors. In addition to the above the CICS and MQ logs are showing RACF messages: 06.53.41 STC04301 ICH408I JOB(MVB1MSTR) STEP(MVB1MSTR)--- This should be USER (ZMQMAB1) GROUP ([EMAIL PROTECTED]) MVB1.MQPB.INITQ.PB.PCCIC CL(MQQUEUE ) INSUFFICIENT ACCESS AUTHORITY FROM MVB1.MQPB.INITQ.** (G) ACCESS INTENT(UPDATE ) ACCESS ALLOWED(NONE ) Has anyone experienced any of the above ? Any help would be much appreciated Regards Michelle This email and any attachments are confidential. They may contain privileged information and are intended for the named addressee(s) only. They must not be distributed without our consent. If you are not the intended recipient, please notify us immediately and do not disclose, distribute or retain this email or any part of it. Unless expressly stated, opinions in this email are those of the individual sender and not N Brown Group plc or any of its subsidiaries. You must take full responsibility for virus checking this email and any attachments. Please note that the content of this email or any of its attachments may contain data that falls within the scope of the Data Protection Acts and that you must ensure that any handling or processing of such data by you is fully compliant with the terms and provisions of the Data Protection Act 1984 and 1998. N Brown Group plc. Registered office: 53 Dale Street, Manchester, M60 6ES. Registered in England No.814103. 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: 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 This email and any attachments are confidential. They may contain privileged information and are intended for the named addressee(s) only. They must not be distributed without our consent. If you are not the intended recipient, please notify us immediately and do not disclose, distribute or retain this email or any part of it. Unless expressly stated, opinions in this email are those of the individual sender and not N Brown Group plc or any of its subsidiaries. You must take full responsibility for virus checking this email and any attachments. Please note that the content of this email or any of its attachments may contain data that falls within the scope of the Data Protection Acts and
MQseries installation
Hi everyone, Is it possible to have MQ v5.2 and MQ v5.3 on the same AIX box? Is there a way of doing this? Thanks, VJ 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: Data conversion with MA7P using .NET application
Hi Elena We are using it and ran into the same problems. We are setting the channels to convert the data for us and my guess is that may be where the problem is. The data coming out of our front end, .Net app seemed to be causing an error which related to it not getting correctly converted. The quick fix that I came up with was to have the .Net app pass the CCSID parm of 500 which is the CCSID of our mainframe qmanager. This rectified the problem immediately. Hope it helps. Dan -Original Message- From: Elena Nanos [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 11:23 AM To: [EMAIL PROTECTED] Subject: Data conversion with MA7P using .NET application Hello, we are using Support pack MA7P - WebSphere MQ classes for Microsoft .NET, which allows MQ to be invoked from Microsoft .NET applications. We ran into a problem with data conversion. The data coming from mainframe going to distributed, is not being converted to ASCII. Is any one else using this support pack and can share the experience with us? Thank you. Elena Nanos Sr. Software and System Architect IBM Certified Solution Expert in CICS WEB Enablement and MQSeries Zurich NA *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
MQSeries msgid length not 24 bytes
I thought MQSeries generated msgid is 24bytes long. We have a processthatsave the value of msgid generated into Sybase database. WhenI ranthe following sql statement to check the length of msgid and found out that they are not 24 bytes long.?? Sybase SQL statement select distinct(datalength(MQ_MSGID)) MsgIdLength from ATABLE Result from above statement MsgIdLength20212223 Please advise on this findings. Thanks, TC Do you Yahoo!? Free online calendar with sync to Outlook(TM).
Re: Production MQ abends - 2019 / 2195 / 2079 and more.
I will look into this by reading up on the RACF CLASSES AND PROFILES Chapter in the System Management Guide. Thanks Morag Hughson [EMAIL PROTECTED]@AKH-Wien.AC.AT on 03/06/2003 16:51:26 Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Production MQ abends - 2019 / 2195 / 2079 and more. In the z/OS System Setup Guide in the chapter MQSeries Security Management, under Security Problem Determination, it talks about Violation messages. In there is states, If the ICH408I violation message shows the queue manager jobname rather than a user ID, this is normally as a result of a blank alternate user ID being specified. Given your other error messages about finding truncated messages, are you not getting enough of the message to find the alternate user ID and so hitting the above problem? Morag Hughson WebSphere MQ for z/OS Development Internet: [EMAIL PROTECTED] Michelle Russell [EMAIL PROTECTED]To: [EMAIL PROTECTED] IAMS.CO.UK cc: Sent by: MQSeries List Subject: Production MQ abends - 2019 / 2195 / 2079 and more. [EMAIL PROTECTED] 03/06/2003 10:00 Please respond to MQSeries List Hi all, MQ V2.1. OS/390 The last two mornings at exactly the same time we have experienced an issue with the connections between MQSeries and a production CICS region. The errors that are being seen in the CICS log are: +CSQC106D PCCIC CSQCTASK MQGET failure. CKTI will end. MQCC=2 MQRC=2019 (Object Handle) +CSQC110I PCCIC CSQCTASK Queue name = MQPB.INITQ.PB.PCCIC +KAD6500 ERROR ON MQCLOSE QAKE.GET.VALIDATE.CUSTOMER.DETAILS.REQUEST +KAD6500 ERROR ON MQCLOSE REASON = 2019 +CSQC111D PCCIC CSQCTASK CKTI has read a trigger message with an incorrect length of 297 As well as the above we are getting 2195 (Unexpected error) and 2079(Truncated msg) errors. In addition to the above the CICS and MQ logs are showing RACF messages: 06.53.41 STC04301 ICH408I JOB(MVB1MSTR) STEP(MVB1MSTR)--- This should be USER (ZMQMAB1) GROUP ([EMAIL PROTECTED]) MVB1.MQPB.INITQ.PB.PCCIC CL(MQQUEUE ) INSUFFICIENT ACCESS AUTHORITY FROM MVB1.MQPB.INITQ.** (G) ACCESS INTENT(UPDATE ) ACCESS ALLOWED(NONE ) Has anyone experienced any of the above ? Any help would be much appreciated Regards Michelle This email and any attachments are confidential. They may contain privileged information and are intended for the named addressee(s) only. They must not be distributed without our consent. If you are not the intended recipient, please notify us immediately and do not disclose, distribute or retain this email or any part of it. Unless expressly stated, opinions in this email are those of the individual sender and not N Brown Group plc or any of its subsidiaries. You must take full responsibility for virus checking this email and any attachments. Please note that the content of this email or any of its attachments may contain data that falls within the scope of the Data Protection Acts and that you must ensure that any handling or processing of such data by you is fully compliant with the terms and provisions of the Data Protection Act 1984 and 1998. N Brown Group plc. Registered office: 53 Dale Street, Manchester, M60 6ES. Registered in England No.814103. 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: Data conversion with MA7P using .NET application
Hello Dan, thank you very much for that useful tip. Elena. Capodicci, Dan (COMFIN, ITSS) [EMAIL PROTECTED]@AKH-Wien.AC.AT on 06/03/2003 11:18:40 AM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Data conversion with MA7P using .NET application Hi Elena We are using it and ran into the same problems. We are setting the channels to convert the data for us and my guess is that may be where the problem is. The data coming out of our front end, .Net app seemed to be causing an error which related to it not getting correctly converted. The quick fix that I came up with was to have the .Net app pass the CCSID parm of 500 which is the CCSID of our mainframe qmanager. This rectified the problem immediately. Hope it helps. Dan -Original Message- From: Elena Nanos [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 11:23 AM To: [EMAIL PROTECTED] Subject: Data conversion with MA7P using .NET application Hello, we are using Support pack MA7P - WebSphere MQ classes for Microsoft .NET, which allows MQ to be invoked from Microsoft .NET applications. We ran into a problem with data conversion. The data coming from mainframe going to distributed, is not being converted to ASCII. Is any one else using this support pack and can share the experience with us? Thank you. Elena Nanos Sr. Software and System Architect IBM Certified Solution Expert in CICS WEB Enablement and MQSeries Zurich NA *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Data conversion with MA7P using .NET application
Dan, MQ convertion works fine when done by the application, plus we have some blobs to traverse the network. Channel convertion is not an option. As far as messing with the CCSID, we're using standard NT, AIX , and MVS queue managers. The application group is converting to the .NET and we have been using the standard to convert at the receiving application without problem. This should support the standard API. glen Capodicci, Dan (COMFIN, ITSS) [EMAIL PROTECTED]@AKH-Wien.AC.AT on 06/03/2003 01:08:42 PM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Data conversion with MA7P using .NET application Hi Glen I can't say whether this is a bug or not (or as I like to refer to them, undocumented enhancements) although I haven't encountered this issue in the past with VB and ActiveX apps that do pretty much the same as is being done in this .Net app. What lead me to putting the CCSID parm change in was that I was receiving a 2110 MQRC_FORMAT_ERROR on the data passing through the channels and the conversion was not taking place. My problem was from the front end up to the mainframe which is why I had the CCSID changed to 500. We have a request/reply scenario so once the requesting data got to the mainframe correctly, I had no further problems from there. I am not having a problem with the conversion on the way down but I am doing it in the channels (I now this is generally not the preferred method but I have found it much easier to work with this way!) The only difference that I would think between the 2 methods here is that the channel method converts it to the CCSID for the receiving qmanager, in my case 437 so I do not need to have the CCSID parm set in the return message. In your case, are you having the mainframe app set the CCSID in the MQMD?!? It sounds as though you are failing on the MQGET with convert, are you getting an error thrown, such as a 2110?!? If so, you might try having the mainframe program setting the CCSID parm to that of the receiving qmanager and see if that helps. Hope it helps!! Dan -Original Message- From: Glen Larson [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 1:10 PM To: [EMAIL PROTECTED] Subject: Re: Data conversion with MA7P using .NET application Dan, the problem is this is a shared channel. we do not want to use channel conversion. So is this a bug in the .NET, or is there some parm the application needs to use. glen larson zurich north america Capodicci, Dan (COMFIN, ITSS) [EMAIL PROTECTED]@AKH-Wien.AC.AT on 06/03/2003 11:18:40 AM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Data conversion with MA7P using .NET application Hi Elena We are using it and ran into the same problems. We are setting the channels to convert the data for us and my guess is that may be where the problem is. The data coming out of our front end, .Net app seemed to be causing an error which related to it not getting correctly converted. The quick fix that I came up with was to have the .Net app pass the CCSID parm of 500 which is the CCSID of our mainframe qmanager. This rectified the problem immediately. Hope it helps. Dan -Original Message- From: Elena Nanos [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 11:23 AM To: [EMAIL PROTECTED] Subject: Data conversion with MA7P using .NET application Hello, we are using Support pack MA7P - WebSphere MQ classes for Microsoft .NET, which allows MQ to be invoked from Microsoft .NET applications. We ran into a problem with data conversion. The data coming from mainframe going to distributed, is not being converted to ASCII. Is any one else using this support pack and can share the experience with us? Thank you. Elena Nanos Sr. Software and System Architect IBM Certified Solution Expert in CICS WEB Enablement and MQSeries Zurich NA *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at
Re: Data conversion with MA7P using .NET application
Elena - This is a known bug in the current .NET support pac. What is happening is that by default the MQQueue class attempts to get the message with a 1 byte buffer. This of course fails (unless you just happen to be passing a 1 or 0 byte message!!) with a truncation failure. The class then resizes its internal buffer and retries the MQGET call, and since the buffer is now large enough the message is retrieved. (BTW, the ActiveX classes do the same thing, but they start with a 2K buffer). The problem with the .NET classes is that after the first MQGET call the MQMD-CCSID field has been updated with the value from the message - which is the value from the mainframe queue manager. When the second call is made, this field is not reinitialized. This tells MQ to convert the data into the code page from the mainframe. Since the data is already in this code page, no conversion takes place. One way to work around this problem is to instruct the class to use a bigger default buffer size. You do this on the put method. For example, to use a 5000 byte buffer in VB.NET code the following myQueue.Get(myMsg, myGMO, 5000) This does, however, require you to know what the largest size message will be. Steve Gies Safeco Insurance IT Specialist - WebSphere MQ -Original Message- From: Elena Nanos [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 8:23 AM To: [EMAIL PROTECTED] Subject: Data conversion with MA7P using .NET application Hello, we are using Support pack MA7P - WebSphere MQ classes for Microsoft .NET, which allows MQ to be invoked from Microsoft .NET applications. We ran into a problem with data conversion. The data coming from mainframe going to distributed, is not being converted to ASCII. Is any one else using this support pack and can share the experience with us? Thank you. Elena Nanos Sr. Software and System Architect IBM Certified Solution Expert in CICS WEB Enablement and MQSeries Zurich NA *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
WMQ 5.3 SupportPac MC74
Title: WMQ 5.3 SupportPac MC74 Does anyone have any knowledge regarding the two items? Does WMQ 5.3 (CSD03) on Win2000 Server work with Microsoft Cluster Server the latest incantation of MC74? Appreciate any feedback, tonyB.
MQSeries 5.3 for Windows NT thread safe?
I have a question. Is MQSeries 5.3 thread safe now? In the past, you couldn't use the same queue manager connection handle for across multiple threads. Has this changed ever? -- Robert Martin Design Engineer SISCO Inc, Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: IPProcs and OPProcs
The Event Monitoring Manual is also a good reference for understanding events. -Original Message- From: Conklin, William [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 12:58 PM To: [EMAIL PROTECTED] Subject: IPProcs and OPProcs Hi All, Is there a way to determine which MQSeries object has a queue/channel open for input (IPPROCS) or output (OPPROCS)? These attributes changes of course as the Qmgr operates. I'm using MQSeries 5.3 on 390, Windows and Solaris. Second question, our SYSTEM.ADMIN.QMGR.EVENT is filling up very fast, in fact we had to clear it out before it filled up the page set. We just moved to 5.3 from 2.1 and we didn't experience this before. Do you know what events the Qmgr is Putting to this queue? I haven't been able to find any detail information about the behavior of this queue. Thanks a MILLION in advance. Bill C. 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: MQseries installation
Sony, You are sure giving us all a good workout! If we collect all your questions, we would have a pretty good MQSeries FAQ. ;-) Current and prior releases of MQ, at least as far back as v2 anyway, all look for executables in /opt/mqm/bin. Therefore it would be impossible to have two versions running at the same time. -- T.Rob -Original Message- From: Sony Varghese [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 12:03 PM To: [EMAIL PROTECTED] Subject: MQseries installation Hi everyone, Is it possible to have MQ v5.2 and MQ v5.3 on the same AIX box? Is there a way of doing this? Thanks, VJ 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: Data conversion with MA7P using .NET application
Hello Steve, thank you very much for your reply, it is nice to know that we are not alone ... The queues using this support pack are set to 4 Meg max message size. Our developer will test setting larger buffer size on a PUT. What size do you recommend? Thanks again. Elena. GIES, STEVE [EMAIL PROTECTED]@AKH-Wien.AC.AT on 06/03/2003 01:55:38 PM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Data conversion with MA7P using .NET application Elena - This is a known bug in the current .NET support pac. What is happening is that by default the MQQueue class attempts to get the message with a 1 byte buffer. This of course fails (unless you just happen to be passing a 1 or 0 byte message!!) with a truncation failure. The class then resizes its internal buffer and retries the MQGET call, and since the buffer is now large enough the message is retrieved. (BTW, the ActiveX classes do the same thing, but they start with a 2K buffer). The problem with the .NET classes is that after the first MQGET call the MQMD-CCSID field has been updated with the value from the message - which is the value from the mainframe queue manager. When the second call is made, this field is not reinitialized. This tells MQ to convert the data into the code page from the mainframe. Since the data is already in this code page, no conversion takes place. One way to work around this problem is to instruct the class to use a bigger default buffer size. You do this on the put method. For example, to use a 5000 byte buffer in VB.NET code the following myQueue.Get(myMsg, myGMO, 5000) This does, however, require you to know what the largest size message will be. Steve Gies Safeco Insurance IT Specialist - WebSphere MQ -Original Message- From: Elena Nanos [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 8:23 AM To: [EMAIL PROTECTED] Subject: Data conversion with MA7P using .NET application Hello, we are using Support pack MA7P - WebSphere MQ classes for Microsoft .NET, which allows MQ to be invoked from Microsoft .NET applications. We ran into a problem with data conversion. The data coming from mainframe going to distributed, is not being converted to ASCII. Is any one else using this support pack and can share the experience with us? Thank you. Elena Nanos Sr. Software and System Architect IBM Certified Solution Expert in CICS WEB Enablement and MQSeries Zurich NA *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: WMQ 5.3 SupportPac MC74
Title: WMQ 5.3 & SupportPac MC74 MQ 5.3 has MSCS support within the base. MC74 is not required (and probably won't work). -Original Message-From: Antony Boggis [mailto:[EMAIL PROTECTED]Sent: Wednesday, 4 June 2003 4:57 AMTo: [EMAIL PROTECTED]Subject: WMQ 5.3 SupportPac MC74 Does anyone have any knowledge regarding the two items? Does WMQ 5.3 (CSD03) on Win2000 Server work with Microsoft Cluster Server the latest incantation of MC74? Appreciate any feedback, tonyB.
Re: IPProcs and OPProcs
As of V5.3 for z/OS you can do a DISPLAY QSTATUS if you want to know what processes are using a queue, this command is also available in Windows and the main flavours of UNIX. Regards Tim A Nick Dilauro [EMAIL PROTECTED]To: [EMAIL PROTECTED] cc: Sent by: MQSeriesSubject: Re: IPProcs and OPProcs List [EMAIL PROTECTED] N.AC.AT 04/06/2003 06:39 Please respond to MQSeries List The Event Monitoring Manual is also a good reference for understanding events. -Original Message- From: Conklin, William [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 12:58 PM To: [EMAIL PROTECTED] Subject: IPProcs and OPProcs Hi All, Is there a way to determine which MQSeries object has a queue/channel open for input (IPPROCS) or output (OPPROCS)? These attributes changes of course as the Qmgr operates. I'm using MQSeries 5.3 on 390, Windows and Solaris. Second question, our SYSTEM.ADMIN.QMGR.EVENT is filling up very fast, in fact we had to clear it out before it filled up the page set. We just moved to 5.3 from 2.1 and we didn't experience this before. Do you know what events the Qmgr is Putting to this queue? I haven't been able to find any detail information about the behavior of this queue. Thanks a MILLION in advance. Bill C. 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: MQClient thread-safe?
Paul, That is effectively what I meant by coordinate, ie. Thread1 and Thread2 share a connection handle Thread1 does a get under syncpoint and Thread2 does a put under syncpoint and then issues the commit which also commits Thread1's get. Hope I've got this right. Regards Tim A Paul Clarke [EMAIL PROTECTED]To: [EMAIL PROTECTED] IBM.COM cc: Sent by: MQSeriesSubject: Re: MQClient thread-safe? List [EMAIL PROTECTED] N.AC.AT 03/06/2003 21:25 Please respond to MQSeries List To all, My apologies I had read about shared connections in V5.3 and promptly forgot them again so yes you now can coordinate units of work across multiple threads. Tim, I don't wish to be picky here but I didn't mention coordination. A shared connection can be used across multiple threads but there is still only one unit of work associated with the connection. 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
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Hi Peter, thanks for the update and the information about your test results. We handle this issue by running multiple overlapping clusters, and having separate channels for each cluster. Eg: QM1 and QM2 are in clusters CL1 and CL2. Rather than- DEFINE NAMELIST(ClusList) names('CL1,CL2') and DEFINE chl(TO.QM1) chltype(CLUSRCVR) ... clusnl(ClusList) we would- DEFINE CHL(TO.QM1.CL1) chltype(CLUSRCVR)... cluster(CL1) and DEFINE CHL(TO.QM1.CL2) chltype(CLUSRCVR)... cluster(CL2). ie a separate channel is used in each cluster. This lets us put different NPMSPEED, SSL and other parameters on channels for different uses (clusters), even when they go to the same queue manager. Our naming standards limit the length of a queue manager name to 8 characters, and also limit cluster names to 8 characters, which means that our channels names are no more than 20 characters. In your environment, you could build an new cluster for this application (you can still use the same queue managers as repositories - just use namelists to list the clusters you want to host). The high performance queues live in the new cluster with NPMSPEED(FAST). Everything else goes in the normal cluster(s). As always in computing, there are trade-offs to be made. In this case, you lose some of the perceived benefits of clustering (simplicity) because you have to build and manage multiple clusters. This makes things like stopping a queue manager more complicated, because you have to suspend from all clusters, not just one. You also have to make correct decisions about which cluster(s) to connect a queue into, which makes administration more complex (but perhaps more interesting as well). Regards, Neil Casey. |-+-- | | Potkay, Peter M | | | (PLC, IT) | | | [EMAIL PROTECTED]| | | RTFORD.COM| | | Sent by: MQSeries | | | List | | | [EMAIL PROTECTED]| | | AC.AT | | | | | | | | | 04/06/2003 01:33 | | | Please respond to | | | MQSeries List | | | | |-+-- --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages| --| Well, I think I have proved what everyone was saying. A channel speed of Normal is what is getting me here. Neil Casey and Brian McCarty provided the exact explanation as to why: non persistent messages sent over a normal speed channel cause persistent message to be written to the channel sync queue, which requires disk. I set up some tests in my lab environment. Here are the results. * Server1: SpokeQM1, Win2000 SP2, MQ 5.3 CSD03 RemoteQ called FinalQ that points to FinalQ on SpokeQM2, via transmit queue HubQM1 Server2: HubQM1, Win2000 SP2, MQ 5.2.1 CSD05 QMAlias called SpokeQM2, which sends messages to transmit queue SpokeQM2.XMITQ Server3: SpokeQM2, Win2000 SP2, MQ 5.2.1 CSD05 Local queue called FinalQ *** Test #1: Channel SpokeQM1.HubQM1 has a speed of NORMAL. Start putting 1K Non-Persistent(NP) messages every 250 milliseconds to the remote queue def on SpokeQM1. Results #1: As expected, constant disk writes on the server that houses HubQM1. Test #2: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 1K NP messages every 250 milliseconds to the remote queue def on SpokeQM1. Results #2: As expected, no disk activity at all on the server that houses HubQM1. Actually, there was disk activity when the channel started/ended, but for the whole duration while the channel was running, no I/O. Test #3: Channel SpokeQM1.HubQM1 has a speed of FAST. Start putting 70,000 byte NP messages every 250 milliseconds to the remote queue def on SpokeQM1. Results #3: No disk activity at all on the server that houses HubQM1. ??? These messages are larger than the 64K queue buffer, so why are the messages flying thru the hub with no I/O? I am happy with these results, just that it is
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Again my apologies havent been expressing my ideas too well of late. With regard to selecting candidates the example below is not entirely clear in that I only mention one set of channels to one queue manager it would have been better as follows. nothing to stop you from having TO.QM1.FAST and TO.QM1.NORMAL, TO.QM2.FAST and TO.QM2.NORMAL, TO.QMx.FAST and TO.QMx.NORMAL sets of channels. As Neil ... Regards Tim A Tim Armstrong/AustraliTo: [EMAIL PROTECTED] a/[EMAIL PROTECTED] cc: Sent by: MQSeries Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi List stent messages [EMAIL PROTECTED] .AC.AT 04/06/2003 07:53 Please respond to MQSeries List For your cluster channels you could write your own exit, nothing to stop you from having a TO.QM1.FAST and a TO.QM1.NORMAL set of channels. As Neil said in another thread rather than try to maintain state information about what channel is next just use a random number to select an appropriate candidate. Below is the default selection criteria from the Queue Manager Clusters manual chapter 11, you should consider its operation if you decide to design your own. Algorithm: The steps in choosing a destination for a message: 1. If a queue name is specified, eliminate queues that are not PUT enabled. Eliminate remote instances of queues that do not share a cluster with the local queue manager. Eliminate remote CLUSRCVR channels that are not in the same cluster as the queue. 2. If a queue manager name is specified, eliminate queue manager alias' that are not PUT enabled. Eliminate remote CLUSRCVR channels that are not in the same cluster as the local queue manager. 3. If the result above contains the local instance of the queue, choose it. 4. If the message is a cluster PCF message, eliminate any queue manager you have already sent a publication or subscription to. 5. If only remote instances of a queue remains, choose Resumed queue managers over Suspended ones. 6. If more than one remote instance of a queue remains, include all MQCHS_INACTIVE and MQCHS_RUNNING channels. 7. If less than one remote instance of a queue remains, include all MQCHS_BINDING, MQCHS_INITIALIZING, MQCHS_STARTING, and MQCHS_STOPPING channels. 8. If less than one remote instance of a queue remains, include all MQCHS_RETRYING channels. 9. If less than one remote instance of a queue remains, include all MQCHS_REQUESTING, MQCHS_PAUSED and MQCHS_STOPPED channels. 10. If more than one remote instance of a queue remains and the message is a cluster PCF message, choose locally defined CLUSSDR channels. 11. If more than one remote instance of a queue remains to any queue manager, choose channels with the highest NETPRTY to each queue manager. 12. If more than one remote instance of a queue remains, choose the least recently used channel. Regards Tim A Potkay, Peter M (PLC, IT) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RTFORD.COMSubject: Re: How a MQSeries Hub does its thing with persistent / non-persi Sent by: MQSeries stent messages List [EMAIL PROTECTED] AC.AT 04/06/2003 01:33 Please respond to MQSeries List Well, I think I have proved what everyone was saying. A channel speed of Normal is what is getting me here. Neil Casey and Brian McCarty provided the exact explanation as to why: non persistent messages sent over a normal speed channel cause persistent message to be written to the channel sync queue, which requires disk. I set up some tests in my lab environment. Here are the results. * Server1: SpokeQM1, Win2000 SP2, MQ 5.3 CSD03 RemoteQ called FinalQ that points to FinalQ on SpokeQM2, via transmit queue HubQM1 Server2: HubQM1, Win2000 SP2, MQ 5.2.1 CSD05 QMAlias called SpokeQM2, which sends messages to transmit queue SpokeQM2.XMITQ Server3: SpokeQM2, Win2000 SP2, MQ 5.2.1 CSD05 Local queue called FinalQ *** Test #1: Channel SpokeQM1.HubQM1 has a speed of NORMAL. Start putting 1K Non-Persistent(NP) messages every 250 milliseconds to the remote queue def on SpokeQM1. Results #1: As expected, constant disk writes on the server that houses
Re: Data conversion with MA7P using .NET application
Elena - You would set the default buffer size on the Get method, not the Put method. As to what size to use, that really depends on your application that is putting messages to your queue. - Steve -Original Message- From: Elena Nanos [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 2:23 PM To: [EMAIL PROTECTED] Subject: Re: Data conversion with MA7P using .NET application Hello Steve, thank you very much for your reply, it is nice to know that we are not alone ... The queues using this support pack are set to 4 Meg max message size. Our developer will test setting larger buffer size on a PUT. What size do you recommend? Thanks again. Elena. GIES, STEVE [EMAIL PROTECTED]@AKH-Wien.AC.AT on 06/03/2003 01:55:38 PM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:Re: Data conversion with MA7P using .NET application Elena - This is a known bug in the current .NET support pac. What is happening is that by default the MQQueue class attempts to get the message with a 1 byte buffer. This of course fails (unless you just happen to be passing a 1 or 0 byte message!!) with a truncation failure. The class then resizes its internal buffer and retries the MQGET call, and since the buffer is now large enough the message is retrieved. (BTW, the ActiveX classes do the same thing, but they start with a 2K buffer). The problem with the .NET classes is that after the first MQGET call the MQMD-CCSID field has been updated with the value from the message - which is the value from the mainframe queue manager. When the second call is made, this field is not reinitialized. This tells MQ to convert the data into the code page from the mainframe. Since the data is already in this code page, no conversion takes place. One way to work around this problem is to instruct the class to use a bigger default buffer size. You do this on the put method. For example, to use a 5000 byte buffer in VB.NET code the following myQueue.Get(myMsg, myGMO, 5000) This does, however, require you to know what the largest size message will be. Steve Gies Safeco Insurance IT Specialist - WebSphere MQ -Original Message- From: Elena Nanos [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 8:23 AM To: [EMAIL PROTECTED] Subject: Data conversion with MA7P using .NET application Hello, we are using Support pack MA7P - WebSphere MQ classes for Microsoft .NET, which allows MQ to be invoked from Microsoft .NET applications. We ran into a problem with data conversion. The data coming from mainframe going to distributed, is not being converted to ASCII. Is any one else using this support pack and can share the experience with us? Thank you. Elena Nanos Sr. Software and System Architect IBM Certified Solution Expert in CICS WEB Enablement and MQSeries Zurich NA *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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 and server configuration
Just curious. What is the difference between 'client' in the server CD and the client from the support pack? Thanks, Ian -Original Message- From: Francois Van der Merwe1 [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 7:11 PM To: [EMAIL PROTECTED] Subject: Re: Client and server configuration Just to make this a little bit more clear. You MUST install the client that is on the SERVER CD. When you start installation from the server CD, one of the options is to also install the client code - use that. Francois van der Merwe Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert Developer Potkay, Peter M (PLC, IT) To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: RTFORD.COMSubject: Re: Client and server configuration Sent by: MQSeries List [EMAIL PROTECTED] AC.AT 03/06/2003 14:02 Please respond to MQSeries List Yes. But if you install the MQServer onto your machine, then you must install the MQClient from the CD. You cannot use the MQClient that you download as a Support Pack. If you install ONLY MQClient on a PC, then you can use either the client from the CD or the client from the support pack download page. -Original Message- From: Teresa Cheung [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 4:56 PM To: [EMAIL PROTECTED] Subject: Client and server configuration Can both have MQSeries client and sever software installed on the same operating system? I am running Windows 2000 . Thanks TC Do you Yahoo!? Free online calendar with sync to Outlook(TM). This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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 v5.3
Hi everyone, Are there any known issues with MQSeries v5.3? Would like your inputs on this ... Thanks. Sony 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