Re: WMQI- Nee help with PUB/SUB
I see. Thanks Christopher. Steve --- Christopher Frank [EMAIL PROTECTED] wrote: Steve, Question: Are creating a topic for a flow and ending the flow with a publication node sufficent for the publisher to be registered with the broker? Is there anything else to be done to register the topic at the broker When I create a topic and put a Publication node at the end of a msg flow, where do I specify the stream queue (which could be SYSTEM.BROKER.DEFAUL.STREAM or a more topic-specific queue). If I don't specify it, would the broker use the default stream queue? Is there an option in the control center for this? I am away from work I cannot check it myself. WMQI does not use the concept of stream queues, that is a concept used by MQ base pub/sub (the MA0C SupportPac). Your publication queue would be specified on the message flow input node (MQInput, for example). However, because SYSTEM.BROKER.DEFAULT.STREAM queue is the default publication queue, applications might be using it, particularly if you are moving from an existing base pub/sub broker to WMQI. In this case you must create and deploy a message flow whose MQInput node services SYSTEM.BROKER.DEFAULT.STREAM. This will give you compatibility with base MQ pub/sub. Regards, Christopher Frank Sr. I/T Specialist - IBM Software Group IBM Certified Solutions Expert - Websphere MQ MQ Integrator Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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
Thanks- WMQI- Nee help with PUB/SUB
Thanks again, Christopher, for a great explanation. Everything is becoming more and more clear now. Steve --- Christopher Frank [EMAIL PROTECTED] wrote: Steve, Here are some answers regarding your quest for a pub/sub checklist: 1- Create Publication queue on the broker. There are actually several queues you may need to create. At a minimum, you are recommended to define SYSTEM.BROKER.DEFAULT.STREAM (the default publication queue) and SYSTEM.BROKER.CONTROL.QUEUE. You also need a SYSTEM.BROKER.INTER.BROKER.COMMUNICATIONS queue if the WMQI broker is to communicate with neighboring MQ base pub/sub brokers. 2- RESYSTEM.BROKERINTERBROKER.COMMUNICATIONS Not sure what you mean by this step. 3-Create a Publish msg flow: It should end with a publication node. Someting like: InputNode1 (which is the pub queue)--- ComputeNode1--a-- PublicationNode --b--2 OutputNode You need a message flow to service each publication queue. For example, if you created the SYSTEM.BROKER.DEFAULT.STREAM (the default publication queue) you would need to create a message flow to service that queue. This flow would look something like: InputNode1---PublicationNode SYSTEM.BROKER.DEFAULT.STREAM (or whatever queue you are using for your publication queue) would be specified on the MQInput node. Note that you can have many publication queues, as long as each is serviced by a message flow. 4- Create a topic for the flow Question: Are creating a topic for a flow and ending the flow with a publication node sufficent for the publisher to be registered with the broker? Is there anything else to be done to register the topic at the broker? Yes. For the simple flow shown above (InputNode1---PublicationNode) this would be sufficient, as long as the publication message was prefixed with an RFH or RFH2 header indicating the topic name. If the inbound message ir not prefixed with an RFH or RFH2 header, your message flow would require some additional smarts. At a minimum, you must specify a topic name property on the Input node. Or, in a Compute node, you can specify a topic name like so: SET OutputRoot.Properties.Topic = 'myTopic'; This is a simple, really nice way to make a non-pub/sub MQ program a publisher. However, there are a frew caveats when using this approach rather than the RFH/RFH2: 1) The message is handled as a local publication. This means that the publication will not be forwarded to neighboring brokers, even if they have subscribers registered on matching topics. 2) Response messages will not be sent to publishing applications that produce messages in this way, even if the MQMD is set to imply that responses should be sent. 3) Existing base MQ pub/sub applications that use RFH format subscriptions will not receive these messages. Because of these limitations it is preferable to build an RFH2 header in your message flow. 5- If MQRFH2 Header is not present in the incoming msg Construct it in the Compute node. If this is a request-reply msg, I am thinkin go copying the MQMD.ReplytoQ/Qmgr into NameValueData like this: ReplyQMY.REPLYQ/ReplyQReplyQmgrMYQMGR/ReplyQmgr making sure the length is multiple of 4 (may need trailing spaces) as specified in the NameValueLength. Is this correct? If by request-reply you mean you want a Broker response message to be sent by the broker to the publisher to indicate the success or failure of a command message, the broker will use the ReplytoQ/Qmgr fields of the MQMD directly, so you don't need to do anything. Question: I know it is recommended that we use MQRFH2 header in new apps. But do I really need it? If I am only interested in ReplyToQ/Qmgr fields I can put them in a app header before the app. data, right? I should add that we would be receiving and sending messages in XML... Correct, an RFH/RFH2 is not required, but may be desirable in some situations. The WMQI Programming Guide explains what these situations are. 6- Persistency (not retantion): Under the heading of Message Persistency in the Introduction an Planning book (on the bottom of page 93) it talks about options for persistency? What I don't understand is, shouldn't the persistency of the publication (which the message actually) be the persistency of the message as specified in MQMD? How can I make the publisher's persistency dependent on the message persistency. I can't find any heading called Message Persistency in the WMQI V2.1 Introduction and Planning Guide. Is this the version you are using? There is a subheading called Message persistence in Chapter 7 (Designing publish/subscribe applications). Is this the reference you're referring to? This is in the section Subscriptions, and is referring to subscribers sending their subscription registration messages as persistent. I think your question, though, is in reference to the persistency of a publication,
Re: WMQI- One vs multipe Execution Groups?
Philip, I don't have any experience with WMQI yet. I am just trying to find out answers to the questions that come to my mind before I get deep into WMQI. So, let me re-phrase the question then: Would you ever want to stop the EG in the Operations tab? Steve --- [EMAIL PROTECTED] wrote: Each EG is a separate process, so it does consume resources. I am a bit confused, however, why would the EG stop if you simply check it out ? I've not noticed this behavior. It only stops if you go to the Operations tab and stop it. [EMAIL PROTECTED] Sent by: To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: .ac.at Subject: WMQI- One vs multipe Execution Groups? 02/24/2003 01:39 PM Please respond to MQSERIES Hi all, I am just wondering whether you would ever want to check out an EG in production. If this happens none of the flows in the EG could run, of course. Has this ever happened to anyone? Wouldn't it be better for each flow to have its own EG? Is there a considerable overhead in this approach -- vs putting all related flows in one EG? Thanks, Steve __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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 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 __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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: WMQI- Nee help with PUB/SUB
Thanks Christopher, Joerg, Marc I have a lot of reading to do now... It would still be very helpful for me if someone more experienced could give me a list of the things that I should do (in point form) to do pub/sub in WMQI. So far, from what I have read, I think these are the steps that I should do or be aware of: 1- Create Publication queue on the broker: DEFINE QLOCAL(SYSTEM.BROKER.DEFAULT.STREAM) REPLACE 2- RESYSTEM.BROKERINTERBROKER.COMMUNICATIONS 3-Create a Publish msg flow: It should end with a publication node. Someting like: InutNode1 (which is the pub queue)--- ComputeNode1--a-- PublicationNode --b--2 OutputNode 4- Create a topic for the flow Question: Are creating a topic for a flow and ending the flow with a publication node sufficent for the publisher to be registered with the broker? Is there anything else to be done to register the topic at the broker? 5- If MQRFH2 Header is not present in the incoming msg Construct it in the Compute node. If this is a request-reply msg, I am thinkin go copying the MQMD.ReplytoQ/Qmgr into NameValueData like this: ReplyQMY.REPLYQ/ReplyQReplyQmgrMYQMGR/ReplyQmgr making sure the length is multiple of 4 (may need trailing spaces) as specified in the NameValueLength. Is this correct? Question: I know it is recommended that we use MQRFH2 header in new apps. But do I really need it? If I am only interested in ReplyToQ/Qmgr fields I can put them in a app header before the app. data, right? I should add that we would be receiving and sending messages in XML... 6- Persistency (not retantion): Under the heading of Message Persistency in the Introduction an Planning book (on the bottom of page 93) it talks about options for persistency? What I don't understand is, shouldn't the persistency of the publication (which the message actually) be the persistency of the message as specified in MQMD? How can I make the publisher's persistency dependent on the message persistency. Please correct me if my understanding of the above points in pub/sub are not quite right. Does anyone have a check-list kind of thing for the steps to be taken? Your comments/help would be much appreciated. Thank you all again, Steve --- Christopher Frank [EMAIL PROTECTED] wrote: Steve, As I am a newbie to WMQI (2.1) and my project requires Pub/Sub process of the messages, I would be eternally grateful if someone could give me a doc/info with all the steps necessary to do this. Also, is there a detailed description of pub/sub anywhere? I dod not find the Using The Control Center manual very helpful. See chapters 2 - 5 of the WMQI Programming Guide for detailed information on writing pub/sub applications. There is also a good Redbook, called MQSeries Publish/Subscribe Applications that you can download from http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246282.pdf. Regards, Christopher Frank Sr. I/T Specialist - IBM Software Group IBM Certified Solutions Expert - Websphere MQ MQ Integrator Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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: WMQI- Nee help with PUB/SUB
Thanks, bobbeee.. Steve --- Robert Broderick [EMAIL PROTECTED] wrote: Pick up the Support Pack for Publish and Subscribe. There is a PDF manual in there describing the programming method of pub/sub Also the administration of the beast. bobbee From: Christopher Frank [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: WMQI- Nee help with PUB/SUB Date: Sat, 22 Feb 2003 13:45:43 -0600 Steve, As I am a newbie to WMQI (2.1) and my project requires Pub/Sub process of the messages, I would be eternally grateful if someone could give me a doc/info with all the steps necessary to do this. Also, is there a detailed description of pub/sub anywhere? I dod not find the Using The Control Center manual very helpful. See chapters 2 - 5 of the WMQI Programming Guide for detailed information on writing pub/sub applications. There is also a good Redbook, called MQSeries Publish/Subscribe Applications that you can download from http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246282.pdf. Regards, Christopher Frank Sr. I/T Specialist - IBM Software Group IBM Certified Solutions Expert - Websphere MQ MQ Integrator Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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: need help with pub/sub
Which is MA0C. MA0D is pretty useful too. Thanks, Steve --- john gilmore [EMAIL PROTECTED] wrote: A specific reference is: MQSeries Publish Subscribe User's Guide, IBM publication GC34-5269-09, May 2002 John Gilmore SystemCraft LLC __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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: WMQI- Nee help with PUB/SUB
A bit more clarification on my question: Question: Are creating a topic for a flow and ending the flow with a publication node sufficent for the publisher to be registered with the broker? Is there anything else to be done to register the topic at the broker When I create a topic and put a Publication node at the end of a msg flow, where do I specify the stream queue (which could be SYSTEM.BROKER.DEFAUL.STREAM or a more topic-specific queue). If I don't specify it, would the broker use the default stream queue? Is there an option in the control center for this? I am away from work I cannot check it myself. Thanks, Steve --- Steve Muller [EMAIL PROTECTED] wrote: Thanks Christopher, Joerg, Marc I have a lot of reading to do now... It would still be very helpful for me if someone more experienced could give me a list of the things that I should do (in point form) to do pub/sub in WMQI. So far, from what I have read, I think these are the steps that I should do or be aware of: 1- Create Publication queue on the broker: DEFINE QLOCAL(SYSTEM.BROKER.DEFAULT.STREAM) REPLACE 2- RESYSTEM.BROKERINTERBROKER.COMMUNICATIONS 3-Create a Publish msg flow: It should end with a publication node. Someting like: InutNode1 (which is the pub queue)--- ComputeNode1--a-- PublicationNode --b--2 OutputNode 4- Create a topic for the flow Question: Are creating a topic for a flow and ending the flow with a publication node sufficent for the publisher to be registered with the broker? Is there anything else to be done to register the topic at the broker? 5- If MQRFH2 Header is not present in the incoming msg Construct it in the Compute node. If this is a request-reply msg, I am thinkin go copying the MQMD.ReplytoQ/Qmgr into NameValueData like this: ReplyQMY.REPLYQ/ReplyQReplyQmgrMYQMGR/ReplyQmgr making sure the length is multiple of 4 (may need trailing spaces) as specified in the NameValueLength. Is this correct? Question: I know it is recommended that we use MQRFH2 header in new apps. But do I really need it? If I am only interested in ReplyToQ/Qmgr fields I can put them in a app header before the app. data, right? I should add that we would be receiving and sending messages in XML... 6- Persistency (not retantion): Under the heading of Message Persistency in the Introduction an Planning book (on the bottom of page 93) it talks about options for persistency? What I don't understand is, shouldn't the persistency of the publication (which the message actually) be the persistency of the message as specified in MQMD? How can I make the publisher's persistency dependent on the message persistency. Please correct me if my understanding of the above points in pub/sub are not quite right. Does anyone have a check-list kind of thing for the steps to be taken? Your comments/help would be much appreciated. Thank you all again, Steve --- Christopher Frank [EMAIL PROTECTED] wrote: Steve, As I am a newbie to WMQI (2.1) and my project requires Pub/Sub process of the messages, I would be eternally grateful if someone could give me a doc/info with all the steps necessary to do this. Also, is there a detailed description of pub/sub anywhere? I dod not find the Using The Control Center manual very helpful. See chapters 2 - 5 of the WMQI Programming Guide for detailed information on writing pub/sub applications. There is also a good Redbook, called MQSeries Publish/Subscribe Applications that you can download from http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246282.pdf. Regards, Christopher Frank Sr. I/T Specialist - IBM Software Group IBM Certified Solutions Expert - Websphere MQ MQ Integrator Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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
WMQI- Nee help with PUB/SUB
Hi all, As I am a newbie to WMQI (2.1) and my project requires Pub/Sub process of the messages, I would be eternally grateful if someone could give me a doc/info with all the steps necessary to do this. Also, is there a detailed description of pub/sub anywhere? I dod not find the Using The Control Center manual very helpful. Thank you all in advance, Steve __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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: WMQI- Beginner's questions
Thank you very much, CF, for an excellent explanation!!! Steve --- Christopher Frank [EMAIL PROTECTED] wrote: Hi Steve, 1- Can someone please explain what this cardinality is all aboout (with an example). In set theory, cardinality refers to the number of members in the set. For example, the cardinality of the set of people in the United States is approximately 270,000,000. Use of this term (as opposed to count or some more intuitive term) doubtless has its origins in the fact that eSQL is a variant of SQL. When specifically applied to database theory, the cardinality of a table refers to the number of rows (or tuples) contained in a table. In WMQI, cardinality is used to refer to the number of elements at a given level in the message tree. Thus you can use the CARDINALITY function to, for example, determine how many instances of a repeating element there are. For example, the following eSQL statement: set I = CARDINALITY(InputBody.data.item[]) DO ...run against a message tree generated from the following XML: data itemx/item itemy/item itemz/item /data ...will count all instances of the item element and set the variable I to 3. Similarly, the following eSQL: WHILE I =CARDINALITY(InputBody.data.item[]) DO SET OutputRoot.XML.mytag.unit[I] = InputBody.data.item[I]; SET I = I + 1; END WHILE; ...will iterate through each item element and create an output XML message like so: mytag unitx/unit unity/unit unitz/unit /mytag 2- If there is a RFH in a message would the message look like this: MQMD-MQRFH-ApplicationData Or, is the whole ApplicationData specified within the name/value pairs? Yes, the message would look like MQMD-MQRFH-ApplicationData. In this example, the MQMD.Format is set to = MQMD_RF_Header. Where would I specify the format as MQFMT_STRING for the application data? In the MQRFH.Format field? Does this format apply to both the name/value fields and ApplicationData? You would specify MQFMT_STRING in the MQRFH.Format field to indicate that the application data is all string (character) data. It would only apply to the ApplicationData, as I believe the name/value pairs that make up the RFH must be strings. Note that with WMQI, you do not need to use the RFH header, as the values it contains can be specified as properties of the MQInput node or a ResetContentDescriptor node of a message flow. An RFH header can be used, but this is not required. Regards, Christopher Frank Sr. I/T Specialist - IBM Software Group IBM Certified Solutions Expert - Websphere MQ MQ Integrator Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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
MQMD setup by a non-MQ sender???!!!
Hi all, I don't have all the details but I think I soon may be involved in a project where, I hear that the messages would be sent to WMQI from AIX (in a send-and-forget fashion)without the involment of MQSeries. In other words, a program (not an MQ program) or a 3rd-party file sending software will send the messages after setting all the required MQMD header and concatinating that with the App. data. This approach makes me a bit nervous. Has anyone every done this? What are the things to watch for? Thanks for all of your input, Steve __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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: MQMD setup by a non-MQ sender???!!!
Thanks for the insight, Frank. I still have no further info on the project. Steve --- Christopher Frank [EMAIL PROTECTED] wrote: Steve, I don't have all the details but I think I soon may be involved in a project where, I hear that the messages would be sent to WMQI from AIX (in a send-and-forget fashion)without the involment of MQSeries. In other words, a program (not an MQ program) or a 3rd-party file sending software will send the messages after setting all the required MQMD header and concatinating that with the App. data. This approach makes me a bit nervous. Has anyone every done this? What are the things to watch for? Hmmm. By this, do they mean on the AIX box they would be using an MQ client? That would not require any MQSeries server code on the AIX box in question. If not, simply creating a data object prepended with the equivelent of an MQMD will not cause it to magically appear on an MQ queue. You can't (legally) put something on an MQ queue without using the services of a queue manager, which requires following a strict set of formats and protocols (which is what an MQ Client does). However, I believe the FAP for MQ is proprietary and would have to be licensed (I'm sure reverse-engineering the FAP is prohibited by the license agreement). And the effort would be non-trivial (especially given that an MQ Client could be used on AIX for no additional charge). If they are not planning to use an MQ Client, I wonder if what they are looking at doing is writing (or expecting someone to write) a custom input node to accept data for input from somewhere other than an MQSeries queue. This is certainly possible with WMQI V2.1. You could write an input node to accept input from a file, or HTTP, etc. However, this would not be sent through MQSeries and would not be retrieved using an MQInput node. By prepending a file with a pseudo-MQMD and using a file-oriented custom WMQI input node, in theory the remainder of the message flow could be built to operate exactly as it would if an MQInput node had been used. However, if this is the intent, the biggest thing to watch out for would be, How would transactionalization be maintained (you mentioned this would be sent in a fire-and-forget fashion)? By not using an MQInput node, the substitute node would be responsible for persisting the data somewhere and retrying in the event the message flow could not successfully process it. It's hard to be more specific until you have the additional details you currently lack. Regards, Christopher Frank Sr. I/T Specialist - IBM Software Group IBM Certified Solutions Expert - Websphere MQ MQ Integrator Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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
WMQI- Beginner's questions
Hi all, I am very new to WMQI. You would have to bear with my stupid questions in the future. Here are some of them: 1- Can someone please explain what this cardinality is all aboout (with an example). 2- If there is a RFH in a message would the message look like this: MQMD-MQRFH-ApplicationData Or, is the whole ApplicationData specified within the name/value pairs? In this example, the MQMD.Format is set to = MQMD_RF_Header. Where would I specify the format as MQFMT_STRING for the application data? In the MQRFH.Format field? Does this format apply to both the name/value fields and ApplicationData? I guess I am just confused by the usage of name/value pairs. I would appreciate it very muuch if someone can give an example of MQMD+RFH+ApplicatioData. Thank you all, Steve __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.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
MQSI- Is it possible to associate messages in msg groups?
Hi all, We will be receiving, into the MQSI input queues, messages that are logically grouped. I don't know yet whether the messages will come in as grouped using MQSeries grouping or application constructed (i.e. using msgid/correlid and certain fields of the application data). Question: Since the layouts of each message will be different, is it possible at all to manupilate these messages in MQSI-- by receiving them all on the same input queue? I don't personally think it is. Maybe these logical messages will have to be put on different MQSI input queues each of which will have a message layout specific for that message. No? Or, they can be put on the same MQSI input queue. And once in MQSI, based on message content, they can be output to different output queues, which would be used as input queues for separare message flows??? How else could it be done? Thanks for all the input in advance. Best regards, Steve __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.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
MQ pub/sub available on OS/390?
Hi all, In what version of MQ is MQ pub/sub available on OS/390? Thanks, Steve __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.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: Question about deleting Perm. Dynamic queues
Tim, thanks for the input. I like your naming convention but how would it address the issue of deleting these PD queues that were not deleted by the client apps due to sys failure etc? If these queues were not deleted before the qmgr is recycled, then they and their persistent msgs will be saved and restored when qmgr comes back up (exactly like local queues). These surviving PD queues cannot be deleted with MQCLOSE any longer by any application according to the manuals. You would have to send a PCF message to the command server to do so. OPENing/Creating these queues will not be a problem; if they exist, client apps will do a regular OPEN. I am more concerned about DELETEing them. I don t have a problem with coming up a meaningful PD queue names but have started having second thoughts about whether using PD queues instead of local queues is still worth the headache. Or for the purposes of access control the generation of the permanent dynamic queue and its access could be done when a new user is created, and deleted when the user is removed from the system. Are you suggesting that Admin could create these queues ahead of time (i.e. before the client app. starts) and delete (again by Admin) them if the users are gone? We'll have about 200 clients with at least 350 users (with a shift work). So, create 350 PD queues? I have been told today that the number of the clients may go well beyond 500. I would love to hear the experience of others as well. Thanks, Steve --- Tim Armstrong [EMAIL PROTECTED] wrote: Ok, here's a different perspective on the overall question of reply to queues in a request/reply scenario. Assign each user a permanent dynamic reply queue that is used by all apps, each app retrieving its messages by message and correlation id's, this nicely handles the following issues, security of visibility to confidential information, containing the impact of a rogue app that reads messages it shouldn't and simplifies the admin tasks related to handling dynamic queues. An apps code works along these lines MQOPEN REPLY.myuser.QUEUE and if this fails it then does an MQOPEN on the Model queue specifying the name REPLY.myuser.QUEUE in the dynamic queue name field. Or for the purposes of access control the generation of the permanent dynamic queue and its access could be done when a new user is created, and deleted when the user is removed from the system. This sounded a bit wierd the first time I heard it but the more I think about it the more I like it. Regards Tim A Miller, Dennis [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeries Subject: Re: Question about deleting Perm. Dynamic queues List MQSERIES@AKH-WIE N.AC.AT 27/08/2002 03:22 AM Please respond to MQSeries List But Steve, the main advantage of persistent messages is to survive a qmgr restart. You go to great lengths for persistent replies, then undermine it by purging the reply queues?? Also, persistence is not a typical requirement for request/reply application, so I have to question whether you really need it. Generally, dynamically creating/deleting permanent queues introduces more headaches than relief. The effort backfires because keeping all involved parties in-sync on an ongoing basis gets too messy. With good naming standards, 200 equivalent reply queues should not overwhelm the administrators. On the other hand, if you really want to simplify admin, sharing a reply queue among 200 clients is quite feasible--especially for request/reply apps where the queue depth is customarily shallow. -Original Message- From: Steve Muller [SMTP:[EMAIL PROTECTED]] Sent: Monday, August 26, 2002 6:27 AM To: [EMAIL PROTECTED] Subject: Re: Question about deleting Perm. Dynamic queues Dennis: Thanks for your reponse. Below, I will explain why and how I decided to use PD (Perm. Dyn.) queues --I WOULD LIKE ALL THESE pd QUEUES GONE BEFORE MQ SHOT-DOWN-- in order not to cause any headache to the MQ Admin guys. Here is the requirement and the design to acheive this: Requirement: - We'll have about 200 clients (Win2K MQ 5.2) that will send mostly persistent requests to the server (we don't know the platform yet) and receive their persistent replies in their perspective reply queues. Some of these clients will run almost non stop (for days if not weeks or months... due to business req's)and some may stop at the end of the day. Design: --- I don't want to create 200 regular local queues for admin purposes. I also don't want to create say 20 local
Re: Question about deleting Perm. Dynamic queues
not as on option on the MQCLOSE. From an application you can do so by sending a PCF message to the command server. Are you certain that permanant dynamic is the best choice, they're kind of a pain from the housekeeping perspective? -Original Message- From: Steve Muller [SMTP:[EMAIL PROTECTED]] Sent: Friday, August 23, 2002 7:52 AM To: [EMAIL PROTECTED] Subject: Question about deleting Perm. Dynamic queues About the Permananet Dynamic queues the Programming Guide manual (page 46) says : They can not be deleted by an application closing the queue, unless it was the application that issued the MQOPEN which created the queue. In other words, it is only the app that created the queue that can delete it (NO other app), right? I just have a need to be able to delete the orphaned Perm. Dyn queues within another app. It could be done via an admistrative script but, we don't want to do that (yet). Your thoughts would be much appreciated. Thanks much, Steve __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.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
Can idle but connected app cause a problem??
Hi all, We ll have about 200 Win2k Clients (MQ 5.2) connect to the queue manager on the server side (the platform to yet to be determined). Clients will send a request to the server app which in turn will send a reply back. In these client apps, we ll be using Perm. Dynamic queues (to be able to store persistent messages too) for the replies coming back from the server app. I have been told that these client apps, once they are started up, WILL REMAIN RUNNING ALL THE TIME though they will not be putting or getting messages most of the time probably. When the apps are started, they will connect to the queue manager and stay connected until they are stopped. We ll use the Fail_IF_quiescing option the way it is recommended. My concern is, if the queue manager needs to be recycled would the fact that these apps are connected cause a problem (i.e. would the qmgr be recycled despite these apps being connected)? Would it be better for these apps to try to MQGET from their reply queue (even if they are not expecting anything) from time to time, say every 30 sec , to detect qmgr quiescing? I would very much appreciate your response. Thanks in advance, Steve __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: One or Many reply queues for Clients? THANKS
Thanks very much, Paul. Steve --- Paul Clarke [EMAIL PROTECTED] wrote: Thank you for your response. I had thought about minimizing the number of queues by 10 times -- like you just suggested. But, I did not know how to go about it. Sorry but, I seem to fail to understand your above explanation. Can you please bear with me and explain a bit more what you mean by the above? Hash value... Prime number, how are they created used? Thanks again, Steve Steve, Well like I said there are many different ways you can achieve this and I hesitate to suggest a way to do this because this list doesn't let one get away with anything. So let me emphasise that this is *one* way you *could* do this. You need a constant, fairly random identifier associated with your client. You might have a userid + department id or whatever. Let's say we use the clients machine hostname. Now add up the numeric characters in the name. ie. in C this could be char * p = HostName; /* null terminated hostname */ intKey = 0; while (*p) Key += *p++; Now we have the ASCII total for the characters we then need to convert this into one of 10 names. Well it's a lot easier to convert to prime numbers so let's convert it to one of 11 names (closest prime). int Hash = Key % 11; The '%' operator gives us the modulus ie. what's left over after division, the remainder. So now we have a number, Hash, between 0 and 10 that is fairly evenly spread across our clients. We can then define 11 queues, ie. REPLYQ_0, REPLYQ_1, REPLYQ_2..REPLYQ_10 and use the Hash number as part of the queue name we open. Does this make it any clearer ? Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.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: One or Many reply queues for Clients?
Jim, and others, thanks for your responses... Jim: I think we'll be using Perm Dyn. queues as you suggested. I was just wondering about the reasoning behind why your applications are not deleting their respective prem. dyn. queues before they terminate-- instead of running a script periodically for that same purpose. Can you please get back to me on that? Thanks, SM --- Jim Ford [EMAIL PROTECTED] wrote: We have a similar environment with about 600 NT clients, and we chose option 2. We use a single permanent dynamic model queue as the source for the reply queues, and the applications make the user's ID part of the permanent queue name. We had thought about option 1, but it can be useful to be able to examine the messages sent to one specific user. It also lets us see who's connected at any particular time by checking IPPROCS on the queues. Administration's no big deal. As I said, we only have a single model queue. And periodically we run a script that blindly tries to delete all of these reply queues. We've found that the queue manager restarts much faster without these 600 queues. And our application will simply recreate the queue the next time the user connects, so we're OK with deleting it. If the queue is open, or if it has messages on it, the queue won't be deleted, so the script just tries to delete everything. Steve Muller [EMAIL PROTECTED]To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: One or Many reply queues for Clients? MQSERIES@AKH-WIE N.AC.AT 07/05/2002 10:17 AM Please respond to MQSeries List Hi all, Part of our MQ environment is OS/390 (2.1) and NT (5.2). We will have about 190 NT clients connected to OS/390. These NT client apps will send a request and get their replies from OS/390, based on a correlid. More than 90% of these requests will be queries. We are estimating that, for all the 190 clients combined, there will be about 50 requests and roughly 50-1 replies per sec. The turn-around time is expected by the user to be 2-12 sec based on the importance of the request. I am thinking that we can have either: 1- One reply queue that would be serviced by all the clients, OR 2- A dedicated reply queue for each client. In the scenario 1: I know that a qualified GET would be slower from a queue with a high Q-depth (I know indexing could be used ). As far as I can see, the major downside to this approach would be if something goes wrong with this queue all the clients would suffer. In the scenario 2: If we have a dedicated reply queue for each client, MQ admin would not be very happy but the retrieval of the msgs would be faster (even if we used qualified Gets). And a problem with one queue would not effect the rest of the reply queues What do you think? Your insights would be much appreciated. Regards, Steve __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.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: One or Many reply queues for Clients?
Jim, Never mind my question re why the applications were not deleting the prem. dyn queues before terminating. I think I know the answer: I can see that some reply queues may become orphaned, in which case they would have to be deleted outside the apps. In my design, I'll try to delete them before terminating the apps. And then run a script, like yours, periodically to delete the orphaned ones. Thanks, Steve --- Jim Ford [EMAIL PROTECTED] wrote: We have a similar environment with about 600 NT clients, and we chose option 2. We use a single permanent dynamic model queue as the source for the reply queues, and the applications make the user's ID part of the permanent queue name. We had thought about option 1, but it can be useful to be able to examine the messages sent to one specific user. It also lets us see who's connected at any particular time by checking IPPROCS on the queues. Administration's no big deal. As I said, we only have a single model queue. And periodically we run a script that blindly tries to delete all of these reply queues. We've found that the queue manager restarts much faster without these 600 queues. And our application will simply recreate the queue the next time the user connects, so we're OK with deleting it. If the queue is open, or if it has messages on it, the queue won't be deleted, so the script just tries to delete everything. Steve Muller [EMAIL PROTECTED]To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: One or Many reply queues for Clients? MQSERIES@AKH-WIE N.AC.AT 07/05/2002 10:17 AM Please respond to MQSeries List Hi all, Part of our MQ environment is OS/390 (2.1) and NT (5.2). We will have about 190 NT clients connected to OS/390. These NT client apps will send a request and get their replies from OS/390, based on a correlid. More than 90% of these requests will be queries. We are estimating that, for all the 190 clients combined, there will be about 50 requests and roughly 50-1 replies per sec. The turn-around time is expected by the user to be 2-12 sec based on the importance of the request. I am thinking that we can have either: 1- One reply queue that would be serviced by all the clients, OR 2- A dedicated reply queue for each client. In the scenario 1: I know that a qualified GET would be slower from a queue with a high Q-depth (I know indexing could be used ). As far as I can see, the major downside to this approach would be if something goes wrong with this queue all the clients would suffer. In the scenario 2: If we have a dedicated reply queue for each client, MQ admin would not be very happy but the retrieval of the msgs would be faster (even if we used qualified Gets). And a problem with one queue would not effect the rest of the reply queues What do you think? Your insights would be much appreciated. Regards, Steve __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.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: One or Many reply queues for Clients?
Paul, It is very easy to use something relatively unique about a client to generate a hash value which can then be used to choose the reply queue to use. Even something as simple as adding up the characters in the host name and taking the modulus of an appropriate prime number would be good enough for these purposes. By changing the prime number you can then vary the storage vs contention equation. Thank you for your response. I had thought about minimizing the number of queues by 10 times -- like you just suggested. But, I did not know how to go about it. Sorry but, I seem to fail to understand your above explanation. Can you please bear with me and explain a bit more what you mean by the above? Hash value... Prime number, how are they created used? Thanks again, Steve --- Paul Clarke [EMAIL PROTECTED] wrote: I am thinking that we can have either: 1- One reply queue that would be serviced by all the clients OR 2- A dedicated reply queue for each client. Steve Steve, I think you're missing the obvious and perhaps preferred alternative, that of 'm' clients using 'n' queues. Generally speaking it is a good idea to avoid the extremes you mention. All clients sharing the same queue gives you the maximum amount of contention on the queue which is not a good thing. Similarly, each client having its own queue gives you the maximum resource overhead which is excessive since most of the time these queues are empty. When you only have 600 clients it is not such a big deal but if you had 6,000 clients then either of these options would give you a poor result. What you should have is say 6,000 clients striped over, say, 60 queues. It is very easy to use something relatively unique about a client to generate a hash value which can then be used to choose the reply queue to use. Even something as simple as adding up the characters in the host name and taking the modulus of an appropriate prime number would be good enough for these purposes. By changing the prime number you can then vary the storage vs contention equation. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.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
One or Many reply queues for Clients?
Hi all, Part of our MQ environment is OS/390 (2.1) and NT (5.2). We will have about 190 NT clients connected to OS/390. These NT client apps will send a request and get their replies from OS/390, based on a correlid. More than 90% of these requests will be queries. We are estimating that, for all the 190 clients combined, there will be about 50 requests and roughly 50-1 replies per sec. The turn-around time is expected by the user to be 2-12 sec based on the importance of the request. I am thinking that we can have either: 1- One reply queue that would be serviced by all the clients, OR 2- A dedicated reply queue for each client. In the scenario 1: I know that a qualified GET would be slower from a queue with a high Q-depth (I know indexing could be used ). As far as I can see, the major downside to this approach would be if something goes wrong with this queue all the clients would suffer. In the scenario 2: If we have a dedicated reply queue for each client, MQ admin would not be very happy but the retrieval of the msgs would be faster (even if we used qualified Gets). And a problem with one queue would not effect the rest of the reply queues What do you think? Your insights would be much appreciated. Regards, Steve __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.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: Thanks: Initiation queue question
Thanks Peter, Dennis. Steve --- Miller, Dennis [EMAIL PROTECTED] wrote: Peter is correct, each trigger monitor needs it's own initq. When running client trigger monitors, that translates to one trigger monitor per client machine. But that is not necessarily the same as a separate initq for each client app. The whole point is to enable one (long-running) trigger monitor to serve many (come-and-go) applications. My point is, that if your clients are dedicated to one application, then I see no benefit to triggering it. You might as well KISS and just have one (long-running) program monitoring the application queue instead of the INITQ. One more thing to think about. As long-running programs, trigger monitors sustain their qmgr connections over long durations. For client trigger monitors, those are client connections that cross the network. Being so much more senstive than local connections, I have a fairly negative impression of long-running clients--especially trigger monitors and especially if there's potential for more than a handful of them. If those are concerns to you also, then you may want to consider other ways to wakeup your clients. -Original Message- From: steve muller [SMTP:[EMAIL PROTECTED]] Sent: Monday, June 10, 2002 10:45 AM To: [EMAIL PROTECTED] Subject: Initiation queue question Hi all, We'll have several (MQ 5.2.1) Client applications running on NT and UNIX. They will connect to the MQ 2.1 OS/390 queue manager. And they will be triggered on the arrival of the first message on their respective local queues on OS/390 (NT.CLIENT1, NT.CLIENT2... UNIX.CLIENT1, UNIX.CLIENT2 and so on... What I am not quite sure about is whether I need two separate initiation queues -- one for the NT client apps and the other for the UNIX (like NT.INITQ and UNIX.INITQ on OS/390). Or would I need a separate initq for each client app (e.g. NT.CLIENT1.INITQ, NT.CLIENT2.INITQ, UNIX.CLIENT1.INTIQ, UNIX.CLIENT2.INITQ...). Can someone please help me with this question? We already have an ititiation queue for the CICS the CICS apps (CICS.INITQ) and another for the batch apps (BATCH.INITQ) in OS/390. I would appreciate your insights. Thanks, Steve __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Initiation queue question
Hi all, We'll have several (MQ 5.2.1) Client applications running on NT and UNIX. They will connect to the MQ 2.1 OS/390 queue manager. And they will be triggered on the arrival of the first message on their respective local queues on OS/390 (NT.CLIENT1, NT.CLIENT2... UNIX.CLIENT1, UNIX.CLIENT2 and so on... What I am not quite sure about is whether I need two separate initiation queues -- one for the NT client apps and the other for the UNIX (like NT.INITQ and UNIX.INITQ on OS/390). Or would I need a separate initq for each client app (e.g. NT.CLIENT1.INITQ, NT.CLIENT2.INITQ, UNIX.CLIENT1.INTIQ, UNIX.CLIENT2.INITQ...). Can someone please help me with this question? We already have an ititiation queue for the CICS the CICS apps (CICS.INITQ) and another for the batch apps (BATCH.INITQ) in OS/390. I would appreciate your insights. Thanks, Steve __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Why 2058 from AMQSPUTC?
I have installed MQ 5.2.1 on my W2K PC. I have created queue manager QM1 and a local queue Q1 (both uppercase) . In the command prompt when I type: AMQSPUTC Q1 QM1 --- both names uppercase I get 2058 (Qmgr name error). I have no problem putting a message using MQ Explorer. Why doesn't amqsputc program recognize QM1? Thanks for all the responses. Steve __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Backed out msg retains its old positon on the Q?
When a message is retrieved with GET + Syncpoint and then backed out, does it preserve its original position on the queue or go to the bottom of the queue? I think it is the latter but wanted to confirm with you. Thanks for your response. SM __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
