Re: MQRC_BACKED_OUT
** Note: This e-mail is subject to the disclaimer contained at the bottom of this message. ** : That is a lot of log to fill up! Is there a chance that there is a running application with a curent uncompleted UOW that has been hanging around for a while...in a loop or just stuck? : The information transmitted in this message and attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of CGU Insurance. This message has been scanned for viruses and cleared by MailMarshal. : 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: MQRC_BACKED_OUT
Hi Graham, AMQ7469 Transactions rolled back to release log space Explanation: The log space for the queue manager is becoming full. One or more long-running transactions have been rolled back to release log space so that the queue manager can continue to process requests. User Response: Try to ensure that the duration of your transactions is not excessive. Consider increasing the size of the log to allow transactions to last longer before the log starts to become full. Emile Kearns SOFTWARE FUTURES the business advantage Proud member of MGX www.softwarefutures.com -Original Message- From: Graham Lekota [mailto:[EMAIL PROTECTED]] Sent: 14 August 2002 05:08 To: [EMAIL PROTECTED] Subject: MQRC_BACKED_OUT I am running a job that sends persistant messages to three remote queues(sequentially). The queues are triggered. The application that reads from the first queue gets triggered soon after all messages(3079) are succesfully put on the queue. The application crushes after reading less than 200 messages(each message is 800KB) with return code 2003(MQRC_BACKED_OUT, AMQ7469: Transactions rolled back to release log space). In fact the last time it crushed it only read 29 messages(thats less than 23MB). The application commits a unit of work after 200 messages. Available hard drive space = 578855MB, Contents of qm.ini file: log: LogPrimaryFiles=50 LogSecondaryFiles=12 LogFilePages=16384 LogType=CIRCULAR LogBufferPages=30 LogPath=/var/mqm/log/LMD1UPAP/ :-( *** This message may contain information which is confidential and subject to legal privilege. If you are not the intended recipient, you may not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify the sender immediately by email, facsimile or telephone and return and/or destroy the original message. *** 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
Todd Carlisle is out of the office.
I will be out of the office starting 08/14/2002 and will not return until 08/26/2002. I will respond to your message when I return. 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
Channels not to be seen in MQ explorer on NT .
Hi, We are facing a problem in with channels in the MQ explorer (WIN NT) .Unable to see the channels there. But using MQMonitor we can see the channels. DISPLAY channel from DOS is working fine and displays all the channels. The error shown on the explorer is "AMQ4082" RC 2136 Has anybody experienced this before ? Any help regarding this error is much appreciated ! Thanks a lot in advance ! Regards Puneet NOTICE: This communication is meant only for the addressee(s) named above and may contain information which is confidential and/or legally privileged. If you are not the named addressee(s), or the agent responsible for receiving and delivering this communication to the named addressee(s), this communication has been sent to you in error. If so, kindly notify the sender and delete the information immediately. Unauthorised dissemination, distribution, copying or reliance on this communication is prohibited and may attract criminal penalties. 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
NT Userid for triggered executables
I have a question regarding security for MQSeries V5.2 on Windows NT that I think may apply to other platforms as well. When MQSeries initiates a process in response to a trigger event, that process runs under a certain userid (e.g., MUSER_MQADMIN under NT). The problem is, every triggered executable will run under the same id. This makes it difficult to grant put/get permissions on queues, as there is no way to distinguish the executables that will be doing the getting/putting. I want to allow some executables to PUT to queue A, and others to PUT to queue B, etc, but I don't see how. IBM sent me a utility - INTLAUNCH - that can be configured with DCOMCNFG to start applications under one further userid, but that's apparently as far as it goes. I'm wondering whether anyone has encountered a similar situation, and if there is a solution short of writing custom trigger monitors. Thanks in advance for your collective expertise! John J Dodd Deutsche Bank Trust Company Americas Corporate Trust & Agency Services Technology 100 Plaza One -- MS# JCY03 - 0605 Jersey City, NJ 07311 Phone: 201-593-6652 Cell: 917-647-1340 Pager: 800-225-0256/pin#9178026157 -- 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 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: Lost MQ message (They are fast and nonpersistent)
Hi Peter, For the channel related problems: In OS/390: When I was working in OS/390, I don't remember the exact name but I think I would look at the job named MQxxCHIN (as far as I remember, in your test env. it is called MQ2TCHIN... Phil would know). In the distrib. environment: Error logs... Hope this helps. Ruzi --- "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> wrote: > I don't think so. Many other applications are using > it with no problems, > including this app, where 99% of the messages make > it ok. > > Any way to tell that the channel had temp problems > and/or discarded a > message after the fact? > > > Peter Potkay > IBM MQSeries Certified Specialist, Developer > [EMAIL PROTECTED] > X 77906 > > > -Original Message- > From: Ruzi R [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 14, 2002 3:11 PM > To: [EMAIL PROTECTED] > Subject: Re: Lost MQ message (They are fast and > nonpersistent) > > > And there were no problems with those "fast" > channels > when the messages were lost? > > Ruzi > > > --- "Potkay, Peter M (PLC, IT)" > <[EMAIL PROTECTED]> wrote: > > Nope it's copied from the request, which set it to > 3 > > days. > > > > The log file confirms that the reply is being put > > with this large value. > > > > > > Peter Potkay > > IBM MQSeries Certified Specialist, Developer > > [EMAIL PROTECTED] > > X 77906 > > > > > > -Original Message- > > From: DiLauro, Nick [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, August 14, 2002 1:25 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Lost MQ message (They are fast and > > nonpersistent) > > > > > > The reply could also be lost anywhere along the > > route if the expiry time has > > been exhausted. Is this a possibility? > > > > -Original Message- > > From: Potkay, Peter M (PLC, IT) > > [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, August 14, 2002 10:02 AM > > To: [EMAIL PROTECTED] > > Subject: Lost MQ message (They are fast and > > nonpersistent) > > > > > > My customer's application is losing an occasional > > message and I can't figure > > out why. Maybe someone has something else I can > look > > at. > > > > VB app client connects to QM1 to put a > nonpersistent > > request message to a > > remote queue pointing to Queue1 on QM2. Put is > > outside of syncpoint and the > > Expiry is 3 days. > > > > Message is routed thru our Hub (QMHUB) and lands > on > > Queue1 on QM2. Queue1 is > > triggered on first and starts up a C program > running > > locally on the Unix > > Tru64 box housing QM2. The reply is built and put > to > > the > > ReplytoQueue/ReplytoQueueManager of the Request > > message. The Expiry of the > > reply is equal to the remaining Expiry of the > > request. The request is > > nonpersistent and outside of syncpoint. The > replying > > app has its internal > > logging turned on is outputting to a file the > MQPUT1 > > RC, the reply to info > > it used, the expiry, etc. > > > > 99% of the time everything is OK. But occasionally > > the requestor said it > > didn't get a reply. The reply queue has no > orphaned > > reply messages. The log > > for the replier says that it did receive the > request > > and did in fact put out > > the reply. But the message is gone. Not on the > reply > > queue, not on the DLQ > > or any XMIT queue on QM1, QM2 or QMHUB. > > > > Using MO71, I see via Queue statistics that the > > replier did get X messages > > put onto its request queue, and X messages were > > removed from the request > > queue. The replier confirms that they put X > > requests. The replier's log says > > they got X requests, and put X replies. The reply > > queue statistics however > > say that only X-1 messages were put to the queue > and > > X-1 messages were > > gotten from the queue. > > > > > > Where is this message disappearing to? The only > > thing I have left now is the > > fact that the channel from QM2 to QMHUB and from > > QMHUB to QM1 is defined as > > MQNPS_FAST. And the Intercommunications manual > says > > the following: > > > > > > > If a channel terminates while fast, nonpersistent > > messages are in transit, > > the messages may be lost and it is up to the > > application to arrange for > > their recovery if required. Similarly, if the > MQPUT > > by the receiving MCA > > fails for any reason, the messages are lost. > > > > > > > Could my message be getting tossed? How would I > know > > this is happening? > > > > > > > > Peter Potkay > > IBM MQSeries Certified Specialist, Developer > > [EMAIL PROTECTED] > > X 77906 > > > > > > > > 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 > > communicati
Re: Channel that always stays running
I read this thread with interest as we have had problems recently with a queue manager listener stopping unexpectedly at around 5AM. The listener is then automatically restarted in about a minute, but our client applications are then hung for up to 2 hours. After reading through the emails and looking up some of the docs it appeared that the keepalive function was working in some default flavor (restart in 1-2 hours). One thing I do not understand is why the heartbeat feature does not seem to work. These apps use CLNTCONN / SVRCONN channels and use MQGET with WAIT. The heartbeat interval is set to the default (300) which would be fine for these applications. Is there something else I need to do to enable this feature? Also, I would appreciate any guesses as to what would cause a listener to stop unexpectedly (it had been working without stops/restarts for many months until we started adding significantly more clients recently). Thanks Tom -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 13, 2002 7:11 AM To: [EMAIL PROTECTED] Subject:Re: Channel that always stays running Can I add my two cents worth about Heartbeats. There have been one or two slightly misleading comments about them which I think I ought to address. Heartbeats serve at least three purposes. 1/ They maintain contact with the receiver channel even when there are no messages to send. This allows the receiver channel to ask the sender channel to end (for example a STOP CHANNEL MODE(QUIESCE). So, if you issued a normal quiesce stop channel on a receiver and the channel wasn't moving any messages it may take up to the heartbeat interval before the channel actually ended. 2/ Since a heartbeat is only sent in relative inactivity the receiver channel will free its resources when it gets one. For example it will free off any excessive message storage and close its queue cache. 3/ It allows the receiver to predict when data should arrive down the socket. This is most pertinent to the current discussion of network outage. Without heartbeats a receiver channel can not predict when the next message will arrive from the sender since the sender has no clue either. However, with heartbeats enabled the receiver knows that either it will receive a heartbeat or a message within a known interval. Consequently the recveiver can issue a receiver with a timeout. If this receive does time out it means that something has gone seriously wrong. In an ideal world a network outage would cause the TCP/IP recv() call to return a nice return code however, as we all know, TCP/IP is notoriously bad at telling us about outages so this timeout is probably our best defence. I would still recommend that people use KEEPALIVE though since there are some cases, such as SVRCONN channels, where we can't use a timeout. One last point about the timeout. The timeout value used will be if (Heartbeat Value < 1 minute) Timeout = Heartbeat * 2 else Timeout = Heartbeat + 1 minute In other words we add a little contingency on the timeout for network latency. Heop this helps, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Lost MQ message (They are fast and nonpersistent)
I don't think so. Many other applications are using it with no problems, including this app, where 99% of the messages make it ok. Any way to tell that the channel had temp problems and/or discarded a message after the fact? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 14, 2002 3:11 PM To: [EMAIL PROTECTED] Subject: Re: Lost MQ message (They are fast and nonpersistent) And there were no problems with those "fast" channels when the messages were lost? Ruzi --- "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> wrote: > Nope it's copied from the request, which set it to 3 > days. > > The log file confirms that the reply is being put > with this large value. > > > Peter Potkay > IBM MQSeries Certified Specialist, Developer > [EMAIL PROTECTED] > X 77906 > > > -Original Message- > From: DiLauro, Nick [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 14, 2002 1:25 PM > To: [EMAIL PROTECTED] > Subject: Re: Lost MQ message (They are fast and > nonpersistent) > > > The reply could also be lost anywhere along the > route if the expiry time has > been exhausted. Is this a possibility? > > -Original Message- > From: Potkay, Peter M (PLC, IT) > [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 14, 2002 10:02 AM > To: [EMAIL PROTECTED] > Subject: Lost MQ message (They are fast and > nonpersistent) > > > My customer's application is losing an occasional > message and I can't figure > out why. Maybe someone has something else I can look > at. > > VB app client connects to QM1 to put a nonpersistent > request message to a > remote queue pointing to Queue1 on QM2. Put is > outside of syncpoint and the > Expiry is 3 days. > > Message is routed thru our Hub (QMHUB) and lands on > Queue1 on QM2. Queue1 is > triggered on first and starts up a C program running > locally on the Unix > Tru64 box housing QM2. The reply is built and put to > the > ReplytoQueue/ReplytoQueueManager of the Request > message. The Expiry of the > reply is equal to the remaining Expiry of the > request. The request is > nonpersistent and outside of syncpoint. The replying > app has its internal > logging turned on is outputting to a file the MQPUT1 > RC, the reply to info > it used, the expiry, etc. > > 99% of the time everything is OK. But occasionally > the requestor said it > didn't get a reply. The reply queue has no orphaned > reply messages. The log > for the replier says that it did receive the request > and did in fact put out > the reply. But the message is gone. Not on the reply > queue, not on the DLQ > or any XMIT queue on QM1, QM2 or QMHUB. > > Using MO71, I see via Queue statistics that the > replier did get X messages > put onto its request queue, and X messages were > removed from the request > queue. The replier confirms that they put X > requests. The replier's log says > they got X requests, and put X replies. The reply > queue statistics however > say that only X-1 messages were put to the queue and > X-1 messages were > gotten from the queue. > > > Where is this message disappearing to? The only > thing I have left now is the > fact that the channel from QM2 to QMHUB and from > QMHUB to QM1 is defined as > MQNPS_FAST. And the Intercommunications manual says > the following: > > > > If a channel terminates while fast, nonpersistent > messages are in transit, > the messages may be lost and it is up to the > application to arrange for > their recovery if required. Similarly, if the MQPUT > by the receiving MCA > fails for any reason, the messages are lost. > > > > Could my message be getting tossed? How would I know > this is happening? > > > > Peter Potkay > IBM MQSeries Certified Specialist, Developer > [EMAIL PROTECTED] > X 77906 > > > > This communication, including attachments, is for > the exclusive use of > addressee and may contain proprietary, confidential > or privileged > information. If you are not the intended recipient, > any use, copying, > disclosure, dissemination or distribution is > strictly prohibited. If > you are not the intended recipient, please notify > the sender > immediately by return email and delete this > communication and destroy all > copies. > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > 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 Listse
Re: Lost MQ message (They are fast and nonpersistent)
Nonpersistent messages and a NPMSPEED of FAST can result in lost messages. Greg Mabrito I/T Asct Sys Prgrmr IMS and MQ Software Support (210)913-3985 D-03-E IBM Certified Specialist - Websphere MQ The opinions herein are solely Greg's and are not necessarily the opinion of USAA. -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 14, 2002 2:11 PM To: [EMAIL PROTECTED] Subject: Re: Lost MQ message (They are fast and nonpersistent) And there were no problems with those "fast" channels when the messages were lost? Ruzi --- "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> wrote: > Nope it's copied from the request, which set it to 3 > days. > > The log file confirms that the reply is being put > with this large value. > > > Peter Potkay > IBM MQSeries Certified Specialist, Developer > [EMAIL PROTECTED] > X 77906 > > > -Original Message- > From: DiLauro, Nick [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 14, 2002 1:25 PM > To: [EMAIL PROTECTED] > Subject: Re: Lost MQ message (They are fast and > nonpersistent) > > > The reply could also be lost anywhere along the > route if the expiry time has > been exhausted. Is this a possibility? > > -Original Message- > From: Potkay, Peter M (PLC, IT) > [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 14, 2002 10:02 AM > To: [EMAIL PROTECTED] > Subject: Lost MQ message (They are fast and > nonpersistent) > > > My customer's application is losing an occasional > message and I can't figure > out why. Maybe someone has something else I can look > at. > > VB app client connects to QM1 to put a nonpersistent > request message to a > remote queue pointing to Queue1 on QM2. Put is > outside of syncpoint and the > Expiry is 3 days. > > Message is routed thru our Hub (QMHUB) and lands on > Queue1 on QM2. Queue1 is > triggered on first and starts up a C program running > locally on the Unix > Tru64 box housing QM2. The reply is built and put to > the > ReplytoQueue/ReplytoQueueManager of the Request > message. The Expiry of the > reply is equal to the remaining Expiry of the > request. The request is > nonpersistent and outside of syncpoint. The replying > app has its internal > logging turned on is outputting to a file the MQPUT1 > RC, the reply to info > it used, the expiry, etc. > > 99% of the time everything is OK. But occasionally > the requestor said it > didn't get a reply. The reply queue has no orphaned > reply messages. The log > for the replier says that it did receive the request > and did in fact put out > the reply. But the message is gone. Not on the reply > queue, not on the DLQ > or any XMIT queue on QM1, QM2 or QMHUB. > > Using MO71, I see via Queue statistics that the > replier did get X messages > put onto its request queue, and X messages were > removed from the request > queue. The replier confirms that they put X > requests. The replier's log says > they got X requests, and put X replies. The reply > queue statistics however > say that only X-1 messages were put to the queue and > X-1 messages were > gotten from the queue. > > > Where is this message disappearing to? The only > thing I have left now is the > fact that the channel from QM2 to QMHUB and from > QMHUB to QM1 is defined as > MQNPS_FAST. And the Intercommunications manual says > the following: > > > > If a channel terminates while fast, nonpersistent > messages are in transit, > the messages may be lost and it is up to the > application to arrange for > their recovery if required. Similarly, if the MQPUT > by the receiving MCA > fails for any reason, the messages are lost. > > > > Could my message be getting tossed? How would I know > this is happening? > > > > Peter Potkay > IBM MQSeries Certified Specialist, Developer > [EMAIL PROTECTED] > X 77906 > > > > This communication, including attachments, is for > the exclusive use of > addressee and may contain proprietary, confidential > or privileged > information. If you are not the intended recipient, > any use, copying, > disclosure, dissemination or distribution is > strictly prohibited. If > you are not the intended recipient, please notify > the sender > immediately by return email and delete this > communication and destroy all > copies. > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > 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 availa
MQSeries 5.2.1 installed on Domain Controller?
The problem we are having is, during the installation of IBM MQ Series 5.2.1 during the preparation wizard, right after it starts services it gives an error msg. The Error msg is in a normal install window. It says: "MQ Series configuration problem, MQSeries is not correctly configured for windows 2000 domain users" It goes on to say "An unexpected error has occurred while validating the security credentials of user 'KNDM06\GmaTech'. Ensure that the network is operational, and that all required domain controllers are available." After I get that error a message box pops up and says: "The process cannot switch to the startup current directory c:\WINNT\system32. Select OK to set Current directory to c:\WINNT or select Cancel to exit." This message pops up ever 5 mins or so even after the installation is exited and system is rebooted. We have tried installing CSD-04 and still have the same problem. The system this is getting installed on is running windows NT 4 Server. The computer is setup as a BDC, the user appears to be in the Administrator group. We have never installed MQ Series on a PDC or BDC and wasn't sure if there was certain rights account have to have setup, or even if MQ can be installed on a PDC or BDC. It appears that after the account is installed the service can't run or won t run. But the second error does not indicate an error that has to do with the user the services is running as. Does any one have any ideas? Thanks, Donovan -- __ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup 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
BIP0068E An unexpected exception occurred: java.lang.NullPointerException
We are getting this error while trying to check in a newly created message flow. BIP0068E An unexpected exception occurred: java.lang.NullPointerException. A java.lang.NullPointerException exception occurred but provided no additional information. Turn on Control Center tracing to capture details of the error. Retry the operation and contact you IBM support center. Kraig P. Stumo Hartford Life 763-765-4727 [EMAIL PROTECTED] * 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
Re: Lost MQ message (They are fast and nonpersistent)
And there were no problems with those "fast" channels when the messages were lost? Ruzi --- "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> wrote: > Nope it's copied from the request, which set it to 3 > days. > > The log file confirms that the reply is being put > with this large value. > > > Peter Potkay > IBM MQSeries Certified Specialist, Developer > [EMAIL PROTECTED] > X 77906 > > > -Original Message- > From: DiLauro, Nick [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 14, 2002 1:25 PM > To: [EMAIL PROTECTED] > Subject: Re: Lost MQ message (They are fast and > nonpersistent) > > > The reply could also be lost anywhere along the > route if the expiry time has > been exhausted. Is this a possibility? > > -Original Message- > From: Potkay, Peter M (PLC, IT) > [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 14, 2002 10:02 AM > To: [EMAIL PROTECTED] > Subject: Lost MQ message (They are fast and > nonpersistent) > > > My customer's application is losing an occasional > message and I can't figure > out why. Maybe someone has something else I can look > at. > > VB app client connects to QM1 to put a nonpersistent > request message to a > remote queue pointing to Queue1 on QM2. Put is > outside of syncpoint and the > Expiry is 3 days. > > Message is routed thru our Hub (QMHUB) and lands on > Queue1 on QM2. Queue1 is > triggered on first and starts up a C program running > locally on the Unix > Tru64 box housing QM2. The reply is built and put to > the > ReplytoQueue/ReplytoQueueManager of the Request > message. The Expiry of the > reply is equal to the remaining Expiry of the > request. The request is > nonpersistent and outside of syncpoint. The replying > app has its internal > logging turned on is outputting to a file the MQPUT1 > RC, the reply to info > it used, the expiry, etc. > > 99% of the time everything is OK. But occasionally > the requestor said it > didn't get a reply. The reply queue has no orphaned > reply messages. The log > for the replier says that it did receive the request > and did in fact put out > the reply. But the message is gone. Not on the reply > queue, not on the DLQ > or any XMIT queue on QM1, QM2 or QMHUB. > > Using MO71, I see via Queue statistics that the > replier did get X messages > put onto its request queue, and X messages were > removed from the request > queue. The replier confirms that they put X > requests. The replier's log says > they got X requests, and put X replies. The reply > queue statistics however > say that only X-1 messages were put to the queue and > X-1 messages were > gotten from the queue. > > > Where is this message disappearing to? The only > thing I have left now is the > fact that the channel from QM2 to QMHUB and from > QMHUB to QM1 is defined as > MQNPS_FAST. And the Intercommunications manual says > the following: > > > > If a channel terminates while fast, nonpersistent > messages are in transit, > the messages may be lost and it is up to the > application to arrange for > their recovery if required. Similarly, if the MQPUT > by the receiving MCA > fails for any reason, the messages are lost. > > > > Could my message be getting tossed? How would I know > this is happening? > > > > Peter Potkay > IBM MQSeries Certified Specialist, Developer > [EMAIL PROTECTED] > X 77906 > > > > This communication, including attachments, is for > the exclusive use of > addressee and may contain proprietary, confidential > or privileged > information. If you are not the intended recipient, > any use, copying, > disclosure, dissemination or distribution is > strictly prohibited. If > you are not the intended recipient, please notify > the sender > immediately by return email and delete this > communication and destroy all > copies. > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > 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: Lost MQ message (They are fast and nonpersistent)
Nope it's copied from the request, which set it to 3 days. The log file confirms that the reply is being put with this large value. Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -Original Message- From: DiLauro, Nick [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 14, 2002 1:25 PM To: [EMAIL PROTECTED] Subject: Re: Lost MQ message (They are fast and nonpersistent) The reply could also be lost anywhere along the route if the expiry time has been exhausted. Is this a possibility? -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 14, 2002 10:02 AM To: [EMAIL PROTECTED] Subject: Lost MQ message (They are fast and nonpersistent) My customer's application is losing an occasional message and I can't figure out why. Maybe someone has something else I can look at. VB app client connects to QM1 to put a nonpersistent request message to a remote queue pointing to Queue1 on QM2. Put is outside of syncpoint and the Expiry is 3 days. Message is routed thru our Hub (QMHUB) and lands on Queue1 on QM2. Queue1 is triggered on first and starts up a C program running locally on the Unix Tru64 box housing QM2. The reply is built and put to the ReplytoQueue/ReplytoQueueManager of the Request message. The Expiry of the reply is equal to the remaining Expiry of the request. The request is nonpersistent and outside of syncpoint. The replying app has its internal logging turned on is outputting to a file the MQPUT1 RC, the reply to info it used, the expiry, etc. 99% of the time everything is OK. But occasionally the requestor said it didn't get a reply. The reply queue has no orphaned reply messages. The log for the replier says that it did receive the request and did in fact put out the reply. But the message is gone. Not on the reply queue, not on the DLQ or any XMIT queue on QM1, QM2 or QMHUB. Using MO71, I see via Queue statistics that the replier did get X messages put onto its request queue, and X messages were removed from the request queue. The replier confirms that they put X requests. The replier's log says they got X requests, and put X replies. The reply queue statistics however say that only X-1 messages were put to the queue and X-1 messages were gotten from the queue. Where is this message disappearing to? The only thing I have left now is the fact that the channel from QM2 to QMHUB and from QMHUB to QM1 is defined as MQNPS_FAST. And the Intercommunications manual says the following: > If a channel terminates while fast, nonpersistent messages are in transit, the messages may be lost and it is up to the application to arrange for their recovery if required. Similarly, if the MQPUT by the receiving MCA fails for any reason, the messages are lost. > Could my message be getting tossed? How would I know this is happening? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Lost MQ message (They are fast and nonpersistent)
The reply could also be lost anywhere along the route if the expiry time has been exhausted. Is this a possibility? -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 14, 2002 10:02 AM To: [EMAIL PROTECTED] Subject: Lost MQ message (They are fast and nonpersistent) My customer's application is losing an occasional message and I can't figure out why. Maybe someone has something else I can look at. VB app client connects to QM1 to put a nonpersistent request message to a remote queue pointing to Queue1 on QM2. Put is outside of syncpoint and the Expiry is 3 days. Message is routed thru our Hub (QMHUB) and lands on Queue1 on QM2. Queue1 is triggered on first and starts up a C program running locally on the Unix Tru64 box housing QM2. The reply is built and put to the ReplytoQueue/ReplytoQueueManager of the Request message. The Expiry of the reply is equal to the remaining Expiry of the request. The request is nonpersistent and outside of syncpoint. The replying app has its internal logging turned on is outputting to a file the MQPUT1 RC, the reply to info it used, the expiry, etc. 99% of the time everything is OK. But occasionally the requestor said it didn't get a reply. The reply queue has no orphaned reply messages. The log for the replier says that it did receive the request and did in fact put out the reply. But the message is gone. Not on the reply queue, not on the DLQ or any XMIT queue on QM1, QM2 or QMHUB. Using MO71, I see via Queue statistics that the replier did get X messages put onto its request queue, and X messages were removed from the request queue. The replier confirms that they put X requests. The replier's log says they got X requests, and put X replies. The reply queue statistics however say that only X-1 messages were put to the queue and X-1 messages were gotten from the queue. Where is this message disappearing to? The only thing I have left now is the fact that the channel from QM2 to QMHUB and from QMHUB to QM1 is defined as MQNPS_FAST. And the Intercommunications manual says the following: > If a channel terminates while fast, nonpersistent messages are in transit, the messages may be lost and it is up to the application to arrange for their recovery if required. Similarly, if the MQPUT by the receiving MCA fails for any reason, the messages are lost. > Could my message be getting tossed? How would I know this is happening? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Lost MQ message (They are fast and nonpersistent)
My customer's application is losing an occasional message and I can't figure out why. Maybe someone has something else I can look at. VB app client connects to QM1 to put a nonpersistent request message to a remote queue pointing to Queue1 on QM2. Put is outside of syncpoint and the Expiry is 3 days. Message is routed thru our Hub (QMHUB) and lands on Queue1 on QM2. Queue1 is triggered on first and starts up a C program running locally on the Unix Tru64 box housing QM2. The reply is built and put to the ReplytoQueue/ReplytoQueueManager of the Request message. The Expiry of the reply is equal to the remaining Expiry of the request. The request is nonpersistent and outside of syncpoint. The replying app has its internal logging turned on is outputting to a file the MQPUT1 RC, the reply to info it used, the expiry, etc. 99% of the time everything is OK. But occasionally the requestor said it didn't get a reply. The reply queue has no orphaned reply messages. The log for the replier says that it did receive the request and did in fact put out the reply. But the message is gone. Not on the reply queue, not on the DLQ or any XMIT queue on QM1, QM2 or QMHUB. Using MO71, I see via Queue statistics that the replier did get X messages put onto its request queue, and X messages were removed from the request queue. The replier confirms that they put X requests. The replier's log says they got X requests, and put X replies. The reply queue statistics however say that only X-1 messages were put to the queue and X-1 messages were gotten from the queue. Where is this message disappearing to? The only thing I have left now is the fact that the channel from QM2 to QMHUB and from QMHUB to QM1 is defined as MQNPS_FAST. And the Intercommunications manual says the following: > If a channel terminates while fast, nonpersistent messages are in transit, the messages may be lost and it is up to the application to arrange for their recovery if required. Similarly, if the MQPUT by the receiving MCA fails for any reason, the messages are lost. > Could my message be getting tossed? How would I know this is happening? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Tool for Browsing MQ Queues?
Hi, I have written a program called MQ Visual Edit. It is written in Java, hence, it can run on many platforms. I am currently running a beta at version 0.2. On the weekend, I will be packaging beta v0.3 and it will include editing (String editing and hex editing). Note: Recognizing XML and editing in an XML format will be included in a future release. You can download it from: http://www.capitalware.biz/beta.html Note: I will make an announcement on the MQ ListServer when v0.3 is available for download. later Roger... Quoting "Flothmann, Eleonore" <[EMAIL PROTECTED]>: > Hi, > > we are looking for a tool to browse mq queues. A special requirement is: in > addition to simply show the messages in hex of string format this tool > should be able to understand XML. If a message is in XML format the message > should be presented in the appropriate XML presentation. > > Any idea? > > Regards > Eleonore > > > - This mail sent through IMP: http://horde.org/imp/ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
MQ Certification - 095 - Questions ...
Hello! I am preparing for the 095 certification. I have already seen the sample questionnaire in IBM website. I wonder if there are any other sample questions around? Or any comprehensive list of questions? May be, those who have already faced it, can chip in few questions they can recollect. I promise to compose all of them, and post it back on here. thank you all. -Mary __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.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
MSI Silent Install question
When installing MQ 5.3 on Win2000, using the Microsoft Software Installer, I am using the silent install mode - i.e. using a response.ini file. In the response file, does the KEEPMQDATA parameter override the LOGFOLDER parameter? I tried to change the location of the log folder by using the LOGFOLDER parameter, but I also used the KEEPMQDATA parm because I wanted to keep the existing MQ object definitions and attributes. My old location was d:\MQSeries\data\log, and I specified d:\MQSeries\log in the LOGFOLDER parm, but, although the install was successful, the log folder did not change. Is this the correct behavior? If so, is the only way to move the log folder to completely uninstall and re-install? Can I still keep my object definitions? (I think I could, they are in a different area). Or I could update the Registry... but that makes me nervous. PS everything is on the same drive because all non-Microsoft software has been banned from the C drive. TIA Peter 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: C++ Foundation Classes
Title: C++ Foundation Classes Pieter - No, if connectively is lost sometime between the internal MQCONN call and the MQPUT call, you will get back an appropriate error message - 2002? - but the classes will not attempt to redrive the put call. - Steve -Original Message-From: Voges, P. (Pieter) [mailto:[EMAIL PROTECTED]]Sent: Tuesday, August 13, 2002 10:45 PMTo: [EMAIL PROTECTED]Subject: C++ Foundation Classes Hi Everyone I got an interesting question from the development team. It comes down to an application running on a Nt Box written in C++ using the mq-client libraries connecting to a QMGR on a Unix AIX Box. The question is whether or not there are build-in error handling in the C++ Foundation classes to cater for loss of connectivity (either network or the QMGR going down). Example - if you do a put to a queue on a qmgr which the client lost connectivity to, will this be handled automatically or will he keep on trying to put infinitaly regardless of the lost connectivity. (Will the classes try to restore the connectivity and how?) Any info will be appreciated Pieter Voges MQ Support Nedcor Bank Limited -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED]] Sent: 13 August 2002 02:11 To: [EMAIL PROTECTED] Subject: Re: Channel that always stays running Can I add my two cents worth about Heartbeats. There have been one or two slightly misleading comments about them which I think I ought to address. Heartbeats serve at least three purposes. 1/ They maintain contact with the receiver channel even when there are no messages to send. This allows the receiver channel to ask the sender channel to end (for example a STOP CHANNEL MODE(QUIESCE). So, if you issued a normal quiesce stop channel on a receiver and the channel wasn't moving any messages it may take up to the heartbeat interval before the channel actually ended. 2/ Since a heartbeat is only sent in relative inactivity the receiver channel will free its resources when it gets one. For example it will free off any excessive message storage and close its queue cache. 3/ It allows the receiver to predict when data should arrive down the socket. This is most pertinent to the current discussion of network outage. Without heartbeats a receiver channel can not predict when the next message will arrive from the sender since the sender has no clue either. However, with heartbeats enabled the receiver knows that either it will receive a heartbeat or a message within a known interval. Consequently the recveiver can issue a receiver with a timeout. If this receive does time out it means that something has gone seriously wrong. In an ideal world a network outage would cause the TCP/IP recv() call to return a nice return code however, as we all know, TCP/IP is notoriously bad at telling us about outages so this timeout is probably our best defence. I would still recommend that people use KEEPALIVE though since there are some cases, such as SVRCONN channels, where we can't use a timeout. One last point about the timeout. The timeout value used will be if (Heartbeat Value < 1 minute) Timeout = Heartbeat * 2 else Timeout = Heartbeat + 1 minute In other words we add a little contingency on the timeout for network latency. Heop this helps, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Peek Messages With a Given CorrID
Palavesam: Thanks for the input. Looks like I have a way to get message based on Broswer option and Match CorrID option. Can I get all my messages (belong to a given user ID)? Thanks. Jerry Palavesam_Subbiah <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on 08/13/2002 11:17:18 PM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: Peek Messages With a Given CorrID Hi Jerry, Your questions is: "how can I peek (without get, since get will remove the message from the Q) all messages for the user?" Answer: To browse the msg related specific user, Use MQGET with Browse option and match CorrID option and set the user ID into the CorrelID field of the MQMD struct used for MQGET. Rgds, Palavesam.S -Original Message- From: Jiede J Yang [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 14, 2002 4:43 AM To: [EMAIL PROTECTED] Subject: Peek Messages With a Given CorrID Importance: High All: There is 1 queue involved. Server side puts messages to the Q with a corrID as the user login ID. All messages for a given user will have the same corrID which is the user login ID. Client side will peek on the messages and put into a UI list or tree. The questions is: how can I peek (without get, since get will remove the message from the Q) all messages for the user? Thanks for your input. Jerry [EMAIL PROTECTED] Cell: (626) 524 - 2554 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ** 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
MQRC_BACKED_OUT
I am running a job that sends persistant messages to three remote queues(sequentially). The queues are triggered. The application that reads from the first queue gets triggered soon after all messages(3079) are succesfully put on the queue. The application crushes after reading less than 200 messages(each message is 800KB) with return code 2003(MQRC_BACKED_OUT, AMQ7469: Transactions rolled back to release log space). In fact the last time it crushed it only read 29 messages(thats less than 23MB). The application commits a unit of work after 200 messages. Available hard drive space = 578855MB, Contents of qm.ini file: log: LogPrimaryFiles=50 LogSecondaryFiles=12 LogFilePages=16384 LogType=CIRCULAR LogBufferPages=30 LogPath=/var/mqm/log/LMD1UPAP/ :-( *** This message may contain information which is confidential and subject to legal privilege. If you are not the intended recipient, you may not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify the sender immediately by email, facsimile or telephone and return and/or destroy the original message. *** 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: AW: Tool for Browsing MQ Queues?
Here is one very popular across our company: http://www-3.ibm.com/software/ts/mqseries/txppacs/ms0h.html Ruzi --- Robert Broderick <[EMAIL PROTECTED]> wrote: > We use this all the time > > http://www-3.ibm.com/software/ts/mqseries/txppacs/ih03.html > > bobbee > > > > >From: Marc Siegert <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: AW: Tool for Browsing MQ Queues? > >Date: Wed, 14 Aug 2002 11:00:58 +0200 > > > >Hi Elli! > > > >Try this. This is an IBM Support Pac and works > fine! > > > >regards Marc > > > >P.S.: Wie geht's sonst so? Hochwasserkatastrophe? > > > > > > -Urspr|ngliche Nachricht- > > Von: Flothmann, Eleonore > [mailto:[EMAIL PROTECTED]] > > Gesendet: Mi 14.08.2002 10:27 > > An: [EMAIL PROTECTED] > > Cc: > > Betreff: Tool for Browsing MQ Queues? > > > > > > > > > >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
[no subject]
Therer are a couple of things to tighten up the model and one configuration attribute that can actually help. First: After you receive your 2033 do you syncpoint and close the queue immed? One of the conditions is if the Transaction is running and the queue is open for I/O. Second: In a situaion like this, where triggering is "FIRST" it is normal to issue a MQGET with an apropriate "WAIT" interval specified to offset possible incoming messages. This helps is resources where the transaction does not have to be constantly restarted on a secon by second basis. This is a tuning parameter and is set acording to your application processing flow. Third: There is an attribute, triggerinterval, that is set on the QMGR level and can help with retriggering on queues where triggering is set to "FIRST". There was a M A J O R discussion as to it's use a short while back. This can(?) help in stances where the application has gone away and messages arrive on the triggerequeue. Read up on it. bobbee >From: Sridhar Ramasubramonian <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Date: Wed, 14 Aug 2002 15:10:28 +0200 > >hi listeners... > >I am working on the below configuration of MQ... >* MQ V1.2 on OS/390 >* Application running in CICS TS 1.3 > >The problem I am facing is with triggering. >We have established a trigger level of first and on this a >transaction gets triggered in CICS. The transactions processes >all messages and then comes down on the QEMPTY condition. >When we are running full load (with many many messages pumped >at some constant interval and the transaction getting triggered >and processing it ) at a point the transaction is not triggered >and messages pile up after that and do not get triggered. > >I inferred after some time that this is caused because the CICS >transaction comes down probably half a second after the >SYNCPOINT is done and it found the queue empty. > In this time CKTI which is the trigger monitoring/triggering >application saw the transaction up and decided not to trigger this >transaction. > >Has anybody else had this problem. Is this the right inference and >is there a solution to this problem. > >Solutions would be really helpful. > >Thanks and regards >Sridhar > >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
[no subject]
hi listeners... I am working on the below configuration of MQ... * MQ V1.2 on OS/390 * Application running in CICS TS 1.3 The problem I am facing is with triggering. We have established a trigger level of first and on this a transaction gets triggered in CICS. The transactions processes all messages and then comes down on the QEMPTY condition. When we are running full load (with many many messages pumped at some constant interval and the transaction getting triggered and processing it ) at a point the transaction is not triggered and messages pile up after that and do not get triggered. I inferred after some time that this is caused because the CICS transaction comes down probably half a second after the SYNCPOINT is done and it found the queue empty. In this time CKTI which is the trigger monitoring/triggering application saw the transaction up and decided not to trigger this transaction. Has anybody else had this problem. Is this the right inference and is there a solution to this problem. Solutions would be really helpful. Thanks and regards Sridhar 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: AW: Tool for Browsing MQ Queues?
Here is another by Dear Ole Paul!! http://www-3.ibm.com/software/ts/mqseries/txppacs/mo71.html bobbee >From: Marc Siegert <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: AW: Tool for Browsing MQ Queues? >Date: Wed, 14 Aug 2002 11:00:58 +0200 > >Hi Elli! > >Try this. This is an IBM Support Pac and works fine! > >regards Marc > >P.S.: Wie geht's sonst so? Hochwasserkatastrophe? > > > -Urspr|ngliche Nachricht- > Von: Flothmann, Eleonore [mailto:[EMAIL PROTECTED]] > Gesendet: Mi 14.08.2002 10:27 > An: [EMAIL PROTECTED] > Cc: > Betreff: Tool for Browsing MQ Queues? > > > > >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
Re: AW: Tool for Browsing MQ Queues?
We use this all the time http://www-3.ibm.com/software/ts/mqseries/txppacs/ih03.html bobbee >From: Marc Siegert <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: AW: Tool for Browsing MQ Queues? >Date: Wed, 14 Aug 2002 11:00:58 +0200 > >Hi Elli! > >Try this. This is an IBM Support Pac and works fine! > >regards Marc > >P.S.: Wie geht's sonst so? Hochwasserkatastrophe? > > > -Urspr|ngliche Nachricht- > Von: Flothmann, Eleonore [mailto:[EMAIL PROTECTED]] > Gesendet: Mi 14.08.2002 10:27 > An: [EMAIL PROTECTED] > Cc: > Betreff: Tool for Browsing MQ Queues? > > > > >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
Enabling Oracle XA Support
Hi All, Whenever I try to start the MQ queue manager with Oracle XA support enabled on HP-UX I get the following error. - AMQ7626: XA resource manager initialization failure. Refer to the error log for more information. - In the MQ error log file I get the following error. - AMQ6188: The system could not dynamically load the shared library '/usr/lib/ora8swit' due to a problem with the library. The errno was 8 and the error message was 'Exec format error'. The queue manager will continue without this library. - The scenario is as follows Operating system - HP-UX 11.0 MQ Series version - 5.2 (without any CSD's) Oracle version- 8.1.7 Compiler - gcc 3.0.1 When I searched the IBM website, I found out that this is a known problem. http://www-3.ibm.com/software/ts/mqseries/support/readme/hpx520_read.html It seems Oracle has a solution to this problem. I have followed the steps as mentioned in the system's admin guide for enabling Oracle XA support. Did anyone get the same problem ? Please let me know if you were able to overcome it. Thanks in advance Vathsa 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
MQAO link problem
Hi all I'm trying to compile and link the c source code as generated by the MQ Adapter Builder, but I can't find the libs to solve the following link error: unresolved external symbol _AQMRT_delete I'm compiling and linking from Visual C++ 6 where is it? thanks Francois van der Merwe 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: Should AMQIQEM4 be run periodically on MQSeries Version 5.2 ?
>While using Version 4, we were told that it was good to run AMQIQEM4 >periodically. >We had been running it monthly. >Now that we are on Version 5.2, I see that the AMQIQEM4 does still exist. >Should we continue to run this (after MQ is quiesced)? >Are there any advantages/issues/concerns in doing so. >Thanks in advance, >Jerry I posed this question to our senior AS/400 Developer Jonathan Rumsey, the answer was. AMQIQEM4 was provided in releases prior to v5.x to cleanup OS/400 userspaces used by MQ - the v5.x products do not make use of userspaces so it is not required to use this at V5.x. Continuing to run this program will have no effect in the V5.2 product. MQSeries does provide a similar feature in v5.2 as part of the ENDMQM CL command - the ENDCCTJOB(*YES) option, which carries out some additional steps over a normal ENDMQM - for example ending TCP/IP listeners, recording a media image of the queue manager and cleaning up temporary files in the Integrated File System (IFS). Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Channel that always stays running
Absolutely!! Thanks for the correction Paul. What was I thinking when I was typing (apparently not the issue at hand...I guess ;-) Ruzi --- Paul Clarke <[EMAIL PROTECTED]> wrote: > >> If no heartbeat packets are received within the > >> Heartbeat check interval the > >> receiver will assume an outage and go "Inactive". > > >How is this possible? Maybe it is an enhancement in > >5.3??? Although it is not explicitly mentioned in > >your info-clip, maybe the Keepalive option is used > >here??? > > >Regards > >Ruzi > > As I said in my previous notes the Distributed > products will issue a > receive with a timeout if heartbeat is active. If > we're heartbeating every > 5 minutes we will issue a receive timeout for 6 > minutes. If the receive > does actually timeout it means we received neither a > heartbeat or a message > in 6 minutes which implies a network failure. > > For those who are interested we actually do this > using a select() call on > all the Unixes and using SO_RCVTIMEO on Windows. > > This is not an enhancement for 5.3 we've done this > for years and years. > > Cheers, > P. > > Paul G Clarke > WebSphere MQ Development > IBM Hursley > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: FFST file.
Jan, I can't answer all your questions but . AMQ6118 is unexpected return code and the unexpected return code is AMQ6162 AMQ6161 is error reading the configuration data Use 'mqrc' to view the messages, for example, mqrc AMQ6118 Looks like you may have something wrong with your INI file. Unfortunately this error is generated in about 90 different places in the product. Any chance you could get a trace of the problem, Even the stack included in the FDC file may help. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
AW: Tool for Browsing MQ Queues?
Hi Elli! Try this. This is an IBM Support Pac and works fine! regards Marc P.S.: Wie geht's sonst so? Hochwasserkatastrophe? -Ursprüngliche Nachricht- Von: Flothmann, Eleonore [mailto:[EMAIL PROTECTED]] Gesendet: Mi 14.08.2002 10:27 An: [EMAIL PROTECTED] Cc: Betreff: Tool for Browsing MQ Queues? 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
Tool for Browsing MQ Queues?
Title: Tool for Browsing MQ Queues? Hi, we are looking for a tool to browse mq queues. A special requirement is: in addition to simply show the messages in hex of string format this tool should be able to understand XML. If a message is in XML format the message should be presented in the appropriate XML presentation. Any idea? Regards Eleonore
Re: Peek Messages With a Given CorrID
how do you enforce the browse option? the only options this node has is input queue name,msgpath,data type,selemsgid,selectcorrelid and transaction mode. Wendy - Original Message - From: "Palavesam_Subbiah" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, August 14, 2002 8:17 AM Subject: Re: Peek Messages With a Given CorrID > Hi Jerry, > > > Your questions is: "how can I peek (without get, since get will remove the > message from the Q) all messages for the user?" > > Answer: > > To browse the msg related specific user, Use MQGET with Browse option and > match CorrID option and set the user ID into the CorrelID field of the MQMD > struct used for MQGET. > > Rgds, > Palavesam.S > > -Original Message- > From: Jiede J Yang [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 14, 2002 4:43 AM > To: [EMAIL PROTECTED] > Subject: Peek Messages With a Given CorrID > Importance: High > > > All: > > There is 1 queue involved. > > Server side puts messages to the Q with a corrID as the user login ID. > All messages for a given user will have the same corrID which is the user > login ID. > > Client side will peek on the messages and put into a UI list or tree. > > The questions is: how can I peek (without get, since get will remove the > message from the Q) all messages for the user? > > Thanks for your input. > > Jerry > > [EMAIL PROTECTED] > Cell: (626) 524 - 2554 > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > ** > This email (including any attachments) is intended for the sole use of the > intended recipient/s and may contain material that is CONFIDENTIAL AND > PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or > distribution or forwarding of any or all of the contents in this message is > STRICTLY PROHIBITED. If you are not the intended recipient, please contact > the sender by email and delete all copies; your cooperation in this regard > is appreciated. > ** > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > *** This message may contain information which is confidential and subject to legal privilege. If you are not the intended recipient, you may not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify the sender immediately by email, facsimile or telephone and return and/or destroy the original message. *** 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
FFST file.
Hi, Could someone shed some light on this... A channel was stopped because of a security exit setting a 'SUPPRESS_FUNCTION' (on OS390) This has happened before & a channel could be restarted. On the Sun Solaris site I can find a 2195 (unexpected error) when opnening a queue manager object (with same name as the queue manager) followed one second later by a 2063 for a queue. There's an FFST file with the same time stamp as the 2195 message, copied below... Because of the different platforms it is hard to correlate the time stamps. I'm curious whether the problems on Sun could be the result of the security exit stopping the channel, or the other way around... Thanks ! Jan.. +--- --+ | | | MQSeries First Failure Symptom Report | | = | | | | Date/Time :- Monday August 12 18:20:00 MET DST 2002 | | Host Name :- *** (SunOS 5.6)| | PIDS :- 5765B75| | LVLS :- 510| | Product Long Name :- MQSeries for Sun Solaris 2 (Sparc) | | Vendor:- IBM| | Probe Id :- ZF053001 | | Application Name :- MQM| | Component :- zfu_as_retrieveauth| | Build Date:- Aug 9 2000| | UserID:- 4010 (mqm) | | Program Name :- amqzlaa0_nd| | Process :- 1376 | | Thread:- 0010 | | QueueManager :- ***| | Major Errorcode :- xecF_E_UNEXPECTED_RC | | Minor Errorcode :- xecU_E_INI_FILE_ERROR | | Probe Type:- MSGAMQ6118 | | Probe Severity:- 2 | | Probe Description :- MQSeries was unable to open a message catalog to | | display an error message for message id hexadecimal 20006118, with| | inserts 536895842, 0, , , and . | | Arith1:- 536895842 20006162 | | | +--- --+ 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
