Re: Evaluation List for Monitoring
Thought this would be of some help for those evaluating technology products. Spreadsheet categories are weighted so you can change those values to fit your needs. Good solid template to start from. If you have questions, don't hesitate to call. Steve 630.721.8861 -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Cynthia Wallace Sent: Thursday, August 21, 2003 2:29 PM To: [EMAIL PROTECTED] Subject: Re: Evaluation List for Monitoring I have one day to provide what is needed to monitor MQSeries so we can begin evaluating the various products out there. Has anyone done this before and could you provide some guidelines for evaluating this type of software? Jeff, I hope you'll have more than one day to make a decision about which product to use ! The attached is a document you might find useful. There is additional criteria besides monitoring i.e. admin, configuration management, security et cetera. The big question is whether you simply want the tool to monitor or if you want escalation and what type of escalation ? are you you looking for automated resolution ? Good Luck - you're going to need it ! ===(See attached file: Tool Eval worksheet.doc) Cynthia Wallace ___ This message was content-scanned by GatewayDefender 8/21/2003 - 3:55:28 PM - BG049b3c8e.0001.mml Vendor MQ Comparison.xls Description: MS-Excel spreadsheet Vendor MQ Comparison.doc Description: MS-Word document
Re: MQCONN FAILED
Title: RE: MQCONN FAILED I have periodically seen similar symptoms on MQ v5.2.0, where MQ does NOT log incidents or outages consistently or the timestamps appear to be wrong. Upgrade to the latest CSD levels at v5.1 to seek resolution. This may not resolve your MQCONN problem but should restore a more consistent MQ logging picture for you. In turn, a more reliable logging environment may lead you to the answer to resolving your MQCONN problem. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Voges, P. (Pieter) Sent: Wednesday, July 09, 2003 4:14 AM To: [EMAIL PROTECTED] Subject: Re: MQCONN FAILED Thanks everybody for the feedback. This one really get to me. I have checked all 3 logs, and 2 of them is empty since the last time the QMGR was sterted. The one under SYSTEM shows a channel going inactive at 18:00 the previous day because of disconnect interval, and active again on the day in question at 09:00. There is nothing inbetween at 06:10 when the error occured. On the sollution to retry the connect because the QMGR might still be coming up, doesn't help. The QMGR has been running since May 18 and this happened on June 25. Thank you Pieter Voges MQ Support Nedcor Limited Tel: (011) 881 4410 Sel: 083 6455 300 E-mail: [EMAIL PROTECTED] http://dotweb.it.nednet.co.za/link.asp?names=Voges,%20Pieter -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED]] Sent: 08 July 2003 04:24 To: [EMAIL PROTECTED] Subject: Re: MQCONN FAILED With an extension on Peter's comments there are three error logs you need to look at. One in /errors and two in /qmgrs one under @SYSTEM/error and one under YOUR_QMGR/error. bobbee From: Potkay, Peter M (PLC, IT) [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: MQCONN FAILED Date: Tue, 8 Jul 2003 08:23:52 -0400 Did you check both the server level MQ error logs as well as the queue manager specific error logs? -Original Message- From: Voges, P. (Pieter) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 08, 2003 2:36 AM To: [EMAIL PROTECTED] Subject: MQCONN FAILED We ran into an interesting problem and if anybody can explain it or supply me with any info in this regard I will really appreciate it. We got a QMGR (5.1 - I know I must upgrade to 5.3) running on a AIX box(4.3). On the box there is an application running as a process that starts up in the morning and then firstly does a connect to the QMGR. Last week the app started and tried to connect. It got a 2059 (QMGR not available) return code. Later in the day the app was restarted and connected fine. My problem is that the QMGR had been running for a month when this happened. It was up and running on the first connect attempt. There was no intervention between the 2 attempts. There are no errors in the logs. It is a very low volume box so no default maximums was reached. Can anybody provide me with any possible causes or direct me to whatever else I can check. Thank you Pieter Voges MQ Support Nedcor Limited Tel: (011) 881 4410 Sel: 083 6455 300 E-mail: [EMAIL PROTECTED] http://dotweb.it.nednet.co.za/link.asp?names=Voges,%20Pieter http://dotweb.it.nednet.co.za/link.asp?names=Voges,%20Pieter _ This email and any accompanying attachments may contain confidential and proprietary information. This information is private and protected by law and, accordingly, if you are not the intended recipient, you are requested to delete this entire communication immediately and are notified that any disclosure, copying or distribution of or taking any action based on this information is prohibited. Emails cannot be guaranteed to be secure or free of errors or viruses. The sender does not accept any liability or responsibility for any interception, corruption, destruction, loss, late arrival or incompleteness of or tampering or interference with any of the information contained in this email or for its incorrect delivery or non-delivery for whatsoever reason or for its effect on any electronic device of the recipient. If verification of this email or any attachment is required, please request a hard-copy version. _ 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. _ 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
Re: Applying HIPER PTF on AIX for CSD03...
Use the 'fuser -fu filename' command to display the process Ids that have this file open. Steve Moen -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of McCarty, Brian Sent: Tuesday, July 08, 2003 11:00 AM To: [EMAIL PROTECTED] Subject: Applying HIPER PTF on AIX for CSD03... There is a HIPER fix out called IY43610 that I am trying to apply on AIX 4.3.3 running WMQ 5.3 CSD03. I stopped the queue managers and used ipcrm and slibclean before trying to copy the files. I was able to move 6 of the files (logged in as root), but I can't get 2 of them to copy. cp: ./libimqb23ia_r.a: Cannot open or remove a file containing a running program. cp: ./libimqs23ia_r.a: Cannot open or remove a file containing a running program. Does anyone have any idea why these files are still being used or if there is a tool or process that I can use to figure it out? Thanks for any advice in advance, Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 MQ/WMQI 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 ___ This message was content-scanned by GatewayDefender 7/8/2003 - 12:12:02 PM - BA045ecefc.0001.mml 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: Applying HIPER PTF on AIX for CSD03...
Try using the fuser command with the ABSOLUTE pathname not the RELATIVE
pathname as specified in your reply. If that doesn't work, execute the
command with no flags ('fuser /filename').
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of McCarty,
Brian
Sent: Tuesday, July 08, 2003 1:05 PM
To: [EMAIL PROTECTED]
Subject: Re: Applying HIPER PTF on AIX for CSD03...
I commented out listener and port entries in inetd.conf and services and
refreshed inetd.conf. There are no memory segments showing up with ipcs -a
| grep mqm and I am executing slibclean. I am still getting cannot open or
remove a file containing a running program.
I tried using fuser -fu libimqb23ia_r.a but it only returns this to the
command line:
libimqb23ia_r.a:
Is there any other options or tools I can use here? Thanks for all the
help,
Brian
-Original Message-
From: Stephan C. Moen [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 11:28 AM
To: [EMAIL PROTECTED]
Subject: Re: Applying HIPER PTF on AIX for CSD03...
Use the 'fuser -fu filename' command to display the process Ids that have
this file open.
Steve Moen
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of McCarty,
Brian
Sent: Tuesday, July 08, 2003 11:00 AM
To: [EMAIL PROTECTED]
Subject: Applying HIPER PTF on AIX for CSD03...
There is a HIPER fix out called IY43610 that I am trying to apply on AIX
4.3.3 running WMQ 5.3 CSD03. I stopped the queue managers and used ipcrm
and slibclean before trying to copy the files. I was able to move 6 of the
files (logged in as root), but I can't get 2 of them to copy.
cp: ./libimqb23ia_r.a: Cannot open or remove a file containing a running
program.
cp: ./libimqs23ia_r.a: Cannot open or remove a file containing a running
program.
Does anyone have any idea why these files are still being used or if there
is a tool or process that I can use to figure it out?
Thanks for any advice in advance,
Brian M. McCarty
USAA, Senior Systems Programmer
210.913.1678
MQ/WMQI 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
___
This message was content-scanned by GatewayDefender
7/8/2003 - 12:12:02 PM - BA045ecefc.0001.mml
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
___
This message was content-scanned by GatewayDefender
7/8/2003 - 2:14:47 PM - BB0407f3b4.0001.mml
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: Why Reason Code 256 in DLQ???
Never ran across this error code before but here are various snippets of what I found under GOOGLE... MQFB_QUIT Application should end. This can be used by a workload scheduling program to control the number of instances of an application program that are running. Sending an MQMT_REPORT message with this feedback code to an instance of the application program indicates to that instance that it should stop processing. However, adherence to this convention is a matter for the application; it is not enforced by the queue manager. An example of a program that could use a feedback code is one that monitors the work loads of other programs serving a queue. If there is more than one instance of a program serving a queue, and the number of messages arriving on the queue no longer justifies this, such a program could send a report message (with the feedback code MQFB_QUIT) to one of the serving programs to indicate that the program should terminate its activity. (A monitoring program could use the MQINQ call to find out how many programs are serving a queue.) Applications should check feedback code on MQGETs. MQSeries enables applications to communicate through the feedback code in the message descriptor. This code can control applications. However, if applications do not check the feedback code, then this feature is unavailable. Applications should, after successfully receiving a message, fall into a block of code where the message descriptor field FeedBack is checked. Based on the value of the feedback field, additional processing may be implemented. Examples include a product shipped MQFB_QUIT to signal to an application to end gracefully, or perhaps application-defined codes to enable or disable extra processing such as logging. See the Feedback field described in Chapter 9, MQMD - Message descriptor for more information. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Ruzi R Sent: Tuesday, July 08, 2003 3:48 PM To: [EMAIL PROTECTED] Subject: Why Reason Code 256 in DLQ??? Hi all, Platform is MQ 5.3 CSD3 for NT. I have 2 qmgrs (QM1 and QM2). I made my target queue ( Q1, a local queue on QM2) put_inhibited for testing purposes. When I send a message from QM1 to that queue I expected for the message to go to DLQ of QM2. And it did, of course :). I also expected to see 2051 (MQRC_PUT_INHIBITED) in the reason field of the DLH. But it has 256 (MQFB_QUIT) instead. Why MQFB_QUIT? Thanks for any input, in advance... 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 ___ This message was content-scanned by GatewayDefender 7/8/2003 - 4:59:52 PM - BB0408bfc5.0001.mml 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: Spiraling (even further) downhill
There is only but ONE truth in business and that it will CHANGE. As the technology wizards we are, we must change with the marketplace, too. Nothing lasts forever - especially in the technology field we have chosen to build our careers on. Let's remember that we live in the greatest country in the world, one that revolves around a capitalist, free-market society. In that business playground, the rules are simple. Rewards are earned by those who work hard and think smart, while penalizing excuses, mistakes, inefficiencies and lack of planning. We have learned in our recent history that business can be BOTH fun (Internet boon years) and cruel (today's environment). I guess you can look at the situation many of us are in today and say, is the cup half-full or half-empty? Your answer will most likely reflect the job status you currently find yourself in. We can bitch and moan about our predicament or you can do something about it. Of all the responses to this thread, I thought Chris Fryett stated it best Find a niche in the market and plug it with your skills so you can earn the money you choose to make. That is ultimately the right answer. There are opportunities out there to build a business around companies that don't pursue offshore opportunities like the Fortune 1000 do. Small to midsize companies are always looking for technical innovation and talent to support those solutions. The business environment of today, both large and small, still has a lot of use for your skills to integrate and automate their internal business processes. There is plenty of work to do, you just have to find your niche. What each of us needs to do in tough business times is to re-evaluate our situation. You need to stand out and clearly differentiate yourself, establish a unique high-margin (hopefully) market position that can be sustained over time. The big challenge is to make yourself (or your company) the go-to-source for a particular problem. Don't be all things to all people: (1) focus on a specific market space and identify a common, mission-critical problem (2) develop a solution (3) develop a unique approach to that solution. Whatever that product and/or service is that you perform, if it is executed in a prompt and quality manner, and within the expectations you set for the customer, you will win your fair share of business. I will not say this is an easy journey. When all is said and done, CAPTAIN YOUR OWN SHIP, DON'T LET SOMEONE ELSE STEER YOUR CAREER OR DESTINY. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Williams, Dave (Systems Management) Sent: Wednesday, June 18, 2003 6:05 AM To: [EMAIL PROTECTED] Subject: Spiraling (even further) downhill This may be one of the more important threads on this list - I'm even more concerned as to the risk at which companies are put (especially financial industries) by this shift to off-shore workers. Is anyone, at the top, paying attention? Dave W. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 3:35 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill (OT) What you can hope for is that the off shore laborers start getting a feel for the good life their financial demands will increase to the point where they price themselves out of the market. The peoplem here is like the period just before Y2K where COBOL programmers were in high demand. There weren't any who could step up to the plate quick enough. So they were turniing out Child 90 day wonders to do the Y2K coding. And now for most intends and purposes have been strandarded by the same industry that spawned them. Talk about genocide!! bobbee From: Beinert, William [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill (OT) Date: Tue, 17 Jun 2003 15:12:25 -0400 LMAO at this rant from a Honda employee... He may have quoted this word for word from the auto workers unnions in the 60s when US cars were garbage because they didn't have any competition from manufacturers who did care about quality. I remember being told Japanese cars were cheap becuase the workers only were paid a bowl of rice a day. Today Japanese labor is as expensive as US labor Things will even out as the rest of the world becomes more prosperous, and the free flow of goods and services will only speed the process. Bill -Original Message- From: Randy J Clark [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 2:36 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill AMEN! Start a union, or maybe get our legislature to wake up and smell the coffee... The good old USA lost 2 million jobs last year. Offshore jobs reduce our wages and also pay zero income taxes. Do you hear that that sucking sound its these jobs on our economy. These offshore income earners at Americans expense spend zero, none, nada,
Re: Spiraling (even further) downhill
There is only but ONE truth in business and that it will CHANGE. As the technology wizards we are, we must change with the marketplace, too. Nothing lasts forever - especially in the technology field we have chosen to build our careers on. Let's remember that we live in the greatest country in the world, one that revolves around a capitalist, free-market society. In that business playground, the rules are simple. Rewards are earned by those who work hard and think smart, while penalizing excuses, mistakes, inefficiencies and lack of planning. We have learned in our recent history that business can be BOTH fun (Internet boon years) and cruel (today's environment). I guess you can look at the situation many of us are in today and say, is the cup half-full or half-empty? Your answer will most likely reflect the job status you currently find yourself in. We can COMPLAIN and moan about our predicament or you can do something about it. Of all the responses to this thread, I thought Chris Fryett stated it best Find a niche in the market and plug it with your skills so you can earn the money you choose to make. That is ultimately the right answer. There are opportunities out there to build a business around companies that don't pursue offshore opportunities like the Fortune 1000 do. Small to midsize companies are always looking for technical innovation and talent to support those solutions. The business environment of today, both large and small, still has a lot of use for your skills to integrate and automate their internal business processes. There is plenty of work to do, you just have to find your niche. What each of us needs to do in tough business times is to re-evaluate our situation. You need to stand out and clearly differentiate yourself, establish a unique high-margin (hopefully) market position that can be sustained over time. The big challenge is to make yourself (or your company) the go-to-source for a particular problem. Don't be all things to all people: (1) focus on a specific market space and identify a common, mission-critical problem (2) develop a solution (3) develop a unique approach to that solution. Whatever that product and/or service is that you perform, if it is executed in a prompt and quality manner, and within the expectations you set for the customer, you will win your fair share of business. I will not say this is an easy journey. When all is said and done, CAPTAIN YOUR OWN SHIP, DON'T LET SOMEONE ELSE STEER YOUR CAREER OR DESTINY. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Williams, Dave (Systems Management) Sent: Wednesday, June 18, 2003 6:05 AM To: [EMAIL PROTECTED] Subject: Spiraling (even further) downhill This may be one of the more important threads on this list - I'm even more concerned as to the risk at which companies are put (especially financial industries) by this shift to off-shore workers. Is anyone, at the top, paying attention? Dave W. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 3:35 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill (OT) What you can hope for is that the off shore laborers start getting a feel for the good life their financial demands will increase to the point where they price themselves out of the market. The peoplem here is like the period just before Y2K where COBOL programmers were in high demand. There weren't any who could step up to the plate quick enough. So they were turniing out Child 90 day wonders to do the Y2K coding. And now for most intends and purposes have been strandarded by the same industry that spawned them. Talk about genocide!! bobbee From: Beinert, William [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill (OT) Date: Tue, 17 Jun 2003 15:12:25 -0400 LMAO at this rant from a Honda employee... He may have quoted this word for word from the auto workers unnions in the 60s when US cars were garbage because they didn't have any competition from manufacturers who did care about quality. I remember being told Japanese cars were cheap becuase the workers only were paid a bowl of rice a day. Today Japanese labor is as expensive as US labor Things will even out as the rest of the world becomes more prosperous, and the free flow of goods and services will only speed the process. Bill -Original Message- From: Randy J Clark [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 2:36 PM To: [EMAIL PROTECTED] Subject: Re: Spiraling downhill AMEN! Start a union, or maybe get our legislature to wake up and smell the coffee... The good old USA lost 2 million jobs last year. Offshore jobs reduce our wages and also pay zero income taxes. Do you hear that that sucking sound its these jobs on our economy. These offshore income earners at Americans expense spend zero, none,
Re: Channel Retry Counts/Intervals
I know that I am opening myself up to a lot of CONSTRUCTIVE CRITICISM but I will be more than happy to take the slings and arrows to benefit the entire community as to what these channel attributes should be set to. From my perspective (have yet to implement this scenario in a production environment) I would set LongRetryCount and LongRetryInterval to ZERO and arbitrary values for ShortRetry Count + Interval that are tailored to your production environment. Once the ShortRetry* attributes have elapsed, the channel will go into a STOPPED state. If you give the network 10 minutes (shorretryinterval=30, shorretrycount=20) or 60 minutes (shortretryinterval=60, shortretrycount=60) to clean itself up, isnt that enough? Why do I want to stay in a retrying state FOREVER? A more robust solution should incorporate the ADOPTNEWMCA, ADOPTNEWMCATIMEOUT and DISCINT (and optionally HBINT) attributes to break a connection within the window defined by the ShorRetry* settings. Therefore if the channel DOES go into a STOPPED state, you really know you have a problem. OK, I now am wearing my shield of armor and am ready to defend myself, so let them arrows fly and see what collective decision we can make Steve -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Glen Shubert Sent: Monday, June 16, 2003 10:22 AM To: [EMAIL PROTECTED] Subject: Re: Channel Retry Counts/Intervals Edward, We just went through the same thing, and we came up with the following: Short Retry Count : 60 Short Retry Interval : 60 Long Retry Count : 9 Long Retry Interval : 300 Glen Shubert [EMAIL PROTECTED] Associate Director TSYS - MQSeries Technical Support Edward Pius [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 06/16/2003 10:31 AM Please respond to MQSeries List To:[EMAIL PROTECTED] cc: Subject:Channel Retry Counts/Intervals Hello, Are there any preferred values for the sender channel short and long retry counts and intervals different from the default values? The defaults I have for a sender channel from an Win 2000 queue manager to a OS/390 queue manager are : Short Retry Count : 10 Short Retry Interval : 60 Long Retry Count : 9 Long Retry Interval : 1200 In appreciation, Edward Pius 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 message was content-scanned by GatewayDefender.com 6/16/2003 - 12:01:16 PM - BB0395deca.0001.mml
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
For those mixing non-persistent messages with persistent messages, if you want to avoid this, simply raise the priority one level higher than your persistent messages. The higher priority messages will be transmitted PRIOR to the lower priority messages. This also eliminates response time problems with VERY LARGE messages or a batch run of many messages, causing response time delays to INTERACTIVE application that require more real-time responses, and minimizes the disk I/O issues that this thread has been talking about. This ASSUMES that queues are defined as PRIORITY versus FIFO. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, Dennis Sent: Friday, May 30, 2003 5:41 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Here's my mindset. Assuming non-persistent messages do not require disk I/O, then they should continue to flow even when your disk I/O sub-system is temporarily unavailable. Since you experiencing something else, there must be conditions under which NP messages are dependent on the disk. I was both attempting to identify some of likely causes and, somewhat-confusingly-in-the-same-breath, suggest that if the logs are on the unavailable disk, you might be heading upstream with a broom stick for a paddle. I stand by my first point, even if there are as few as two messages in a batch. If one is persistent, then non-persistent msgs in the same batch will be blocked until the logs are available. Similarly, the qmgr may at times suspend all activity until it can access the logs. The lesson is to put logs on high-performance, high-availability media--redundant, hot-swapable raid or the like. Putting logs on media that is routinely taken out of service is paramount to drilling holes in your broomstick. I am not necessarily an advocate for separate channels, but I do think it could improve the odds that non-persistent messages will flow when the SAN is unavailable. Generally, while one qmgr process waits for I/O, the others may be dispatched to make good use of the available time, including their own disk I/O and, hopefully, network I/O for non-persistent messages that do not require disk. Tasks waiting on I/O do not consume--they are overlapped with those needing CPU, lest a staggering percentage of the CPU resource would go to waste. The notion of being a CPU being busy waiting is silly--faster machines don't wait at twice the speed! Point #1. If a server is dealing with persistent and non persistent messages, the persistent ones have to negatively effect the non persistent ones, at a hardware level (disk and CPU). It does not matter whether you have separate QMs on that server split between persistent and non persistent. Both QMs share the CPU and disk. It does not matter whether you have separate channels or not. All MCAs share the same CPU and disk. Only true if there is contention for one of the resources: CPU, memory, or I/O. If you can dedicate a task (either by separate Qmgrs or separate channels) to non-persistent messages that are not dependent on disk I/O, then you do not have competion for that resource and there would not be an adverse affect with respect to it. Point #2. If the disk is temporarily unavailable, then persistent messages are effected, and due to point #1, non persistent ones are effected as well. I agree (in a contrary way): If tasks handling non-persistent messages are dependent on disk, then they may be adversely affected by the unavailable disk. If tasks handling non-persistent messages are not dependent on disk, then they may be favorably affected by the unavailable disk! This occurs because other tasks waiting on disk are not competing for CPU. -Original Message- From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 1:01 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Hi Dennis. I agree that non-persistent and persistent messages in a batch will be available at the same time. But my batches are of 1 or 2 messages. Since my BATCHINT is zero, and the channel can keep the XMIT queue at zero, I doubt I am incurring any performance hit. 1 or 2 messages are sent across, mybe message #1 is a nonpersistent that is held back until the batch completes, but the batch completes almost immediately, since no more message have yet arrived and the BATCHINT expires. At this point I am still not convinced, in my scenario, that this setting has an effect for the above reason. It has also been mentioned more than once to make a separate channel for persistent vs. non-persistent messages. I don't see how that makes a difference. So I make 2 separate channels from SPOKEQM1 to HUBQM. As far as the hub and its receiving MCAs are concerned, big deal. The HUB
Re: How to Monitor queue size full
There is NO reason to monitor queue sizes. The queue files (e.g., AIX platform is /var/mqm/qmgrs/QmgrName/queues/*) DYNAMICALLY change in size based on usage or when a queue manager is restarted or if previously active queues have been idle for some time. What you mean to say is you want to monitor the size of the file system where the queues for the queue manager in question reside. I believe under V5.1 and below, queue sizes could grow to 320MBs, V5.2 this changed to 2GBs and V5.3 its now 2TBs (for UNIX systems). For V5.1 systems, in the TuningParameters section of the mq.ini file, if you specify the keyword 'DefaultQFileSize' and set it to 1GB (DefaultQFileSize=10), then bounce the queue manager, any NEW queues created will now grow up to this size. If a Queue Full condition is encountered, check messages that go to your DLQ for a reason code of 2053 (MQRC_Q_FULL or Hexadecimal number 0805 - how the RC is stored in the DLQ header). Now tailor your DLQ Rules Table appropriately for the action you want your DLQ utility (e.g., runmqdlq) to take when this type of error condition is encountered. REASON(MQRC_Q_FULL) ACTION(FWD) FEWQ(OverFlowQueue) runmqdlq MyRulesTable.txt A 2053 reason code is normally associated with maximum number of messages reached. I have never seen a condition where the queue size was at capacity. If somebody has seen this condition and it was registered within the AMQERR01.LOG file, please respond back as to what the AMQ number issue. I'm sure I would not be the only one interested in this error. We do manage messages UP TO 85MBs in size, so if the application reading this queue becomes hung, it won't take but a few hundred messages before this condition becomes reality. Also check your SYSTEM.ADMIN.PERFM.EVENT queue, because when queue full conditions are encountered, an event message will be put to this queue by the queue manager that detected this condition. If you have enabled PERFORMANCE EVENTS and are monitoring this queue, then you should be able to catch this condition when it occurs, and alert your staff. Stephan C. Moen -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Christopher D. Fryett Sent: Thursday, April 03, 2003 10:05 AM To: [EMAIL PROTECTED] Subject: Re: How to Monitor queue size full If I recall correctly there is no event triggers for queue size, just depth. If you are coming across an issue of queue size you may want to look at your design again and validate you can support the message sizes for the queue definitions you have. You may also need to review the method in how you put and get information on the queues. Unless there is a specific reason to leave the messages on the queues, you may want to figure out (if it is an issue) why they are not being pulled from the queue ASAP. Chris -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Jiede J Yang Sent: Thursday, April 03, 2003 9:06 AM To: [EMAIL PROTECTED] Subject: Re: How to Monitor queue size full Look into the Event Monitor book in the MQ Info Center, you can rely on soultino from there Thanks. Email: [EMAIL PROTECTED] mqm mqm [EMAIL PROTECTED]To: [EMAIL PROTECTED] O.UKcc: Sent by: MQSeriesSubject: Re: How to Monitor queue size full List [EMAIL PROTECTED] N.AC.AT 04/03/2003 09:48 AM Please respond to MQSeries List There's a number of tools that monitor system resource usage or alert when thresholds are reached e.g. BMC Patrol, Tivoli. Any particular platform ? mqm --- Mittal, Gaurav [EMAIL PROTECTED] wrote: We have queues defined to have a maximum depth of 6,40,000 messages and a max size of 2GB.I know we can monitor the queue depths using 'High Depth Event' .Is there a way by which we can monitor the queue size (in terms of file size not number of messages) also. Any pointers would be useful.. Thanks n Regds Gaurav 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 __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com 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
SWOT Analysis with listeners as inetd or runmqlsr AND channels as threads or processes
MQSeries Experts, I am inquiring from the vast array of knowledge within the MQSeries community on two simple topics. Please respond to the strengths and weaknesses of the following. 1) Choice of listener: inetd or runmqlsr process. 2) Choice of channel: start as a thread or process. Im not looking for book responses, just REAL-LIFE experiences, especially from a performance, reliability, scalability, and MQSeries Version (5.3, 5.2 and below) perspective. Thank you. Steve Moen
Re: AMQZLAA0 question
Polly,
You caught my interest on
this topic since some of our MQ platforms are on AIX 4.3.3 running MQ V5.2. I
ran a few simple tests and this is what I found.
I ran the
/usr/mqm/samp/bin/amqsput command.
While this MQ app was waiting for input, a new amqzlaa0 agent would get
spawned. I did this for two other
amqsput instances and two additional amqzlaa0 agents would appear when the ps ef|grep
amqzlaa0 command was executed.
When these three amqsput instances were terminated normally, the
amqzlaa0 processes would disappear within 40 seconds. In addition, when amqsput was terminated abnormally (either
Ctrl-C or kill PID), the same number of amqzlaa0 agents that were
created would timeout and terminate.
From what I can tell, whenever an MQCONN call is issued, a new amqzlaa0
agent is created. It doesnt appear they are being reused since they terminate
within 40 seconds. In regards to threads, it doesnt appear this comes into
play since for each application that issues an MQCONN call, a new amqzlaa0
process is created a one-to-one correspondence. Try this out yourself on your platform.
In addition, execute the svmon
command to determine if disconnected agents are consuming a lot of memory.
for I in $(ps ef|grep
amqzlaa0 | awk {print $2})
do
svmon P $I
read stuff
done
Stephan C. Moen
-Original
Message-
From: MQSeries List
[mailto:[EMAIL PROTECTED]On Behalf Of Siegman,
Polly
Sent: Thursday, February 20, 2003
12:19 PM
To: [EMAIL PROTECTED]
Subject: AMQZLAA0 question
AIX
4.3.3
MQSeries
5.2 CSD04
When an
MQCONN is issued from an application the amqzma0 process (execution controller)
picks this up and contacts amqzlaa0 (agent process) to start a thread for the
connection. When the agent process reaches 62 threads a second amqzlaa0
process is started and so on.
Well, I
currently have about 60 amqzlaa0 processes running with timestamps dating back
to November. When the execution controller contacts the agent to start a
new thread does it automatically go to the most recent amqzlaa0 process and
look for less then 62 threads or does it start at the first amqzlaa0 and search
for open slots to start the thread? If disconnects were
issued and the threads ended, there should be less then 62 threads in previous amqzlaa0
processes. Are these slots reused throughout the amqzlaa0
processes or does the execution controller automatically start at the end and
if 62 threads have been started, start a new anqzlaa0 processes, disregarding
all previous amqzlaa0 processes?
Polly Siegman
Unix System Administrator
PerotSystems @ OwensMinor
Ph. (804)935-4290
Pager (800)Page-MCI pin #1576939
For
your protection, this e-mail has been scanned for known
viruses
and other damaging content by GatewayDefender.com
Re: Maximum size of defined message
Title: RE: Maximum size of defined message The simple answer Linda is there is no overhead or resource waste to set a queue to its architectural limit for a message size. This also has been validated multiple times by our esteemed friends who have supported this product since its inception IBMs MQSeries Support Team. Stephan C. Moen -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Kinnard.Linda Sent: Thursday, February 20, 2003 12:52 PM To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message I think another ways to ask is is there overhead or resource waste to set queue to it's maximum architectural limit? -Original Message- From: Stephan C. Moen [SMTP:[EMAIL PROTECTED] Sent: Thursday, February 20, 2003 07:02 AM To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message You state four strong points to which most of this audience would agree with, including myself. But when we get down to the root of my original question, nobody has yet answered it (maximum message size). All I'm asking from fellow contributors, is that whatever size your enterprise settles on a maximum message size, it won't take long before you see a message in your DLQ or ERROR logs that states message too big for queue, channel or queue manager. So why arbitrarily set it to a value that will eventually be broken and just set it to it's maximum architectural limit. My point, if its going to fail, let the application fail versus having the message transport fail. If the application isn't designed to accept that size message, that is what needs to be fixed, or at least the application generating that size of a message. In Incident Management, the END GOAL is to always find the 'root cause' of the problem, then resolve it. From my perspective, allow MQSeries to take care of message flow and your applications take responsibility of message processing. All MQSeries is asked to do is to route messages to their ultimate destination. Let the application make the decision what its going to do with the message. It's that simple. Stephan C. Moen -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Broderick Sent: Thursday, February 20, 2003 6:45 AM To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message You know, if I was sitting on the right hand of GOD I would heartly agree with you. But having been around the block a few times and written my fair share of code and managed others who claim the same. I have noticed: 1 - Programmers never do what they should or supposed to do. 2 - Getting calls at 3AM suck 3 - In the financial world s-h-i-t travels downward and you don't want to be on the bottom of the ladder (DTC saying, but true) 4 - In reality, Technology does not drive the Business, many business analyist are aware of the expectations, limitations and pitfalls of technology. After explaining this situation to one good 'business analyst, see if he/she jumps up and down with joy at the prospect of being responsible for someone elses mistakes and agrees you should do it that way. A good architect WILL not only design a good system. He/She will also take care of his job security by keeping the people who sign the checks happy!! As once said in a movie somewhere...You fight the battles you can win! From: Stephan C. Moen [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message Date: Thu, 20 Feb 2003 00:14:13 -0600 Bobbee, I guess I take a different tack. I look for consistency, continuity, and simplicity in my operational environment. I don't want to create artificial limits for my technology stack because I know eventually, those limits will be tested and require changes; that has been proven over time. So why not start out by taking those limits off the table. Why should I place artificial limits on my infrastructure if I don't have to. Isn't that a primary goal of MQSeries - reliability, availability and scalability (RAS)? If the message size is raised ABOVE the maximum limit, the problem will be caught at the application ISSUING the call, which is where it should be; just following your viewpoint of determining where the BLAME should go. Lastly, the application can easily be coded to handle large message sizes. As we all know, the MQGET call will return the size of the message is has or tried to retrieve. If your application buffer is too small to accept the read message, there are several options that can be done. Following anyone of the steps listed below, will prevent you from waking up at 3AM. 1) perform another MQGET with a dynamically allocated buffer set to the message size from the first call 2) have the application automatically move the message into an ERROR queue; keep the workflow moving.. 3) allow MQGET to truncate the message
Re: Maximum size of defined message
You state four strong points to which most of this audience would agree with, including myself. But when we get down to the root of my original question, nobody has yet answered it (maximum message size). All I'm asking from fellow contributors, is that whatever size your enterprise settles on a maximum message size, it won't take long before you see a message in your DLQ or ERROR logs that states message too big for queue, channel or queue manager. So why arbitrarily set it to a value that will eventually be broken and just set it to it's maximum architectural limit. My point, if its going to fail, let the application fail versus having the message transport fail. If the application isn't designed to accept that size message, that is what needs to be fixed, or at least the application generating that size of a message. In Incident Management, the END GOAL is to always find the 'root cause' of the problem, then resolve it. From my perspective, allow MQSeries to take care of message flow and your applications take responsibility of message processing. All MQSeries is asked to do is to route messages to their ultimate destination. Let the application make the decision what its going to do with the message. It's that simple. Stephan C. Moen -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Broderick Sent: Thursday, February 20, 2003 6:45 AM To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message You know, if I was sitting on the right hand of GOD I would heartly agree with you. But having been around the block a few times and written my fair share of code and managed others who claim the same. I have noticed: 1 - Programmers never do what they should or supposed to do. 2 - Getting calls at 3AM suck 3 - In the financial world s-h-i-t travels downward and you don't want to be on the bottom of the ladder (DTC saying, but true) 4 - In reality, Technology does not drive the Business, many business analyist are aware of the expectations, limitations and pitfalls of technology. After explaining this situation to one good 'business analyst, see if he/she jumps up and down with joy at the prospect of being responsible for someone elses mistakes and agrees you should do it that way. A good architect WILL not only design a good system. He/She will also take care of his job security by keeping the people who sign the checks happy!! As once said in a movie somewhere...You fight the battles you can win! From: Stephan C. Moen [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message Date: Thu, 20 Feb 2003 00:14:13 -0600 Bobbee, I guess I take a different tack. I look for consistency, continuity, and simplicity in my operational environment. I don't want to create artificial limits for my technology stack because I know eventually, those limits will be tested and require changes; that has been proven over time. So why not start out by taking those limits off the table. Why should I place artificial limits on my infrastructure if I don't have to. Isn't that a primary goal of MQSeries - reliability, availability and scalability (RAS)? If the message size is raised ABOVE the maximum limit, the problem will be caught at the application ISSUING the call, which is where it should be; just following your viewpoint of determining where the BLAME should go. Lastly, the application can easily be coded to handle large message sizes. As we all know, the MQGET call will return the size of the message is has or tried to retrieve. If your application buffer is too small to accept the read message, there are several options that can be done. Following anyone of the steps listed below, will prevent you from waking up at 3AM. 1) perform another MQGET with a dynamically allocated buffer set to the message size from the first call 2) have the application automatically move the message into an ERROR queue; keep the workflow moving.. 3) allow MQGET to truncate the message (not the best option), so a poison-loop condition doesn't exist 4) You can always have your application determine the max message size of the queue manager it is connecting to. This will GUARANTEE that the application will NEVER receive a message it can't handle because of message size. To address your point about a good architect, isn't the architect's job to MINIMIZE outages and not point fingers. If anything, it's the architect's fault for not designing the application to handle this type of situation. That's what a GOOD architect would do; eliminate POTENTIAL problems before they have a chance to surface. I would assume that is a line-item in every MQSeries Architect's Best Practices Binder. So I will post the question again, what are the issues? I have yet to hear a reason why this wouldn't be a good idea. And Bobbee, please proof-read your reply. I'm not totally sure what you were trying to say
Re: Maximum size of defined message
Strong spirited debate by all - that's what I like to see this type of forum provide. Thank you all for sharing your thoughts and experiences to the MQSeries community. Solid points were made by both sides of the equation. And I second the motion of Robert's closing - this was fun. Job well done by all who participated... Stephan C. Moen VP of Sales and Business Development The Preferred Solutions Group, Inc. 630.820.5963 (work) 630.721-8861 (cell) [EMAIL PROTECTED] www.webspherecommunity.com -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Broderick Sent: Thursday, February 20, 2003 2:04 PM To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message So...now that we have heard the Choir sing let me put my final two cents in and stop playing devils advocate. I have the XMIT queues, QMRG, queues and what-not set to MAX. I set the SYSTEM.DEFAULT.LOCAL.QUEUE to MAX which gets all the defined queues afterwoods set to MAX. The application, when I can get my hands on them will check for specific msg lengths imed and dump the message with an ack where necessary. The limitation on message size is an old design statement. The receiving application usually will handle the message in a maner I have just described. What I do find is that when the sending application calls and asks why did you dump my message and nack, the Tower of Bable rule imed applies and a situation that would have been quickly fixed had the message stayed where it was will quickly turn into a formal tennis match of EMAILs between the respective parties. But then the managers need to have somethng to do!! This was fun!! bee-oh-dubble-bee-dubble-eegghh _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 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 _ For your protection, this e-mail has been scanned for known viruses and damaging content by http://GATEWAYDEFENDER.com 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: Pesistent vs non-pesistent message
When in doubt, goto www.google.com to resolve your worries. Here are a few topics to search on that will pull the information you are looking for. A PERFORMANCE COMPARISON OF IBM MQSERIES MQ PERFORMANCE TUNING MQSERIES PERFORMANCE TUNING GETTING THE MOST OUT OF MQSERIES MQSERIES FOR HP-UX V5.2 MQSERIES FOR ISERIES V5.2 You will be surprised how much quality information you will pull back. Stephan C. Moen 630.721-8861 (cell) -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Rodrmguez Alvarez-Querol, Manuel Carlos Sent: Wednesday, February 19, 2003 7:35 AM To: [EMAIL PROTECTED] Subject: Re: Pesistent vs non-pesistent message Pls check the performance supportpac website. http://www-3.ibm.com/software/integration/support/supportpacs/perfreppacs.ht ml Cheers, Manuel Carlos Rodriguez IBM Certified Specialist - WebSphere MQ -Mensaje original- De: K K [SMTP:[EMAIL PROTECTED]] Enviado el: Wednesday, February 19, 2003 2:10 PM Para: [EMAIL PROTECTED] Asunto: Pesistent vs non-pesistent message Dear all, I am looking for any benchmark on the performance of persistent vs non-persistent message, in particular on CPU consumption. Do you know of any redbook or manual or web site has such report? TIA KK 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 _ For your protection, this e-mail has been scanned for known viruses and damaging content by http://GATEWAYDEFENDER.com 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
Maximum size of defined message
Why dont we declare the maximum size message for our queue managers, queues, and channels when we FIRST create these objects. From some very preliminary tests conducted on AIX boxes, it appears that size doesnt matter for MQSeries. Testing different size messages with the three mentioned MQ objects, the svmon P PID utility showed little variation in memory consumption between using the default 4MB message size or a 100MB message except when it was actually being transmitted. Basically the question Im asking is that you might as well define ALL your MQSeries objects with the maximum message size and eliminate all the runtime errors associated with message too large for the MQ object it is targeted for. It doesnt appear that memory is preallocated for these resources UNTIL it is needed. Looking for some brisk discussion on this. Not looking for your thoughts, just facts that can either prove or disprove the statement made above. Thanks. Stephan C. Moen
Re: Maximum size of defined message
Bobbee, I guess I take a different tack. I look for consistency, continuity, and simplicity in my operational environment. I don't want to create artificial limits for my technology stack because I know eventually, those limits will be tested and require changes; that has been proven over time. So why not start out by taking those limits off the table. Why should I place artificial limits on my infrastructure if I don't have to. Isn't that a primary goal of MQSeries - reliability, availability and scalability (RAS)? If the message size is raised ABOVE the maximum limit, the problem will be caught at the application ISSUING the call, which is where it should be; just following your viewpoint of determining where the BLAME should go. Lastly, the application can easily be coded to handle large message sizes. As we all know, the MQGET call will return the size of the message is has or tried to retrieve. If your application buffer is too small to accept the read message, there are several options that can be done. Following anyone of the steps listed below, will prevent you from waking up at 3AM. 1) perform another MQGET with a dynamically allocated buffer set to the message size from the first call 2) have the application automatically move the message into an ERROR queue; keep the workflow moving.. 3) allow MQGET to truncate the message (not the best option), so a poison-loop condition doesn't exist 4) You can always have your application determine the max message size of the queue manager it is connecting to. This will GUARANTEE that the application will NEVER receive a message it can't handle because of message size. To address your point about a good architect, isn't the architect's job to MINIMIZE outages and not point fingers. If anything, it's the architect's fault for not designing the application to handle this type of situation. That's what a GOOD architect would do; eliminate POTENTIAL problems before they have a chance to surface. I would assume that is a line-item in every MQSeries Architect's Best Practices Binder. So I will post the question again, what are the issues? I have yet to hear a reason why this wouldn't be a good idea. And Bobbee, please proof-read your reply. I'm not totally sure what you were trying to say on your first reply ( but I responded to what I 'thought' you were saying ) but I'm sure your second one will be crystal clear. Stephan C. Moen -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Broderick Sent: Wednesday, February 19, 2003 12:48 PM To: [EMAIL PROTECTED] Subject: Re: Maximum size of defined message Well if you think about itWhat if a distributed application send you a normal size message of 100 bytes. You application processes messages from many suppliers that give you messages of the same size. You go ahead and set the MAX Queue size for a message at 100Meg. Now the distributed application send you a message that is larger than the 100 bytes, actually it send you MANY of shuch messages. Two things come to mind Fist of all prior to setting the max size. The problem is theres. now it is yours. Second. Your application cannot handle the message so it backs up on the queue and all your other suppling systems begin to get constipated t. This problem is now also yours!! As I always teach in my design classes. A good architect will design a system so that everybody else is to BLAME and you never get awaken at 3AM for stupid reasons that could have been avoided by blaming someone else! bobbee From: Stephan C. Moen [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Maximum size of defined message Date: Wed, 19 Feb 2003 09:27:25 -0600 Why don t we declare the maximum size message for our queue managers, queues, and channels when we FIRST create these objects. From some very preliminary tests conducted on AIX boxes, it appears that size doesn t matter for MQSeries. Testing different size messages with the three mentioned MQ objects, the svmon P PID utility showed little variation in memory consumption between using the default 4MB message size or a 100MB message except when it was actually being transmitted. Basically the question I m asking is that you might as well define ALL your MQSeries objects with the maximum message size and eliminate all the runtime errors associated with message too large for the MQ object it is targeted for. It doesn t appear that memory is preallocated for these resources UNTIL it is needed. Looking for some brisk discussion on this. Not looking for your thoughts, just facts that can either prove or disprove the statement made above. Thanks. Stephan C. Moen _ 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
Re: W2K Trigger monitor triggers going to DLQ
What I have done in the past is dump the contents of the message using one of the sample programs provided when you install MQM on the platform in question. On a Windows system, this would be something like Drive Letter:\Program Files\IBM\MQSeries\Tools\C\Samples\Bin\amqsbcg. This utility will view or browse the message on the DLQ, dumping the contents of that message to your console. It will NOT read the message off the queue. In the body of the message dumped, review the 6th word (11th and 12th bytes). Since the error code is in hexadecimal, if you have a UNIX machine around, simply do the following at the command line: bc ibase=16 07EE CNTRL-D BC is a binary calculator. ibase means BC will read its input in base 16 vs. base 10. All input values need to be in UPPERCASE. The decimal equivalent of 07EE is 2030. Now take that value and look it up either in MQSeries Information Center or use the following command on UNIX systems - grep 2030 /usr/include/cmqc.h. The returned string of the last example will give you why the message got redirected to the DLQ. Other codes you may find in the DLQ are as follows: HEXDECIMAL ERROR DESCRIPTION 07EE 2030Message Too Big for Queue 07EF 2031Message Too Big for Queue Manager 0805 2053Queue Full 0835 2101MQ Object Damaged 08AA 2218Message Too Big for Channel Stephan C. Moen [EMAIL PROTECTED] -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Wesley Shaw Sent: Monday, February 17, 2003 7:16 AM To: [EMAIL PROTECTED] Subject: W2K Trigger monitor triggers going to DLQ I have a triggered process where the trigger message is going to the DLQ. Below is the message header. I am trying to figure out the reason code. Anybody decode that for me quicker than I ? (Embedded image moved to file: pic04664.pcx) Wesley Shaw OJRP 10th Floor Work: 804 771 3589 (736-3589) Pager: 888 436 2805 Mobile 804 512 5260 _ For your protection, this e-mail has been scanned for known viruses and damaging content by http://GATEWAYDEFENDER.com 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
