Re: arrival time of last message
I assume you are looking to create some sort of monitoring app that will alert you if queue X has not received a message in N minutes. If this is the case, you might look into the RESET QSTATS command (See the Command Reference for details). If you create a program that sends a RESET QSTATS (queue-name) command every N minutes, it will tell you how many messages have been enqueued and dequeued since the last RESET command was sent. If the enqueued count is 0, you have not received any messages in the interval. Hope this helps. - Steve -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of I Sent: Tuesday, November 18, 2003 5:17 AM To: [EMAIL PROTECTED] Subject: Re: arrival time of last message It's odd that server folk are less vigilant than the mainframe folk. You'd think the maintainers of the less reliable and proven platform would *more* vigilant if anything, but I guess one can never tell. But back to the point... do they have channel triggering configured correctly? I've encountered a few situations where it hasn't been, and channels have timed out, never to be automatically restarted. Ian -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Larry Murray Sent: Tuesday, 18 November 2003 10:35 To: [EMAIL PROTECTED] Subject: arrival time of last message Good evening folks.. We are having an issue with some servers that send messages to MQ on the mainframe. MQ, as always, is working perfectlybut evey now and then one of the servers just stops sending messages. The server folks are less vigilant than the mainframe guys. Usually we see that a server is no longer sending messages beause because the CICS transactions triggered as a result of the arrival of a message stops. So..I am looking for a method that I can employ to query MQ as to the last time a message arrived on a queue. The messages are not persistent. When CICS executes the triggered transaction, the message goes away. Is there a time stamp some placein the queue stats that a program can access that will give a dte/time stamp of the last message that hit the queue? Thanks...Larry Larry Murray Putnam Investments Tech Services 1-617-760-3270 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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 V5R31 ON ZOS - CSQY340E
Hey Mike - not sure about your problem, but I recently migrated from v2.1 to v5.3.1 and there is a separate FMID(JMS5319) for "Full Function feature". I hadn't read much about this, so I asked IBM and they said this was required when installing full blown MQ. I guess there is a "reduced function" form of MQ that you get when you install WAS v5. Hope that helps. Mike Lawrence <[EMAIL PROTECTED]To: [EMAIL PROTECTED] LINES.COM> cc: Sent by: MQSeriesSubject: MQSERIES V5R31 ON ZOS - CSQY340E List <[EMAIL PROTECTED] n.AC.AT> 11/18/2003 05:17 PM Please respond to MQSeries List Hello, I am attempting to bring up new version of MQSeries in Development. We When I brought it up I got message CSQY340E @MQT1 Queue manager has restricted functionality, but previously had full functionality. Unsupported objects will be deleted (losing messages), invalid attributes will be changed 29 CSQY341D @MQT1 Reply Y to continue or N to cancel: I thought this may be because of the No java/internet gateway...so I ans It then deleted all my channels and basically was worthless - would allo I have looked through the Fine Manuals and while it talks of Restricted Any help would be appreciated...I will happily read about this if you ca Thanks in advance. Mike Lawrence 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 V5R31 ON ZOS - CSQY340E
Some of my message was truncated...so here it is again. Thanks again in advance. Hello, I am attempting to bring up new version of MQSeries in Development. We are running bare bones - no java, no internet gateway ...just MQseries. When I brought it up I got message CSQY340E @MQT1 Queue manager has restricted functionality, but previously had full functionality. Unsupported objects will be deleted (losing messages), invalid attributes will be changed 29 CSQY341D @MQT1 Reply Y to continue or N to cancel: I thought this may be because of the No java/internet gateway...so I answered yes. It then deleted all my channels and basically was worthless - would not allow connections to CICS... Who would need this... I have looked through the Fine Manuals and while it talks of Restricted functionality it doesn't elaborate... I want my full functionality back. Any help would be appreciated...I will happily read about this if you can help me find the correct Fine Manual. Thanks in advance. Mike Lawrence 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 do you test a MQSeries recovery plan
Bill/Jeff, we (bank...) run our production servers clustered hardware using Veritas and Sun Cluster 3.0, to deal with occasional cpu and disk failures. For total disaster (the infamous 747) we have a Disaster Recovery (DR) procedure that fits in with our company DR procedure, every 6 to 12 months this is tested for large parts of the business, so we simply 'slide in' with the overall plan... Doesn't an airline have such procedures? Michael -Oorspronkelijk bericht- Van: MQSeries List [mailto:[EMAIL PROTECTED] Bill Anderson Verzonden: dinsdag 18 november 2003 23:45 Aan: [EMAIL PROTECTED] Onderwerp: Re: How do you test a MQSeries recovery plan Jeff My problems are similar. We run a 7/24 messaging service for the airline industry. While some messages are rather mundane, others are critical (like gee, some butt head just hijacked my airplane). There is no budget line item to provide me with a test environment so, when I make changes, it goes straight into production. I have a script that automates running the save queue manager utility offered by IBM every night. That gives me assurance that even if our 2nd level support people make a minor change to a customers configuration, I get a snapshot of it every day. I also back up all of the configuration files (such as qm.ini) because I have customized them. If I ever lost a queue manager because of a hardware failure or something, I could rebuild it quicker than it would take to fix the box its self. I do worry about the logs though, all of our message traffic is persistent. If we lost a disk, everything that was "on queue" would be gone. Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Jeff A Tressler <[EMAIL PROTECTED]To: [EMAIL PROTECTED] >cc: Sent by: MQSeriesSubject: How do you test a MQSeries recovery plan List <[EMAIL PROTECTED] N.AC.AT> 11/18/2003 04:46 PM Please respond to MQSeries List We are working on solidifying our MQSeries recovery plans. Coming up with a plan seems easy but how do you test it before actually needing it to be sure it accomplishes you needs? Do people actually create and mess with queue managers? Does this risk corrupting your queue managers and possibly your systems? 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: How do you test a MQSeries recovery plan
Jeff My problems are similar. We run a 7/24 messaging service for the airline industry. While some messages are rather mundane, others are critical (like gee, some butt head just hijacked my airplane). There is no budget line item to provide me with a test environment so, when I make changes, it goes straight into production. I have a script that automates running the save queue manager utility offered by IBM every night. That gives me assurance that even if our 2nd level support people make a minor change to a customers configuration, I get a snapshot of it every day. I also back up all of the configuration files (such as qm.ini) because I have customized them. If I ever lost a queue manager because of a hardware failure or something, I could rebuild it quicker than it would take to fix the box its self. I do worry about the logs though, all of our message traffic is persistent. If we lost a disk, everything that was "on queue" would be gone. Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Jeff A Tressler <[EMAIL PROTECTED]To: [EMAIL PROTECTED] >cc: Sent by: MQSeriesSubject: How do you test a MQSeries recovery plan List <[EMAIL PROTECTED] N.AC.AT> 11/18/2003 04:46 PM Please respond to MQSeries List We are working on solidifying our MQSeries recovery plans. Coming up with a plan seems easy but how do you test it before actually needing it to be sure it accomplishes you needs? Do people actually create and mess with queue managers? Does this risk corrupting your queue managers and possibly your systems? 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 V5R31 ON ZOS - CSQY340E
Hello, I am attempting to bring up new version of MQSeries in Development. We When I brought it up I got message CSQY340E @MQT1 Queue manager has restricted functionality, but previously had full functionality. Unsupported objects will be deleted (losing messages), invalid attributes will be changed 29 CSQY341D @MQT1 Reply Y to continue or N to cancel: I thought this may be because of the No java/internet gateway...so I ans It then deleted all my channels and basically was worthless - would allo I have looked through the Fine Manuals and while it talks of Restricted Any help would be appreciated...I will happily read about this if you ca Thanks in advance. Mike Lawrence Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
How do you test a MQSeries recovery plan
We are working on solidifying our MQSeries recovery plans. Coming up with a plan seems easy but how do you test it before actually needing it to be sure it accomplishes you needs? Do people actually create and mess with queue managers? Does this risk corrupting your queue managers and possibly your systems? 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: Invalid CCSID from WIN 2000 client to Z/OS
In general, MQ on zOS certainly does support MQGMO_CONVERT (ie receiver gets it right). You are linking with the correct library if you are using MQIC32.DLL. The MQM.DLL library is for use when you have a queue manager on the local windows machine, and you are using server binding to attach to it. You may have to look at translating your message to the correct target character set (500). MQ provides some tools to assist with this (crtmqcvx). Regards, Neil Casey. |-+> | | "Benjamin F. | | | Zhou"| | | <[EMAIL PROTECTED]| | | USA.COM> | | | Sent by: MQSeries| | | List | | | <[EMAIL PROTECTED]| | | n.AC.AT> | | || | || | | 19/11/2003 06:59 | | | Please respond to| | | MQSeries List| | || |-+> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Invalid CCSID from WIN 2000 client to Z/OS | >--| I dimmly remember MQ on z/os doesn't support "receiver gets it right", I could be wrong. But, if that's the case, you'll need to set your NT sending MCA definition to convert=yes. cheers, Benjamin F. Zhou Messaging & Integration Enterprise Applicatin Integration Mercedes-Benz USA x.2474 Nushi Mehr <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .COM>cc: Sent by: Subject: Re: Invalid CCSID from WIN 2000 client to Z/OS MQSeries List <[EMAIL PROTECTED] en.AC.AT> 11/18/2003 12:49 PM Please respond to MQSeries List Thanks for your reply. I am not using ACTIVE X i AM USING Power Builder compiling C code. Iam thinking may be is the MQ library that I am using. I use MQIC32.LIB and maybe I should use MQM.LIB. How ever when we use MQM.LIB we get connection problem with MQCONN. Neil Casey <[EMAIL PROTECTED]> wrote: I don't know why your message is not getting converted. CP437 is US ASCII, which would be the code page of your PC. Are you certain that you are attempting to convert the incoming message. It may be that you should create the original message in CodePage 500 (International EBCDIC). The MQ Automation Classes for ActiveX provide methods for performing this conversion on message data as it is created or retrieved. The correct settings for the MQMD.Format and MQCIH.Format depends upon whether you are trying to drive the 3270 bridge or the DPL bridge. Possible values for the MQCIH.Format would be CSQCBDCI to drive conversion of 3270 map data, or MQSTR for character only DPL data. I haven't tried any of the conversion options with the CICS bridge. Regards, Neil Casey |-+> | | Nushi Mehr | | | | | COM> | | | Sent by: MQSeries| | | List | | | | | n.AC.AT> | | | | | | | | | 18/11/2003 09:27 | | | Please respond to| | | MQSeries List | | | | |-+> > --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Invalid CCSID from WIN 2000 client to Z/OS | > --| Thank you so much for your reply, I do exactly what you are saying regarding the mqmd, mqcih format. But it is not converting. I am not sure I might have to apply the PTF UQ76248, UQ76249. Any ideas ? Neil Casey wrote: Hello, MQSeries does not in general support conversion of CICS bridge datastreams, although conversion is possible in some specific instances. Look at the WebSphere MQ Application Programming Guide, Chapter 17, Under heading Programming for the Distributed Environment. It basically says that you need to ensure that your message is already in the correct CCSID for CICS (which in your case seems to be CCSID 500). If your
Re: Invalid CCSID from WIN 2000 client to Z/OS
I dimmly remember MQ on z/os doesn't support "receiver gets it right", I could be wrong. But, if that's the case, you'll need to set your NT sending MCA definition to convert=yes. cheers, Benjamin F. Zhou Messaging & Integration Enterprise Applicatin Integration Mercedes-Benz USA x.2474 Nushi Mehr <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .COM>cc: Sent by: Subject: Re: Invalid CCSID from WIN 2000 client to Z/OS MQSeries List <[EMAIL PROTECTED] en.AC.AT> 11/18/2003 12:49 PM Please respond to MQSeries List Thanks for your reply. I am not using ACTIVE X i AM USING Power Builder compiling C code. Iam thinking may be is the MQ library that I am using. I use MQIC32.LIB and maybe I should use MQM.LIB. How ever when we use MQM.LIB we get connection problem with MQCONN. Neil Casey <[EMAIL PROTECTED]> wrote: I don't know why your message is not getting converted. CP437 is US ASCII, which would be the code page of your PC. Are you certain that you are attempting to convert the incoming message. It may be that you should create the original message in CodePage 500 (International EBCDIC). The MQ Automation Classes for ActiveX provide methods for performing this conversion on message data as it is created or retrieved. The correct settings for the MQMD.Format and MQCIH.Format depends upon whether you are trying to drive the 3270 bridge or the DPL bridge. Possible values for the MQCIH.Format would be CSQCBDCI to drive conversion of 3270 map data, or MQSTR for character only DPL data. I haven't tried any of the conversion options with the CICS bridge. Regards, Neil Casey |-+> | | Nushi Mehr | | | | | COM> | | | Sent by: MQSeries| | | List | | | | | n.AC.AT> | | | | | | | | | 18/11/2003 09:27 | | | Please respond to| | | MQSeries List | | | | |-+> > --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Invalid CCSID from WIN 2000 client to Z/OS | > --| Thank you so much for your reply, I do exactly what you are saying regarding the mqmd, mqcih format. But it is not converting. I am not sure I might have to apply the PTF UQ76248, UQ76249. Any ideas ? Neil Casey wrote: Hello, MQSeries does not in general support conversion of CICS bridge datastreams, although conversion is possible in some specific instances. Look at the WebSphere MQ Application Programming Guide, Chapter 17, Under heading Programming for the Distributed Environment. It basically says that you need to ensure that your message is already in the correct CCSID for CICS (which in your case seems to be CCSID 500). If your message data is pure text, then you can achieve conversion by specifying a MQCIH.Format of MQString. Otherwise, you need to build the data stream in EBCDIC and/or mainframe binary data formats, and correctly set the Format and CCSID fields in the headers. The actual text from the manual is: Programming for th e distributed environment CICS DPL programs and transactions can be driven through the CICS bridge when the client application resides on a workstation. The main consideration when programming for the distributed environment is data conversion between the different encoding schemes and CCSID values of the workstation and z/OS. Conversion is carried out by two different routines, one for the MQCIH structure and another for the vector. You can ensure that conversion of the MQCIH is achieved by specifying MQFMT_CICS in the MQMD.Format field. Vector conversion, however, requires a little more consideration. CICS transactions in the distributed environment Conversion is only supported by the CICS bridge for the outbound SEND MAP and RECEIVE MAP request vectors, and for the inbound RECEIVE MAP vector. To achieve conversion of the SEND MAP and RECEIVE MAP vectors, do this: Make sure that you ass emble your maps specifying DSECT=ADSDL in your DFHMSD macro. Your map must be assembled under CICS Transaction Server for OS/390 Version 1.2 or greater for the ADSD or ADSDL to be made available. If you do not have the original mapset definition, recreate the map using the CICS DFHBMSUP utility. Specify a value of MQCADSD_SEND+MQCADSD_MSGFORMAT in field MQCIH.ADSDescriptor. If you are using an ADSD or ADSDL to build your RECEIVE MAP ADS, you must also add in the v
Same question in other words
Production as/400 Box1QMGR01 running Contingency as/400 Box2 QMGRx stand by Within an mq cluster I have QMGR01 running over AS/400. In the event of a fatal failure other qmgr, in a separate box, should replace the as/400 qmgr. Both qmgrs have the same queues. How can I make the cluster to recognize the backup qmgr? I am confused because the contingency as/400 box will take the ip address of the production box. Is it posible to use the same name for both qmgrs? Any ideas will be apreciated. Yonny R. Serrano GBM Dominicana Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
How do I search MQ list server
I use to be able to go to this site and I was able to search for all kinds of MQ words. This site it is not providing the same easy functions or I don't know how to use it. Would some body kindly tell me how I can brows list server based on a key. THanks for your help. Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard
Re: Invalid CCSID from WIN 2000 client to Z/OS
Thanks for your reply. I am not using ACTIVE X i AM USING Power Builder compiling C code. Iam thinking may be is the MQ library that I am using. I use MQIC32.LIB and maybe I should use MQM.LIB. How ever when we use MQM.LIB we get connection problem with MQCONN. Neil Casey <[EMAIL PROTECTED]> wrote: I don't know why your message is not getting converted. CP437 is US ASCII,which would be the code page of your PC. Are you certain that you areattempting to convert the incoming message. It may be that you shouldcreate the original message in CodePage 500 (International EBCDIC). The MQAutomation Classes for ActiveX provide methods for performing thisconversion on message data as it is created or retrieved.The correct settings for the MQMD.Format and MQCIH.Format depends uponwhether you are trying to drive the 3270 bridge or the DPL bridge. Possiblevalues for the MQCIH.Format would be CSQCBDCI to drive conversion of 3270map data, or MQSTR for character only DPL data.I haven't tried any of the conversion options with the CICS bridge.Regards,Neil Casey|-+>| | Nushi Mehr || | <[EMAIL PROTECTED]|| | COM> || | Sent by: MQSeries|| | List || | <[EMAIL PROTECTED]|| | n.AC.AT> || | || | || | 18/11/2003 09:27 || | Please respond to|| | MQSeries List || | ||-+>>--|| || To: [EMAIL PROTECTED] || cc: || Subject: Re: Invalid CCSID from WIN 2000 client to Z/OS |>--|Thank you so much for your reply,I do exactly what you are saying regarding the mqmd, mqcih format.But it is not converting. I am not sure I might have to apply the PTFUQ76248, UQ76249.Any ideas ?Neil Casey <[EMAIL PROTECTED]>wrote:Hello,MQSeries does not in general support conversion of CICS bridgedatastreams,although conversion is possible in some specific instances.Look at the WebSphere MQ Application Programming Guide, Chapter 17, Underheading Programming for the Distributed Environment.It basically says that you need to ensure that your message is already inthe correct CCSID for CICS (which in your case seems to be CCSID 500). Ifyour message data is pure text, then you can achieve conversion byspecifying a MQCIH.Format of MQString. Otherwise, you need to build thedata stream in EBCDIC and/or mainframe binary data formats, and correctlyset the Format and CCSID fields in the headers.The actual text from the manual is:Programming for th e distributed environmentCICS DPL programs and transactions can be driven through the CICS bridgewhen the client application resides on a workstation.The main consideration when programming for the distributed environment isdata conversion between the different encoding schemes and CCSID values ofthe workstation and z/OS. Conversion is carried out by two differentroutines, one for the MQCIH structure and another for the vector.You can ensure that conversion of the MQCIH is achieved by specifyingMQFMT_CICS in the MQMD.Format field. Vector conversion, however, requiresalittle more consideration.CICS transactions in the distributed environmentConversion is only supported by the CICS bridge for the outbound SEND MAPand RECEIVE MAP request vectors, and for the inbound RECEIVE MAP vector.To achieve conversion of the SEND MAP and RECEIVE MAP vectors, do this:Make sure that you ass emble your maps specifying DSECT=ADSDL in yourDFHMSD macro. Your map must be assembled under CICS TransactionServer for OS/390 Version 1.2 or greater for the ADSD or ADSDL to bemade available. If you do not have the original mapset definition,recreate the map using the CICS DFHBMSUP utility.Specify a value of MQCADSD_SEND+MQCADSD_MSGFORMAT in fieldMQCIH.ADSDescriptor. If you are using an ADSD or ADSDL to build yourRECEIVE MAP ADS, you must also add in the value MQCADSD_RECV for thisfield.Specify a value of CSQCBDCI in field MQCIH.Format on every inboundmessage.If you want to use vectors other than SEND MAP and RECEIVE MAP to drivetransactions in the distributed environment, you must either write yourowndata conversion routines or create and interpret the data streams in theformat required by z/OS.The MQCIH.Format is always set to CSQCBDCO in outbound messages. If youwant to specify another format type for outbound conversion, you mustintercept the message by writing to a local reply queue. Change the valueof MQCIH.Format to specify your own routine before sending it on to theremote environment.No support is provided for conversion between workstation and mainframeformats of vectors other than SEND MAP (outbound) and RECEIVE MAP (bothinbound and outbound).CICS DPL programs in the distributed environmentIf you are driving a DPL program that neither receives nor returnsCOMMAREAdata, or
Re: Impact of Syncpoint?
This is true. Ruuning test at Hursely's request they indicated that we needed to pump in 10K or more messages for them to get a realistic view of what was going on. This was for MQSI 2.1 on the OS390. From: John Scott <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Impact of Syncpoint? Date: Tue, 18 Nov 2003 13:26:44 - I ran my test on my laptop running Windows XP with WMQ 5.3 CSD05. The performance improvements may only apply to distributed platforms (Windows, Unix, AS/400 etc.) which I have always believed come of the same basic code base. I have always believed that the OS/390 version of WMQ comes from a different code base because that platform is so significantly different. As you're running on the mainframe, you might want to try more messages (try 1 messages or maybe even more). It might be that your test run is so short that the different in performance is not noticeable. Cheers John. IBM Certified Specialist - MQSeries Argos Ltd -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: 18 November 2003 12:53 To: [EMAIL PROTECTED] Subject: Re: Impact of Syncpoint? Thanks Scott... I should have stated the scenario a bit more clearly. Currently, an app is getting messages (Pers or non-pers) outside UOW contrary to my recommendation. I asked them to use syncpoint for persistent messages for abvious reasons. Since they have to deal with Pers and non-pers msgs in the same app, I suggested the use of MQGMO_SYINCPOINT_IF_PERSISTENT option. And they will have to commit after every Pers message. Now they are asking me how much impact (postive or negative) this syncpointing will have on performance. To that end, I have just done the following 2 tests, on the mainframe 5.3, which produced the same result (i.e. no difference): I used 1K long 1000 Persistent mesgs ineach case: 1- MQGET loop: - Get with no-syncpoint - Write the msg to a file End-loop - Commit (after the 1000th message) 2- MQGET loop: - Get with syncpoint - Write the msg to a file - Commit End-loop In each test, CPU usage was 03. I wonder why your test results are different from mine. Were your tests done on NT? Even so, I did not think that there would be this much difference. Any ideas? Thanks, Ruzi Scott <[EMAIL PROTECTED]> wrote: > You still get an improvement by using syncpoint > after every message. The > test I did reduced the time for 1000 persistent > messages from 25 to 15 > seconds... > > Regards > John Scott > IBM Certified Specialist - MQSeries > Argos Ltd > > > -Original Message- > From: Ruzi R [mailto:[EMAIL PROTECTED] > Sent: 17 November 2003 19:03 > To: [EMAIL PROTECTED] > Subject: Re: Impact of Syncpoint? > > > Paul, > > Thanks for the response. But the requirement is that > we have to do a commit after every persistent > message > read off the queue (as opposed to after a batch of > messages read). > > Thanks, > > Ruzi > > --- Paul Clarke <[EMAIL PROTECTED]> wrote: > > Depends what you mean by 'impact'. I assume you're > > talking about persistent > > messages here. Generally speaking the addition of > > syncpoint to persistent > > message operations will increase the performance > > since we only need to > > force the log at commit time rather than for every > > message. > > > > Download my MA01 support pac if you want to have a > > play. > > Choose a local queue, say Q1 > > Load the queue with messages :- > > > > q -oQ1 -ap > > > > at the prompt type > > #1000 > > > > you now have 1000 persistent messages on your > queue. > > > > Get them off by specifying :- > > > > q -IQ1 -t -q > > > > this will printout something like > > > > 1000 Interations in 441.00 ms, Average = 0.44ms or > > 2267.6 per second > > > > This is doing your gets outside of syncpoint. > > To do it inside of syncpoint you can tell queue > how > > often to commit, let's > > say every 100 messages > > > > Load up your queue again and then type > > > > q -IQ1 -t -q -p100 > > > > The line now reads > > 1000 Interations in 90.00 ms, Average = 0.09ms or > > 1.1 per second > > > > By doing the gets under syncpoint (and quite a lot > > of them) we're now about > > 5 times faster. > > > > These were the numbers produced on my ThinkPad and > > will depend greatly on > > the speed of your disks, the type of disks, your > CPU > > speed etc etc. > > > > There are also, I believe, a number of support > pacs > > which detail the speed > > of MQ operations on the support pac website. > > > > Hope this helps, > > P. > > > > Paul G Clarke > > WebSphere MQ Development > > IBM Hursley > > > > > > > > |-+> > > | | Ruzi R | > > | | <[EMAIL PROTECTED]| > > | | M> | > > | | Sent by: MQSeries| > > | | List | > > | | <[EMAIL PROTECTED]| > > | | N.AC.AT> | > > |
Re: PipeLineLength=2
>Thanks Jim. Do you know anyway to tell if the parameter is actually taking effect? Should there be a message in the error logs or >something? We have changed it on several servers (sender and receiver sides), but I can't yet tell if it is actually doing anything. >Thanks again, >B Brian, Not sure what you mean by effect but you can tell you have it switched on if you look at the IPPROCS value of your transmission queue and see it has the value 2. You can also look at queue handles for the same reason. 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: Using ia07 Email Node for WMQI v2.1
I'll have to check a few things because the XML is being created by a stored procedure, and don't ask me why they are doing this instead of using WMQI. Long story Thanks for the info. Chris |-+> | | "Capodicci, Dan | | | (COMFIN, ITSS)" | | | <[EMAIL PROTECTED]| | | .COM>| | | Sent by: | | | "MQSeries List" | | | <[EMAIL PROTECTED]| | | n.AC.AT> | | || | || | | 11/18/2003 09:54 | | | AM | | | Please respond to| | | "MQSeries List" | | || |-+> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Using ia07 Email Node for WMQI v2.1 | | | >--| Hi I am using the Email node also with the same versions of WMQI and WMQ and not having this problem. The "To" tags are repeating, i.e. [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Are you directing the failures to a queue?!? I had some problems setting this up originally and found that the Email node will tack on some helpful error messages. Also, (this may be obvious but just in case :) in my case I am using a compute node in front of the Email node to formulate the XML and initially, I directed the output to a queue so I could validate the xml that I was building. then once tested, I started sending it to the Email node. Are you sure you are sending the multiple "To" tags to the Email node?!? Thanks Dan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Christopher Fryett Sent: Tuesday, November 18, 2003 10:28 AM To: [EMAIL PROTECTED] Subject: Using ia07 Email Node for WMQI v2.1 We are using the Email node (ia07) for WMQI v2.1 on WMQ v5.3 with the latest CSDs. We are using the SMTP version and not Sendmail. We are experiencing a problem when using multiple email address tags within our input stream going into the email node for our message flows. The first email address in the tag works, but the subsequent ones don't. Has anyone used multiple email addresses with this node, and is there any different type of configuration needed in order to allow repeating , , , because this is putting a real crunch in our ability to send email to multiple people properly. Your insight and wisdom is greatly appreciated. Chris 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: PipeLineLength=2
What I would probably do is take a channel and set the BATCHSZ to something small ( 2? ) and then use MA01 (q), with no pausing between messages, and just begin pounding the transmit queue and channel. That way you are certain to drive both threads of the channel. Then just watch for any error messages in the AMQERR logs (both /var/mqm/errors and /var/mqm/qmgrs//errors. Kinda' crude, but in this case "no news is good news" since the only time you see any messages is when something goes wrong. Cheers... Jim Nuckolls McCarty, Brian wrote: Thanks Jim. Do you know anyway to tell if the parameter is actually taking effect? Should there be a message in the error logs or something? We have changed it on several servers (sender and receiver sides), but I can't yet tell if it is actually doing anything. Thanks again, B -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Jim Nuckolls Sent: Monday, November 17, 2003 8:42 PM To: [EMAIL PROTECTED] Subject: Re: PipeLineLength=2 Brian, be sure you are on MQ 5.3 because it doesn't work on MQ 5.2 CSD06. I have been assured by the Lab that the fix was put into MQ 5.3. With high volumes of messages on MQ 5.2 you will begin to see channel protocol errors and receivers rejecting batches due to sequence errors. Base problem appeared to be the wrong LUWID being presented to the wrong thread. A fix is available from the Lab for MQ 5.2 however I have not had the opportunity to test it at my customer as yet. The quick fix was to turn it off since production wasn't pushing it hard enough to warrant its use anyway. Cheers... Jim Nuckolls McCarty, Brian wrote: We are looking at adding PipeLineLength=2 to under CHANNELS: in our qm.ini files. Has anyone had issues with this before? How do you know the settings is actually taking effect? Please let me know your opinions on this parameter. Thanks, Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 WMQ(I) Specialist/Solutions Expert e-business Solution Advisor/Designer/Technologist 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: Using ia07 Email Node for WMQI v2.1
Hi I am using the Email node also with the same versions of WMQI and WMQ and not having this problem. The "To" tags are repeating, i.e. [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Are you directing the failures to a queue?!? I had some problems setting this up originally and found that the Email node will tack on some helpful error messages. Also, (this may be obvious but just in case :) in my case I am using a compute node in front of the Email node to formulate the XML and initially, I directed the output to a queue so I could validate the xml that I was building. then once tested, I started sending it to the Email node. Are you sure you are sending the multiple "To" tags to the Email node?!? Thanks Dan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Christopher Fryett Sent: Tuesday, November 18, 2003 10:28 AM To: [EMAIL PROTECTED] Subject: Using ia07 Email Node for WMQI v2.1 We are using the Email node (ia07) for WMQI v2.1 on WMQ v5.3 with the latest CSDs. We are using the SMTP version and not Sendmail. We are experiencing a problem when using multiple email address tags within our input stream going into the email node for our message flows. The first email address in the tag works, but the subsequent ones don't. Has anyone used multiple email addresses with this node, and is there any different type of configuration needed in order to allow repeating , , , because this is putting a real crunch in our ability to send email to multiple people properly. Your insight and wisdom is greatly appreciated. Chris 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
LDAP with MQ v5.3 CSD04 zLinux
Hello, Has anyone experienced problems with LDAP using MQ v5.3 CSD04 on zLinux? Thanks, Jeff Jeffrey D. RossSenior MQ AdministratorCertified WebSphere MQ Specialist & Solutions ExpertTransUnion, LLC[EMAIL PROTECTED]www.transunion.com NOTICE:The information contained in this e-mail is intended only for the use of the recipient named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this in error, please notify the sender and return this email (and attachment). Delete the original message or any copy of it from your computer system. Thank you.
Re: MQ V5.3 Programs compatible with MQV5.2
Don The quick beginnings and README install doc is what you should be looking over for the most recent upgrade information. Your next choice is to call IBM or look at their web site. The quick beginnings compiler list are the compilers verified by IBM. Your old V5.2 code should work fine on V5.3 server without recompiling. I did not try running V5.3 compiled code on V5.2 server. Thanks Frank -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Thomas, Don Sent: Tuesday, November 18, 2003 10:08 AM To: [EMAIL PROTECTED] Subject: Re: MQ V5.3 Programs compatible with MQV5.2 Frank, Thanks for your response. I've been reading the V5.3 Quick Beginnings and the latest version of Application Programming Guide and they do not agree. For example, in the Quick Beginnings book under Compilers there is a note that says the bundled C compiler is not supported. Yet in the APG in Table 59, the bundled C compiler is listed as being supported. Nor is there any mention of recompiles being necessary as part of migrating form V5.2 to V5.3. Hence my confusion. The only blurb that I have found so far that even remotely deals with this question is in the Quick Beginnings which states that any MQ Version 5 client can connect to any queue manager that supports client attachments, but you only get the functionality that is supported by that queue manager. Has anyone been in this situation? Running code compiled with V5.3 in a V5.2 environment? Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: Bright, Frank [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 4:20 PM To: Thomas, Don Subject: RE: MQ V5.3 Programs compatible with MQV5.2 You shouldn't run V5.3 code on V5.2 server. Check the quick beginnings and review your compiler software requirements for V5.3. Also review the current status to Roquewave software. Thanks Frank 201-269-4071 -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Thomas, Don Sent: Monday, November 17, 2003 3:09 PM To: [EMAIL PROTECTED] Subject: MQ V5.3 Programs compatible with MQV5.2 Are programs compiled using the WMQ V5.3 libraries able to run on servers that are at WMQ V5.2? Specifically I'm referring to an HPUX 11.0 environment. There are two servers, one is development and one is production. The plan is to upgrade the development first and verify the applications and then upgrade the production. If there is a need to promote programs to production before it is upgraded to V5.3 will the programs need to be recompiled back to the V5.2 code? Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive - This e-mail message and any attachments contain confidential information from Medco Health Solutions, Inc. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive - This e-mail message and any attachments contain confidential information from Medco Health Solutions, Inc. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments. 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 ia07 Email Node for WMQI v2.1
We are using the Email node (ia07) for WMQI v2.1 on WMQ v5.3 with the latest CSDs. We are using the SMTP version and not Sendmail. We are experiencing a problem when using multiple email address tags within our input stream going into the email node for our message flows. The first email address in the tag works, but the subsequent ones don't. Has anyone used multiple email addresses with this node, and is there any different type of configuration needed in order to allow repeating , , , because this is putting a real crunch in our ability to send email to multiple people properly. Your insight and wisdom is greatly appreciated. Chris Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQ V5.3 Programs compatible with MQV5.2
Frank, Thanks for your response. I've been reading the V5.3 Quick Beginnings and the latest version of Application Programming Guide and they do not agree. For example, in the Quick Beginnings book under Compilers there is a note that says the bundled C compiler is not supported. Yet in the APG in Table 59, the bundled C compiler is listed as being supported. Nor is there any mention of recompiles being necessary as part of migrating form V5.2 to V5.3. Hence my confusion. The only blurb that I have found so far that even remotely deals with this question is in the Quick Beginnings which states that any MQ Version 5 client can connect to any queue manager that supports client attachments, but you only get the functionality that is supported by that queue manager. Has anyone been in this situation? Running code compiled with V5.3 in a V5.2 environment? Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: Bright, Frank [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 4:20 PM To: Thomas, Don Subject: RE: MQ V5.3 Programs compatible with MQV5.2 You shouldn't run V5.3 code on V5.2 server. Check the quick beginnings and review your compiler software requirements for V5.3. Also review the current status to Roquewave software. Thanks Frank 201-269-4071 -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Thomas, Don Sent: Monday, November 17, 2003 3:09 PM To: [EMAIL PROTECTED] Subject: MQ V5.3 Programs compatible with MQV5.2 Are programs compiled using the WMQ V5.3 libraries able to run on servers that are at WMQ V5.2? Specifically I'm referring to an HPUX 11.0 environment. There are two servers, one is development and one is production. The plan is to upgrade the development first and verify the applications and then upgrade the production. If there is a need to promote programs to production before it is upgraded to V5.3 will the programs need to be recompiled back to the V5.2 code? Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive - This e-mail message and any attachments contain confidential information from Medco Health Solutions, Inc. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments. 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: Damaged Queues
Hi I believe this is a known problem with version 5.3. I experienced the problem on both Win2000 and Solaris. The "non" technical explanation is that if a queue has an application that does a get until it receives a 2033 (basically drains the queue) and the qmanager is recycled, the queue sometimes comes up as damaged. There may be other circumstances where this happens but this is when I experienced the problem. There originally was an efix for this but I believe it is now packaged in CSD05. Since I applied the fix, I have not seen the problem again. Thanks Dan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Bryan Baynes - CPX Mngd Services SDC Sent: Tuesday, November 18, 2003 7:58 AM To: [EMAIL PROTECTED] Subject: Damaged Queues Hi All.. Has anyone had the problem of Damaged Queues on AIX and MQ 5.3? If so, what can cause this? It does look like a hardware error. The message number of the error is 2016 and the queue is the DEAD Letter Queue. A client has encountered the problem twice in the last 2 weeks. Your help is greatly appreciated Bryan Baynes 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: Impact of Syncpoint?
Ruzi "In each test, CPU usage was 03." What type of performance impact are you looking for CPU usage or throughput? I believe most of the answers that you've received address throughput not CPU usage. They are improved response time due to less time waiting on MQ to force the data to the queues. Rick |-+---> | | Ruzi R <[EMAIL PROTECTED]> | | | | | | Sent by: MQSeries List | | | <[EMAIL PROTECTED]> | | | | | | | | | | | | Tuesday November 18, 2003 06:53 AM | | | Please respond to MQSeries List | | | | |-+---> >| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Impact of Syncpoint? | >| Thanks Scott... I should have stated the scenario a bit more clearly. Currently, an app is getting messages (Pers or non-pers) outside UOW contrary to my recommendation. I asked them to use syncpoint for persistent messages for abvious reasons. Since they have to deal with Pers and non-pers msgs in the same app, I suggested the use of MQGMO_SYINCPOINT_IF_PERSISTENT option. And they will have to commit after every Pers message. Now they are asking me how much impact (postive or negative) this syncpointing will have on performance. To that end, I have just done the following 2 tests, on the mainframe 5.3, which produced the same result (i.e. no difference): I used 1K long 1000 Persistent mesgs ineach case: 1- MQGET loop: - Get with no-syncpoint - Write the msg to a file End-loop - Commit (after the 1000th message) 2- MQGET loop: - Get with syncpoint - Write the msg to a file - Commit End-loop In each test, CPU usage was 03. I wonder why your test results are different from mine. Were your tests done on NT? Even so, I did not think that there would be this much difference. Any ideas? Thanks, Ruzi Scott <[EMAIL PROTECTED]> wrote: > You still get an improvement by using syncpoint > after every message. The > test I did reduced the time for 1000 persistent > messages from 25 to 15 > seconds... > > Regards > John Scott > IBM Certified Specialist - MQSeries > Argos Ltd > > > -Original Message- > From: Ruzi R [mailto:[EMAIL PROTECTED] > Sent: 17 November 2003 19:03 > To: [EMAIL PROTECTED] > Subject: Re: Impact of Syncpoint? > > > Paul, > > Thanks for the response. But the requirement is that > we have to do a commit after every persistent > message > read off the queue (as opposed to after a batch of > messages read). > > Thanks, > > Ruzi > > --- Paul Clarke <[EMAIL PROTECTED]> wrote: > > Depends what you mean by 'impact'. I assume you're > > talking about persistent > > messages here. Generally speaking the addition of > > syncpoint to persistent > > message operations will increase the performance > > since we only need to > > force the log at commit time rather than for every > > message. > > > > Download my MA01 support pac if you want to have a > > play. > > Choose a local queue, say Q1 > > Load the queue with messages :- > > > > q -oQ1 -ap > > > > at the prompt type > > #1000 > > > > you now have 1000 persistent messages on your > queue. > > > > Get them off by specifying :- > > > > q -IQ1 -t -q > > > > this will printout something like > > > > 1000 Interations in 441.00 ms, Average = 0.44ms or > > 2267.6 per second > > > > This is doing your gets outside of syncpoint. > > To do it inside of syncpoint you can tell queue > how > > often to commit, let's > > say every 100 messages > > > > Load up your queue again and then type > > > > q -IQ1 -t -q -p100 > > > > The line now reads > > 1000 Interations in 90.00 ms, Average = 0.09ms or > > 1.1 per second > > > > By doing the gets under syncpoint (and quite a lot > > of them) we're now about > > 5 times faster. > > > > These were the numbers produced on my ThinkPad and > > will depend greatly on > > the speed of your disks, the type of disks, your > CPU > > speed etc etc. > > > > There are also, I believe, a number of support > pacs > > which detail the speed > > of MQ operations on the support pac website. > > > > Hope this helps, > > P. > > > > Paul G Clarke > > WebSphere MQ Development
Re: Impact of Syncpoint?
Scott, Thanks again for the info... I will do some testing when I have a chance with a VB program (after I make some modifications) on W2K. It is just that I had my mainframe pgm all ready to run; tha's why I used it in my testings. Ruzi --- John Scott <[EMAIL PROTECTED]> wrote: > I ran my test on my laptop running Windows XP with > WMQ 5.3 CSD05. The > performance improvements may only apply to > distributed platforms (Windows, > Unix, AS/400 etc.) which I have always believed come > of the same basic code > base. I have always believed that the OS/390 version > of WMQ comes from a > different code base because that platform is so > significantly different. > > As you're running on the mainframe, you might want > to try more messages (try > 1 messages or maybe even more). It might be that > your test run is so > short that the different in performance is not > noticeable. > > Cheers > John. > IBM Certified Specialist - MQSeries > Argos Ltd > > > -Original Message- > From: Ruzi R [mailto:[EMAIL PROTECTED] > Sent: 18 November 2003 12:53 > To: [EMAIL PROTECTED] > Subject: Re: Impact of Syncpoint? > > > Thanks Scott... > > I should have stated the scenario a bit more > clearly. Currently, an app is > getting messages (Pers or > non-pers) outside UOW contrary to my recommendation. > I > asked them to use syncpoint for persistent messages > for abvious reasons. Since they have to deal with > Pers > and non-pers msgs in the same app, I suggested the > use > of MQGMO_SYINCPOINT_IF_PERSISTENT option. And they > will have to commit after every Pers message. Now > they are asking me how much impact (postive or > negative) this syncpointing will have on > performance. > > > To that end, I have just done the following 2 tests, > on the mainframe 5.3, which produced the same result > (i.e. no difference): I used 1K long 1000 Persistent > mesgs ineach case: > > 1- MQGET loop: >- Get with no-syncpoint >- Write the msg to a file >End-loop >- Commit (after the 1000th message) > > 2- MQGET loop: >- Get with syncpoint >- Write the msg to a file >- Commit >End-loop > > In each test, CPU usage was 03. I wonder why your > test > results are different from mine. Were your tests > done > on NT? Even so, I did not think that there would be > this much difference. Any ideas? > > Thanks, > > Ruzi > > Scott <[EMAIL PROTECTED]> wrote: > > You still get an improvement by using syncpoint > > after every message. The > > test I did reduced the time for 1000 persistent > > messages from 25 to 15 > > seconds... > > > > Regards > > John Scott > > IBM Certified Specialist - MQSeries > > Argos Ltd > > > > > > -Original Message- > > From: Ruzi R [mailto:[EMAIL PROTECTED] > > Sent: 17 November 2003 19:03 > > To: [EMAIL PROTECTED] > > Subject: Re: Impact of Syncpoint? > > > > > > Paul, > > > > Thanks for the response. But the requirement is > that > > we have to do a commit after every persistent > > message > > read off the queue (as opposed to after a batch of > > messages read). > > > > Thanks, > > > > Ruzi > > > > --- Paul Clarke <[EMAIL PROTECTED]> wrote: > > > Depends what you mean by 'impact'. I assume > you're > > > talking about persistent > > > messages here. Generally speaking the addition > of > > > syncpoint to persistent > > > message operations will increase the performance > > > since we only need to > > > force the log at commit time rather than for > every > > > message. > > > > > > Download my MA01 support pac if you want to have > a > > > play. > > > Choose a local queue, say Q1 > > > Load the queue with messages :- > > > > > > q -oQ1 -ap > > > > > > at the prompt type > > > #1000 > > > > > > you now have 1000 persistent messages on your > > queue. > > > > > > Get them off by specifying :- > > > > > > q -IQ1 -t -q > > > > > > this will printout something like > > > > > > 1000 Interations in 441.00 ms, Average = 0.44ms > or > > > 2267.6 per second > > > > > > This is doing your gets outside of syncpoint. > > > To do it inside of syncpoint you can tell queue > > how > > > often to commit, let's > > > say every 100 messages > > > > > > Load up your queue again and then type > > > > > > q -IQ1 -t -q -p100 > > > > > > The line now reads > > > 1000 Interations in 90.00 ms, Average = 0.09ms > or > > > 1.1 per second > > > > > > By doing the gets under syncpoint (and quite a > lot > > > of them) we're now about > > > 5 times faster. > > > > > > These were the numbers produced on my ThinkPad > and > > > will depend greatly on > > > the speed of your disks, the type of disks, your > > CPU > > > speed etc etc. > > > > > > There are also, I believe, a number of support > > pacs > > > which detail the speed > > > of MQ operations on the support pac website. > > > > > > Hope this helps, > > > P. > > > > > > Paul G Clarke > > > WebSphere MQ Development > > > IBM Hursley > > > > > > > > > > > > |-+> > > > | | Ruzi R |
Re: arrival time of last message
The channel is not the issue. The server just stops functioning correctly. I want the mainframe to be able to recognize a server has stopped sending messages. I am also looking into using CICS stats to help with this issue. Thanks Larry Murray Putnam Investments Tech Services 1-617-760-3270 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: PipeLineLength=2
Thanks Jim. Do you know anyway to tell if the parameter is actually taking effect? Should there be a message in the error logs or something? We have changed it on several servers (sender and receiver sides), but I can't yet tell if it is actually doing anything. Thanks again, B -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Jim Nuckolls Sent: Monday, November 17, 2003 8:42 PM To: [EMAIL PROTECTED] Subject: Re: PipeLineLength=2 Brian, be sure you are on MQ 5.3 because it doesn't work on MQ 5.2 CSD06. I have been assured by the Lab that the fix was put into MQ 5.3. With high volumes of messages on MQ 5.2 you will begin to see channel protocol errors and receivers rejecting batches due to sequence errors. Base problem appeared to be the wrong LUWID being presented to the wrong thread. A fix is available from the Lab for MQ 5.2 however I have not had the opportunity to test it at my customer as yet. The quick fix was to turn it off since production wasn't pushing it hard enough to warrant its use anyway. Cheers... Jim Nuckolls McCarty, Brian wrote: >We are looking at adding PipeLineLength=2 to under CHANNELS: in our qm.ini files. >Has anyone had issues with this before? How do you know the settings is actually >taking effect? > >Please let me know your opinions on this parameter. > >Thanks, > >Brian M. McCarty >USAA, Senior Systems Programmer >210.913.1678 >WMQ(I) Specialist/Solutions Expert >e-business Solution Advisor/Designer/Technologist > >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: Damaged Queues
Title: Message We've been experiencing this kind of thing on AIX and WMQ 5.3. We were currently at CSD03, but we're currently upgrading to CSD05 to see if that sorts out the problem. I noticed that we also get 2016 errors when attempting to display queues in runmqsc. There is a technote on IBM's site. Check out: http://www-1.ibm.com/support/docview.wss?rs=171&context=SSFKSJ&q=kill&uid=swg21143549&loc=en_US&cs=utf-8&lang=en Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd -Original Message-From: Bryan Baynes - CPX Mngd Services SDC [mailto:[EMAIL PROTECTED] Sent: 18 November 2003 12:58To: [EMAIL PROTECTED]Subject: Damaged Queues Hi All.. Has anyone had the problem of Damaged Queues on AIX and MQ 5.3? If so, what can cause this? It does look like a hardware error. The message number of the error is 2016 and the queue is the DEAD Letter Queue. A client has encountered the problem twice in the last 2 weeks. Your help is greatly appreciated Bryan Baynes *** 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 addressee, any disclosure, reproduction, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using the 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.
Re: Impact of Syncpoint?
I ran my test on my laptop running Windows XP with WMQ 5.3 CSD05. The performance improvements may only apply to distributed platforms (Windows, Unix, AS/400 etc.) which I have always believed come of the same basic code base. I have always believed that the OS/390 version of WMQ comes from a different code base because that platform is so significantly different. As you're running on the mainframe, you might want to try more messages (try 1 messages or maybe even more). It might be that your test run is so short that the different in performance is not noticeable. Cheers John. IBM Certified Specialist - MQSeries Argos Ltd -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: 18 November 2003 12:53 To: [EMAIL PROTECTED] Subject: Re: Impact of Syncpoint? Thanks Scott... I should have stated the scenario a bit more clearly. Currently, an app is getting messages (Pers or non-pers) outside UOW contrary to my recommendation. I asked them to use syncpoint for persistent messages for abvious reasons. Since they have to deal with Pers and non-pers msgs in the same app, I suggested the use of MQGMO_SYINCPOINT_IF_PERSISTENT option. And they will have to commit after every Pers message. Now they are asking me how much impact (postive or negative) this syncpointing will have on performance. To that end, I have just done the following 2 tests, on the mainframe 5.3, which produced the same result (i.e. no difference): I used 1K long 1000 Persistent mesgs ineach case: 1- MQGET loop: - Get with no-syncpoint - Write the msg to a file End-loop - Commit (after the 1000th message) 2- MQGET loop: - Get with syncpoint - Write the msg to a file - Commit End-loop In each test, CPU usage was 03. I wonder why your test results are different from mine. Were your tests done on NT? Even so, I did not think that there would be this much difference. Any ideas? Thanks, Ruzi Scott <[EMAIL PROTECTED]> wrote: > You still get an improvement by using syncpoint > after every message. The > test I did reduced the time for 1000 persistent > messages from 25 to 15 > seconds... > > Regards > John Scott > IBM Certified Specialist - MQSeries > Argos Ltd > > > -Original Message- > From: Ruzi R [mailto:[EMAIL PROTECTED] > Sent: 17 November 2003 19:03 > To: [EMAIL PROTECTED] > Subject: Re: Impact of Syncpoint? > > > Paul, > > Thanks for the response. But the requirement is that > we have to do a commit after every persistent > message > read off the queue (as opposed to after a batch of > messages read). > > Thanks, > > Ruzi > > --- Paul Clarke <[EMAIL PROTECTED]> wrote: > > Depends what you mean by 'impact'. I assume you're > > talking about persistent > > messages here. Generally speaking the addition of > > syncpoint to persistent > > message operations will increase the performance > > since we only need to > > force the log at commit time rather than for every > > message. > > > > Download my MA01 support pac if you want to have a > > play. > > Choose a local queue, say Q1 > > Load the queue with messages :- > > > > q -oQ1 -ap > > > > at the prompt type > > #1000 > > > > you now have 1000 persistent messages on your > queue. > > > > Get them off by specifying :- > > > > q -IQ1 -t -q > > > > this will printout something like > > > > 1000 Interations in 441.00 ms, Average = 0.44ms or > > 2267.6 per second > > > > This is doing your gets outside of syncpoint. > > To do it inside of syncpoint you can tell queue > how > > often to commit, let's > > say every 100 messages > > > > Load up your queue again and then type > > > > q -IQ1 -t -q -p100 > > > > The line now reads > > 1000 Interations in 90.00 ms, Average = 0.09ms or > > 1.1 per second > > > > By doing the gets under syncpoint (and quite a lot > > of them) we're now about > > 5 times faster. > > > > These were the numbers produced on my ThinkPad and > > will depend greatly on > > the speed of your disks, the type of disks, your > CPU > > speed etc etc. > > > > There are also, I believe, a number of support > pacs > > which detail the speed > > of MQ operations on the support pac website. > > > > Hope this helps, > > P. > > > > Paul G Clarke > > WebSphere MQ Development > > IBM Hursley > > > > > > > > |-+> > > | | Ruzi R | > > | | <[EMAIL PROTECTED]| > > | | M> | > > | | Sent by: MQSeries| > > | | List | > > | | <[EMAIL PROTECTED]| > > | | N.AC.AT> | > > | || > > | || > > | | 17/11/2003 16:59 | > > | | Please respond to| > > | | MQSeries List| > > |-+> > > > > > >--- > >
Re: Damaged Queues
Title: Damaged Queues 2016 - MQRC_GET_INHIBITED What makes you say the queue is damaged? If it is damaged and you have linear logging switch on, you can recover the object otherwise you need to redefine the object. I reckon there may one or two reasons but first make sure you've given the correct message number. From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bryan Baynes - CPX Mngd Services SDC Sent: 18 November 2003 02:58 PM To: [EMAIL PROTECTED] Subject: Damaged Queues Hi All.. Has anyone had the problem of Damaged Queues on AIX and MQ 5.3? If so, what can cause this? It does look like a hardware error. The message number of the error is 2016 and the queue is the DEAD Letter Queue. A client has encountered the problem twice in the last 2 weeks. Your help is greatly appreciated Bryan Baynes Any views expressed in this message are those of the individual sender, and T-Systems South Africa (Pty) Ltd accepts no liability therefore, except where the sender specifically states them to be those of T-Systems South Africa (Pty) Ltd. Although this message has been scanned for the possible presence of computer viruses prior to despatch, T-Systems South Africa (Pty) Ltd cannot be held responsible for any viruses or other material transmitted with, or as part of, this message.
Re: arrival time of last message
It's odd that server folk are less vigilant than the mainframe folk. You'd think the maintainers of the less reliable and proven platform would *more* vigilant if anything, but I guess one can never tell. But back to the point... do they have channel triggering configured correctly? I've encountered a few situations where it hasn't been, and channels have timed out, never to be automatically restarted. Ian -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Larry Murray Sent: Tuesday, 18 November 2003 10:35 To: [EMAIL PROTECTED] Subject: arrival time of last message Good evening folks.. We are having an issue with some servers that send messages to MQ on the mainframe. MQ, as always, is working perfectlybut evey now and then one of the servers just stops sending messages. The server folks are less vigilant than the mainframe guys. Usually we see that a server is no longer sending messages beause because the CICS transactions triggered as a result of the arrival of a message stops. So..I am looking for a method that I can employ to query MQ as to the last time a message arrived on a queue. The messages are not persistent. When CICS executes the triggered transaction, the message goes away. Is there a time stamp some placein the queue stats that a program can access that will give a dte/time stamp of the last message that hit the queue? Thanks...Larry Larry Murray Putnam Investments Tech Services 1-617-760-3270 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Impact of Syncpoint?
Before anyone points out, I should add that the Commit after the 1000th message has no impact on the MQ messages since the messages were outside UOW. Ruzi --- Ruzi R <[EMAIL PROTECTED]> wrote: > Thanks Scott... > > I should have stated the scenario a bit more > clearly. > Currently, an app is getting messages (Pers or > non-pers) outside UOW contrary to my recommendation. > I > asked them to use syncpoint for persistent messages > for abvious reasons. Since they have to deal with > Pers > and non-pers msgs in the same app, I suggested the > use > of MQGMO_SYINCPOINT_IF_PERSISTENT option. And they > will have to commit after every Pers message. Now > they are asking me how much impact (postive or > negative) this syncpointing will have on > performance. > > > To that end, I have just done the following 2 tests, > on the mainframe 5.3, which produced the same result > (i.e. no difference): I used 1K long 1000 Persistent > mesgs ineach case: > > 1- MQGET loop: >- Get with no-syncpoint >- Write the msg to a file >End-loop >- Commit (after the 1000th message) > > 2- MQGET loop: >- Get with syncpoint >- Write the msg to a file >- Commit >End-loop > > In each test, CPU usage was 03. I wonder why your > test > results are different from mine. Were your tests > done > on NT? Even so, I did not think that there would be > this much difference. Any ideas? > > Thanks, > > Ruzi > > Scott <[EMAIL PROTECTED]> wrote: > > You still get an improvement by using syncpoint > > after every message. The > > test I did reduced the time for 1000 persistent > > messages from 25 to 15 > > seconds... > > > > Regards > > John Scott > > IBM Certified Specialist - MQSeries > > Argos Ltd > > > > > > -Original Message- > > From: Ruzi R [mailto:[EMAIL PROTECTED] > > Sent: 17 November 2003 19:03 > > To: [EMAIL PROTECTED] > > Subject: Re: Impact of Syncpoint? > > > > > > Paul, > > > > Thanks for the response. But the requirement is > that > > we have to do a commit after every persistent > > message > > read off the queue (as opposed to after a batch of > > messages read). > > > > Thanks, > > > > Ruzi > > > > --- Paul Clarke <[EMAIL PROTECTED]> wrote: > > > Depends what you mean by 'impact'. I assume > you're > > > talking about persistent > > > messages here. Generally speaking the addition > of > > > syncpoint to persistent > > > message operations will increase the performance > > > since we only need to > > > force the log at commit time rather than for > every > > > message. > > > > > > Download my MA01 support pac if you want to have > a > > > play. > > > Choose a local queue, say Q1 > > > Load the queue with messages :- > > > > > > q -oQ1 -ap > > > > > > at the prompt type > > > #1000 > > > > > > you now have 1000 persistent messages on your > > queue. > > > > > > Get them off by specifying :- > > > > > > q -IQ1 -t -q > > > > > > this will printout something like > > > > > > 1000 Interations in 441.00 ms, Average = 0.44ms > or > > > 2267.6 per second > > > > > > This is doing your gets outside of syncpoint. > > > To do it inside of syncpoint you can tell queue > > how > > > often to commit, let's > > > say every 100 messages > > > > > > Load up your queue again and then type > > > > > > q -IQ1 -t -q -p100 > > > > > > The line now reads > > > 1000 Interations in 90.00 ms, Average = 0.09ms > or > > > 1.1 per second > > > > > > By doing the gets under syncpoint (and quite a > lot > > > of them) we're now about > > > 5 times faster. > > > > > > These were the numbers produced on my ThinkPad > and > > > will depend greatly on > > > the speed of your disks, the type of disks, your > > CPU > > > speed etc etc. > > > > > > There are also, I believe, a number of support > > pacs > > > which detail the speed > > > of MQ operations on the support pac website. > > > > > > Hope this helps, > > > P. > > > > > > Paul G Clarke > > > WebSphere MQ Development > > > IBM Hursley > > > > > > > > > > > > |-+> > > > | | Ruzi R | > > > | | <[EMAIL PROTECTED]| > > > | | M> | > > > | | Sent by: MQSeries| > > > | | List | > > > | | <[EMAIL PROTECTED]| > > > | | N.AC.AT> | > > > | || > > > | || > > > | | 17/11/2003 16:59 | > > > | | Please respond to| > > > | | MQSeries List| > > > |-+> > > > > > > > > > >--- > > | > > > | > > > > > > | > > > | To: [EMAIL PROTECTED] > > > > > > | > > > | cc: > > > > > > | > > > | Subject: Impact of Syncpoint? > > > > > >
Damaged Queues
Title: Damaged Queues Hi All.. Has anyone had the problem of Damaged Queues on AIX and MQ 5.3? If so, what can cause this? It does look like a hardware error. The message number of the error is 2016 and the queue is the DEAD Letter Queue. A client has encountered the problem twice in the last 2 weeks. Your help is greatly appreciated Bryan Baynes
Re: Impact of Syncpoint?
Thanks Scott... I should have stated the scenario a bit more clearly. Currently, an app is getting messages (Pers or non-pers) outside UOW contrary to my recommendation. I asked them to use syncpoint for persistent messages for abvious reasons. Since they have to deal with Pers and non-pers msgs in the same app, I suggested the use of MQGMO_SYINCPOINT_IF_PERSISTENT option. And they will have to commit after every Pers message. Now they are asking me how much impact (postive or negative) this syncpointing will have on performance. To that end, I have just done the following 2 tests, on the mainframe 5.3, which produced the same result (i.e. no difference): I used 1K long 1000 Persistent mesgs ineach case: 1- MQGET loop: - Get with no-syncpoint - Write the msg to a file End-loop - Commit (after the 1000th message) 2- MQGET loop: - Get with syncpoint - Write the msg to a file - Commit End-loop In each test, CPU usage was 03. I wonder why your test results are different from mine. Were your tests done on NT? Even so, I did not think that there would be this much difference. Any ideas? Thanks, Ruzi Scott <[EMAIL PROTECTED]> wrote: > You still get an improvement by using syncpoint > after every message. The > test I did reduced the time for 1000 persistent > messages from 25 to 15 > seconds... > > Regards > John Scott > IBM Certified Specialist - MQSeries > Argos Ltd > > > -Original Message- > From: Ruzi R [mailto:[EMAIL PROTECTED] > Sent: 17 November 2003 19:03 > To: [EMAIL PROTECTED] > Subject: Re: Impact of Syncpoint? > > > Paul, > > Thanks for the response. But the requirement is that > we have to do a commit after every persistent > message > read off the queue (as opposed to after a batch of > messages read). > > Thanks, > > Ruzi > > --- Paul Clarke <[EMAIL PROTECTED]> wrote: > > Depends what you mean by 'impact'. I assume you're > > talking about persistent > > messages here. Generally speaking the addition of > > syncpoint to persistent > > message operations will increase the performance > > since we only need to > > force the log at commit time rather than for every > > message. > > > > Download my MA01 support pac if you want to have a > > play. > > Choose a local queue, say Q1 > > Load the queue with messages :- > > > > q -oQ1 -ap > > > > at the prompt type > > #1000 > > > > you now have 1000 persistent messages on your > queue. > > > > Get them off by specifying :- > > > > q -IQ1 -t -q > > > > this will printout something like > > > > 1000 Interations in 441.00 ms, Average = 0.44ms or > > 2267.6 per second > > > > This is doing your gets outside of syncpoint. > > To do it inside of syncpoint you can tell queue > how > > often to commit, let's > > say every 100 messages > > > > Load up your queue again and then type > > > > q -IQ1 -t -q -p100 > > > > The line now reads > > 1000 Interations in 90.00 ms, Average = 0.09ms or > > 1.1 per second > > > > By doing the gets under syncpoint (and quite a lot > > of them) we're now about > > 5 times faster. > > > > These were the numbers produced on my ThinkPad and > > will depend greatly on > > the speed of your disks, the type of disks, your > CPU > > speed etc etc. > > > > There are also, I believe, a number of support > pacs > > which detail the speed > > of MQ operations on the support pac website. > > > > Hope this helps, > > P. > > > > Paul G Clarke > > WebSphere MQ Development > > IBM Hursley > > > > > > > > |-+> > > | | Ruzi R | > > | | <[EMAIL PROTECTED]| > > | | M> | > > | | Sent by: MQSeries| > > | | List | > > | | <[EMAIL PROTECTED]| > > | | N.AC.AT> | > > | || > > | || > > | | 17/11/2003 16:59 | > > | | Please respond to| > > | | MQSeries List| > > |-+> > > > > > >--- > | > > | > > > > | > > | To: [EMAIL PROTECTED] > > > > | > > | cc: > > > > | > > | Subject: Impact of Syncpoint? > > > > | > > | > > > > | > > | > > > > | > > > > > >--- > | > > > > > > > > MQ 5.3/W2K I have been asked to find out the > > "performance impact" of using Syncpoint in MQGETs. > > Is > > there a document around that deals with this > issue? > > > > Thanks, > > > > Ruzi > > > > Instructions for managing your mailing list > > subscription are provided in > > the Listserv General Users Guide available a
Re: Impact of Syncpoint?
You still get an improvement by using syncpoint after every message. The test I did reduced the time for 1000 persistent messages from 25 to 15 seconds... Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: 17 November 2003 19:03 To: [EMAIL PROTECTED] Subject: Re: Impact of Syncpoint? Paul, Thanks for the response. But the requirement is that we have to do a commit after every persistent message read off the queue (as opposed to after a batch of messages read). Thanks, Ruzi --- Paul Clarke <[EMAIL PROTECTED]> wrote: > Depends what you mean by 'impact'. I assume you're > talking about persistent > messages here. Generally speaking the addition of > syncpoint to persistent > message operations will increase the performance > since we only need to > force the log at commit time rather than for every > message. > > Download my MA01 support pac if you want to have a > play. > Choose a local queue, say Q1 > Load the queue with messages :- > > q -oQ1 -ap > > at the prompt type > #1000 > > you now have 1000 persistent messages on your queue. > > Get them off by specifying :- > > q -IQ1 -t -q > > this will printout something like > > 1000 Interations in 441.00 ms, Average = 0.44ms or > 2267.6 per second > > This is doing your gets outside of syncpoint. > To do it inside of syncpoint you can tell queue how > often to commit, let's > say every 100 messages > > Load up your queue again and then type > > q -IQ1 -t -q -p100 > > The line now reads > 1000 Interations in 90.00 ms, Average = 0.09ms or > 1.1 per second > > By doing the gets under syncpoint (and quite a lot > of them) we're now about > 5 times faster. > > These were the numbers produced on my ThinkPad and > will depend greatly on > the speed of your disks, the type of disks, your CPU > speed etc etc. > > There are also, I believe, a number of support pacs > which detail the speed > of MQ operations on the support pac website. > > Hope this helps, > P. > > Paul G Clarke > WebSphere MQ Development > IBM Hursley > > > > |-+> > | | Ruzi R | > | | <[EMAIL PROTECTED]| > | | M> | > | | Sent by: MQSeries| > | | List | > | | <[EMAIL PROTECTED]| > | | N.AC.AT> | > | || > | || > | | 17/11/2003 16:59 | > | | Please respond to| > | | MQSeries List| > |-+> > > >--- | > | > > | > | To: [EMAIL PROTECTED] > > | > | cc: > > | > | Subject: Impact of Syncpoint? > > | > | > > | > | > > | > > >--- | > > > > MQ 5.3/W2K I have been asked to find out the > "performance impact" of using Syncpoint in MQGETs. > Is > there a document around that deals with this issue? > > Thanks, > > Ruzi > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive *** 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 addressee, any disclosure, reproduction, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using the 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.archiv
