Re: MQ Client throughput - 2 questions
The distributed products attempt to avoid writing persistent messages to the log when no loss of integrity is implied, however as far as I'm aware the current 390 product always logs persistent messages. I can't comment on 390 client performance, but as far as distributed client performance is concerned our 5.3 NT client benchmark runs at over 1000 persistent round trips per second where each round trip involves the client sending the server a persistent message, the server gets the request and sends a reply and the client receivies the reply (thus each round trip involves three transactions). At this sort of rate we're running about 60 client applications and the server has 20 threads proocessing the input queue. The equivalent 5.2 benchmark ran at about 350 round trips/sec and should be documented in the 5.2 performance report. We're running a 4 way 700MHz box as the server and another to simulate the 60 clients. Andy. Robert Broderick <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 06/20/2002 12:55:37 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: MQ Client throughput - 2 questions So if we are sending messages to an OS390 where the default option is Syncpoint, unless we turn off the syncpoint it is in force and messages regardless of persistence will go to the log bobbee >From: "David C. Partridge" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: MQ Client throughput - 2 questions >Date: Thu, 20 Jun 2002 10:02:28 +0100 > >Bobbee I think that what was written was "you cannot g'tee that persistent >messages will always go to the logs". There are special cases (e.g.) if >there is an non syncpoint MQGET outstanding that this message will satisfy >the message will just be delivered without logging. > >Dave > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. 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: Upgrade from V5.0 to V5.2 (Sun Solaris)
Dennis, Sorry, 'define + replace' only causes the explicitly modified attributes to be changed and so will not affect the DefaultQFileSize. Andy. Dennis Bryngelson <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 06/17/2002 07:57:08 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Upgrade from V5.0 to V5.2 (Sun Solaris) If I would run a script that does a "DEFINE" "REPLACE" would the new attribute for DefaultQFileSize be picked up or do I have to do a "DELETE" and then a "DEFINE" ? Thanks Dennis Bryngelson Andrew Hickson cc: Sent by: MQSeriesSubject: Re: Upgrade from V5.0 to V5.2 List (Sun Solaris) 06/17/2002 10:59 AM Please respond to MQSeries List DefaultQFileSize is a qmgr related parameter and as such should not appear in qm.ini, not mqs.ini. When set this parameter overrides the default the maximum queue file size, and only affects queues created while the override is in effect. When the queue is created then the attribute is copied into the queue file and in order to subsequently change the maximum queue size the attribute in the queue file needs to be changed (or the queue deleted and recreated in which case the new queue will be recreated with the current DefaultQFileSize attribute). This allows different queues to be created with different maximum queue file sizes (albeit in a rather unfriendly way). Hence when you migrate from 5.0 to 5.2 the maximum queue size won't change unless you take specific action. Andy. Dennis Bryngelson <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 06/17/2002 04:18:35 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Upgrade from V5.0 to V5.2 (Sun Solaris) We are upgrading from V5.0 to V5.2 on Sun Solaris. We have set in our "mqs.ini" file the tuning parameter of "DefaultQFileSize". It is currently set to 1gb. With V5.2 the default queue size is 2gb. My question is when we upgrade to V5.2 will our default Queue size automatically go up to 2gb or will we have to re-create our Queue Managers (also take out the DefaultQFileSize parameter from mqs.ini file)? Thanks Dennis Bryngelson The Hartford * PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/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 e-mail, delete this communication and destroy all copies. * Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: vms process for amqzlaa0.exe over-paging
I assume that if some process is submitting messages then some other process is receiving messages, is the receiving program a user program, or an MQ program ? (e.g. an MCA). The queue manager treats the buffer size provided by the receiving application as a hint as to how big the message is likely to be, this causes overheads if the app specifies a very large buffer size unnecessarily. If the receiving process specifies a very large buffer size then the agent will allocate a buffer into which the message could be read, while if the application specifies a reasonable buffer size then the agent will read the message directly into shared memory from where it can be copied to the application process. Andy. David Awerbuch <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 06/13/2002 10:05:26 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:vms process for amqzlaa0.exe over-paging Hello, I have a simple MQ installation here, on a VAX 7000-650. I have an application that is submitting 1000 byte messages, one at a tine, persistent, CMIT after each one. I noticed that while my application is running, an agent process running AMQZLAA0.EXE is regularly soft-paging about 450 pages per second - this coming from polycenter performance graphs generated from data collected realtime, as well as from watching a "show proc /cont". It is not hard-paging. The process consistently uses 31760 virtual pages, with regular jumps to about 32900 and then drops back to 31760. Does anyone have any ideas why the ZAA0 executable is soft-paging so much? We've been writing off as an artifact of the way AMQZLAA0 is handling messages; that it acquires a buffer, copies the messages into it and build control blocks, then releases it again. But, given a message size of 1000 bytes (that 2-3 pages), and a current throughput of only about 1 message per second, I can;t see how that many pages would be acquired and released per second to process a single message. I hope someone in IBM can help me out here. Thanks, Dave A. Here is the "show process" for AAZ0. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 13-JUN-2002 16:52:40.70 User: MQADMIN Process ID: 24016D05 Node: VAXP Process name: "VAXPQM_AG_5" Terminal: User Identifier:[MQSERIES,MQS_SERVER] Base priority: 4 Default file spec: Not available Process Quotas: Account name: SYSTEM CPU limit: Infinite Direct I/O limit: 250 Buffered I/O byte count quota:169280 Buffered I/O limit: 500 Timer queue entry quota: 233 Open file quota:284 Paging file quota:942280 Subprocess quota:92 Default page fault cluster: 64 AST quota: 247 Enqueue quota: 4739 Shared file limit:0 Max detached processes:0 Max active jobs: 0 Accounting information: Buffered I/O count: 542 Peak working set size: 5567 Direct I/O count: 188 Peak virtual size: 32732 Page faults:29680 Mounted volumes:0 Images activated: 1 Elapsed CPU time: 0 00:00:06.68 Connect time: 0 00:00:24.50 Authorized privileges: ACNT ALLSPOOL ALTPRIAUDIT BUGCHKBYPASSCMEXEC CMKRNL DETACHDIAGNOSE DOWNGRADE EXQUOTA GROUP GRPNAMGRPPRV IMPORT LOG_IOMOUNT NETMBXOPER PFNMAPPHY_IOPRMCEB PRMGBL PRMMBXPSWAPMREADALL SECURITY SETPRVSHARE SHMEM SYSGBL SYSLCKSYSNAMSYSPRVTMPMBXUPGRADE VOLPROWORLD Process privileges: ACNT may suppress accounting messages ALLSPOOL may allocate spooled device ALTPRI may set any priority value AUDITmay direct audit to system security audit log BUGCHK may make bug check log entries BYPASS may bypass all object access controls CMEXEC may change mode to exec CMKRNL may change mode to kernel DETACH may create detached processes DIAGNOSE may diagnose devices DOWNGRADEmay downgrade object secrecy EXQUOTA may exceed disk quota GROUPmay affect other processes in same group GRPNAM may insert in group logical name table GRPPRV may access group objects via system protection IMPORT may set classification for unlabeled object LOG_IO may do logical i/o MOUNTmay execute mount acp function NETMBX may create network device OPER may perform operator functions PFNMAP may map to specific physical pages PHY_IO may do physical i/o PRMCEB may create permanent common event clusters PRMGBL
Re: Client
The implications of MQCMIT failures are not confined to either the client interface, or single phase commit. For example, It's quite possible to get a 2009 response to an MQCMIT of an MQ coordinated transaction involving another resource manager (i.e. MQBEGIN), in which case you don't know if the transaction committed or backed out. You are however assured that the transaction will either backout, or commit and that the resources involved will be in a consistent state. As far as I'm aware disconnect (either explicit (MQDISC) or implicit (termination)) doesn't give rise to any additional concerns. Andy. "Miller, Dennis" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 06/13/2002 12:06:05 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Client With respect to LUW's, coders of client applications need to be aware of considerations beyond the obvious lack of support for MQBegin. Suppose an MQCMIT is requested by the client, there is a window of uncertainty until the response comes back across the channel. If the connection is lost during that window, the client is uncertain if the qmgr processed the request or not. So, I suspect it's possible for an MQCMIT request to fail (i.e. 2009) even though the commit is actually successful. Perhaps Andy or Paul can confirm that. Along similar lines, if the client abends during that window, the MQCMIT may still progress to satisfactory completion. A client that resumes after having missed the MQCMIT response, probably should not assume that it failed. > -Original Message- > From: Robert Broderick [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, June 12, 2002 8:27 AM > To: [EMAIL PROTECTED] > Subject: Re: Client > > TNX Pete, > > I am also looking for any "holes' in Clients vs Server withingthe > transactional arena. Would it be wise to use client connections for > transactional data. Things you would do via an LUW. Is there a possibility > of getting out of sync with what I have thought I have done and what was > actually done. On the server you do not have this problem as long as you > use > syncpoint, and any supporting software (ie CICS for DB2 and VSAM > coordination). BUT...with the client I know I cannot coordinate this > globally but can the message transfer be out of sync AT ANY TIME because > of > a disconnect? > >bobbee > > > >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: Client > >Date: Wed, 12 Jun 2002 08:45:39 -0400 > > > >More Pros > >Client can connect to more than 1 QM at a time > >Client can automatically use alternate channels when primary is down > > > >More Cons > >Performance suffers, as MQI calls must flow over a network > >MQBegin Verb not valid in Client environment > > > > > >Peter Potkay > >IBM MQSeries Certified Specialist, Developer > >[EMAIL PROTECTED] > >X 77906 > > > > > >-Original Message- > >From: Robert Broderick [mailto:[EMAIL PROTECTED]] > >Sent: Tuesday, June 11, 2002 7:58 PM > >To: [EMAIL PROTECTED] > >Subject: Client > > > > > >I'm sorry I'm opening up this can of worms. Someone gave a great and > >detailed discribtion on this subject once. I had saved this in my > >"MQSeries > >noteworthy LISTSERV comments" word doc somewhere and now can not find it. > >SO > > > >Client vs Server Pros/Cons > > > >1 - Clients cannot partake in GUOW > >2 - The client also has no local queues > >3 - The Client is cheap > >4 - ? > > > >Some questions: > > > >What happens in a Client UOW if the connection fails in the middle of a > MQ > >commit. Is there a indoubt condition with regards to the transaction. > > > >Using syncpoint buys me transaction coordination with the MQServer. But > to > >what point. (refer to question 1). > > > >Are there other considerations to worry about. My client side is on the > >rusty side. > > > > bobbee > > > >_ > >Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp. > > > >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 communication, including attachments, is for the exclusive use of > >addressee and may contain proprietary, confidential or privileged > >information. If you are not the intended recipient, any use, copying, > >disclosure, dissemination or distribution is strictly prohibited. If > >you are not the intended recipient, please notify the sender > >immediately by return email and delete this communication and destroy all > >copies. > > > >Instructions for managing your mailing list subscription are provided in > >the Listserv General Us
Re: Reason 2056
You cannot change the size of the log files once a queue manager has been created. You can change the number of log files after the queue manager has been created. Andy. Graham Lekota <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 06/12/2002 10:32:50 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Reason 2056 Andy, Stefan is talking about error logs, which is not what you are looking for: You can change the size of the LogFilePages(on solaris the files are /var/mqm/mqs.ini and /var/mqm/QM_NAME/qm.ini) and the number of primary+secondary files based on how much data(within a unit of work) you handle at any given time. All you need to do is restart the the queue manager and the changes will take effect. Go through the mq mauals(system admin + intercommication) to get the full story. Ta. * Graham Lekota Systems Support Analyst Liberty Group +27 83 327 3619 +27 11 408 4683 [EMAIL PROTECTED] * Unemployment doesn t work. * * * -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Stefan Sievert Sent: Tuesday, June 11, 2002 10:24 PM To: [EMAIL PROTECTED] Subject: Re: Reason 2056 Andy, if you want to change the size of the logs, you would need to delete and re-create the queue manager. If your calculations say that an increase in number of log files is sufficient, then Philips answer applies. Chapter 15 of the System Administration manual contains a section on how to calculate the log size. Good luck! Stefan >From: Andrew Goade <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Reason 2056 >Date: Tue, 11 Jun 2002 14:04:37 -0500 > >Stefan, >I found out that my logs are the issue. How would I go about changing the >size of them to accomidate for a large number of messages(~600,000/day)? > >Thanks, >Andy > > > > > Stefan Sievert > [EMAIL PROTECTED] > TMAIL.COM> cc: > Sent by: MQSeries Subject: Re: Reason 2056 > List > n.AC.AT> > > > 06/11/2002 01:38 > PM > Please respond to > MQSeries List > > > > > > >Andy, >every queue has a representation in the file system, on W2K that would be >\qmgrs\\queues\ >You should be able to find a file named 'Q' in this directory, that's the >actual queue file. >The reason code description explicitly states a lack of disk space as the >cause of the problem. You said 'the disk seems to have enough space'. Can >you confirm that it *definitely* has enough space? If you are using >persistent messages and have the logs on the same disk, you probably want >to >have at least (my guesstimate) 100MB of free space available. How many >messages do you expect to receive in total? >Cheers, >Stefan > > >From: Andrew Goade <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: Reason 2056 > >Date: Tue, 11 Jun 2002 13:06:01 -0500 > > > >Stefan, > >The max message size is 1000 bytes. That means there should be no more > >than 30M of data. Where do you check to see how big a certain queue is?? > > > >Andy > > > > > > > > > > Stefan Sievert > > >[EMAIL PROTECTED] > > TMAIL.COM> cc: > > Sent by: MQSeries Subject: Re: Reason 2056 > > List > > > n.AC.AT> > > > > > > 06/11/2002 12:31 > > PM > > Please respond to > > MQSeries List > > > > > > > > > > > > > >Andy, > >what is the size of each message you are sending? Beyond the maximum > >numbers > >of messages on a queue (MAXDEPTH) and the available disk space, queues >are > >limited to a maximum size of 2GByte on 5.2 for NT. > >Is it possible that you hit this limit with your transmission? In other > >words: Is 3 * yourMsgSize > 2GB ? > >Stefan > > > > > > >From: Andrew Goade <[EMAIL PROTECTED]> > > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > > >To: [EMAIL PROTECTED] > > >Subject: Reason 2056 > > >Date: Tue, 11 Jun 2002 11:13:28 -0500 > > > > > >We are sending a large number of messages between an AS/400 running >v5r2 > > >and Windows 2000 V5r2.1. The messages flow correctly for about the >first > > >30,000 records, then they start to back log. When the back log starts, > > >only a handful of messages flow between the systems. When browsing the > > >2000's logs I see a reason code 2056(MQRC_Q_SPACE_NOT_AVALIABLE). The > > >local queue has a max depth of 64, and the disk seems to have >enough > > >space. Has anyo
Re: Problem receiving messages from a restarted client applicatio n.
Dennis, The problem occurs irrespective of the bindings mode. The description of MQGMO_WAIT in the MQGMO section of the APRM decribes which app will be awoken when a suitable message arrives and states "if one or more nonbrowse MQGET calls is waiting, one is activated". While we do what the APRM says I agree that this is a problem that should be fixed. Andy. "Miller, Dennis" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/31/2002 07:59:40 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. Andy, Let's see...we have 2 tasks waiting on MQGET when a message lands on the queue. One of the MQGET's fails. Now, we have 1 task waiting on MQGET and a message on the queue, but MQ does not service the request. Meanwhile, another task can issue an MQGET and grab the message ahead of the task that's been waiting. 1. Is this also true for local MQGETs or is it particular just to clients? 2. Where, in the APRM, is this documented as you earlier indicated? > -Original Message- > From: Andrew Hickson [SMTP:[EMAIL PROTECTED]] > Sent: Friday, May 31, 2002 12:10 AM > To: [EMAIL PROTECTED] > Subject: Re: Problem receiving messages from a restarted client > applicatio n. > > Pavel, > That's a little simplistic, but basically yes, if the MQGET gets as far as > waiting for a message and then the get is awoken due to delivery of a > message and fails before removing the message from the queue then we won't > wake up another waiter to MQGET the message off the queue. Are you > thinking > of any other non aparable failure in particular ? > > Andy. > > Pavel Tolkachev <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/30/2002 > 11:22:34 PM > > Please respond to MQSeries List <[EMAIL PROTECTED]> > > Sent by:MQSeries List <[EMAIL PROTECTED]> > > > To:[EMAIL PROTECTED] > cc: > Subject:Re: Problem receiving messages from a restarted client >applicatio n. > > > > Andy: > > Does this mean that, if that woken destructive MQGET fails for any reason, > you do not attempt to look for the next qualifying candidate? > > Thank you, > Pavel > > Message History > > > > From: Andrew Hickson <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on > 05/30/2002 10:54 PM CET > > Please respond to MQSeries List <[EMAIL PROTECTED]> > > DELEGATED - Sent by:MQSeries [EMAIL PROTECTED]> > > > To:[EMAIL PROTECTED] > cc: > Subject:Re: Problem receiving messages from a restarted client > applicatio n. > > > Dennis/Rick, > As stated in the APRM, when an MQPUT occurs we try and wake up one > qualifying destructive MQGET (we explicitly do not specify which of > multiple waiters would be woken). > The problem here is that we haven't recognized that this waiter isn't > really a destructive MQGET and from there on it all awry. > > Andy. > > Richard Brunette <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on > 30/05/2002 21:08:57 > > Please respond to MQSeries List <[EMAIL PROTECTED]> > > Sent by:MQSeries List <[EMAIL PROTECTED]> > > > To:[EMAIL PROTECTED] > cc: > Subject:Re: Problem receiving messages from a restarted client >applicatio n. > > > > Dennis > > I believe its worse than that. They don't wake up one with a large buffer > either. They simply don't look further. So without a new stimulus such as > a > new message arriving or some other UOW message being backed out there is > nothing to wake the other waiting gets. Is that correct Andy? > > Rick > > > |-+---> > | | "Miller, Dennis"| > | | <[EMAIL PROTECTED]>| > | | | > | | Sent by: MQSeries List | > | | <[EMAIL PROTECTED]> | > | | | > | | | > | | | > | | Thursday May 30, 2002 02:48 PM | > | | Please respond to MQSeries List | > | | | > |-+---> > > > > -- > -
Re: Problem receiving messages from a restarted client applicatio n.
Pavel, That's a little simplistic, but basically yes, if the MQGET gets as far as waiting for a message and then the get is awoken due to delivery of a message and fails before removing the message from the queue then we won't wake up another waiter to MQGET the message off the queue. Are you thinking of any other non aparable failure in particular ? Andy. Pavel Tolkachev <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/30/2002 11:22:34 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. Andy: Does this mean that, if that woken destructive MQGET fails for any reason, you do not attempt to look for the next qualifying candidate? Thank you, Pavel Message History ------------ From: Andrew Hickson <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 05/30/2002 10:54 PM CET Please respond to MQSeries List <[EMAIL PROTECTED]> DELEGATED - Sent by:MQSeries [EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. Dennis/Rick, As stated in the APRM, when an MQPUT occurs we try and wake up one qualifying destructive MQGET (we explicitly do not specify which of multiple waiters would be woken). The problem here is that we haven't recognized that this waiter isn't really a destructive MQGET and from there on it all awry. Andy. Richard Brunette <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 30/05/2002 21:08:57 Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. Dennis I believe its worse than that. They don't wake up one with a large buffer either. They simply don't look further. So without a new stimulus such as a new message arriving or some other UOW message being backed out there is nothing to wake the other waiting gets. Is that correct Andy? Rick |-+---> | | "Miller, Dennis"| | | <[EMAIL PROTECTED]>| | | | | | Sent by: MQSeries List | | | <[EMAIL PROTECTED]> | | | | | | | | | | | | Thursday May 30, 2002 02:48 PM | | | Please respond to MQSeries List | | | | |-+---> > | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Problem receiving messages from a restarted client applicatio n. | > | >Truncated msg failed doesn't change the queue state and so there's no >backout action for this hConn (typically the UOW won't even have been >created). As there's no backout action we don't consider waking up another >MQGET when we discover that the first client ends. I understand, now, there is no backout action. But, then app2's MQGET should be serviced even sooner--perhaps even before you discover the client is gone. Still fishing for the reason app2 doesn't wake up. Do I interpret you correctly, that after a 2080, MQ does not service another waiting MQGET if its buffer is also too short? 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 -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Instructions for ma
Re: Problem receiving messages from a restarted client applicatio n.
Dennis/Rick, As stated in the APRM, when an MQPUT occurs we try and wake up one qualifying destructive MQGET (we explicitly do not specify which of multiple waiters would be woken). The problem here is that we haven't recognized that this waiter isn't really a destructive MQGET and from there on it all awry. Andy. Richard Brunette <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 30/05/2002 21:08:57 Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. Dennis I believe its worse than that. They don't wake up one with a large buffer either. They simply don't look further. So without a new stimulus such as a new message arriving or some other UOW message being backed out there is nothing to wake the other waiting gets. Is that correct Andy? Rick |-+---> | | "Miller, Dennis"| | | <[EMAIL PROTECTED]>| | | | | | Sent by: MQSeries List | | | <[EMAIL PROTECTED]> | | | | | | | | | | | | Thursday May 30, 2002 02:48 PM | | | Please respond to MQSeries List | | | | |-+---> > | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Problem receiving messages from a restarted client applicatio n. | > | >Truncated msg failed doesn't change the queue state and so there's no >backout action for this hConn (typically the UOW won't even have been >created). As there's no backout action we don't consider waking up another >MQGET when we discover that the first client ends. I understand, now, there is no backout action. But, then app2's MQGET should be serviced even sooner--perhaps even before you discover the client is gone. Still fishing for the reason app2 doesn't wake up. Do I interpret you correctly, that after a 2080, MQ does not service another waiting MQGET if its buffer is also too short? 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: Problem receiving messages from a restarted client applicatio n.
Dennis, Truncated msg failed doesn't change the queue state and so there's no backout action for this hConn (typically the UOW won't even have been created). As there's no backout action we don't consider waking up another MQGET when we discover that the first client ends. rgds Andy. "Miller, Dennis" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/30/2002 06:02:56 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. Thank you for the clarification. In doing more reading last night, I came to the same conclusion, but it's always nice to get confirmation from the source. Quite annoyingly, I believe it's MQCC_WARNING/MQRC_TRUNCATED_MSG_FAILED, which may add to the confusion. I understand the scenario to be that this sequence, with an adequate buffer size, works as expected: App1 agent issues MQGET+wait+syncpoint App2 agent issues MQGET+wait+syncpoint App1 client crashes Message arrives Message is delivered to App1 agent with RC=0 MQ discovers that client is gone App1 agent disconnects and rolls back message Message is delivered to App2 agent with RC=0 However, when the buffer is too small, the following is observed: App1 agent issues MQGET+wait+syncpoint App2 agent issues MQGET+wait+syncpoint App1 client crashes Message arrives Message is not delivered to App1 agent because RC=2080 MQ discovers that client is gone App1 agent disconnects and rolls back (exactly what, if anything, get's rolled back is interesting) App2 agent does not see message <==why is this??? App3 agent issues MQGET+wait+syncpoint App3 agent's MQGET returns with RC=2080 > -Original Message- > From: Andrew Hickson [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, May 30, 2002 12:27 AM > To: [EMAIL PROTECTED] > Subject: Re: Problem receiving messages from a restarted client > applicatio n. > > MQCC_FAILED/MQRC_TRUNCATED_MSG_FAILED does not result in the message being > explicitly locked. > > I'm not sure if If I'm interpretting this discussion correctly, are we > discussing the following situation: > > App1 issues MQGET+wait with buffer length X > App2 issues MQGET +wait with buffer length Y > App3 issues MQPUT for message of length Z where X < Z < Y > > As a result of the MQPUT App1 is woken with MQRC_TRUNCATED_MSG_FAILED, but > does not reissue the MQGET with a bigger buffer. App2 is now waiting when > the message it's waiting for is already sitting on the queue. > > I would agree that this doesn't seem like a completely correct > implementation, although it does improve the chances of the message being > available if/when App1 reissues the MQGET with a correctly sized buffer, > and I think it is in accordance with the documentation of MQGMO_WAIT in > the > APRM. I'd be concerned that if I fixed the queue manager to wake up > another > waiting MQGET under these circumstances then some existing apps could > break. Any comments ? > > Andy. > > > "Miller, Dennis" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/30/2002 > 01:38:13 AM > > Please respond to MQSeries List <[EMAIL PROTECTED]> > > Sent by:MQSeries List <[EMAIL PROTECTED]> > > > To:[EMAIL PROTECTED] > cc: > Subject:Re: Problem receiving messages from a restarted client >applicatio n. > > > > >Actually I don't see why the larger messages that cause this problem, > >should ever have been locked or need a back-out as the get would be > failing > >on a 2080. When the client is not terminated and the surrogate can return > >the 2080, it does not prevent a new get from another client from getting > >the message. > > You raise an interesting question. If a get under syncpoint fails, does > the > candidate message become available to other processes immediately or is it > reserved until completion of the UOW. (By "candidate", I mean whatever > message would be returned if the MQGET had been successful). In the case > of > a RC=2080, at least, the MD gets filled out and you get part of the > message > back, despite the failure. Since, it's common place to obtain a larger > buffer and try the read again, I expect MQ withholds that message from > other > processes until it's "freed" by completion of the UOW. Honestly, this is > conjecture on my part, but it does explain part of the behavior you are > seeing. > > Also, I am curious, is your client MQGET a browse or destructive? > > > > > > -Original Message- > > From: Richa
Re: Problem receiving messages from a restarted client application.
Rick, I'd anticipate treating the apps with small buffers as non destructive getter's and waking them all in the event that I couldn't find a true destructive get for the message. Andy. Richard Brunette <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/30/2002 05:33:10 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client application. Andy Please keep in mind when you are deciding what to wake, that in the original problem both applications had the same size buffer. Both where surrogates of two instances of the same Java application. Both start their gets with a 4096 buffer and when it/if fails the Java internals come back to the surrogate with a larger buffer. The difference between the two is one had crashed so only the surrogate was left around. The instance that was started to replace it was waiting with the same initial buffer. As this is common in the object interfaces, we would like to see a solution that with let a waiting second client process even if at first glance this client does not appear any more capable of handling the message. In reality it was. Thanks, Rick 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: Backed out msg retains its old positon on the Q?
It preserves its original position. Andy. steve muller <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/30/2002 04:32:18 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Backed out msg retains its old positon on the Q? When a message is retrieved with GET + Syncpoint and then backed out, does it preserve its original position on the queue or go to the bottom of the queue? I think it is the latter but wanted to confirm with you. Thanks for your response. SM __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.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
Re: cleanmqlogs QMGR recycling
A fix for the problem with rcdmqimg not taking media images for some cached permanent dynamic queues (ghost queues), and therefore not allowing the media recovery LSN to progress as expected should be included in the next CSD. Robert Broderick <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/30/2002 03:52:11 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: cleanmqlogs QMGR recycling Thanks Rob, I know the application are using static queues but I will mention the prospect of the rcdmqimg having problems in this area in my support doc. If anybody get creative in the future But to my origional question, I read in the script: Now, if you never run rcdmqimg and you never restart your # queue manager, you will never reduce the number of logs # needed for media recovery. Therefore, this script will not # gzip/compress/unlink anything. Not too useful. I would assume by this that both the rcdmqimg and a restart are necessary. This is how my veritas scripts are coded. If anybody knows otherwise let me know. >From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: cleanmqlogs QMGR recycling >Date: Thu, 30 May 2002 08:45:48 -0500 > > >-Original Message- > >From: Robert Broderick [mailto:[EMAIL PROTECTED]] > >Sent: Wednesday, May 29, 2002 6:45 PM > >To: [EMAIL PROTECTED] > >Subject: cleanmqlogs QMGR recycling > > > > > >With MQSeries 5.2 do you have to recycle the queue manager after doing a > >rcdmqimg to run the cleanmqlogs. Someone indicated there was a quirk in >MQ > >pre-5.2 that required you to do this to make the END-OF-LOG messages get > >generated. > > > > bobbee > >Bobbee, > >We ran across a bug in rcdmqimg that it would not generate the END-OF-LOG >messages if there were any permanent dynamic queues existing. Attached is >a >copy of the email exchange and workaround. > >-- T.Rob > >-- > >From: Woodruff, Chris >Sent: Friday, January 11, 2002 1:57:32 PM >To: mqseries >Subject: RE: Erica... pmr 60601,122 attn: Erica > >Erica, > >Thank you. I did delete all the PERMDYN queues associated with the ghost >queues, and after doing > > rcdmqimg -m NYTFMDQA1 -l -t all '*' > >the reported logfile required for media recovery did move as I would >expect. >However, before this worked correctly, I also had to delete the MODEL >queues >that were used to create the PERMDYN queues in question. This isn't a very >convenient fix as I will need to delete these MODEL queues every time I >want >to clean my logfiles. And after the cleaning, I will have to recreate the >MODEL queues so the system will work! > >This works as a workaround, but I'll be looking forward to the actual fix. >:-) > >Thanks again! > >Chris > > >-Original Message- >From: mqseries >Sent: Friday, January 11, 2002 12:21 PM >To: Woodruff, Chris >Subject: Re: Erica... pmr 60601,122 attn: Erica > > >Hi Chris, > >Here is the latest update from the change team: > >Thanks for the docs. We found that the queue managers using perm >dynamic queues for the "calculation of the media restart LSN" >appears to include the resulting ghost queue, resulting in the >media restart log extent not moving on as expected. The work around >for the problem is to delete the ghost queues in the queue manager >before doing rcdmqimg. >. >We want the customer to follow the work around provided above. A >defect(61889) has been opened for this problem. > >*** >Let me know if the work a round solves your problem. > >Regards, >MQSeries Level 2 Support - Distributed Platforms >Email: [EMAIL PROTECTED] >Need publications? Go to http://www.ibm.com/shop/publications/order > >When sending mail to MQSERIES, please add the Level 2 rep's name and the >Problem Number in the Subject line. >** In addition please call the support center and update your problem >record. (or electronically update your problem record) ** > >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 _ Join the world s largest e-mail service with MSN Hotmail. http://www.hotmail.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
Re: Problem receiving messages from a restarted client application.
Rick, I've discussed this with the mainframe developers (I'm one of the developers on the MQ distributed products) and understand they have fixed a number of problems in this area recently (I assume 5.3). The 390 product has a couple of additional complications in this area (mark skip backout & get with signal), and I think that all that might be required on the distributed platforms is to avoid only waking a single waiter if the waiters buffer is too small and doesn't want to accept a truncated message. It might be sensible to awaken a waiter with a big enough buffer in preference to waking both the waiter with a small buffer and the waiter with a big buffer in my earlier example, but I'll make that decision when I look at the code in detail. It's now too late for this change to get in the first distributed 5.3 deliverable and I'd expect it to appear in the first 5.3 CSD. If you want the fix earlier then you'll need to raise a problem with the support center and the service team should be able to port the fix back to 5.2. Andy. Richard Brunette <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/30/2002 04:03:32 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client application. This application was simply using an indefinite wait. As I said we have convinced the application developers to make a number of changes that with provide a better design for their business problem. These changes have greatly reduced the frequency that the application will be exposed to this problem. However the problem still exists and is the type of issue that is going to hit you and not necessarily be easily identified. The exposure risk is going up with more java development with unspecified message lengths. As Andy says (and testing proves) the message isn't locked or considered part of a unit of work. It is available to any get that comes along. It just will not be delivered to a get that is already waiting for it, unless there is another message that becomes available to tell the queue manager to wake up the get that is waiting. I'm well aware of receiving the portion of the message that fits in the buffer as Dennis mentions and even questioned the idea of the message being locked myself, but its just not the case. It sounds like Andy understands both the issue and why the internals of the queue manager code is causing this behavior. I'm assuming, from your many past posts to this list Andy, that your one of the IBMers on this list with detailed knowledge of the internal code-base of the mainframe queue managers. Thanks Pavel, Dennis, and Mike for you comments. Andy I'd like to hear any further information on what will be done or what is to the expected behavior of the queue manager and the surrogates in this situation. In addition a co-worker here has sent IBM and ETR on this issue. Rick 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: Problem receiving messages from a restarted client applicatio n.
MQCC_FAILED/MQRC_TRUNCATED_MSG_FAILED does not result in the message being explicitly locked. I'm not sure if If I'm interpretting this discussion correctly, are we discussing the following situation: App1 issues MQGET+wait with buffer length X App2 issues MQGET +wait with buffer length Y App3 issues MQPUT for message of length Z where X < Z < Y As a result of the MQPUT App1 is woken with MQRC_TRUNCATED_MSG_FAILED, but does not reissue the MQGET with a bigger buffer. App2 is now waiting when the message it's waiting for is already sitting on the queue. I would agree that this doesn't seem like a completely correct implementation, although it does improve the chances of the message being available if/when App1 reissues the MQGET with a correctly sized buffer, and I think it is in accordance with the documentation of MQGMO_WAIT in the APRM. I'd be concerned that if I fixed the queue manager to wake up another waiting MQGET under these circumstances then some existing apps could break. Any comments ? Andy. "Miller, Dennis" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/30/2002 01:38:13 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Problem receiving messages from a restarted client applicatio n. >Actually I don't see why the larger messages that cause this problem, >should ever have been locked or need a back-out as the get would be failing >on a 2080. When the client is not terminated and the surrogate can return >the 2080, it does not prevent a new get from another client from getting >the message. You raise an interesting question. If a get under syncpoint fails, does the candidate message become available to other processes immediately or is it reserved until completion of the UOW. (By "candidate", I mean whatever message would be returned if the MQGET had been successful). In the case of a RC=2080, at least, the MD gets filled out and you get part of the message back, despite the failure. Since, it's common place to obtain a larger buffer and try the read again, I expect MQ withholds that message from other processes until it's "freed" by completion of the UOW. Honestly, this is conjecture on my part, but it does explain part of the behavior you are seeing. Also, I am curious, is your client MQGET a browse or destructive? > -Original Message- > From: Richard Brunette [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, May 29, 2002 11:31 AM > To: [EMAIL PROTECTED] > Subject: Re: Problem receiving messages from a restarted client > application. > > Pavel > > I'm not sure that I understand what your saying. From everything I've seen > the syncpoint processing performs exactly as I would suspect and as > documented in this usage note from the APR manual. Without syncpointing > successful gets do lose the message when the 'surrogate' can't return > them. > And with syncpointing they are backed out and available for another > program > to browse or get. > >3. If the application issuing the MQGET call is running as an MQ > client, it is possible for the message retrieved to be lost if > during > the processing of the MQGET call the MQ client terminates > abnormally or the client connection is severed. This arises because > the surrogate that is running on the queue-manager's platform and > which issues the MQGET call on the client's behalf cannot detect > the loss of the client until the surrogate is about to return the > message to the client; this is after the message has been removed > from the queue. This can occur for both persistent messages and > nonpersistent messages. > > > The risk of losing messages in this way can be eliminated by always > retrieving messages within units of work (that is, by specifying the > MQGMO_SYNCPOINT option on the MQGET call, and using the MQCMIT > or > MQBACK calls to commit or back out the unit of work when processing > of the message is complete). If MQGMO_SYNCPOINT is specified, and > the > client terminates abnormally or the connection is severed, the > surrogate backs out the unit of work on the queue manager and the > message is reinstated on the queue. > > I don't know that I've ever read anything to suggest that fully backed-out > message would under any circumstances not be available to another client > that was already waiting on a get (let alone an open). In fact if I use a > smaller message in the test the already waiting client does get the > message. > > Actually I don't see why the larger messages that cause this problem, > should ever have been locked or need a back-out as the get would be > failing > on a 2080. When the client is not terminated and the surrogate can return > the 2080, it does not prevent a new get from another client from getting > the message. It appears as though there is nothing to
Re: MQSeries PUB/SUB
Stephen, I'd prefer it if you would correct the problem with the DCE mismatch first. If the problem persists once this is fixed then please send me the FDC. Are you dependant upon the MQ DCE threads support ? If you're not using DCE threads support (e.g. if you simply installed everything (including DCE support) without considering the consequences) then you'd likely see a significant performance improvement by removing the MQ DCE support. Of course if this is not a new installation then you'll need to consider the implications of this change. If you are using DCE threads then you'll need to install the version of the broker which also uses DCE threads. Andy. Stephen Cook <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 28/05/2002 22:13:13 Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: MQSeries PUB/SUB strmqbrk does not match the queue manager in this respect - strmqbrk does not link to strmqbrk_d but endmqm does link to endmqm_d. Each attempt to start the broker does produce an FDC. Should I send the FDC? Thanks. Andrew Hickson wrote: > Are you running draft 4 or draft 11 threads, does your broker match your > queue manager in this respect ? (e.g does strmqbrk link to strmqbrk_d, does > endmqm link to endmqm_d). Note that HP performance is MUCH improved when > running draft 11 threads. > > Were any FDC's produced ? If not then it is likely that a trace will be > required to understand what's going on. If you'd like to send me a trace > then I'll have a look, but I probably won't get to it until Thursday at the > earliest. > > Andy. > > Stephen Cook <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 28/05/2002 18:17:26 > > Please respond to MQSeries List <[EMAIL PROTECTED]> > > Sent by:MQSeries List <[EMAIL PROTECTED]> > > To:[EMAIL PROTECTED] > cc: > Subject:MQSeries PUB/SUB > > All, > > We are trying to setup an MQSeries PUB/SUB environment > on HP-UX v.11 running MQ 5.2 with CSD04. We've > installed SupportPacs - MA0C (MQSeries - > Publish/Subscribe) and MA0F (MQSeries Application > Messaging Interface). We seem to have a problem after > we've created and started a QMGR and we attempt to > start the broker (strmqbrk -m QMgrName). We receive > the message - 'MQSeries message broker for queue > manager PUBSUB not active.' The QMGR error logs > contains the following error - "An attempt has been > made to run the MQSeries message broker (PUBSUB) but > the broker has ended for reason '5800: (Unexpected > Error)'." Thanks for any help that can be provided. > > 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 PUB/SUB
Are you running draft 4 or draft 11 threads, does your broker match your queue manager in this respect ? (e.g does strmqbrk link to strmqbrk_d, does endmqm link to endmqm_d). Note that HP performance is MUCH improved when running draft 11 threads. Were any FDC's produced ? If not then it is likely that a trace will be required to understand what's going on. If you'd like to send me a trace then I'll have a look, but I probably won't get to it until Thursday at the earliest. Andy. Stephen Cook <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 28/05/2002 18:17:26 Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:MQSeries PUB/SUB All, We are trying to setup an MQSeries PUB/SUB environment on HP-UX v.11 running MQ 5.2 with CSD04. We've installed SupportPacs - MA0C (MQSeries - Publish/Subscribe) and MA0F (MQSeries Application Messaging Interface). We seem to have a problem after we've created and started a QMGR and we attempt to start the broker (strmqbrk -m QMgrName). We receive the message - 'MQSeries message broker for queue manager PUBSUB not active.' The QMGR error logs contains the following error - "An attempt has been made to run the MQSeries message broker (PUBSUB) but the broker has ended for reason '5800: (Unexpected Error)'." Thanks for any help that can be provided. 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.2 CSD4 New System Queue
Yes, This is the internal queue that the queue manager uses to guarantee that non durable JMS subscriptions are deregistered in the event of an unexpected termination of either the queue manager or the subscriber. There's also a new queue manager process (amqzdma) which manages the queue. Andy. Ruud van Zundert <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 28/05/2002 19:25:23 Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: MQ V5.2 CSD4 New System Queue Stefan - thanks. I've read the post, and you're right, it could have something to do with a 'pub/sub deferred deregister message' (try and say that quickly ;-) ). Any IBMers wish to comment as well? Regards ... Ruud -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Stefan Sievert Sent: 28 May 2002 18:12 To: [EMAIL PROTECTED] Subject: Re: MQ V5.2 CSD4 New System Queue Ruud, I have to say upfront that I don't know the documented truth, but it 'smells' like it has something to do with what is described in this recent post: http://www.messageq.com/forums/vienna/msg_body.php3?ID=31105 Obviously CSD04 introduces support for deferred messages that will only be made availble to other applications at the time the producing application disconnects. Hopr that helps, Stefan >From: Ruud van Zundert <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: MQ V5.2 CSD4 New System Queue >Date: Tue, 28 May 2002 15:35:13 +0100 > >All, > >When I create a queue manager I like the usual confirmation >stating that 29 objects have been created. >Then, having just applied CSD4 for MQ V5.2 on Windows, this >number is now 30. There is a new system queue called > >SYSTEM.PENDING.DATA.QUEUE > >Also, if you run 'strmqm -c ' this extra queue is added >to an existing queue manager. > >There is no documentation in the readme for CSD4 and a trawl >through the internet has not revealed anything. >The comment on the queue itself states 'MQ deferred message q'. > >Any takers? > >Regards ... Ruud > >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 _ Send and receive Hotmail on your mobile device: http://mobile.msn.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 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: Expiry
Yes the timestamp is separate to the MQMD put date/time fields. In this respect the MCA is just another MQI application. The queue manager has already adjusted the remaining expiry time for the time the message was on the xmit-q by the time the message is returned to the MCA (as documented under the description of Expiry in the MQMD section of the APRM). The MCA then propagates the new expiry interval to the partner system. Andy. John Scott <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/27/2002 03:06:30 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Expiry Andy, This timestamp is separate to the MQMD put date/time fields? I assumed that MCAs were just regular applications using the MQI to get/put messages, so how do you get the original timestamp for the message to compare against the now timestamp? Is it in the MQMD for the message on the xmitq and the original values saved off in the MQMD1 MsgDesc of the MQXH structure? John. Andrew Hickson <[EMAIL PROTECTED]> wrote: John, When the message is MQPUT we remember the time at which the put occured, when an MQGET occurs then we take another timestamp and subtract the time the message has been stored to calculate the remaining expiry interval. This remaining expiry interval is then transmitted with the message to the remote system. There is never any comparison of clocks from different machines. Andy. John Scott @AKH-WIEN.AC.AT> on 05/27/2002 02:35:58 PM Please respond to MQSeries List Sent by: MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: Expiry --- Andrew Hickson wrote: > John, > If you "move the clock forward one hour" then we're > not talking about the > relative time zones and time synchro! nization of two > machines in an MQ > network, which I believe was the context of this > thread. It was probably a bad example so I'll try again... If two machines think they are in the same time zone, but the receiving machine is 10 minutes ahead because clocks aren't sync'ed, how does MQ know that even though the message was put at 17:00 GMT that from the "ahead" machines point of view, the message was originally put at 17:10 GMT (17:00@QMGR_A === 17:10@QMGR_B)? The only way I can see it is if there is an internal "local put date/time" that gets saved along with the message and then compared against the date/time on read to determine if we've exceeded the expiry interval. Is this correct? > Certainly if you start messing around with the > system clock you can get > messages to expire in less wallclock time then the > interval specified in > the MQMD. > > Andy. > > John Scott @AKH-WIEN.AC.AT> on > 05/27/2002 01:05:08 PM > > Please respond to MQSeries List > > > Sent by: MQSeries List > > > To: [EMAIL PROTECTED] > cc: > Subject: Re: Expiry > > > > --- Andrew Hickson > wrote: > > Expiry is transmitted between machines as an > > interval. Consequently the > > relative timezones and clock sync should have no > > effect on the expiry > > calculation. > > OK, if I put a message at 17:00 GMT with a 1 hour > expiry interval, and then move the clock forward one > hour and try to read the message, what happens? > > I would expect the message to be expired, because > the > time "elapsed" is >1hr. > > What is the expiry interval compared to (internally > by > MQSeries) when a messag! e is read from the queue > before > it is deemed expired (or the expiry interval gets > reduced accordingly)? I assume that the expiry > interval does not reduce automatically while the > message is on the queue, only when MQSeries removes > the message from the queue. > > Does MQSeries keep it's own version of elapsed time > rather than relying on the system clock or > something? > > > If you can get a message with a 10 minute expiry > to > > expire in less than 10 > > minutes on the distributed platforms then please > > send me a trace and I'll > > look into it. > > > > Thanks > > Andy. > > > > John Scott @AKH-WIEN.AC.AT> > on > > 05/27/2002 10:30:27 AM > > > > Please respond to MQSeries List > > > > > > Sent by: MQSeries List > > > > > > > To: [EMAIL PROTECTED] > > cc: > > Subject: Re: Expiry > > > > > > > > --- Jon Shearer > > > wrote: > I'm seeing behavior that suggests the > > expiry > > > interval is not simply a > > > > > I want to know: > > > 1) why does the message expire before 10 minutes > > has > > > elapsed? > > > &g
Re: Expiry
John, When the message is MQPUT we remember the time at which the put occured, when an MQGET occurs then we take another timestamp and subtract the time the message has been stored to calculate the remaining expiry interval. This remaining expiry interval is then transmitted with the message to the remote system. There is never any comparison of clocks from different machines. Andy. John Scott <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/27/2002 02:35:58 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject: Re: Expiry --- Andrew Hickson <[EMAIL PROTECTED]> wrote: > John, > If you "move the clock forward one hour" then we're > not talking about the > relative time zones and time synchronization of two > machines in an MQ > network, which I believe was the context of this > thread. It was probably a bad example so I'll try again... If two machines think they are in the same time zone, but the receiving machine is 10 minutes ahead because clocks aren't sync'ed, how does MQ know that even though the message was put at 17:00 GMT that from the "ahead" machines point of view, the message was originally put at 17:10 GMT (17:00@QMGR_A === 17:10@QMGR_B)? The only way I can see it is if there is an internal "local put date/time" that gets saved along with the message and then compared against the date/time on read to determine if we've exceeded the expiry interval. Is this correct? > Certainly if you start messing around with the > system clock you can get > messages to expire in less wallclock time then the > interval specified in > the MQMD. > > Andy. > > John Scott <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on > 05/27/2002 01:05:08 PM > > Please respond to MQSeries List > <[EMAIL PROTECTED]> > > Sent by:MQSeries List <[EMAIL PROTECTED]> > > > To:[EMAIL PROTECTED] > cc: > Subject:Re: Expiry > > > > --- Andrew Hickson <[EMAIL PROTECTED]> > wrote: > > Expiry is transmitted between machines as an > > interval. Consequently the > > relative timezones and clock sync should have no > > effect on the expiry > > calculation. > > OK, if I put a message at 17:00 GMT with a 1 hour > expiry interval, and then move the clock forward one > hour and try to read the message, what happens? > > I would expect the message to be expired, because > the > time "elapsed" is >1hr. > > What is the expiry interval compared to (internally > by > MQSeries) when a message is read from the queue > before > it is deemed expired (or the expiry interval gets > reduced accordingly)? I assume that the expiry > interval does not reduce automatically while the > message is on the queue, only when MQSeries removes > the message from the queue. > > Does MQSeries keep it's own version of elapsed time > rather than relying on the system clock or > something? > > > If you can get a message with a 10 minute expiry > to > > expire in less than 10 > > minutes on the distributed platforms then please > > send me a trace and I'll > > look into it. > > > > Thanks > > Andy. > > > > John Scott <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> > on > > 05/27/2002 10:30:27 AM > > > > Please respond to MQSeries List > > <[EMAIL PROTECTED]> > > > > Sent by:MQSeries List > <[EMAIL PROTECTED]> > > > > > > To:[EMAIL PROTECTED] > > cc: > > Subject:Re: Expiry > > > > > > > > --- Jon Shearer > <[EMAIL PROTECTED]> > > wrote: > I'm seeing behavior that suggests the > > expiry > > > interval is not simply a > > > > > I want to know: > > > 1) why does the message expire before 10 minutes > > has > > > elapsed? > > > > I always thought (i.e. this is my theory to date) > > that > > the put date/time would be stored in GMT (UTC) in > > the > > MQMD on the queue. It is then converted to your > > local > > time (BST/PDT) when accessed, depending on the > time > > zone of the machine. > > > > I would confirm that the machines are time-synced > > with > > each other. This means that if it really is 17:00 > > GMT > > and 10:00 PDT, the machines reflect this at the > same > > point in time. If the machines report 17:09 GMT > and > > 10:00 PDT, then the mainframe could think that 9 > > minutes have passed since the message was put. > > > > It's a bit like having two machines in
Re: Expiry
John, If you "move the clock forward one hour" then we're not talking about the relative time zones and time synchronization of two machines in an MQ network, which I believe was the context of this thread. Certainly if you start messing around with the system clock you can get messages to expire in less wallclock time then the interval specified in the MQMD. Andy. John Scott <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/27/2002 01:05:08 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject: Re: Expiry --- Andrew Hickson <[EMAIL PROTECTED]> wrote: > Expiry is transmitted between machines as an > interval. Consequently the > relative timezones and clock sync should have no > effect on the expiry > calculation. OK, if I put a message at 17:00 GMT with a 1 hour expiry interval, and then move the clock forward one hour and try to read the message, what happens? I would expect the message to be expired, because the time "elapsed" is >1hr. What is the expiry interval compared to (internally by MQSeries) when a message is read from the queue before it is deemed expired (or the expiry interval gets reduced accordingly)? I assume that the expiry interval does not reduce automatically while the message is on the queue, only when MQSeries removes the message from the queue. Does MQSeries keep it's own version of elapsed time rather than relying on the system clock or something? > If you can get a message with a 10 minute expiry to > expire in less than 10 > minutes on the distributed platforms then please > send me a trace and I'll > look into it. > > Thanks > Andy. > > John Scott <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on > 05/27/2002 10:30:27 AM > > Please respond to MQSeries List > <[EMAIL PROTECTED]> > > Sent by:MQSeries List <[EMAIL PROTECTED]> > > > To:[EMAIL PROTECTED] > cc: > Subject:Re: Expiry > > > > --- Jon Shearer <[EMAIL PROTECTED]> > wrote: > I'm seeing behavior that suggests the > expiry > > interval is not simply a > > > I want to know: > > 1) why does the message expire before 10 minutes > has > > elapsed? > > I always thought (i.e. this is my theory to date) > that > the put date/time would be stored in GMT (UTC) in > the > MQMD on the queue. It is then converted to your > local > time (BST/PDT) when accessed, depending on the time > zone of the machine. > > I would confirm that the machines are time-synced > with > each other. This means that if it really is 17:00 > GMT > and 10:00 PDT, the machines reflect this at the same > point in time. If the machines report 17:09 GMT and > 10:00 PDT, then the mainframe could think that 9 > minutes have passed since the message was put. > > It's a bit like having two machines in the same time > zone, but their clocks are out by 10 minutes. > Machine > A puts the message at 17:00, but when machine B > loads > it, it thinks it is 17:10, and determines that the > message has expired. > > > 2) why are the messages that are processed rather > > quickly not expired? > > I guess that expiry is not an exact science, or that > your machines are just less than 10 minutes out in > UTC > terms. > > Regards > John. > > > __ > Do You Yahoo!? > Everything you'll ever need on one web page > from News and Sport to Email and Music Charts > http://uk.my.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 __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.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
Re: Expiry
Expiry is transmitted between machines as an interval. Consequently the relative timezones and clock sync should have no effect on the expiry calculation. If you can get a message with a 10 minute expiry to expire in less than 10 minutes on the distributed platforms then please send me a trace and I'll look into it. Thanks Andy. John Scott <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/27/2002 10:30:27 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Expiry --- Jon Shearer <[EMAIL PROTECTED]> wrote: > I'm seeing behavior that suggests the expiry > interval is not simply a > I want to know: > 1) why does the message expire before 10 minutes has > elapsed? I always thought (i.e. this is my theory to date) that the put date/time would be stored in GMT (UTC) in the MQMD on the queue. It is then converted to your local time (BST/PDT) when accessed, depending on the time zone of the machine. I would confirm that the machines are time-synced with each other. This means that if it really is 17:00 GMT and 10:00 PDT, the machines reflect this at the same point in time. If the machines report 17:09 GMT and 10:00 PDT, then the mainframe could think that 9 minutes have passed since the message was put. It's a bit like having two machines in the same time zone, but their clocks are out by 10 minutes. Machine A puts the message at 17:00, but when machine B loads it, it thinks it is 17:10, and determines that the message has expired. > 2) why are the messages that are processed rather > quickly not expired? I guess that expiry is not an exact science, or that your machines are just less than 10 minutes out in UTC terms. Regards John. __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.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
Re: find lost msg in active log
Glen,
Sorry I can't explain this, this message certainly appears to have been put
at approx 8:15 pm on 5/14/2002 (GMT) (there's an internal time in the AQRH
which is independant of the PutDate/PutTime in the compressed MQMD in the
log record which confirms this).
Sorry
Andy.
Glen Larson <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/23/2002
10:59:11 PM
Please respond to MQSeries List <[EMAIL PROTECTED]>
Sent by:MQSeries List <[EMAIL PROTECTED]>
To:[EMAIL PROTECTED]
cc:
Subject:Re: find lost msg in active log
Andy,
I've managed to dump the logs and have been looking thru the files and have
found some things which confuse me. NT says that 689 log file was last
modified on 5/13 at 8:30pm
(Embedded image moved to file: pic19169.pcx)
yet in the log I have found messages that have an MQMD timestamp that is
later.
200205140150827 GMT is after 5/13/2002/8:30 pm local
any help on why that is, and how can I determine the right log file to
dump, without dumping it?
thanks
glen larson
sample log extract:
LOG RECORD - LSN <0:0:9:62963>
**
HLG Header: lrecsize 845, version 1, rmid 0, eyecatcher HLRH
LogRecdType . . : AQM Put Message (257)
Eyecatcher . . : ALRH Version . . . . : 1
LogRecdLen . . : 825 LogRecdOwnr . . : 256(AQM)
XTranid . . . . : TranType: MQITranNum{High 0, Low 12984}
QueueName . . . : USZ.
Qid . . . . . . : {Hash 3572395625, Counter: 10}
ThisLSN . . . . : <0:0:0:0>
PrevLSN . . . . : <0:0:9:62743>
Version . . . . : 3
SpcIndex . . . : 1
PrevLink.Locn . : 36 PrevLink.Length : 8
PrevDataLink . : {High 0, Low 2048}
Data.Locn . . . : 2048 Data.Length . . : 601
Data . . . . . :
0: 41 51 52 48 04 00 00 00 FF FF FF FF FF FF FF FFAQRH
00016: 00 00 00 00 00 00 00 00 01 00 00 00 02 00 C0 01..À.
00032: 00 00 00 00 00 00 01 00 99 00 00 00 00 00 00 00?...
00048: B7 02 00 00 C3 E2 D8 40 D4 D8 D7 F1 40 40 40 40·...ÃâØ@ÔØ×ñ
00064: 40 40 40 40 B7 A0 73 48 47 6D 58 26 43 49 49 44· sHGmX&CIID
00080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00096: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00112: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00
00128: 00 00 00 00 FF FF FF FF 00 00 00 00 00 00 00 00
00144: 00 00 00 00 ED 00 00 00 0B 35 9A D0 FF FF FF FFí5?Ð
00160: 4D 44 20 20 01 00 00 00 00 00 00 00 01 00 00 00MD
00176: 00 00 00 00 11 03 00 00 F4 01 00 00 4D 51 53 54ô...MQST
00192: 52 20 20 20 00 00 00 00 01 00 00 00 55 53 5A 2ER USZ.
00208: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
00224: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00240: 20 20 20 20 20 20 20 20 20 20 20 20 XX XX XX XX
1
00256: XX XX XX 20 20 20 20 20 20 20 20 20 20 20 20 20XXX
00272: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00288: 20 20 20 20 20 20 20 20 20 20 20 20 -- -- -- --
00304: -- -- -- 20 20 20 20 20 1A 11 E4 E2 E9 E4 D9 F0xxx ..äâéäÙð
00320: F0 F0 4B E4 E2 E9 E9 E5 F1 C3 F3 A0 73 48 46 93ððKäâééåñÃó sHF.
00336: 97 00 01 00 00 00 00 00 20 20 20 20 20 20 20 20
00352: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00368: 20 20 20 20 20 20 20 20 01 00 00 00 -- -- -- --
00384: -- -- -- -- -- -- -- -- 20 20 20 20 20 20 20 20
00400: 20 20 20 20 20 20 20 20 32 30 30 32 30 35 31 3420020514
00416: 32 30 31 35 30 38 32 37 20 20 20 20 00 00 00 0020150827
00432: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Andrew Hickson <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 05/14/2002
12:05:45 PM
Please respond to MQSeries List <[EMAIL PROTECTED]>
Sent by:MQSeries List <[EMAIL PROTECTED]>
To:[EMAIL PROTECTED]
cc:
Subject:Re: find lost msg in active log
Glen,
If you're using linear logging, and a persistent message was actually on a
queue at some point in time then it will have been logged. The log is
intended for recovery purposes and doesn't contain any details relating to
the identity of the application that removed the message, but if you're
lucky then some other message may have been put in the same transaction and
might contain some user/application identity.
I'm afraid that the distributed log dumper, dmpmqlog, is not a thing of
beauty, being intended primarily for service use, but it will format the
contents of the recovery log to a more readable form.
Andy.
Glen Larson <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/14/2002
05:35:14 PM
Please respond to MQSeries List <[EMAIL PROTECTED]>
Sent by:MQSeries List <[EMAIL PROTECTED]>
To:[EMAIL PROTECTED]
cc:
Re: Accessing MQ from CORBA programs (2195, 2095 errors)
Phillip, 2195 is MQRC_UNEXPECTED_ERROR, wheras attempting to share hconn's between threads should result in MQRC_HCONN_ERROR. I don't think you specified what platform you're using, if it's AIX, HPUX, AS400 or LINUX then you need to ensure that you link threaded applications with libmqm_r. If you run threaded applications with libmqm on those platforms then you might expect MQRC_UNEXPECTED_ERROR and MQRC_CALL_IN_PROGRESS. Andy. "Chris A. Dahl" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 14/05/2002 20:56:22 Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Accessing MQ from CORBA programs (2195, 2095 errors) Philip, You cannot share queue manager connections between threads. I understand that this may be possible in version 5.3 (not yet GA). Regards, Chris "Philip, Aby" cc: Sent by: Subject: Accessing MQ from CORBA programs (2195, 2095 errors) MQSeries List 05/14/02 01:40 PM Please respond to MQSeries List Hi everyone, I was just trying out an MQ access from a CORBA server program. Let's say that there is a method called balance() which gives me the balance after accessing the queues to put a message on. So I have a client which is connecting to the CORBA server and calling this 'balance()' method. Now if this client calls the server just once..I get the results as expected. Then I tried accesing the same server thru a pthread in the client. This time the access to the server from the client happens within a thread. When I do this once..everything is fine. Now I tried putting this in a loop so that the same client has about 10 threads trying to access the server..This time te results are funny..I keep getting 2059, 2195 error codes saying that there is some sort of access in progress and all. And I get a few successful calls in between for a few threads. Any idea on why this can happen? Or has anyone faced any problems like this before? Thanks Kind Regards Aby 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: find lost msg in active log
Glen, If you're using linear logging, and a persistent message was actually on a queue at some point in time then it will have been logged. The log is intended for recovery purposes and doesn't contain any details relating to the identity of the application that removed the message, but if you're lucky then some other message may have been put in the same transaction and might contain some user/application identity. I'm afraid that the distributed log dumper, dmpmqlog, is not a thing of beauty, being intended primarily for service use, but it will format the contents of the recovery log to a more readable form. Andy. Glen Larson <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/14/2002 05:35:14 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:find lost msg in active log Hi, I know I'm grasping at straws, but. I'm running MQ5.2 CSD03, on Win NT 4.0 sp6.A One of my users has lost production messages that were on the MQ server, (he saw via a browse utility). He would like to find out who removed the messages, (he's afraid his application has a bug), And if possible recover the messages. I know that if we were on MVS is would be possible with a support pack.I have not seen a similar tool for NT in the support packs. Is there a tool available that could do either (recover the message, and/or identify the application that got the message)? thanks Glen Larson Zurich NA *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQSERIES Digest - 8 May 2002 to 9 May 2002 (#2002-134)
Dave, You can't always do that, it doesn't work like that all the time. The relationship between the queue file and the log is fairly simple, but is NOT a guaranteed part of the queue manager externals, consequently I try not to explain how it works for fear that customers will take advantage of the current implemntation in a way that will not guarantee future compatibility. For example there are a large number of changes in 5.3 to try to avoid writing messages to both the log and the queue file. If you shut the queue manager down in a completely clean manner then one of the things that the queue manager will (currently) do is to synchronize the queue file and the log. Similarly when you restart the queue manager following a completely clean shutdown then there's no log replay or backout to perform (but you do need to be aware of any indoubt messages). Under these circumstances the queue manager can usually be fooled by replacing one 'clean' queue file with another similar queue file. Personally I'd be tempted to investigate further the performance of using the MQI to backup/restore the contents of the queue rather than building upon undocumented observed behaviour. One option that you should consider using to speed up the process is batching (say 100 messages per syncpoint). I ran a simple test on my NT desktop (2 way 800Mhz) running MQ 5.3 to load a queue with 35000 messages each 4K bytes long. It took 75 seconds when the log was on a fast device (non volatile write cache) and 87 seconds with the log on a standard SCSI device. By contrast putting the messages individually (outside syncpoint took 76 seconds with the fast device and 437 seconds with the slow device. Andy. David Awerbuch <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/13/2002 03:25:52 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: MQSERIES Digest - 8 May 2002 to 9 May 2002 (#2002-134) Hello Bobbee in Georgia, I am using circular logging, but I must admit I do not see where you are going with your question; I would appreciate your elaborating if you so desrire. Anyway, I did exactly what I originally was asking about. All the messages involved were persistent. 1. I shutdown the QM, 2. copied the 'Q' file (this is the XMIT queue) 3. restarted the QM, 4. cleared the Queue, 5. shutdown and restarted the QM (to do a full recycle on the QM), 6. shutdown the QM, 7. restored the 'Q' file, 8. restarted the QM 9. runmqsc ==> DISPLAY Q(XYZ) CURDEPTH took about 60 seconds to complete, but it did report all 35008 messages. 10. started the channel and away went all 35008 messages to the other side. 11. Not believing it, I shutdown QM again 12. restored the 'Q' file again, 13 restarted QM and viola! all 35008 message are back again. 14. started channel again, all 35008 went across. This is while running MQSeries 2.2.1 for VAX/VMS. Now, get this!! this same technique worked on MQSeries 5.1 for Windows NT4. Yup, now I also replay 35000 messages through my target application without having to go through the channel. I never would have though this to work, given everything I've read and the opinions of others that all persistent messages are backed in the log files and not in the 'Q' files. I was surprised I did not receive a single response from anyway in IBM saying "You can't do that", or "it doesn't work that way". Thanks for all the responses. Dave Awerbuch - original message - Date: Wed, 8 May 2002 12:13:38 -0400 From: "Robert Broderick" <[EMAIL PROTECTED]> Subject: Re: Saving contents of a queue. Dave, R u using Circular or lin logging. You can also see where I am going with this. If it's lin you maybe able to use the record image and restore object from image commands. This will certainly move you into an area of log file overhead BUT...it may restore the objects faster than 5 hours. Also there is a timing thing here to be considered. (you know, what does the queue look like now as opposed to when I want the queue restored) I am not really sure this may work for you but I'd figure I'd throw it into the soup to see if it added some taste!! bobbee in Georgia >From: David Awerbuch <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Saving contents of a queue. >Date: Wed, 8 May 2002 06:15:42 -0700 > >Hello, > >I am running MQSeries 2.2.1.1 on Vax VMS 6.2. I have a queue with 35000 >messages, that took 5 hours to setup, for a stress test. In order to avoid >this 5 hour expense every time I want to run the stress test, I would like >to >save the queue contents for later restoration. All my messages are >persistent. > >Can I simply save a copy of the queue's 'Q' file (59MB), then when I need >it >copy it back and restart the queue manager? > >Or do I need to perform some other hocus-pocus to achieve the same? > >Please be sure to CC: your response
Re: FW: Starting Broker
Joe, 5.3 GA's at the end of June. Andy. "Jodl, Joe R" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/09/2002 09:34:54 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: FW: Starting Broker Thanks Andy I will just use the naming of TST.PRD for now till we move to 5.3 What is the status of MQ 5.3? Thanks again. -----Original Message- From: Andrew Hickson [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 09, 2002 1:48 PM To: [EMAIL PROTECTED] Subject: Re: FW: Starting Broker Joe, I'm afraid that this is a real bug. MQCONN tries to guess where the queue manager is located to avoid having to read mqs.ini to discover the prefix. When the name has a "." in it then it doesn't pull this trick as it can see that it has to read mqs.ini to find out how the "." has been translated. The broker is a special application that has already read mqs.ini and performed much of the initialization performed by MQCONN, but MQCONN still guesses the queue manager prefix it gets it wrong, but because much of the initialization has already been performed the check to see if the guess was good doesn't fail in the way it should and MQCONN then attempts to use the wrong prefix and fails in a way the broker does not expect. I've raised an internal defect which should be fixed in 5.3, I'm afraid that if you want a fix on an earlier release then you'll need to contact the support center. Sorry Andy. "Jodl, Joe R" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/09/2002 06:39:06 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:FW: Starting Broker FYI ... I found that if I name the Qmgr with a '.' in the name it works. If I have the qmgr named without I get the not active message. TEST.QMGR works TESTQMGRDoesn't -Original Message- From: Jodl, Joe R Sent: Wednesday, May 08, 2002 3:10 PM To: MQ List server questions (E-mail) Subject: Starting Broker I am running MQ version 5.2 on Unix Solaris 8. Our systems group wants to use a different filesystem instead of /var/mqm for the logging and the Qmgr info. I reviewed the documentation relating to this (7.0 Configuration Files) and moved the created Qmgr files to the new filesystem. Before doing this I did start mq and the broker without any problems. I then stopped everything and move the directories. When I tryed to bring things up the qmgr starts fine along with the command server but I get the following error when trying to start the message broker: $ strmqbrk -m TEST.QMGR MQSeries message broker for queue manager TEST.QMGR not active. I couldn't find anything in the logs related to this. Any ideas will be much appreciated. Thanks in advance Joe 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: Version Number
In general the default version numbers are set to 1 so that a simple recompile of the app, or a part of the app, should not cause the application behaviour to change or cause the queue manager to refer to fields in the structure which may not be initialized, or even allocated in memory. For example, on the distributed platforms, a message put with a V1 MQMD is not subject to the queue manager checking the validity of the MQ headers in the payload, while a message put with a V2 MQMD is subject to the queue manager checking the validity of the MQ headers in the payload. At V5.0 (when the MQMD V2) was introduced we decided that it was better to discover an invalid header at the point the bad message entered the MQ network, rather than when the data was used, and added this checking. To ensure compatibility we only enabled the checking if the version number was 2, thus ensuring compatibility with all existing apps even if they were recompiled. Andy. "Kasischke, Bob" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/09/2002 10:27:06 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Version Number I think the answer is ... because. IBM just decided to set it to 1. I know the C API does the same thing. Now the Java Client (MA88) on the other hand sets all versions to 2. Why 2? I couldn't find anything in the pubs that describes why they use 2 and of course it leads to great confusion when things work with C clients and not with Java Clients. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 08, 2002 1:29 PM To: [EMAIL PROTECTED] Subject: Version Number OK Two dollar question here. OS390 MQ v 5.2 The CMQV has upwards of version 3 available for the MQOD. Why does the CMQODV copybook have a default vaule of version one (1) specified. Is this because of downward compatability (or something) or has the wrong copybook been installed or must you force (which is what we did) the version number to open up the additional functionality? bobbee _ Chat with friends online, try MSN Messenger: http://messenger.msn.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 *** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. 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: Log files
Lizette, You can change the number of log files after a queue manager has been created, but the log file size is fixed at queue manager creation. While the 2003 could be due to too small a log it is also possible that it is due to a poorly written app. Have you ensured that the application suffering from the 2003 is working as designed, and in particular is calling MQCMIT when it should ? Andy. "Anderson, Lizette T. (RyTull)" <[EMAIL PROTECTED]> @AKH-WIEN.AC.AT> on 05/09/2002 11:57:30 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Log files I changed the log size in services and stopped and restarted the server. The log files did not increase. Does anyone have an idea? -Original Message- From: Day, Stan [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 09, 2002 2:01 PM To: [EMAIL PROTECTED] Subject: Re: Log files If they haven't changed the interface betweent NT4 and W2K, from the Start menu go into IBM MQSeries, then MQSeries Services. Right click the queue manager, click Properties and select the Log tab. This is where you manage the number of log files. If I'm not mistaken, you'll have to stop and restart the queue manager for the changes to become active. -Original Message- From: Anderson, Lizette T. (RyTull) [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 09, 2002 1:55 PM To: [EMAIL PROTECTED] Subject: Re: Log files I will increase the number of logs. Is there a general rule? Also I am running 5.2 MQSERIES FOR Windows and there does not seem to be a MQS.INI. Where can I add logs? -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 09, 2002 1:39 PM To: [EMAIL PROTECTED] Subject: Re: Log files If I remember correctly, you can increase the number of logs but not the size of the logs. I believe you need to delete and create the queue manager. At one point I was about to attempt to create a queue manager with larger logs and then copy the old logs to the new logs, switch the logs between the managers and restart the old queue manager. I never got to try this or think it all the way through. BUT..unless someone else has information it may be worth a try. Of course you need to try this on the side first! bobbee >From: "Anderson, Lizette T. (RyTull)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Log files >Date: Thu, 9 May 2002 13:00:42 -0500 > >I am only familiar with log files on OS/390 and I may have a problem with >the log file on a Windows 2000 server. Can anyone direct me to >documentation or instructions on how to increase the size of an MQ log on >Windows 2000? We are getting a 2003 error message on an MQGET and it seems >to point to a log problem. > > >--- Legal Disclaimer: The information contained in this communication may >be >confidential, is intended only for the use of the recipient named above, >and >may be legally privileged. If the reader of this message is not the >intended recipient, you are hereby notified that any dissemination, >distribution, or copying of this communication, or any of its contents, is >strictly prohibited. If you have received this communication in error, >please re-send this communication to the sender and delete the original >message and any copy of it from your computer system. Thank you. --- > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx 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 --- Legal Disclaimer: The information contained in this communication may be confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message and any copy of it from your computer system. Thank you. --- Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.
Re: FW: Starting Broker
Joe, I'm afraid that this is a real bug. MQCONN tries to guess where the queue manager is located to avoid having to read mqs.ini to discover the prefix. When the name has a "." in it then it doesn't pull this trick as it can see that it has to read mqs.ini to find out how the "." has been translated. The broker is a special application that has already read mqs.ini and performed much of the initialization performed by MQCONN, but MQCONN still guesses the queue manager prefix it gets it wrong, but because much of the initialization has already been performed the check to see if the guess was good doesn't fail in the way it should and MQCONN then attempts to use the wrong prefix and fails in a way the broker does not expect. I've raised an internal defect which should be fixed in 5.3, I'm afraid that if you want a fix on an earlier release then you'll need to contact the support center. Sorry Andy. "Jodl, Joe R" <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/09/2002 06:39:06 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:FW: Starting Broker FYI ... I found that if I name the Qmgr with a '.' in the name it works. If I have the qmgr named without I get the not active message. TEST.QMGR works TESTQMGRDoesn't -Original Message- From: Jodl, Joe R Sent: Wednesday, May 08, 2002 3:10 PM To: MQ List server questions (E-mail) Subject: Starting Broker I am running MQ version 5.2 on Unix Solaris 8. Our systems group wants to use a different filesystem instead of /var/mqm for the logging and the Qmgr info. I reviewed the documentation relating to this (7.0 Configuration Files) and moved the created Qmgr files to the new filesystem. Before doing this I did start mq and the broker without any problems. I then stopped everything and move the directories. When I tryed to bring things up the qmgr starts fine along with the command server but I get the following error when trying to start the message broker: $ strmqbrk -m TEST.QMGR MQSeries message broker for queue manager TEST.QMGR not active. I couldn't find anything in the logs related to this. Any ideas will be much appreciated. Thanks in advance Joe 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 using C++..doubt
On the distributed platforms it is a really bad idea to issue an MQGET with a very big buffer unless you expect to receive a really big message. It is good practice for performance sensitive applications to track the message sizes and dynamically resize the buffer as appropriate. For messages below about 8K this isn't necessary. Andy. Kevin Tobin/Australia/IBM@[EMAIL PROTECTED]> on 05/07/2002 08:53:22 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: MQSeries using C++..doubt One trick that I know of - Issue an MQGET with a buffer length of zero - MQ will fail the MQGET but the API returns how big the message is - This allows you to create the buffer and then re issue the read..this time with the right message size. You can also consider creating a buffer that is the same as the maximum message size for the queue - depending on resources of your server using MQINQ to get the maximum message size. The latter is faster since there is less memory management and API calling . Just some thoughts Kevin N Vinodh <[EMAIL PROTECTED] To: .IN>[EMAIL PROTECTED] Sent by: MQSeries List cc: <[EMAIL PROTECTED] Subject: MQseriies T> using C++..doubt 07/05/2002 05:16 PM Please respond to MQSeries List hi I want to GET messages from queues. The message size is not known earlier. Is there any method in C++ for MQSeries which will increase or decrease the buffer size after doing the GET call. even if we do a MALLOC we must know the message size prior doing the GET call. My requirement is that message is not known at all. Only thing is the message size shoud not exceed 4 MB as i am using MQseres 2.1 on OS/390. Can any one give me a sample C++ program which does this?? Thanx in advance. Vinodh 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: 2059 Intermittent Error
Jeff, Are your apps using the server or the client bindings ? What do you mean by " The queue manager has maximum threads set at 256" ? Using the server bindings there's scope for some contention during high connect rates, but while that might cause some of your connects to slow down it would not cause a 2059. Thanks Andy. Jeffrey Ross <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 05/03/2002 03:46:22 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:2059 Intermittent Error Hello, I am getting this strange error and I am hoping that the theory behind it is true. Maybe somebody out here has experienced this. I have an application team running AIX 4.3.3, MQ 5.2. The queue manager has maximum threads set at 256. Fifty instances of a program, all hitting one queue, are fired off at once. At the same time, another program, for each putting, is fired off getting the messages off of the queue. Every now and then, for one of the 50 putting the message on, a 2059 error comes back. That error is Queue Manager Not Available. For example, application instance 32 comes back with the 2059, instance 33, 34, 35 process fine. Instance 36 comes back with a 2059. These instance numbers are examples because there is no pattern to it. If the application only does 40, instead of 50, it works without the 2059. It sounds like there is contention for the queue manager while attempting the MQCONN. The thing that confuses me is that only a maximum of 100 applications are hitting the queue manager at one time. There are no other applications running against this queue manager. Has anybody ever seen anything similar to this before or have I totally confused everyone? Thanks, Jeff Jeffrey D. Ross Certified IBM WebSphere MQ Specialist TransUnion, LLC Tel 312 985 2742 Fax 312 466 7997 Nextel 312 296 0904 [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. 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
