Re: Backout of failed a C++ Application
Hello Neil, If this is a TCP client, this is possible (that connection on a server outlives the client app). Try to play with keepalive (I am not sure what is the default timeout on Windows though; on Solaris, it is set machine-wide and the default is sometimes 2 hours). You can try to set HBINT but this will not work unless client crashes while waiting for a message in MQGET -- but it worth to do, anyway for it will make transaction back out faster. Hope this will help, Pavel --- Can anyone explain what should happen if the above application has got a message under syncpoint and then crashes. Logically I know that the message should re-appear on the queue, especially if a disconnect is issued, but I'm wondering how the qmanager knows that the application has died and that the connection handle should be removed from its pool and any uncommitted work backed out. Is it possible that the connection handle survives the unplanned termination of the applciation, and therefore does not release the handle and backout those uncomitted messages? The scenario here is that messages do not appear to be returned to the queue when the app fails. Of course there may be another reason for this, though the app code I have seen does not appear to rollback any messages or dump them on the DLQ. Upon an app restart, there is knowledge of the messages previously conusumed but not yet committed. There is only one instance of the application, we believe. MQ Version is 5.2.1 I believe, platform Windows 2000 or similar. MQ clusters are in place though I'm led to believe that affinities exist and are catered for, as in this case. Any views appreciated. Neil -- 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: Extended Transactional Client & WLS
Thanks, Peter! Will know whom to ask if I have problems. If anyone has it working with just basic MQ, please share you experience. Sincerely, Pavel "Potkay, Peter M (PLC, IT)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: RTFORD.COM>Subject: Re: Extended Transactional Client & WLS Sent by: MQSeries List <[EMAIL PROTECTED] AC.AT> 04/30/2004 08:52 AM Please respond to MQSeries List Pavel, we have done this with WL 6.1 and JMS. Been in production for about 3 months. -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Thursday, April 29, 2004 10:00 PM To: [EMAIL PROTECTED] Subject: Extended Transactional Client & WLS Hello, Has anyone gotten these two working together? I am interested in sending a message from some session or other EJB to MQ queue, under the XA transaction, managed by Weblogic (8.1 SP2). I did not start trying yet; before going into it, I am trying to get encouraged by hearing that this is doable. Preferably, I would use "pure" Java MQ (i.e. non-JMS) but if it is not an option, JMS would do, too. Thank you, Pavel -- 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 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 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: Message Tracking
Actually, Bristol does offer a development only version which we've considered so I guess number 3 wins Bubba Michael Dag <[EMAIL PROTECTED]> wrote: Steve, I don't think we are full circle yet... maybe it's not a circle but a 8 (don't know how to draw it otherwise) The ball started with Roger's post which started with Developers saying "where's my message - MQ lost it". Roger knows very well tools like TransactionVision and QN-AppWatch are out there, so suggests that... to prove MQ didn't loose it His management looks at the price of those tools, which are priced for "production" use. (and of course why not... they certainly provide value!) Management response "we have no money..." (the dot's are probably: not that kind of money to prove developers are wrong... and have not even looked at the value of those tools in "production" use) Roger (smart as he is) comes up with the idea to write his own logging tool... Then the discussion starts what to do 1. ignore developers, MQ is always OK 2. beat developers to death with courses... 3. beat management, back and forth... 4. etc, etc... Roger decides to do what he needs NOW! (he has been in those discussions and decides he's been on the losing end to many times and doesn't want to go there anymore...) Then other tools like Cressida are suggested, then IBM needs to fix it, then Del jumps in saying "what about persisten messages?" (so the logs are not enough...) and points out there are tools out there that exactly do what Roger needs... (duh... Roger knows that already) So I jump in with my 2 cents to allow for "development" use of the mentioned tools like QN-AppWatch and suggest that to Del. and price the two differently (ofcourse the development version should be a lot cheaper... :-) This is a two-sword deal... people get to experience value that they also need in "production" which they never get to (most of the time) as the price is to "high" to perceive the value when buying and not having any "hands-on" experience with the tools. So it is not only good for the Roger's (sorry... me included) but also good for the tool developers (not the ones loosing the messages :-)) ) to get their product sold... Difference in price between a "development" license and a "production" license will not be argued! ... IMHO... this is where you said that it will be argued (you may have misunderstood me or not...) So now it looks like we are full circle... but there are 3 may be even more outcomes... 1. Roger will develop his tool and sell it to the development community, if it doesn''t take him too long he is even the guy to give it away... 2. IBM comes with a solution in the product as they have been listening... (I won't hold my breath...) 3. Companies like Bristol / Reconda / Cressida decide to take the two-sword deal and come out with "development" versions that have all functionality, but have some 'delays or capacity limiters built in... at an affordable rate for MQAdmins (not developers... ha...) 4. If any of the above comes true we all will be a lot happier... So let's wait and see which of the 3 happens first... (my bet is on Roger...) Michael -Oorspronkelijk bericht-Van: MQSeries List [mailto:[EMAIL PROTECTED]Namens Kelly, SteveVerzonden: Friday, April 30, 2004 10:16 PMAan: [EMAIL PROTECTED]Onderwerp: Re: Message Tracking John, I think this discussion has gone around in a circle. If your developer asks "where's my message - MQ lost it" then you do have a way to prove otherwise - some message tracking software e.g. Bristol's TransactionVision amongst others. Isn't that where we started. The issue is, now, cost. Re. about proving whether message expiry has worked correctly, if a reply is important there should be no expiry anyway ! Then if he doesn't get the reply message he can legitimately complain. Steve. From: John Scott [mailto:[EMAIL PROTECTED] Sent: 30 April 2004 18:36To: [EMAIL PROTECTED]Subject: Re: Message Tracking To put this as a problems and not a suggestion or solution as James requested, I think a fundamental problem is that it is difficult to track messages once they have been removed from a queue. Thus if an application puts a message on a local queue and another one has been left reading messages from a queue, the original developer asks "where's my message - MQ lost it". We have no real way to prove otherwise - even saying "see - the input procs is > 0 so someone read the message" is not conclusive because we also say to developers when messages build up that input procs > 0 doesn't prove anything as the input procs only indicates someone has the queue open for input, not that they're actually doing any MQGETs on it. Another problem is that when messages expire, we have no way of proving this has happened either. Whether IBM provide a solution using the transaction logs or not is an implementation detail I will leave to them. Regards John Scott IBM Certified Specialis
Re: Setmqaut on v5.1
Sid, are you trying these commands on a 5.1 system, or a 5.3 system? At 5.1, the wild cards will not work. Only at 5.3. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, April 30, 2004 6:27 PM To: [EMAIL PROTECTED] Subject: Re: Setmqaut on v5.1 Yep..tried that one!...no luck Sid -Original Message- From: Nick Dilauro [mailto:[EMAIL PROTECTED] Sent: Saturday, 1 May 2004 3:17 AM To: [EMAIL PROTECTED] Subject: Re: Setmqaut on v5.1 Did you try TST.** ? I believe TST.* will only work for TST.XXX and not for TST.XXX.YYY. Nick -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, April 30, 2004 12:07 AM To: [EMAIL PROTECTED] Subject: Setmqaut on v5.1 Howdy all (again), I am in the process of migrating an old v5.1 server to v5.3 on a new platform. As part of the process I have moved a copy of the queue managers over to the new Win2K machine and they work ok, but I am having security nightmares prior to upgrading the MQ to v5.3 When I try: Setmqaut -m QML_MQM -t q -n TST.* -g MQCLIENTS +put -get +inq +browse I get AMQ7085: Object TST.*, type q not found I have thousands of queues which are named: TST.abc01 TST.abc01.data TST.abc02 TST.abc02.data I have tried variations on -g and -p using groups and principals, I have also tried TST.*.* and every vriant I can think of. The manual (SC34-6068-00) System Administration Guide says you can use wildcards!! (page 308)... But it doesn't work! What am I doing wrong ? Sid Young Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This 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: Setmqaut on v5.1
Yep..tried that one!...no luck Sid -Original Message- From: Nick Dilauro [mailto:[EMAIL PROTECTED] Sent: Saturday, 1 May 2004 3:17 AM To: [EMAIL PROTECTED] Subject: Re: Setmqaut on v5.1 Did you try TST.** ? I believe TST.* will only work for TST.XXX and not for TST.XXX.YYY. Nick -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, April 30, 2004 12:07 AM To: [EMAIL PROTECTED] Subject: Setmqaut on v5.1 Howdy all (again), I am in the process of migrating an old v5.1 server to v5.3 on a new platform. As part of the process I have moved a copy of the queue managers over to the new Win2K machine and they work ok, but I am having security nightmares prior to upgrading the MQ to v5.3 When I try: Setmqaut -m QML_MQM -t q -n TST.* -g MQCLIENTS +put -get +inq +browse I get AMQ7085: Object TST.*, type q not found I have thousands of queues which are named: TST.abc01 TST.abc01.data TST.abc02 TST.abc02.data I have tried variations on -g and -p using groups and principals, I have also tried TST.*.* and every vriant I can think of. The manual (SC34-6068-00) System Administration Guide says you can use wildcards!! (page 308)... But it doesn't work! What am I doing wrong ? Sid Young 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: SSL on z/OS and RACF
All, Does anyone know if it's necessary to have a unique key ring for each queue manager on z/OS ? On the distributed side, it is necessary. From my reading in WMQ Security (z/OS), I think you use the same key ring for all queue managers, but I'm not 100% sure about this. Any help is appreciated Thanks ! Phil This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates. 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: Message Tracking
Title: Message Steve, I don't think we are full circle yet... maybe it's not a circle but a 8 (don't know how to draw it otherwise) The ball started with Roger's post which started with Developers saying "where's my message - MQ lost it". Roger knows very well tools like TransactionVision and QN-AppWatch are out there, so suggests that... to prove MQ didn't loose it His management looks at the price of those tools, which are priced for "production" use. (and of course why not... they certainly provide value!) Management response "we have no money..." (the dot's are probably: not that kind of money to prove developers are wrong... and have not even looked at the value of those tools in "production" use) Roger (smart as he is) comes up with the idea to write his own logging tool... Then the discussion starts what to do 1. ignore developers, MQ is always OK 2. beat developers to death with courses... 3. beat management, back and forth... 4. etc, etc... Roger decides to do what he needs NOW! (he has been in those discussions and decides he's been on the losing end to many times and doesn't want to go there anymore...) Then other tools like Cressida are suggested, then IBM needs to fix it, then Del jumps in saying "what about persisten messages?" (so the logs are not enough...) and points out there are tools out there that exactly do what Roger needs... (duh... Roger knows that already) So I jump in with my 2 cents to allow for "development" use of the mentioned tools like QN-AppWatch and suggest that to Del. and price the two differently (ofcourse the development version should be a lot cheaper... :-) This is a two-sword deal... people get to experience value that they also need in "production" which they never get to (most of the time) as the price is to "high" to perceive the value when buying and not having any "hands-on" experience with the tools. So it is not only good for the Roger's (sorry... me included) but also good for the tool developers (not the ones loosing the messages :-)) ) to get their product sold... Difference in price between a "development" license and a "production" license will not be argued! ... IMHO... this is where you said that it will be argued (you may have misunderstood me or not...) So now it looks like we are full circle... but there are 3 may be even more outcomes... 1. Roger will develop his tool and sell it to the development community, if it doesn''t take him too long he is even the guy to give it away... 2. IBM comes with a solution in the product as they have been listening... (I won't hold my breath...) 3. Companies like Bristol / Reconda / Cressida decide to take the two-sword deal and come out with "development" versions that have all functionality, but have some 'delays or capacity limiters built in... at an affordable rate for MQAdmins (not developers... ha...) 4. If any of the above comes true we all will be a lot happier... So let's wait and see which of the 3 happens first... (my bet is on Roger...) Michael -Oorspronkelijk bericht-Van: MQSeries List [mailto:[EMAIL PROTECTED]Namens Kelly, SteveVerzonden: Friday, April 30, 2004 10:16 PMAan: [EMAIL PROTECTED]Onderwerp: Re: Message Tracking John, I think this discussion has gone around in a circle. If your developer asks "where's my message - MQ lost it" then you do have a way to prove otherwise - some message tracking software e.g. Bristol's TransactionVision amongst others. Isn't that where we started. The issue is, now, cost. Re. about proving whether message expiry has worked correctly, if a reply is important there should be no expiry anyway ! Then if he doesn't get the reply message he can legitimately complain. Steve. From: John Scott [mailto:[EMAIL PROTECTED] Sent: 30 April 2004 18:36To: [EMAIL PROTECTED]Subject: Re: Message Tracking To put this as a problems and not a suggestion or solution as James requested, I think a fundamental problem is that it is difficult to track messages once they have been removed from a queue. Thus if an application puts a message on a local queue and another one has been left reading messages from a queue, the original developer asks "where's my message - MQ lost it". We have no real way to prove otherwise - even saying "see - the input procs is > 0 so someone read the message" is not conclusive because we also say to developers when messages build up that input procs > 0 doesn't prove anything as the input procs only indicates someone has the queue open for input, not that they're actually doing any MQGETs on it. Another problem is that when messages expire, we have no way of proving this has happened either. Whether IBM provide a solution using the transaction logs or not is an implementation detail I will leave to them. Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd
Re: Message Tracking
Title: Message John, I think this discussion has gone around in a circle. If your developer asks "where's my message - MQ lost it" then you do have a way to prove otherwise - some message tracking software e.g. Bristol's TransactionVision amongst others. Isn't that where we started. The issue is, now, cost. Re. about proving whether message expiry has worked correctly, if a reply is important there should be no expiry anyway ! Then if he doesn't get the reply message he can legitimately complain. Steve. From: John Scott [mailto:[EMAIL PROTECTED] Sent: 30 April 2004 18:36To: [EMAIL PROTECTED]Subject: Re: Message Tracking To put this as a problems and not a suggestion or solution as James requested, I think a fundamental problem is that it is difficult to track messages once they have been removed from a queue. Thus if an application puts a message on a local queue and another one has been left reading messages from a queue, the original developer asks "where's my message - MQ lost it". We have no real way to prove otherwise - even saying "see - the input procs is > 0 so someone read the message" is not conclusive because we also say to developers when messages build up that input procs > 0 doesn't prove anything as the input procs only indicates someone has the queue open for input, not that they're actually doing any MQGETs on it. Another problem is that when messages expire, we have no way of proving this has happened either. Whether IBM provide a solution using the transaction logs or not is an implementation detail I will leave to them. Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd -Original Message-From: Glen Shubert [mailto:[EMAIL PROTECTED] Sent: 30 April 2004 16:27To: [EMAIL PROTECTED]Subject: Re: Message TrackingI fully agree with Frank. As a matter of fact, I had a conversation with IBM about that about 3 weeks ago. I told them that we needed a tool to be able to track messages from the time we received it to the point it left my queue manager. This would include CICS gets/puts, Database time, etc.Glen Shubert[EMAIL PROTECTED]Associate DirectorTSYS - MQSeries Technical Support "Bright, Frank" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 04/30/04 11:11 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: Message TrackingI am going to offer another opinion about message tracking.IBM logs message activity within its own logs for recovery purposes. I justthink the exit you propose is a duplication of the internal MQ logging. IBMmade use of the MQ logs in the creation of the MO12 (MQSeries for OS/390 -Log extract program) support pac. I believe this capability to trackmessages should be built into the product across the platforms.Thanks Frank-Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of GunterJeschawitzSent: Thursday, April 29, 2004 8:24 AMTo: [EMAIL PROTECTED]Subject: Re: Message TrackingI played around with the sample API Exit and installed it for the listenerand I believe you'll get all information needed. It only works for you ifthe application use client connection.This will produce very big log-files so I can't recommend to use it in anproduction environment, but in your case it may be acceptable.GunterInstructions for managing your mailing list subscription are provided in theListserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive-This e-mail message and any attachments contain confidential information from Medco. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments.Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking
Email problems for Roger Lacroix and Capitalware
All, The hosting company where Capitalware Inc. has its web site ( www.capitalware.biz ) had one of its main computer compromised late Thursday (April 29 Eastern time). It is now back online. If anyone sent me or Capitalware Inc. email within the last 24 hours, could you please resend it. Sorry for the inconvenience. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz 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: Forcing Logs
Sounds like your platform is MVS?? It's in the Sys Admin Guide. ARCHIVE LOG MODE(QUIESCE) There is also a TIME parameter. Hope that helped. Gina -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Williams, Dave (Systems Management) Sent: Friday, April 30, 2004 3:15 PM To: [EMAIL PROTECTED] Subject: Forcing Logs Anyone know how to force the logs to archive? I don't know where to look. Thanks, Dave W. 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
DB2 installation hangs when using Terminal Services
Hello MQ'ers, I am trying to install DB2 7.1 using Terminal Services on a remote Windows2000 Terminal. The installation goes to a certain extent, and halts without any error. The latest entries in the DB2.log are like this: - Administration Server: Log On Username:db2admin TCP/IP Service Name:db2cDB2DAS00 Port Number:523 Named Pipes Control Server: Log On Username:db2admin TCP/IP Service Name:db2cDB2CTLSV Port Number:50002 Named Pipes Target Directory: D:\IBM\SQLLIB Program Folder: IBM DB2 - The session on the remote terminal "hangs", with no control on it. I had to kill that session and connect again to see what was going on. I tried it a couple of times and I face the same problem each time I tried it. Has anyone seen this? Thank you. Sudheer 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: Message Tracking
I'm afraid they will argue. It's the old "real money" issue. That is, spend outside an already agreed software budget versus spend against an agreed development budget. ie. they have to pay you anyway so you're paid to find a solution to the problem. They don't care that your costs are higher than an off-the-shelf solution. It ain't in the budget. And I've worked in banking and government organisations where in theory money is no object and this is still a barrier. The real answer to this problem is to ensure that in the original project budget to implement an MQ (well in fact any) infrastructure, you include the support costs: management tools, configuration tools, monitoring tools, support tools etc. Hindsight is a great thing! Regarding loggng for audit/compliance reasons, building your own wrapper to do this just covers your bit. If there isn't similar logging in other applications then you don't have an end-to-end audit trail anyway. This needs to be an enterprise-wide initiative. And if you have an intermediate integration broker (SeeBeyond, MQSI etc. ) you may not have the same logging of the bit in the middle anyway. Sorry, Steve. From: Michael Dag [mailto:[EMAIL PROTECTED] Sent: 30 April 2004 18:35To: [EMAIL PROTECTED]Subject: Re: Message Tracking Del, this whole discussion started with "we have no money... " maybe you as a designer can talk to the sales guys to come up with "development" license fees in addition to "production" license fees? you could also see this as a stepping stone as people get used to functionality, no one will argue the difference between "development" fee versus "production" fees... my 2 cents... Michael -Oorspronkelijk bericht-Van: MQSeries List [mailto:[EMAIL PROTECTED]Namens DelVerzonden: Friday, April 30, 2004 7:31 PMAan: [EMAIL PROTECTED]Onderwerp: Re: Message Tracking yes, but what about non-persistent messages?... I know that companies such as Cressida offer log recovery products, but I still like our solution best (as the designer, of course I am totally biased...) -- I also agree very much with education of the LOB developers suggested by Bobbee and others, but it doesn't resolve the audit and compliance issues being raised these days... http://www-306.ibm.com/software/integration/mqreconda/ "Bright, Frank" <[EMAIL PROTECTED]> wrote: I am going to offer another opinion about message tracking.IBM logs message activity within its own logs for recovery purposes. I justthink the exit you propose is a duplication of the internal MQ logging. IBMmade use of the MQ logs in the creation of the MO12 (MQSeries for OS/390 -Log extract program) support pac. I believe this capability to trackmessages should be built into the product across the platforms.ThanksFrank-Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of GunterJeschawitzSent: Thursday, April 29, 2004 8:24 AMTo: [EMAIL PROTECTED]Subject: Re: Message TrackingI played around with the sample API Exit and installed it for the listenerand I believe you'll get all information needed. It only works for you ifthe application use client connection.This will produce very big log-files so I can't recommend to use it in anproduction environment, but in your case it may be acceptable.GunterInstructions for managing your mailing list subscription are provided in theListserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive-This e-mail message and any attachments contain confidential information from Medco. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments.Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive
Forcing Logs
Anyone know how to force the logs to archive? I don't know where to look. Thanks, Dave W. 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: IMS Adapter
Bridge / Adapter. I don't know the difference -- yet. I am reading and reading and reading. Fortunately this is occurring in development and not production. I am trying some stuff. "Beinert, William" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: OM> Subject: Re: IMS Adapter Sent by: MQSeries List <[EMAIL PROTECTED] n.AC.AT> 04/30/2004 02:38 PM Please respond to MQSeries List Peter is right on about the bridge (a real PITA to track down errors in this environment, IMHO) but Dick says he has a problem with the Adapter - and these are Bridge problems. I can't imagine the Adapter generating these kinds of errors. Bill -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Potkay, Peter M (PLC, IT) Sent: Friday, April 30, 2004 9:31 AM To: [EMAIL PROTECTED] Subject: Re: IMS Adapter When the IMS bridge receives a nonzero IMS-OTMA sense code, the IMS bridge converts the sense code from hexadecimal to decimal, adds the value MQFB_IMS_ERROR (300), and places the result in the Feedback field of the reply message. This results in the feedback code having a value in the range MQFB_IMS_FIRST (301) through MQFB_IMS_LAST (399) when an IMS-OTMA error has occurred. You have to subtract MQFB_ERROR from that value (300), which gives you the OTMA sense code. Chapter 4 of the OTMA Guide and reference (available at http://www-3.ibm.com/software/data/ims/shelf/v6pdf2/OTMA_V6.pdf) contains a list of OTMA sense codes and their cause. You should also see a message CSQ2001I in the SYSOUT of your MSTR started task that gives you additional information. Here are some common codes I have seen: 291 = MQFB_DATA_LENGTH_ZERO Data length zero. A segment length was zero in the application data of the message. 292 = MQFB_DATA_LENGTH_NEGATIVE Data length negative. A segment length was negative in the application data of the message. 293 = MQFB_DATA_LENGTH_TOO_BIG Data length too big. A segment length was too big in the application data of the message. 294 = MQFB_BUFFER_OVERFLOW Buffer overflow. The value of one of the length fields would cause the data to overflow the message buffer. 295 = MQFB_LENGTH_OFF_BY_ONE Length in error by one. The value of one of the length fields was one byte too short. 296 = MQFB_IIH_ERROR MQIIH structure not valid or missing. The Format field in MQMD specifies MQFMT_IMS, but the message does not begin with a valid MQIIH structure. 298 = MQFB_NOT_AUTHORIZED_FOR_IMS Userid not authorized for use in IMS. The user ID contained in the message descriptor MQMD, or the password contained in the Authenticator field in the MQIIH structure, failed the validation performed by the IMS bridge. As a result the message was not passed to IMS. 300 = MQFB_IMS_ERROR Unexpected error returned by IMS. An unexpected error was returned by IMS. Consult the MQSeries error log on the system on which the IMS bridge resides for more information about the error. . 301 = MQFB_IMS_FIRST Lowest value for IMS-generated feedback. 325 = VALID TCODE STOPPED Although a valid TCODE was specified, the TCODE in question has been stopped in IMS. 326 = INVALID TCODE The TCODE specified in the IIH header is not a valid TCODE. 399 = MQFB_IMS_LAST Highest value for IMS-generated feedback. -Original Message- From: Dick Killian [mailto:[EMAIL PROTECTED] Sent: Friday, April 30, 2004 9:25 AM To: [EMAIL PROTECTED] Subject: IMS Adapter I have inherited MQSeries Adapter for IMS. I am somewhat familiar with MQ but not IMS. A programmer is getting a feedback code of 335. Does anyone know where to look up these codes? It doesn't seem to be in MQ Messages and Codes? MQSeries v5.2, IMS v7, OS/390 v2.10 _ Regards, Dick Killian Energy East Utility Shared Services Information Technology Mainframe Systems Software (585) 771-6049 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list sub
Tracking question
Hi, I have a scenario where I need to send a response message within 30 seconds; however, if the application didn't put the response back by then, I still need to send a message saying something like " In process" or other user defined messages. I'm looking for a solutions or SupportPack to meet those requirements. Any help is appreciated. Thanks in advance, > Hossam > > 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: IMS Adapter
Peter is right on about the bridge (a real PITA to track down errors in this environment, IMHO) but Dick says he has a problem with the Adapter - and these are Bridge problems. I can't imagine the Adapter generating these kinds of errors. Bill -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Potkay, Peter M (PLC, IT) Sent: Friday, April 30, 2004 9:31 AM To: [EMAIL PROTECTED] Subject: Re: IMS Adapter When the IMS bridge receives a nonzero IMS-OTMA sense code, the IMS bridge converts the sense code from hexadecimal to decimal, adds the value MQFB_IMS_ERROR (300), and places the result in the Feedback field of the reply message. This results in the feedback code having a value in the range MQFB_IMS_FIRST (301) through MQFB_IMS_LAST (399) when an IMS-OTMA error has occurred. You have to subtract MQFB_ERROR from that value (300), which gives you the OTMA sense code. Chapter 4 of the OTMA Guide and reference (available at http://www-3.ibm.com/software/data/ims/shelf/v6pdf2/OTMA_V6.pdf) contains a list of OTMA sense codes and their cause. You should also see a message CSQ2001I in the SYSOUT of your MSTR started task that gives you additional information. Here are some common codes I have seen: 291 = MQFB_DATA_LENGTH_ZERO Data length zero. A segment length was zero in the application data of the message. 292 = MQFB_DATA_LENGTH_NEGATIVE Data length negative. A segment length was negative in the application data of the message. 293 = MQFB_DATA_LENGTH_TOO_BIG Data length too big. A segment length was too big in the application data of the message. 294 = MQFB_BUFFER_OVERFLOW Buffer overflow. The value of one of the length fields would cause the data to overflow the message buffer. 295 = MQFB_LENGTH_OFF_BY_ONE Length in error by one. The value of one of the length fields was one byte too short. 296 = MQFB_IIH_ERROR MQIIH structure not valid or missing. The Format field in MQMD specifies MQFMT_IMS, but the message does not begin with a valid MQIIH structure. 298 = MQFB_NOT_AUTHORIZED_FOR_IMS Userid not authorized for use in IMS. The user ID contained in the message descriptor MQMD, or the password contained in the Authenticator field in the MQIIH structure, failed the validation performed by the IMS bridge. As a result the message was not passed to IMS. 300 = MQFB_IMS_ERROR Unexpected error returned by IMS. An unexpected error was returned by IMS. Consult the MQSeries error log on the system on which the IMS bridge resides for more information about the error. . 301 = MQFB_IMS_FIRST Lowest value for IMS-generated feedback. 325 = VALID TCODE STOPPED Although a valid TCODE was specified, the TCODE in question has been stopped in IMS. 326 = INVALID TCODE The TCODE specified in the IIH header is not a valid TCODE. 399 = MQFB_IMS_LAST Highest value for IMS-generated feedback. -Original Message- From: Dick Killian [mailto:[EMAIL PROTECTED] Sent: Friday, April 30, 2004 9:25 AM To: [EMAIL PROTECTED] Subject: IMS Adapter I have inherited MQSeries Adapter for IMS. I am somewhat familiar with MQ but not IMS. A programmer is getting a feedback code of 335. Does anyone know where to look up these codes? It doesn't seem to be in MQ Messages and Codes? MQSeries v5.2, IMS v7, OS/390 v2.10 _ Regards, Dick Killian Energy East Utility Shared Services Information Technology Mainframe Systems Software (585) 771-6049 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General 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: Message Tracking
Del, this whole discussion started with "we have no money... " maybe you as a designer can talk to the sales guys to come up with "development" license fees in addition to "production" license fees? you could also see this as a stepping stone as people get used to functionality, no one will argue the difference between "development" fee versus "production" fees... my 2 cents... Michael -Oorspronkelijk bericht-Van: MQSeries List [mailto:[EMAIL PROTECTED]Namens DelVerzonden: Friday, April 30, 2004 7:31 PMAan: [EMAIL PROTECTED]Onderwerp: Re: Message Tracking yes, but what about non-persistent messages?... I know that companies such as Cressida offer log recovery products, but I still like our solution best (as the designer, of course I am totally biased...) -- I also agree very much with education of the LOB developers suggested by Bobbee and others, but it doesn't resolve the audit and compliance issues being raised these days... http://www-306.ibm.com/software/integration/mqreconda/ "Bright, Frank" <[EMAIL PROTECTED]> wrote: I am going to offer another opinion about message tracking.IBM logs message activity within its own logs for recovery purposes. I justthink the exit you propose is a duplication of the internal MQ logging. IBMmade use of the MQ logs in the creation of the MO12 (MQSeries for OS/390 -Log extract program) support pac. I believe this capability to trackmessages should be built into the product across the platforms.ThanksFrank-Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of GunterJeschawitzSent: Thursday, April 29, 2004 8:24 AMTo: [EMAIL PROTECTED]Subject: Re: Message TrackingI played around with the sample API Exit and installed it for the listenerand I believe you'll get all information needed. It only works for you ifthe application use client connection.This will produce very big log-files so I can't recommend to use it in anproduction environment, but in your case it may be acceptable.GunterInstructions for managing your mailing list subscription are provided in theListserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive-This e-mail message and any attachments contain confidential information from Medco. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments.Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Message Tracking
Title: Message To put this as a problems and not a suggestion or solution as James requested, I think a fundamental problem is that it is difficult to track messages once they have been removed from a queue. Thus if an application puts a message on a local queue and another one has been left reading messages from a queue, the original developer asks "where's my message - MQ lost it". We have no real way to prove otherwise - even saying "see - the input procs is > 0 so someone read the message" is not conclusive because we also say to developers when messages build up that input procs > 0 doesn't prove anything as the input procs only indicates someone has the queue open for input, not that they're actually doing any MQGETs on it. Another problem is that when messages expire, we have no way of proving this has happened either. Whether IBM provide a solution using the transaction logs or not is an implementation detail I will leave to them. Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd -Original Message-From: Glen Shubert [mailto:[EMAIL PROTECTED] Sent: 30 April 2004 16:27To: [EMAIL PROTECTED]Subject: Re: Message TrackingI fully agree with Frank. As a matter of fact, I had a conversation with IBM about that about 3 weeks ago. I told them that we needed a tool to be able to track messages from the time we received it to the point it left my queue manager. This would include CICS gets/puts, Database time, etc.Glen Shubert[EMAIL PROTECTED]Associate DirectorTSYS - MQSeries Technical Support "Bright, Frank" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 04/30/04 11:11 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: Message TrackingI am going to offer another opinion about message tracking.IBM logs message activity within its own logs for recovery purposes. I justthink the exit you propose is a duplication of the internal MQ logging. IBMmade use of the MQ logs in the creation of the MO12 (MQSeries for OS/390 -Log extract program) support pac. I believe this capability to trackmessages should be built into the product across the platforms.Thanks Frank-Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of GunterJeschawitzSent: Thursday, April 29, 2004 8:24 AMTo: [EMAIL PROTECTED]Subject: Re: Message TrackingI played around with the sample API Exit and installed it for the listenerand I believe you'll get all information needed. It only works for you ifthe application use client connection.This will produce very big log-files so I can't recommend to use it in anproduction environment, but in your case it may be acceptable.GunterInstructions for managing your mailing list subscription are provided in theListserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive-This e-mail message and any attachments contain confidential information from Medco. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments.Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you ** Click here to visit the Argos home page http://www.argos.co.uk The information contained in this message or any of its attachments may be privileged and/or confidential, and is intended exclusively for the addressee. Unauthorised disclosure, copying or distribution of the contents is strictly prohibited. The views expressed may not be official policy, but the personal views of the originator. If you have received t
Re: Message Tracking
yes, but what about non-persistent messages?... I know that companies such as Cressida offer log recovery products, but I still like our solution best (as the designer, of course I am totally biased...) -- I also agree very much with education of the LOB developers suggested by Bobbee and others, but it doesn't resolve the audit and compliance issues being raised these days... http://www-306.ibm.com/software/integration/mqreconda/ "Bright, Frank" <[EMAIL PROTECTED]> wrote: I am going to offer another opinion about message tracking.IBM logs message activity within its own logs for recovery purposes. I justthink the exit you propose is a duplication of the internal MQ logging. IBMmade use of the MQ logs in the creation of the MO12 (MQSeries for OS/390 -Log extract program) support pac. I believe this capability to trackmessages should be built into the product across the platforms.ThanksFrank-Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of GunterJeschawitzSent: Thursday, April 29, 2004 8:24 AMTo: [EMAIL PROTECTED]Subject: Re: Message TrackingI played around with the sample API Exit and installed it for the listenerand I believe you'll get all information needed. It only works for you ifthe application use client connection.This will produce very big log-files so I can't recommend to use it in anproduction environment, but in your case it may be acceptable.GunterInstructions for managing your mailing list subscription are provided in theListserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive-This e-mail message and any attachments contain confidential information from Medco. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments.Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Setmqaut on v5.1
Did you try TST.** ? I believe TST.* will only work for TST.XXX and not for TST.XXX.YYY. Nick -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, April 30, 2004 12:07 AM To: [EMAIL PROTECTED] Subject: Setmqaut on v5.1 Howdy all (again), I am in the process of migrating an old v5.1 server to v5.3 on a new platform. As part of the process I have moved a copy of the queue managers over to the new Win2K machine and they work ok, but I am having security nightmares prior to upgrading the MQ to v5.3 When I try: Setmqaut -m QML_MQM -t q -n TST.* -g MQCLIENTS +put -get +inq +browse I get AMQ7085: Object TST.*, type q not found I have thousands of queues which are named: TST.abc01 TST.abc01.data TST.abc02 TST.abc02.data I have tried variations on -g and -p using groups and principals, I have also tried TST.*.* and every vriant I can think of. The manual (SC34-6068-00) System Administration Guide says you can use wildcards!! (page 308)... But it doesn't work! What am I doing wrong ? Sid Young 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: Server Farm Specs
An old IBM saying goes: It's better to have one queue manager with 100 queues than 10 queue managers with 10 queues each... -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of W Samuel Sent: Friday, April 30, 2004 11:09 AM To: [EMAIL PROTECTED] Subject: Server Farm Specs Hi everyone, What are parameters that we would consider for deciding on the specifications for a Server that'll host initially 10 queue managers and that can grow in future ... has to be 24 x 7 Looking at AIX as the operating system .. but not clear on how to arrive at the specs for such a host system Any docs on this ? Your thoughts please .. Thanks, WS Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html 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: Message Tracking
I fully agree with Frank. As a matter of fact, I had a conversation with IBM about that about 3 weeks ago. I told them that we needed a tool to be able to track messages from the time we received it to the point it left my queue manager. This would include CICS gets/puts, Database time, etc. Glen Shubert [EMAIL PROTECTED] Associate Director TSYS - MQSeries Technical Support "Bright, Frank" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 04/30/04 11:11 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: Message Tracking I am going to offer another opinion about message tracking. IBM logs message activity within its own logs for recovery purposes. I just think the exit you propose is a duplication of the internal MQ logging. IBM made use of the MQ logs in the creation of the MO12 (MQSeries for OS/390 - Log extract program) support pac. I believe this capability to track messages should be built into the product across the platforms. Thanks Frank -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Gunter Jeschawitz Sent: Thursday, April 29, 2004 8:24 AM To: [EMAIL PROTECTED] Subject: Re: Message Tracking I played around with the sample API Exit and installed it for the listener and I believe you'll get all information needed. It only works for you if the application use client connection. This will produce very big log-files so I can't recommend to use it in an production environment, but in your case it may be acceptable. Gunter Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive - This e-mail message and any attachments contain confidential information from Medco. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
Re: Message Tracking
I am going to offer another opinion about message tracking. IBM logs message activity within its own logs for recovery purposes. I just think the exit you propose is a duplication of the internal MQ logging. IBM made use of the MQ logs in the creation of the MO12 (MQSeries for OS/390 - Log extract program) support pac. I believe this capability to track messages should be built into the product across the platforms. Thanks Frank -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Gunter Jeschawitz Sent: Thursday, April 29, 2004 8:24 AM To: [EMAIL PROTECTED] Subject: Re: Message Tracking I played around with the sample API Exit and installed it for the listener and I believe you'll get all information needed. It only works for you if the application use client connection. This will produce very big log-files so I can't recommend to use it in an production environment, but in your case it may be acceptable. Gunter Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive - This e-mail message and any attachments contain confidential information from Medco. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Message Tracking
Unfortunately, the biggest thing that continually trips up most developers is their belief in their own ability; there couldn't possibly be anything wrong with their code, could there ? But seriously, as Bobbee said, its about education; most developers don't understand the implications of what they are coding re. things like persistence, expiry, msgid, correlid, syncpoints etc. Steve. -Original Message- From: James Kingdon [mailto:[EMAIL PROTECTED] Sent: 30 April 2004 14:31 To: [EMAIL PROTECTED] Subject: Re: Message Tracking I'd be interested to hear what the most common scenarios are that lead to developers believing that MQ lost their message, particularly when using the JMS API. As has been mentioned in this thread, this isn't the sort of complaint that you hear raised against ftp or databases, but does seem to occur with reasonable frequency with messaging. This might indicate that our APIs aren't as good, or that the underlying paradigm is more complex, but in either case suggests that we could do more to support developers facing the question "where's my message?". I can think of a few obvious things that crop up on a regular basis: not starting the JMS Connection sending a message under transaction and not committing incorrectly formed message selectors remote client connections performing receives outside of syncpoint using message expiry publishing messages before creating the subscriber sending the message somewhere other than where it was supposed to go another application left running that consumes from the same destination With the added power of the MQI there are plenty of additional problems that can arise, like forgetting to clear messageID and correlationID fields when reusing the MQMD, and we haven't yet got to problems of multi-queue manager routing or adding a transformation engine to the mix. So, let me know what sort of things trip up your developers (or yourselves - I think I've done *all* of the above at sometime or other) and I'll push for features that will hopefully make it easier to support and work with our products. It would be best if you send problems, not suggestions for solutions - I'm not sure what the IP implications would be for the latter, and I wouldn't want good ideas to be delayed from getting into the product because of legal concerns. No promises, no time-scales, but rest assured we're listening. Regards, James. 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
Server Farm Specs
Hi everyone, What are parameters that we would consider for deciding on the specifications for a Server that'll host initially 10 queue managers and that can grow in future ... has to be 24 x 7 Looking at AIX as the operating system .. but not clear on how to arrive at the specs for such a host system Any docs on this ? Your thoughts please .. Thanks, WS Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html 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: Message Tracking
James, In my experience the most common problem has been programmer ignorance. I do not mean to disparage programmers by this, some simply do not understand MQ. For instance I get phone calls where a user wants to know why their 'queue isn't running'. You don't know what you don't know. In most cases, after directing programmers to the Application Programming manuals the number of uninformed questions are greatly reduced. As for the API's, if anything they are overly simple. By that I mean that it is very easy to code the calls for MQ. So, many programmers read just enough to be able to get their programs to compile. Couple this with the assured delivery concept/promise of MQ and some think that the rest is magic. They never think through the whole design of actually moving the messages to their destination. That may also be an effect of compartmentalizing the responsibilities of writing applications to interface with MQ and actually administering MQ. These are just some of my impressions for what they're worth... -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of James Kingdon Sent: Friday, April 30, 2004 9:31 AM To: [EMAIL PROTECTED] Subject: Re: Message Tracking I'd be interested to hear what the most common scenarios are that lead to developers believing that MQ lost their message, particularly when using the JMS API. As has been mentioned in this thread, this isn't the sort of complaint that you hear raised against ftp or databases, but does seem to occur with reasonable frequency with messaging. This might indicate that our APIs aren't as good, or that the underlying paradigm is more complex, but in either case suggests that we could do more to support developers facing the question "where's my message?". I can think of a few obvious things that crop up on a regular basis: not starting the JMS Connection sending a message under transaction and not committing incorrectly formed message selectors remote client connections performing receives outside of syncpoint using message expiry publishing messages before creating the subscriber sending the message somewhere other than where it was supposed to go another application left running that consumes from the same destination With the added power of the MQI there are plenty of additional problems that can arise, like forgetting to clear messageID and correlationID fields when reusing the MQMD, and we haven't yet got to problems of multi-queue manager routing or adding a transformation engine to the mix. So, let me know what sort of things trip up your developers (or yourselves - I think I've done *all* of the above at sometime or other) and I'll push for features that will hopefully make it easier to support and work with our products. It would be best if you send problems, not suggestions for solutions - I'm not sure what the IP implications would be for the latter, and I wouldn't want good ideas to be delayed from getting into the product because of legal concerns. No promises, no time-scales, but rest assured we're listening. Regards, James. 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: Message Tracking
I think there is a lot of good stuff already in the product to insure that the program knows what happened to its message(syncpoints, report messages, etc). IF the programmers only take time to learn it, understand it, implement it, and act upon it. An MQAdmins job seems to be to prove MQ works and to understanding all the connecting apps. I would bet there would be a lot more cases of missing DB2 inserts if the goal was for JMS to call a DB2 insert which sent the row to another DB2 table on another server that then transformed that into an Oracle insert that then inserted it on a SQL server in East Hoboken. Oh, and it needed its row updated back in LA on the original DB in under 2 seconds with the result of all this. And if MQ was just doing an MQPUT to a local queue and that's it, there would be no problems. Man, who calls and yells at AT&T that the phone system has crashed when the person you are calling is not home to answer the phone? -Original Message- From: James Kingdon [mailto:[EMAIL PROTECTED] Sent: Friday, April 30, 2004 9:31 AM To: [EMAIL PROTECTED] Subject: Re: Message Tracking I'd be interested to hear what the most common scenarios are that lead to developers believing that MQ lost their message, particularly when using the JMS API. As has been mentioned in this thread, this isn't the sort of complaint that you hear raised against ftp or databases, but does seem to occur with reasonable frequency with messaging. This might indicate that our APIs aren't as good, or that the underlying paradigm is more complex, but in either case suggests that we could do more to support developers facing the question "where's my message?". I can think of a few obvious things that crop up on a regular basis: not starting the JMS Connection sending a message under transaction and not committing incorrectly formed message selectors remote client connections performing receives outside of syncpoint using message expiry publishing messages before creating the subscriber sending the message somewhere other than where it was supposed to go another application left running that consumes from the same destination With the added power of the MQI there are plenty of additional problems that can arise, like forgetting to clear messageID and correlationID fields when reusing the MQMD, and we haven't yet got to problems of multi-queue manager routing or adding a transformation engine to the mix. So, let me know what sort of things trip up your developers (or yourselves - I think I've done *all* of the above at sometime or other) and I'll push for features that will hopefully make it easier to support and work with our products. It would be best if you send problems, not suggestions for solutions - I'm not sure what the IP implications would be for the latter, and I wouldn't want good ideas to be delayed from getting into the product because of legal concerns. No promises, no time-scales, but rest assured we're listening. Regards, James. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: IMS Adapter
When the IMS bridge receives a nonzero IMS-OTMA sense code, the IMS bridge converts the sense code from hexadecimal to decimal, adds the value MQFB_IMS_ERROR (300), and places the result in the Feedback field of the reply message. This results in the feedback code having a value in the range MQFB_IMS_FIRST (301) through MQFB_IMS_LAST (399) when an IMS-OTMA error has occurred. You have to subtract MQFB_ERROR from that value (300), which gives you the OTMA sense code. Chapter 4 of the OTMA Guide and reference (available at http://www-3.ibm.com/software/data/ims/shelf/v6pdf2/OTMA_V6.pdf) contains a list of OTMA sense codes and their cause. You should also see a message CSQ2001I in the SYSOUT of your MSTR started task that gives you additional information. Here are some common codes I have seen: 291 = MQFB_DATA_LENGTH_ZERO Data length zero. A segment length was zero in the application data of the message. 292 = MQFB_DATA_LENGTH_NEGATIVE Data length negative. A segment length was negative in the application data of the message. 293 = MQFB_DATA_LENGTH_TOO_BIG Data length too big. A segment length was too big in the application data of the message. 294 = MQFB_BUFFER_OVERFLOW Buffer overflow. The value of one of the length fields would cause the data to overflow the message buffer. 295 = MQFB_LENGTH_OFF_BY_ONE Length in error by one. The value of one of the length fields was one byte too short. 296 = MQFB_IIH_ERROR MQIIH structure not valid or missing. The Format field in MQMD specifies MQFMT_IMS, but the message does not begin with a valid MQIIH structure. 298 = MQFB_NOT_AUTHORIZED_FOR_IMS Userid not authorized for use in IMS. The user ID contained in the message descriptor MQMD, or the password contained in the Authenticator field in the MQIIH structure, failed the validation performed by the IMS bridge. As a result the message was not passed to IMS. 300 = MQFB_IMS_ERROR Unexpected error returned by IMS. An unexpected error was returned by IMS. Consult the MQSeries error log on the system on which the IMS bridge resides for more information about the error. . 301 = MQFB_IMS_FIRST Lowest value for IMS-generated feedback. 325 = VALID TCODE STOPPED Although a valid TCODE was specified, the TCODE in question has been stopped in IMS. 326 = INVALID TCODE The TCODE specified in the IIH header is not a valid TCODE. 399 = MQFB_IMS_LAST Highest value for IMS-generated feedback. -Original Message- From: Dick Killian [mailto:[EMAIL PROTECTED] Sent: Friday, April 30, 2004 9:25 AM To: [EMAIL PROTECTED] Subject: IMS Adapter I have inherited MQSeries Adapter for IMS. I am somewhat familiar with MQ but not IMS. A programmer is getting a feedback code of 335. Does anyone know where to look up these codes? It doesn't seem to be in MQ Messages and Codes? MQSeries v5.2, IMS v7, OS/390 v2.10 _ Regards, Dick Killian Energy East Utility Shared Services Information Technology Mainframe Systems Software (585) 771-6049 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Message Tracking
I'd be interested to hear what the most common scenarios are that lead to developers believing that MQ lost their message, particularly when using the JMS API. As has been mentioned in this thread, this isn't the sort of complaint that you hear raised against ftp or databases, but does seem to occur with reasonable frequency with messaging. This might indicate that our APIs aren't as good, or that the underlying paradigm is more complex, but in either case suggests that we could do more to support developers facing the question "where's my message?". I can think of a few obvious things that crop up on a regular basis: not starting the JMS Connection sending a message under transaction and not committing incorrectly formed message selectors remote client connections performing receives outside of syncpoint using message expiry publishing messages before creating the subscriber sending the message somewhere other than where it was supposed to go another application left running that consumes from the same destination With the added power of the MQI there are plenty of additional problems that can arise, like forgetting to clear messageID and correlationID fields when reusing the MQMD, and we haven't yet got to problems of multi-queue manager routing or adding a transformation engine to the mix. So, let me know what sort of things trip up your developers (or yourselves - I think I've done *all* of the above at sometime or other) and I'll push for features that will hopefully make it easier to support and work with our products. It would be best if you send problems, not suggestions for solutions - I'm not sure what the IP implications would be for the latter, and I wouldn't want good ideas to be delayed from getting into the product because of legal concerns. No promises, no time-scales, but rest assured we're listening. Regards, James. 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
IMS Adapter
I have inherited MQSeries Adapter for IMS. I am somewhat familiar with MQ but not IMS. A programmer is getting a feedback code of 335. Does anyone know where to look up these codes? It doesn't seem to be in MQ Messages and Codes? MQSeries v5.2, IMS v7, OS/390 v2.10 _ Regards, Dick Killian Energy East Utility Shared Services Information Technology Mainframe Systems Software (585) 771-6049 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: Extended Transactional Client & WLS
Pavel, we have done this with WL 6.1 and JMS. Been in production for about 3 months. -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Thursday, April 29, 2004 10:00 PM To: [EMAIL PROTECTED] Subject: Extended Transactional Client & WLS Hello, Has anyone gotten these two working together? I am interested in sending a message from some session or other EJB to MQ queue, under the XA transaction, managed by Weblogic (8.1 SP2). I did not start trying yet; before going into it, I am trying to get encouraged by hearing that this is doable. Preferably, I would use "pure" Java MQ (i.e. non-JMS) but if it is not an option, JMS would do, too. Thank you, Pavel -- 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 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: Removing a dead server from an MQ cluster
Just remember (from the Clusters manual):
"You can issue the RESET CLUSTER command only from full repository queue managers."
Mike Davidson
TSYS MQ Tech Support
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Sent by: MQSeries List <[EMAIL PROTECTED]>
04/29/2004 10:32 PM
Please respond to MQSeries List
To: [EMAIL PROTECTED]
cc:
Subject: Removing a dead server from an MQ cluster
Howdy all,
I have a server (MQ2) that has been disconnected (forceably) from a cluster
and physically removed and will not be replaced. The existing queue manager
(MQ1) on the other server still thinks it is present. Can I issue a reset
cluster command on MQ1 as shown below safely:
Reset cluster('MQCLUSTER') QMNAME('MQ2') ACTION(FORCEREMOVE) QUEUES(YES)
Thanks
Sid
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
The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
Re: MQ clustering experience
Don't even consider this unless you are 5.3. Clustering is much improved at this level. Check out this doc, which is "MD05: MQSeries - Design considerations for large Clusters": http://www-1.ibm.com/support/docview.wss?rs=203&q1=mA1J&uid=swg24006367&loc=en_US&cs=utf-8&lang=en And this one, which is "MP7A: WebSphere MQ for Windows V5.3 - Performance tuning for large clusters": http://www-1.ibm.com/support/docview.wss?rs=203&uid=swg24006424&loc=en_US&cs=utf-8&lang=en Don't cluster just so you can say you are clustered. You don't need workload balancing, one of the major benifits of clustering. The other benifit is reduce administration. Your design basically says its the enterprise QMs talking only with the distributed QMs. Well the more enterpise QMs you have, assuming each one has to talk to each distributed QM, the more savings you will have as far as defing channels and XMIT queues. And more savings still if the enterprise QMs need to talk to each other as well. And the more queues you have, the less work their will be proportianalty for building all those remote queue defs. I suppose the apps could always MQOPEN the queue/QM, so their would be no need for remote defs... A lot of clustering magic is still undocemented and under the covers. IF something goes wrong, it is a lot easier to try and fix regular old distributed channels than clustering. But, it is getting more stable with every release and there is more documentation as time goes by. Get yourself a copy of the advanced clustering session from last year's conferance, which contains good stuff found nowhere else. Or better yet, go to this year's conferance and attend all the clustering sessions. -Original Message-From: Mike Davidson [mailto:[EMAIL PROTECTED]Sent: Friday, April 30, 2004 7:04 AMTo: [EMAIL PROTECTED]Subject: Re: MQ clustering experienceYour concerns that the "workload balancing" benefits of clustering might not apply to your situation are valid. However, another (rather valuable) benefit to implementing MQ clustering in such an environment as yours with many qmgrs is the reduction in object definitions to maintain. There are, of course, other considerations that need to be accounted for - such as your mention of certain qmgrs not having a need for channels to other qmgrs. That's fine in clustering - if the qmgrs don't need to talk, then MQ won't create the auto-defined senders. But, on the flip-side, if they ever do need to talk MQ will dynamically create them as needed. It sounds like you may even want to set up a couple of clusters - grouping qmgrs together depending on business process, environment, geography, etc. The mention of multiple clusters sometimes makes folks cringe, but it might suit your situation - you'll have to decide for yourself. This is the kind of thread that could go on for a while. I know that there are many more things that could be said about your concerns, and the things I've mentioned are some basic (yet important) considerations, but that's the first thing that came to mind about your scenario.I hope this helps. Mike DavidsonTSYS MQ Tech Support[EMAIL PROTECTED] "[EMAIL PROTECTED]" Sent by: MQSeries List <[EMAIL PROTECTED]> 04/30/2004 12:11 AM Please respond to "[EMAIL PROTECTED]" To: [EMAIL PROTECTED] cc: Subject: MQ clustering experienceHello Everyone, I am working at a shop that is revamping it's use of MQ. To date, my personal experience supporting MQ has not included using clustering. A proposal is under consideration to deploy hundreds of MQ servers as one cluster. This would include a handful of enterprise side QMGRs (including a few on z/OS) with the majority of QMGRs being widely dispersed. There is currently no need for the dispersed QMGRs to connect to each other so channels would exist between the enterprise QMGRs and the individual, dispersed QMGRs. Each dispersed QMGR would essentially be a clone of one another ... meaning something in the MQ object names on each QMGR would be unique but the number, type and attributes of the MQ objects from one QMGR to another would be uniform. There is also no use of client connections currently under consideration. The topology of the QMGRs will leave little, or no, opportunity to employ workload distribution. The enter prise side QMGRs will regularly be used to deliver messages to all of the dispersed QMGRs. While I crack the manuals and review the list's archives to learn more specifics about clustering benefits and pitfalls, I would appreciate hearing from others with experience using clustering, especially larger clusters. If the proposal is adopted, with what am I likely to be confronted? Will the single cluster transmit queue on each enterprise QMGR adequately ser
Re: Backout of failed a C++ Application
IIRC on MVS the default is COMMIT, not BACKOUT when the application fails Dave
Re: Removing a dead server from an MQ cluster
As long as MQ1 is a Full Repository, yes.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 29, 2004 10:33 PM
To: [EMAIL PROTECTED]
Subject: Removing a dead server from an MQ cluster
Howdy all,
I have a server (MQ2) that has been disconnected (forceably) from a cluster
and physically removed and will not be replaced. The existing queue manager
(MQ1) on the other server still thinks it is present. Can I issue a reset
cluster command on MQ1 as shown below safely:
Reset cluster('MQCLUSTER') QMNAME('MQ2') ACTION(FORCEREMOVE) QUEUES(YES)
Thanks
Sid
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all copies.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Backout of failed a C++ Application
Can anyone explain what should happen if the above application has got a message under syncpoint and then crashes. Logically I know that the message should re-appear on the queue, especially if a disconnect is issued, but I'm wondering how the qmanager knows that the application has died and that the connection handle should be removed from its pool and any uncommitted work backed out. Is it possible that the connection handle survives the unplanned termination of the applciation, and therefore does not release the handle and backout those uncomitted messages? The scenario here is that messages do not appear to be returned to the queue when the app fails. Of course there may be another reason for this, though the app code I have seen does not appear to rollback any messages or dump them on the DLQ. Upon an app restart, there is knowledge of the messages previously conusumed but not yet committed. There is only one instance of the application, we believe. MQ Version is 5.2.1 I believe, platform Windows 2000 or similar. MQ clusters are in place though I'm led to believe that affinities exist and are catered for, as in this case. Any views appreciated. Neil
OpenVMS Cluster
Anybody implemented MQ in an OpenVMS cluster? Any guidelines / best practices etc? Steve.
Re: MQ clustering experience
Your concerns that the "workload balancing" benefits of clustering might not apply to your situation are valid. However, another (rather valuable) benefit to implementing MQ clustering in such an environment as yours with many qmgrs is the reduction in object definitions to maintain. There are, of course, other considerations that need to be accounted for - such as your mention of certain qmgrs not having a need for channels to other qmgrs. That's fine in clustering - if the qmgrs don't need to talk, then MQ won't create the auto-defined senders. But, on the flip-side, if they ever do need to talk MQ will dynamically create them as needed. It sounds like you may even want to set up a couple of clusters - grouping qmgrs together depending on business process, environment, geography, etc. The mention of multiple clusters sometimes makes folks cringe, but it might suit your situation - you'll have to decide for yourself. This is the kind of thread that could go on for a while. I know that there are many more things that could be said about your concerns, and the things I've mentioned are some basic (yet important) considerations, but that's the first thing that came to mind about your scenario. I hope this helps. Mike Davidson TSYS MQ Tech Support [EMAIL PROTECTED] "[EMAIL PROTECTED]" Sent by: MQSeries List <[EMAIL PROTECTED]> 04/30/2004 12:11 AM Please respond to "[EMAIL PROTECTED]" To: [EMAIL PROTECTED] cc: Subject: MQ clustering experience Hello Everyone, I am working at a shop that is revamping it's use of MQ. To date, my personal experience supporting MQ has not included using clustering. A proposal is under consideration to deploy hundreds of MQ servers as one cluster. This would include a handful of enterprise side QMGRs (including a few on z/OS) with the majority of QMGRs being widely dispersed. There is currently no need for the dispersed QMGRs to connect to each other so channels would exist between the enterprise QMGRs and the individual, dispersed QMGRs. Each dispersed QMGR would essentially be a clone of one another ... meaning something in the MQ object names on each QMGR would be unique but the number, type and attributes of the MQ objects from one QMGR to another would be uniform. There is also no use of client connections currently under consideration. The topology of the QMGRs will leave little, or no, opportunity to employ workload distribution. The enter prise side QMGRs will regularly be used to deliver messages to all of the dispersed QMGRs. While I crack the manuals and review the list's archives to learn more specifics about clustering benefits and pitfalls, I would appreciate hearing from others with experience using clustering, especially larger clusters. If the proposal is adopted, with what am I likely to be confronted? Will the single cluster transmit queue on each enterprise QMGR adequately service messages intended for many / all of the dispersed QMGRs in this cluster configuration? Without the benefits of workload distribution, I am concerned whether clustering in this situation is prudent. Thanks for your thought, Bill 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 The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
Re: Message Tracking
"Give them a Fish and they eat for the day. Teach them to fish and they eat forever". Maybe and education of MQ Architecture would be helpful. I know "MOST" (?" developers can sit still for a few minutes to have explained WHY the message cannot be lost. Works at my current site. AND THAT'S GOVERNMENT!! bobbee From: "Adiraju, Rao" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Message Tracking Date: Fri, 30 Apr 2004 09:31:12 +1200 Hi Roger What you are trying to do is "perception" management. For "perception" management, from my experience, the things that you are going develop will not help. It will take lot of your time in developing and explaining these reports to your newbie developers. If you think by showing all tracing reports to every tom, , and Harry and convince them that there messages aren't lost - you will have a huge battle ahead. By all this, newbie's will confuse and will scare more of the MQ product and it will aggravate the perceptions more. If I were you, I would have taken the other route - ie: talk to your boss, then your VP followed by their VP and before he/she hears their complaint sell the idea that MQ don't loose messages and new comers need some sort of in-house training/orientation to be effective. It isn't that difficult to convince the senior management given the IBM backing and others experiences in this arena. That's how I have dealt it in before, that's how I handle it in future. Anyway keep us posted with your experiences. Cheers Rao Ps: if my boss (and bosses boss) don't have a trust on me, my consultancy won't last long anyway, and I will be looking for somewhere else before it is too late. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: 30 April 2004 6:16 AM To: [EMAIL PROTECTED] Subject: Re: Message Tracking Hi, I would love to do that but it won't fly. They are already confused enough with doing JMS / Java with MQ inside WebLogic. Unless I take over the coding there is no hope in hell of implementing that type of framework. I can just hear the comments: You want to use an abstract layer to call an abstract layer (JMS) to put a message to a queue. No, I think I'll skip that headache. :) Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting David Awerbuch <[EMAIL PROTECTED]>: > Roger, > > Perhaps as the "Messaging Architect" you can request that they first > develop a messaging API that must be used by all developers. This > API, based on the values of environment variables, would be able to > log anything and/or everything you might want it to at a particular > time. Not only would this externally controlled logging system make a > great debugging tool for developers, it would probably prove > invaluable in shooting down a real program bug that only raises its > ugly head under very specific circumstances and only in production. > > I have implemented APIs like this for different clients in different > messaging / store-and-forward systems more times than I care to > remember. Each time, this simple interface has saved our butts during > a real production problem. > Each time, it proved the messaging system was working flawlessly, and > that there was some other problem with the application - > complex-conditional logic errors, errant pointers, "dynamic" static > data, and compiler optimization errors, just to name four. > > Dave A. > > > -Original Message- > From: Roger Lacroix [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 29, 2004 11:16 AM > To: [EMAIL PROTECTED] > Subject: Re: Message Tracking > > > Hi, > > I fully agree with you but sadly as the 'Messaging Architect' for one > division I do not have the authority to request or mandate anything. > I can only recommend things. > > I have written WMQ Naming Standards documents and WMQ Programming > Standards documents for the client but it just goes over the newbie's head. > > So, this may be a difficult solution but it will give me fewer > headaches. :) > > Regards, > Roger Lacroix > Capitalware Inc. > http://www.capitalware.biz > > > Quoting "Benjamin F. Zhou" <[EMAIL PROTECTED]>: > > > Roger, > > > > you seem want to show them evidence that THEY are nuts. it probably > > won't work that way. Beside, with the time you need for one or more > > evidence collector, you could have long taught all of them enough to > > be good-enough MQ-developers. > > > > cheers, > > > > Benjamin F. Zhou > > Technical Specialist > > Messaging&Integration Supp. > > Mercedes-Benz USA > > x.2474 > > > > > > > > Roger Lacroix > > <[EMAIL PROTECTED] To: > > [EMAIL PROTECTED] > > ALWARE.BIZ> cc: > > Sent by: MQSeriesSubject: Message > Tracking > > List > > <[EMAIL PROTECTED] > > C.AT> > > > > > >
Re: ESQL SELECT to fetch non-null tags
Sorry, but I don't understand your problem correctly - perhaps because
I don't know your input. Can you send me the input XML structure?
Tibor
> Tibor,
> Sorry I forgot to mention that I can have others tags under Books.
> But I need to fill the array with Book1 , 2 or 3 which ever exists.
> Is there some way that I can refer to this Variable.
> I tried REF.{'Book' || CAST I AS CHAR'};
> Does'nt Work!
> Tibor <[EMAIL PROTECTED]> wrote:
> I try something like this (not tested):
> DECLARE I INTEGER;
> DECLARE J INTEGER;
> DECLARE C INTEGER;
> SET I = 1;
> SET J = 1;
> SET C = CARDINALITY(InputRoot.XML.Books[]);
> WHILE I <= C DO
> IF InputRoot.XML.Books.*[I] IS NOT NULL THEN
> SET APR[J] = InputRoot.XML.Books.*[I];
> SET J=J+1;
> END IF;
> SET I=I+1;
> END WHILE;
> But when cardinality of Books[] is large, using reference is more
> efficient.
> Tibor
>
>> I have an XML
>>
>> A
>> B
>> C
>>
>> I want to fill out an array with only the non null tags Book1 , Book2 and Book3.
>> If Book2 is not present I want ARR[1] = A and ARR[2]=C
>> How should my ESQL be?
>> -
>> Do you Yahoo!?
>> Win a $20,000 Career Makeover at Yahoo! HotJobs
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive
> -
> Do you Yahoo!?
> Win a $20,000 Career Makeover at Yahoo! HotJobs
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: Setmqaut on v5.1
And while you are at it - go straight to CSD06 or higher. Dave Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: ESQL : CASE WHEN
Won't work because syntax definition of 'CASE'
#1
SET myVar = CASE UPPER(var)
WHEN 'AB' THEN '12'
WHEN 'CD' THEN '00'
WHEN 'EF' THEN '00'
WHEN 'GH' THEN '00'
END;
#2
SET myVar = CASE
WHEN UPPER(var) = 'AB' THEN '12'
WHEN UPPER(var) IN ('CD' , 'EF' , 'GH') THEN '00'
END;
#3 (but this isn't identical to your question)
SET myVar = CASE UPPER(var)
WHEN 'AB' THEN '12'
ELSE '00'
END;
By the way, clause 'ELSE' is recommended to avoid NULL values.
HTH,
Tibor
> Can I not have multiple condition in a case like..
> SET myVar = CASE UPPER(var)
>WHEN 'AB' THEN '12'
>WHEN 'CD' OR 'EF' OR 'GH' THEN '00'
>END;
> I tried
> SET myVar = CASE UPPER(var)
>WHEN 'AB' THEN '12'
>WHEN IN ('CD' , 'EF' , 'GH') THEN '00'
>END;
> Gives me an error !!
> __
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.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: Setmqaut on v5.1
Hi Sid, If you are using setmqaut on V5.1 Then you must not use a generic name for the profile. Please refer the document for Version V5.1 System Admin (SC34-6068-00) is for Version 5.3 If it is failing on Version 5.3, I think you need to apply the fix for it. https://www6.software.ibm.com/dl/wsmqcsd/wsmqcsd-p WebSphere MQ v5.3 CSD01 Harshal. IBM CERTIFIED System Administrator WebSphere MQ V5.3 -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, April 30, 2004 12:37 PM To: [EMAIL PROTECTED] Subject: Setmqaut on v5.1 Howdy all (again), I am in the process of migrating an old v5.1 server to v5.3 on a new platform. As part of the process I have moved a copy of the queue managers over to the new Win2K machine and they work ok, but I am having security nightmares prior to upgrading the MQ to v5.3 When I try: Setmqaut -m QML_MQM -t q -n TST.* -g MQCLIENTS +put -get +inq +browse I get AMQ7085: Object TST.*, type q not found I have thousands of queues which are named: TST.abc01 TST.abc01.data TST.abc02 TST.abc02.data I have tried variations on -g and -p using groups and principals, I have also tried TST.*.* and every vriant I can think of. The manual (SC34-6068-00) System Administration Guide says you can use wildcards!! (page 308)... But it doesn't work! What am I doing wrong ? Sid Young 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: Message Tracking
Actually I mis-spoke myself. The API exit can be called *three times* for an MQGET, depending on exactly which entry point(s) you activate. 1) Before MQGET - typically use to log things like options pointer values and MQMD (did the developer remember to reset message id, correl id, ccsid etc.). The MQGET hasn't been issued at this point. 2) Before data conversion (but after the MQGET). IIRC this is always called if set up even if data conv not specified. 3) After data conversion. Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Roger Lacroix Sent: 29 April 2004 19:02 To: [EMAIL PROTECTED] Subject: Re: Message Tracking Hi, So the difference in the data between calls 'before get' and 'after get' would be the data conversion (if the app did a get with convert) ? Or would the be just for timestamping how long the get call took? i.e. because 'before get' call would not have the message data yet. Regards, Roger Lacroix Quoting "David C. Partridge" <[EMAIL PROTECTED]>: > Yes, that's *exactly* what I mean, so if you do 100 gets followed by a > backout, the exit is called 200 times (for before get and after get entries) > and then once before the backout and once afterwards. > > Dave > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Roger > Lacroix > Sent: 29 April 2004 16:03 > To: [EMAIL PROTECTED] > Subject: Re: Message Tracking > > > Hi, > > Hummm, so are you suggesting that under SyncPoint the Api Exit is called > twice: > once for the get and then again for commit (or back). > > Hummm, most interesting. > > > Regards, > Roger Lacroix > Capitalware Inc. > http://www.capitalware.biz > > > Quoting "David C. Partridge" <[EMAIL PROTECTED]>: > > > The API Exit is invoked at MQCMIT and MQBACK time, but you'll have royal > fun > > keeping track of what was > > committed and backed out it you are logging messages to see what happened. > > > > Dave > > > > Instructions for managing your mailing list subscription are provided in > > the Listserv General Users Guide available at http://www.lsoft.com > > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > > > 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
Setmqaut on v5.1
Howdy all (again), I am in the process of migrating an old v5.1 server to v5.3 on a new platform. As part of the process I have moved a copy of the queue managers over to the new Win2K machine and they work ok, but I am having security nightmares prior to upgrading the MQ to v5.3 When I try: Setmqaut -m QML_MQM -t q -n TST.* -g MQCLIENTS +put -get +inq +browse I get AMQ7085: Object TST.*, type q not found I have thousands of queues which are named: TST.abc01 TST.abc01.data TST.abc02 TST.abc02.data I have tried variations on -g and -p using groups and principals, I have also tried TST.*.* and every vriant I can think of. The manual (SC34-6068-00) System Administration Guide says you can use wildcards!! (page 308)... But it doesn't work! What am I doing wrong ? Sid Young 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: Message Tracking
Am Do, den 29.04.2004 schrieb Adiraju, Rao um 23:31: > If you think by showing all tracing > reports to every tom, , and Harry and convince them that there messages > aren't lost - you will have a huge battle ahead. By all this, newbie's will > confuse and will scare more of the MQ product and it will aggravate the > perceptions more. > only as I could prove to them in their own code that they never puted or got the message. The only way to do this is to prompt they to put trace direct before or behind put or get. Mostly they have trace in the code, but not on the right place. Gunter 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
