Re: Truncated Failed Messages and the BackOutCount
If this were my application, I would prefer to allow truncated messages in the MQGET. You will not get a return code of zero. It will be a return code of 1 and reason code of 2079. When that condition is met, move the message to another queue or just discard the message and continue looping through the queue (you will only have 500 bytes, the rest is lost). I have found that you can not control whether garbage is sent to your application queue, but you CAN control how you deal with those messages. (Kind of applies to life, too. How profound) Valerie A. Howells SBC/Ameritech Middleware MQ Team Hoffman Estates, IL IBM Certified MQ Series Specialist email: [EMAIL PROTECTED] -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Sent: Friday, August 02, 2002 2:03 PM To: [EMAIL PROTECTED] Subject: Truncated Failed Messages and the BackOutCount About to test some code on the mainframe and before I crash the TCODE because of an endless loop, I need your guys opinion. Mainframe app is triggered OnFirst. Does GETs with No-Syncpoint, Does not Accept truncated messages, specifies a buffer of 500 bytes. If a message is put on the queue that is 501 bytes, the app will be triggered, but the GET will fail with reason MQRC_TRUNCATED_MSG_FAILED. The manual says that the message will not be removed. The app will do its error process and then end. The queue will be closed. If the message was not removed, and a triggered on first queue is being closed with a queue depth of greater than 0, a new trigger message will be generated. Poisoned message loop for an app that gets outside of syncpoint! Normally no problem. Code some logic that checks the MQMD-Backoutcount immediately after the GET and handle values greater than n. But if the message was never removed from the queue, will the backout count be increased every time the GET fails because of a truncated message error? 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
Re: Reg MQ-JMS programs.
Supraba, you will have to either specify your connection attributes in the JNDI directory entry for you xxxConnectionFactory (where xxx is either 'Queue' or 'Topic', depending on your appl.model) or you can do it at runtime, using the methods of the MQxxxConnectionFactory class: setChannel(...), setHostName(...) and setPort(...) Chapter 10 of the MQ Using Java manual contains all the juicy details. Hope this helps. Everybody have a nice weekend, Stefan >From: Supraba Shekharan <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Reg MQ-JMS programs. >Date: Fri, 2 Aug 2002 15:14:55 +0530 > >Hi all, > >I have a querry regarding MQ JMS programs. >We are writing a JMS program (running on NT server) to write to a MQ queue >on the mainframe. There is only a MQclient running on the NT and the MQ >server runs on the mainframe. What is the config file that MQseries >provides (in its directories) to specify the IP address and port of the >MQServer on the mainframe? > >Thanks in advance for any help and suggestions. > >Thanks, >Supraba. > >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 _ 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
Re: Truncated Failed Messages and the BackOutCount
The backout count only applies for messages that are backed out within a unit of work, explicitly or through an abend. So, in the case described, even if the MQBACK command were issued, it would be a NO OP since the get was done with No-syncpoint. Even if the get was done with syncpoint and then an MQBACK was issued after receiving the 2080, the BACKOUT count is still zero, since the message was not backed out, but remained on the queue because of the 2080. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Sent: Friday, August 02, 2002 12:03 PM To: [EMAIL PROTECTED] Subject: Truncated Failed Messages and the BackOutCount About to test some code on the mainframe and before I crash the TCODE because of an endless loop, I need your guys opinion. Mainframe app is triggered OnFirst. Does GETs with No-Syncpoint, Does not Accept truncated messages, specifies a buffer of 500 bytes. If a message is put on the queue that is 501 bytes, the app will be triggered, but the GET will fail with reason MQRC_TRUNCATED_MSG_FAILED. The manual says that the message will not be removed. The app will do its error process and then end. The queue will be closed. If the message was not removed, and a triggered on first queue is being closed with a queue depth of greater than 0, a new trigger message will be generated. Poisoned message loop for an app that gets outside of syncpoint! Normally no problem. Code some logic that checks the MQMD-Backoutcount immediately after the GET and handle values greater than n. But if the message was never removed from the queue, will the backout count be increased every time the GET fails because of a truncated message error? 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
Re: Truncated Failed Messages and the BackOutCount
Since the message was never removed, the backout count will not be updated. When you receive the truncated message you've got to either adjust your buffer so that the larger message can be excepted (remember even though the call failed the actual message length is still returned), or use accept truncated message. Joe De Blassio perot systems -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Sent: Friday, August 02, 2002 3:03 PM To: [EMAIL PROTECTED] Subject: Truncated Failed Messages and the BackOutCount About to test some code on the mainframe and before I crash the TCODE because of an endless loop, I need your guys opinion. Mainframe app is triggered OnFirst. Does GETs with No-Syncpoint, Does not Accept truncated messages, specifies a buffer of 500 bytes. If a message is put on the queue that is 501 bytes, the app will be triggered, but the GET will fail with reason MQRC_TRUNCATED_MSG_FAILED. The manual says that the message will not be removed. The app will do its error process and then end. The queue will be closed. If the message was not removed, and a triggered on first queue is being closed with a queue depth of greater than 0, a new trigger message will be generated. Poisoned message loop for an app that gets outside of syncpoint! Normally no problem. Code some logic that checks the MQMD-Backoutcount immediately after the GET and handle values greater than n. But if the message was never removed from the queue, will the backout count be increased every time the GET fails because of a truncated message error? 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
Reg MQ-JMS programs.
Hi all, I have a querry regarding MQ JMS programs. We are writing a JMS program (running on NT server) to write to a MQ queue on the mainframe. There is only a MQclient running on the NT and the MQ server runs on the mainframe. What is the config file that MQseries provides (in its directories) to specify the IP address and port of the MQServer on the mainframe? Thanks in advance for any help and suggestions. Thanks, Supraba. 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: Truncated Failed Messages and the BackOutCount
Peter, I did a very quick batch program to try this out (reading only one message so there couldn't be a loop). Here's what I found -- The buffer in the program was 15 bytes and the message was 100 bytes. And I did get the 2080 for a truncation failed. And the message did stay on the queue. And -- what you really wanted to know -- the backout count is still 0 on the message. So, looks like checking the backout count won't work. Hmmm My best, Rebecca -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Sent: Friday, August 02, 2002 3:03 PM To: [EMAIL PROTECTED] Subject: Truncated Failed Messages and the BackOutCount About to test some code on the mainframe and before I crash the TCODE because of an endless loop, I need your guys opinion. Mainframe app is triggered OnFirst. Does GETs with No-Syncpoint, Does not Accept truncated messages, specifies a buffer of 500 bytes. If a message is put on the queue that is 501 bytes, the app will be triggered, but the GET will fail with reason MQRC_TRUNCATED_MSG_FAILED. The manual says that the message will not be removed. The app will do its error process and then end. The queue will be closed. If the message was not removed, and a triggered on first queue is being closed with a queue depth of greater than 0, a new trigger message will be generated. Poisoned message loop for an app that gets outside of syncpoint! Normally no problem. Code some logic that checks the MQMD-Backoutcount immediately after the GET and handle values greater than n. But if the message was never removed from the queue, will the backout count be increased every time the GET fails because of a truncated message error? 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 ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. 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: Truncated Failed Messages and the BackOutCount
No the backout count will not be increased by the failed gets. So yes, if you don't handle the error you're headed for a world of hurt. If you have no intention of processing messages larger than 500 bytes then I would handle the situation immediately. How you handle it is of course up to you, just don't ignore it. Either remove it to a backout queue, remove it destructively, or stop the triggering process (whatever creative solution you come up with), but don't let your application get into a triggering loop. Rick |-+---> | | "Potkay, Peter M (PLC, IT)" | | | <[EMAIL PROTECTED]> | | | | | | Sent by: MQSeries List | | | <[EMAIL PROTECTED]> | | | | | | | | | | | | Friday August 2, 2002 02:03 PM | | | Please respond to MQSeries List | | | | |-+---> >| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Truncated Failed Messages and the BackOutCount | >| About to test some code on the mainframe and before I crash the TCODE because of an endless loop, I need your guys opinion. Mainframe app is triggered OnFirst. Does GETs with No-Syncpoint, Does not Accept truncated messages, specifies a buffer of 500 bytes. If a message is put on the queue that is 501 bytes, the app will be triggered, but the GET will fail with reason MQRC_TRUNCATED_MSG_FAILED. The manual says that the message will not be removed. The app will do its error process and then end. The queue will be closed. If the message was not removed, and a triggered on first queue is being closed with a queue depth of greater than 0, a new trigger message will be generated. Poisoned message loop for an app that gets outside of syncpoint! Normally no problem. Code some logic that checks the MQMD-Backoutcount immediately after the GET and handle values greater than n. But if the message was never removed from the queue, will the backout count be increased every time the GET fails because of a truncated message error? 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
Re: how the server uses userId from client
Thanks for your info, Paul. The question I have is - is it possible for the client to pass a specific user id to the server for authentication, or will the server always automatically use the userid with which the user logged in (into the NT box) ? If this can be done, it will solve my problem temporarily at least. I could not find a way to do this either I am not at all familiar with exits, and since I need to do this quickly, I am looking for an alternative, simpler solution... Thanks, - krishnan Paul Clarke <[EMAIL PROTECTED]>wrote: Krishnan,This has been discussed at length before; it might be worth you reading thearchives.If you set the value of MCAUSER then, as you say, that is the userid thatthe QM will use for it's access control checks. If you set MCAUSER toblanks then it will be changed to the logged on userid of the client when aclient connects. However, be careful with this option. You are trustingyour network. Effectively you are leaving yourself wide open for someone toconnect to your queue manager and say they're 'mqm' and therefore haveaccess to all your queues and all your messages.The only way to reliably do what you ask is to have a security exit at theSVRCONN end which authenticates with the client, ensure he is who you thinkhe is which then sets the value of MCAUSER accordingly.Cheers,P.Paul G ClarkeWebSphere MQ DevelopmentIBM HursleyInstr uctions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archiveDo You Yahoo!? Yahoo! Health - Feel better, live better
Re: Truncated Failed Messages and the BackOutCount
I believe the BackoutCount gets incremented with each failed Get, with or without Syncpoint.. Your app would have to manually deal with the poisoned 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
Truncated Failed Messages and the BackOutCount
About to test some code on the mainframe and before I crash the TCODE because of an endless loop, I need your guys opinion. Mainframe app is triggered OnFirst. Does GETs with No-Syncpoint, Does not Accept truncated messages, specifies a buffer of 500 bytes. If a message is put on the queue that is 501 bytes, the app will be triggered, but the GET will fail with reason MQRC_TRUNCATED_MSG_FAILED. The manual says that the message will not be removed. The app will do its error process and then end. The queue will be closed. If the message was not removed, and a triggered on first queue is being closed with a queue depth of greater than 0, a new trigger message will be generated. Poisoned message loop for an app that gets outside of syncpoint! Normally no problem. Code some logic that checks the MQMD-Backoutcount immediately after the GET and handle values greater than n. But if the message was never removed from the queue, will the backout count be increased every time the GET fails because of a truncated message error? 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: how the server uses userId from client
Krishnan, This has been discussed at length before; it might be worth you reading the archives. If you set the value of MCAUSER then, as you say, that is the userid that the QM will use for it's access control checks. If you set MCAUSER to blanks then it will be changed to the logged on userid of the client when a client connects. However, be careful with this option. You are trusting your network. Effectively you are leaving yourself wide open for someone to connect to your queue manager and say they're 'mqm' and therefore have access to all your queues and all your messages. The only way to reliably do what you ask is to have a security exit at the SVRCONN end which authenticates with the client, ensure he is who you think he is which then sets the value of MCAUSER accordingly. 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: Triggers on WinOS to Java Pgms
Neal, Just a wild guess but is c:\program files\ibm\mqseries\bin in your PATH while the other directories (folders) you have been trying are not in your PATH? You might also make sure your CLASSPATH includes the folders you need when trying to run from a different folder/user. The environment variables (PATH, CLASSPATH) could be set in the system area so they are defined for all users. The user the trigger monitor is running as may be the key to your problem so make sure that user has permissions set appropriately. I apologize if you have exhausted these possibilities already. Regards, Chris "Bockwoldt, Neal K" To: [EMAIL PROTECTED] Subject: Triggers on WinOS to Java Pgms Sent by: MQSeries List 08/02/02 10:12 AM Please respond to MQSeries List To my Trigger Happy Colleauges, We use MQ 5.2 csd04 on WinNT4sp6a and Win2000 with triggers to java programs. Initially, on NT, we could not get the triggers to fire using the trigger monitor provided in MQServices. On the other hand, if we manually started RUNMQTRM, the triggered programs would run fine regardless of where they were located. The application of CSD04 seemed to solved that problem. When we installed MQ on a Win2000 server with CSD04 we encountered the same problem again. What we've learned is that the MQServices trigger monitor only seem to work if we run the java pgms in c:\program files\ibm\mqseries\bin. (When we applied CSD04 to our first NT server, we happened to have the trigger pgms in c:\program files\ibm\mqseries\bin and never tried them in a different location until we setup the Win2000 server.) Has anyone else encountered this restriction? Shouldn't it run in any directory? Why does it work anywhere for the manually started RUNMQTRM but not the Trigger monitor provided in MQ Services? Sincerely, Neal K. Bockwoldt Ameren Services [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Triggers on WinOS to Java Pgms
Title: Triggers on WinOS to Java Pgms To my Trigger Happy Colleauges, We use MQ 5.2 csd04 on WinNT4sp6a and Win2000 with triggers to java programs. Initially, on NT, we could not get the triggers to fire using the trigger monitor provided in MQServices. On the other hand, if we manually started RUNMQTRM, the triggered programs would run fine regardless of where they were located. The application of CSD04 seemed to solved that problem. When we installed MQ on a Win2000 server with CSD04 we encountered the same problem again. What we've learned is that the MQServices trigger monitor only seem to work if we run the java pgms in c:\program files\ibm\mqseries\bin. (When we applied CSD04 to our first NT server, we happened to have the trigger pgms in c:\program files\ibm\mqseries\bin and never tried them in a different location until we setup the Win2000 server.) Has anyone else encountered this restriction? Shouldn't it run in any directory? Why does it work anywhere for the manually started RUNMQTRM but not the Trigger monitor provided in MQ Services? Sincerely, Neal K. Bockwoldt Ameren Services [EMAIL PROTECTED]
Re: Strange MQ Series Security Problem
Have you tried the following? >From the MQSeries Queue Manager Clusters manual: On queue manager CORK, to grant the user MyUser access to the queues in a cluster, issue the following setmqaut commands: setmqaut -m CORK -t qmgr -p MyUser +connect setmqaut -m CORK -t qmgr -p MyUser +setall setmqaut -m CORK -n SYSTEM.CLUSTER.TRANSMIT.QUEUE -t queue -p MyUser +setall Bob Fruncillo -Original Message- From: Leon Grey [mailto:[EMAIL PROTECTED]] Sent: Friday, August 02, 2002 8:58 AM To: [EMAIL PROTECTED] Subject: Strange MQ Series Security Problem We are currently undergoing a task which is expected to tighten up security on a Clustered MQ environment housed on Unix Solaris machines. Initially, the clustered environment was put in place to serve an application executing as a user with mqm membership. Having the application operate as a superuser to MQSeries would have serious security implications in our production environment. Therefore, we opted to revoke the users' mqm membership. Once complete we configured the OAM, giving the user the expected level of authorisation on both the queue manager and the queues. As a precaution we issued the REFRESH SECURITY(*) command. To test the changes, I attempted to use the amqsput application. The application returns a 2059 - MQRC_Q_MGR_NOT_AVAILABLE. I have tried everything to ressolve this problem. This includes setting the OAM to give the user +all permissions to the queue and queue manager. Attempting an amqsput from the mqm user works as expected. Has anybody had any similar experiences? This task should have been straightforward but I just can't seem to find a resolution. I will appreciate all comments. Leon __ 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
how the server uses userId from client
I read the manuals but I am confused about the answer to a basic MQSeries question: I have MQServer running on an AIX. I have one userid on this machine who has full access to MQ objects. I have set the MCAUSER on the server connection channel to this userid. I have several MQSeries clients running on NT try to connect to this MQSeries server using this channel (through MQSERVER env variable). My questions are : 1. My understanding is that the server always uses the channel's MCAUSER value as the userid to authorize with - is that a correct assumption ? 2. But what I really want to do is to have each client pass the userid it wants to connect to the server with. How can I do this ? I am trying to use the C++ interface on the client on version 5.1 (this does not have ImqChannel class). If using C, It looks like the MQCD structure might help me, but I am not clear on where or how to use this structure... Thanks in advance for any help, - krishnanDo You Yahoo!? Yahoo! Health - Feel better, live better
Strange MQ Series Security Problem
We are currently undergoing a task which is expected to tighten up security on a Clustered MQ environment housed on Unix Solaris machines. Initially, the clustered environment was put in place to serve an application executing as a user with mqm membership. Having the application operate as a superuser to MQSeries would have serious security implications in our production environment. Therefore, we opted to revoke the users' mqm membership. Once complete we configured the OAM, giving the user the expected level of authorisation on both the queue manager and the queues. As a precaution we issued the REFRESH SECURITY(*) command. To test the changes, I attempted to use the amqsput application. The application returns a 2059 - MQRC_Q_MGR_NOT_AVAILABLE. I have tried everything to ressolve this problem. This includes setting the OAM to give the user +all permissions to the queue and queue manager. Attempting an amqsput from the mqm user works as expected. Has anybody had any similar experiences? This task should have been straightforward but I just can't seem to find a resolution. I will appreciate all comments. Leon __ 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
Re: Channel problem
>Paul, >Can you explain what you mean by 'trace the channel' ? >Regards >Sundari Sundari, All I was suggesting was that if you really want to know what the channel did you can switch on MQ trace. This goes for any MQI application. Switch trace on with a command like strmqtrc -t detail -t all. run your test and then end trace and you'll have a trace file for each process that did MQ work. One of them will be the amqcrsta channel process. The exact commands for switching trace on. formatting the files etc change depending on the platform. If you can't understand the trace files then you can send them to me if you like and I'll take a look. Hope 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: Channel problem
Emile, Rebecca, I have not changed the expiry attribute, I mean that I am not explicitly changing the expiry attribute of the message in my application program. I think the default is unlimited expiry time. Do I have to set it to something so that messages remain ? Plus, today we changed a few attributes of the transmission queue. We set the trigger type to F and also set the inititation queue to SYSTEM.CHANNEL.INITQ so that once a message is received in the transmission queue the Channel is started from its inactive state. But still there is some problem when we stop and restart a channel. Messages just disappear. They are not found on the DLQ either. Paul, Can you explain what you mean by 'trace the channel' ? Regards Sundari -Original Message- From: Emile Kearns [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 7:41 PM To: [EMAIL PROTECTED] Subject: Re: Channel problem If the channel was stopped manually, it must be started before messages will flow between systems. Yes, persistence is used when the QMGR needs to recover the queue. If the messages had an expiry time, the QMGR will discard them when the expiry time is reached. Do you have default DLQ assigned to the QMGR? Emile Kearns SOFTWARE FUTURES the business advantage Proud member of MGX www.softwarefutures.com -Original Message- From: Ganapathy, Sundari (Cognizant) [mailto:[EMAIL PROTECTED]] Sent: 01 August 2002 03:35 To: [EMAIL PROTECTED] Subject: Re: Channel problem No channel triggering. We stopped the channel for some other purpose(test) and in the meanwhile we had placed a number of messages in the XMITQ. When we noticed the problem we re-started the channel and found that the messages were not there. The messages are not persistant. I thought message persistance was required only when the queue manager itself goes down. Correct me if I am wrong. We are checking the DLQ. Queue was inactive not stopped. Sundari -Original Message- From: Emile Kearns [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 6:37 PM To: [EMAIL PROTECTED] Subject: Re: Channel problem Three questions: 1. Are you using channel triggering and why is the channel in a stopped state? 2. Are your messages persistant and do you interrogate the expiry option on the message? 3. When you say LOST, are the message gone, have you checked the DLQ? Emile Kearns SOFTWARE FUTURES the business advantage Proud member of MGX www.softwarefutures.com -Original Message- From: Ganapathy, Sundari (Cognizant) [mailto:[EMAIL PROTECTED]] Sent: 01 August 2002 02:37 To: [EMAIL PROTECTED] Subject: Channel problem Hi We are writing COBOL API that runs on OS/390 and places messages on queues running on AIX. I had mailed the problem to the listers already yesterday and now I have the problem much more well defined. Hope someone can help. When the sender channel is running and my application program places messages in the queue all goes fine. When the sender channel is stopped and my application program places messages all the messages get accumulated in the XMITQ. When I restart the sender channel the first two messages alone are logged into the remote queue. The rest of the messages are lost. Actually someone over here suggested that the message ids of the rest of the messages are lost and that is why the messages are lost and they said the MQ administrator should be able to log message ids into some buffer area if the channel is not running. Do you have any more suggestions on this ? Regards Sundari * Work : +91 44 811 3063 Extn 2253 Vnet: 42253 * Home : +91 44 654 4396 * Mobile: +91 98410 33803 .. Think Big. Think Differently. Challenge conventional wisdom. Think long term. - Dhirubhai Ambani 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 and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com
Updated SupportPac MO71
The latest version of my Administrator support Pac has just been out up on the Support Pac Web Site (http://www-3.ibm.com/software/ts/mqseries/txppacs/mo71.html). My thanks to all the beta testers for their comments and suggestions (and to Rebecca for checking my grammar :-D ) . As usual, please write to me with any problems or comments both good and bad, Cheers, Paul. 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
Maximum Queue File Size
Hi, What's the maximum size of a Queue File on Windows 2000 with MQSeries V5.2.1?? Is it 2GB? I don't think the Capacity Planning guide Support pac is updated in the IBM site. Regards, Rajesh **Disclaimer** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited.
