Mark Akerman/AEPIN is out of the office.
I will be out of the office starting 08/22/2003 and will not return until 08/24/2003. I will respond to your message when I return. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: message CSQX558E - too many channels?
CSQX558E csect-name Remote channel channel-name not available Explanation: The channel channel-name at the remote queue manager is currently stopped or is otherwise unavailable. For example, there might be too many channels current to be able to start it. Severity: 8 System Action: The channel does not start. System Programmer Response: This might be a temporary situation, and the channel will retry. If not, check the status of the channel at the remote queue manager. If it is stopped, issue a START CHANNEL command to restart it. If there are too many channels current, either wait for some of the operating channels to terminate, or stop some channels manually, before restarting the channel. -Original Message- From: EARmerc Roberts [mailto:[EMAIL PROTECTED] Sent: 21 August 2003 10:00 To: [EMAIL PROTECTED] Subject: Re: message CSQX558E - too many channels? Thanx, Joep, I looked and found values of 200, which should have been enough considering our current level of activity. I am thinking that the message doc is somewhat misleading. I am assuming that dynamic channels are included in the specification and we are IP-only. I'll do some more research on the problem. again, Thanx. Ernest Roberts IT - Sr Sys Prog MBUSA, LLC __ Robert, There are several parameters limiting the number of active channels. They are in CSQ6CHIP. See sample SCSQPROC(CSQ4X4PRM). Have a look at ACTCHL, CURRCHL, LU62CHL and TCPCHL. Cheers, Joep -Original Message- From: EARmerc Roberts [mailto:[EMAIL PROTECTED] Sent: donderdag 21 augustus 2003 16:18 To: [EMAIL PROTECTED] Subject: message CSQX558E - too many channels? Hello MQ persons, We are running MQ v 5.3 on OS/390 v2.10. Our qmgr reported message CSQX558E for a channel and the M&C guide said about this: "there might be too many channels current to be able to start it." The channel appeared to have no problem after a STOP and then a START were issued. What I want to do is make sure I am not restricting our growing MQ traffic with my current parameter settings. Is there a parameter that actually limits the number of active channels? Is there a DISPLAY command that can show that parameter value? I found parameter "CTHREAD=300" in the assembly JCL for CSQ6SYSP. Also, "IDBACK=20" was specified for non-TSO connections. The doc doesn't give a clear indication of what the parameters affect, but does state that a channel initiator can have more than one connection to a qmgr. Am I on the right track with this issue? should I alter those parameters upward? Thanx in advance? Ernest Roberts IT - Sr Sys Prog MBUSA, LLC 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 ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. ** 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 __ For information about the Standard Bank group visit our web site __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of Standard Bank Group Limited is proprietary to the group. It is confidential, legally privileged and protected by law. Standard Bank does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of the group. The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reac
Security and user IDs
I have a scenario on a single WMQ 5.2 (CSD06) server running on Win2K that I've not come across before. The server has a single QM, the default. The QM runs fine and I can connect, send & receive messages. The mqm group is defined, with a single user MUSR_ADMIN. Logged on as Administrator (local), I do not seem to have authority to do any MQ operations. Althought I can start/stop the QM and see the status of the Command Server, etc from the Services MMC, the MQExplorer MMC is blank (even if I ensure "display system objects" is selected). So I added Administrator to the mqm group (it wasn't there before) and restarted the service. Still not authorized, even though as Administrator on a Windows system (according to the docs) I should be able to administer any local queue manager. Do I need to run "setmqaut" giving "Administrator" all necessary rights? I'll run away and try to find the solution myself, but if anyone can point me directly to the appropriate section (System Admin Guide:Websphere MQ Security), I'd appreciate it. tonyB. 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
Clusters and MQExplorer - Does it cheat?
QM1 and QM2 are full repositories for cluster HOMER. QM3 is a partial repository in HOMER. I add 10 queues to QM1 and QM2 and cluster them into HOMER. Before any applications put any messages to them, MQExplorer shows them on QM3. And QM3's partial Repository queue never got updated! Is MQExplorer going behind the scenes, connecting to QM1 and QM2, and trying to be smart about what it should show in QM3's view? MO71 and QPASA do not show those queues until they are actually put to via QM3. I am assuming they are getting their cluster info from the partial repository on QM3, right? If so, I think this is very misleading on MQExplorer's part. I had a problem (another scenario) where the partial repository was not getting updated. All the message kept going to the DLQ, with a 2085, cause the QM correctly knew nothing about those queues. Yet that ^@&^#& Explorer showed them there, totally misleading us! Seems to me it should be consistent. Explorer should work the way MQ does in regards to clustering and what it shows. I dunno. I'm done venting. Time to go home. Just hoping for some affirmation on my theory as to how I wasted my afternoon today solving the customer's "problem"! ;-) Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified 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: mqver remotely? Maybe MO71?
You say that you built a script that started by triggering and then reads the application queue that has messages that the body contains a command to run? Just looking for clarification because I think we would like to do this also for more than just mqver. Does the script actually call a program that does the get then put (of the command output)?, or did you write the MQ part into the script also? Did you have any other problems or gotcha's that we should look for? Thanks in advance for any other input. B -Original Message- From: John Matoba [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 11:03 AM To: [EMAIL PROTECTED] Subject: Re: mqver remotely? Maybe MO71? We created a script that is triggered by an MQ message and assumes the message body contains a unix command. When the script is triggered, it runs the unix command and returns the output in a reply message. From a hub queue manager, we can send an mqver command to all our queue managers and generate a report of all the version info on all our queue managers. Such a script is fairly simple to write and as you might imagine, is quite useful in centrally issuing other unix commands. John Matoba Information Systems Northwestern Mutual Life 414-665-4160 -Original Message- From: Peter.Potkay [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 10:02 AM To: MQSERIES Subject: Re: mqver remotely? Maybe MO71? Paul, I am forwarding your reply to my IBM rep Tom Kruczek. Maybe he can push this request over to Hursley officially. -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 10:50 AM To: [EMAIL PROTECTED] Subject: Re: mqver remotely? Maybe MO71? >Is there anyway to get the MQ version of a box without having to actually >log onto the box? MQExplorer? QPASA? MO71? >It is a pain having to log onto individual boxes just to run the mqver >command when you want to see what CSDs have been applied. >Paul, would there be anyway for MO71 to do this in a future version? MO71 pretty much only talks to the command server, this is so it doesn't require an agent running on the target machine. Consequently if you want MO71 to be able to tell you the CSD level it really means that we need a command server version of the MQVER command. It doesn't seem an unreasonable requirement to me to have one added but this isn't really my area. 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 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: Initiation Queue
I don't know if Every triggering should be called an IBM design mistake. There are valid scenarios for it. Imagine an application that takes 90 seconds to process a message, and there is someone waiting for the reply. You want to trigger this app. What if messages are expected to arrive during peak hours at a rate of 1 every 10 seconds. If you Trigger to Every, you can have multiple instances all working together. The design mistake is in the code people put out in programs that are triggered on every that don't read the queue until 2033. Reading till 2033 solves all the problems related to only 1 trigger message upon restart. Yes, in this rare case where you are restarting with > 0 messages in the queue, you will have a back log as the one process works it's a** off trying to clear the queue, but I assume the message have been sitting there a while anyway. And, any new fresh messages arriving WILL kick off new processes. Having said all that, is almost a given that your app can probably handle it by being triggered on first and reading until 2033. 97% of scenarios call for First I think. Every is probably overused out in MQ land, and probably misused, but I say it has its place. (And don't forget the Service Initiation Concept touted by Dennis as another way to spawn off multiple instances without using Every. Probably a better way to do it anyway...) -Original Message- From: Neil Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 20, 2003 6:23 PM To: [EMAIL PROTECTED] Subject: Re: Initiation Queue Hi Brent, You should almost certainly have only one initq in this situation. The difference between the actions for different queues can be controlled by the content of the TRIGDATA, the PROCESS, and the content of the PROCESS. One of the objectives of having triggering is to reduce the number of long running processes which just sit around waiting for work. Rather than having one process per application queue, you trigger all of the application queues into a single trigger queue, and then have just one long running process (the trigger monitor). You would need separate initq's if the fundamental action for the two queues was different (ie one triggered a batch job, and the other triggered a CICS transaction). The basic philosphy at my site is to have one trigger monitor (and therefore one initq) per environment. This means 1 for each CICS, one for each IMS, one for batch on each MVS LPAR. You may find that you need more in order to control concurrency and manage your throughput, but you can't get away with less (except by not using triggering). BTW, if you are new to triggering, you should start with an idea that trigger(first) is most commonly the right solution. Trigger(depth) can have some specific uses (but watch out because it disables triggering when it fires, and your application is required to reset the trigger state) and Trigger(every) is quite possibly a design mistake by IBM. Trigger(every) has some dangerous properties, especially in a restart situation, where only one trigger message is generated, not one per message on the queue, so if you design your application with an expectation of trigger(every) and it only processes a single message per call, you can get stuck with messages on the queue not getting processed after a restart when persistent messages are in the queue at the shutdown or failure. Regards, Neil Casey. |-+> | | Brent Ireland| | | <[EMAIL PROTECTED]> | | | Sent by: MQSeries| | | List | | | <[EMAIL PROTECTED]| | | n.AC.AT> | | || | || | | 21/08/2003 07:32 | | | Please respond to| | | MQSeries List| | || |-+> >--- ---| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Initiation Queue | >--- ---| Hi I am new to MQ Series and have a question concerning initiation queues. i have set up 2 local queues that are defined for queue manager X. when a message arrives in q1 trigger a process to submit a JCL A. when a message arrives in q2 trigger a process to submit a JCL B. My question is do i have to define a initiation queue for each process or can i define just one initiation queue for both processes? which is the better method? thanks in advance. Brent Ireland CAE Inc. 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.ar
Re: JMS Pub/Sub using Different Streams
Jay, >>>My problem is how does the JMS, Pub/Sub classes tell the >>>broker what stream it wants its subscription on. I run the >>>show broker command, and I see the new stream, but my JMS >>>test program is registered for the topic in question on >>>the default stream. I don't see anything in the JMS >>>classes that I can set to specifiy a different stream. You would use the BROKERPUBQ property of the TCF definition to specify the publication queue name. 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
JMS Pub/Sub using Different Streams
I have a system currently using the Pub/Sub SupportPac broker. we send approx 12 million msg/day to the broker. My subscribers are using JMS, Pub/Sub to get the data for their topics. I now have the need to create different "STREAMS" for the broker to use to get better thoughput. I have written a C program that has registered another stream for the broker to use. I also have a C program that publishes on that stream to my topic. My problem is how does the JMS, Pub/Sub classes tell the broker what stream it wants its subscription on. I run the show broker command, and I see the new stream, but my JMS test program is registered for the topic in question on the default stream. I don't see anything in the JMS classes that I can set to specifiy a different stream. I am using A TopicConnectionFactory, TopicConnection, TopicSession and a durable subscriber. Thanks for any help. -- Jay H. Lang Chief Technologist Distributed Computing Professionals Inc. IBM Certified Specialist - MQSeries 303 277-1873 - Office 303 807-9700 - Cell 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: Evaluation List for Monitoring
Thought this would be of some help for those evaluating technology products. Spreadsheet categories are weighted so you can change those values to fit your needs. Good solid template to start from. If you have questions, don't hesitate to call. Steve 630.721.8861 -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Cynthia Wallace Sent: Thursday, August 21, 2003 2:29 PM To: [EMAIL PROTECTED] Subject: Re: Evaluation List for Monitoring >I have one day to provide what is needed to monitor MQSeries so we can >begin evaluating the various products out there. Has anyone done this >before and could you provide some guidelines for evaluating this type of software? Jeff, I hope you'll have more than one day to make a decision about which product to use ! The attached is a document you might find useful. There is additional criteria besides monitoring i.e. admin, configuration management, security et cetera. The big question is whether you simply want the tool to monitor or if you want escalation and what type of escalation ? are you you looking for automated resolution ? Good Luck - you're going to need it ! ===>(See attached file: Tool Eval worksheet.doc) Cynthia Wallace ___ This message was content-scanned by GatewayDefender 8/21/2003 - 3:55:28 PM - BG049b3c8e.0001.mml Vendor MQ Comparison.xls Description: MS-Excel spreadsheet Vendor MQ Comparison.doc Description: MS-Word document
Re: Syncpoint question
David I think your colleague is correct. As soon as the app starts doing its destructive gets then they will no longer be available for browsing... so the browser will only see a shrinking subset.. or none.. of the messages during this period. Once the puts start... the browser will see no messages until everything is committed... at that point the new set will be available and the old set is physically gone. I don't think his solution is the answer either... but I'm not convinced there is an answer. If the updater puts the new set out of syncpoint, then both the old and new sets are available for some period of time. As soon as he enters the destructive get loop, he again has the original problem - one by one the old messages are no longer available to the browsing app... and the new set may or may not be available depending upon the put syncpoint option. Assuming I am right about an uncommitted get stopping a message from being available to a browse, I think there will always be a window. Regards Darren. - Original Message - From: "David C. Partridge" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 21, 2003 2:30 PM Subject: Syncpoint question > A colleague of mine has raised a question which suggests there may be a > problem with a particular use of syncpoint processing. > > Consider a queue containing a number of messages (say 3) each with a unique > correlid. This queue is browsed by applications to extract certain > information.There is also an update application. > > The update application does a destructive get of the old messages and then > puts new messages all under a unit of work. When the last new message is > put the whole UOW is committed. > > My colleague is pretty certain that in this case there will be a window in > which a browsing application will not see a complete set of messages on the > queue (either old set or new set) and may in fact see no messages. Is he > correct? > > If he is correct, what is the best update strategy to ensure that a browsing > application will see either: > > The old set of messages > or > The new set of messages > > He has proposed the following as solution: > > Do a sequential browse of all the existing messages (that are not control > messages) and record the message ids as a persistent control message on the > same queue using a correlid that won't occur in the messages of interest (we > can do this). > > Put the new messages to the queue (either in or out of syncpoint) > > Under syncpoint loop doing a destructive get of any control messages and > messages with message ids as specified in the data of the control message. > > Commit. > > Regards, > David C. Partridge > Security and MQ Products Manager > Primeur Group > Tel: +44 (0)1926 511058 > Mobile: +44 (0)7713 880197 > > 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: Syncpoint question
Yup, when the app does a destructive GET under syncpoint, the message is no longer available, even though the UOW is still uncommitted. The queue depth reflects the message leaving the queue. How fast is the update app? If it only takes a few seconds to update and commit, during which time the browse apps would see nothing, then just code a wait interval into the browsers. As soon as the updates are posted they will get their browse back. When the update app is about to do its thing, it can get all the messages real fast, before processing them. This is so the browsing app has less chance of not being able to get to message #1 and #2 (already "in" the update app), but being able to get message #3. If this is a problem, i.e. you want the browsers to have an all new or all old scenario, then code the update app to open the queue exclusively, so no one can even get to the queue during the update period. Of course, the browsers would need retry logic. -Original Message- From: David C. Partridge [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 9:31 AM To: [EMAIL PROTECTED] Subject: Syncpoint question A colleague of mine has raised a question which suggests there may be a problem with a particular use of syncpoint processing. Consider a queue containing a number of messages (say 3) each with a unique correlid. This queue is browsed by applications to extract certain information.There is also an update application. The update application does a destructive get of the old messages and then puts new messages all under a unit of work. When the last new message is put the whole UOW is committed. My colleague is pretty certain that in this case there will be a window in which a browsing application will not see a complete set of messages on the queue (either old set or new set) and may in fact see no messages. Is he correct? If he is correct, what is the best update strategy to ensure that a browsing application will see either: The old set of messages or The new set of messages He has proposed the following as solution: Do a sequential browse of all the existing messages (that are not control messages) and record the message ids as a persistent control message on the same queue using a correlid that won't occur in the messages of interest (we can do this). Put the new messages to the queue (either in or out of syncpoint) Under syncpoint loop doing a destructive get of any control messages and messages with message ids as specified in the data of the control message. Commit. Regards, David C. Partridge Security and MQ Products Manager Primeur Group Tel: +44 (0)1926 511058 Mobile: +44 (0)7713 880197 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 CSQX558E - too many channels?
Thanx, Joep, I looked and found values of 200, which should have been enough considering our current level of activity. I am thinking that the message doc is somewhat misleading. I am assuming that dynamic channels are included in the specification and we are IP-only. I'll do some more research on the problem. again, Thanx. Ernest Roberts IT - Sr Sys Prog MBUSA, LLC __ Robert, There are several parameters limiting the number of active channels. They are in CSQ6CHIP. See sample SCSQPROC(CSQ4X4PRM). Have a look at ACTCHL, CURRCHL, LU62CHL and TCPCHL. Cheers, Joep -Original Message- From: EARmerc Roberts [mailto:[EMAIL PROTECTED] Sent: donderdag 21 augustus 2003 16:18 To: [EMAIL PROTECTED] Subject: message CSQX558E - too many channels? Hello MQ persons, We are running MQ v 5.3 on OS/390 v2.10. Our qmgr reported message CSQX558E for a channel and the M&C guide said about this: "there might be too many channels current to be able to start it." The channel appeared to have no problem after a STOP and then a START were issued. What I want to do is make sure I am not restricting our growing MQ traffic with my current parameter settings. Is there a parameter that actually limits the number of active channels? Is there a DISPLAY command that can show that parameter value? I found parameter "CTHREAD=300" in the assembly JCL for CSQ6SYSP. Also, "IDBACK=20" was specified for non-TSO connections. The doc doesn't give a clear indication of what the parameters affect, but does state that a channel initiator can have more than one connection to a qmgr. Am I on the right track with this issue? should I alter those parameters upward? Thanx in advance? Ernest Roberts IT - Sr Sys Prog MBUSA, LLC 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 ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. ** 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 CSQX558E - too many channels?
Thanx, Rebecca. I am hunting it down. Ernest Roberts IT - Sr Sys Prog MBUSA, LLC __ Hi, Ernest. Yes, there is a parameter that limits the number of active channels. It's in the CSQ6CHIP macro that you coded to create your XPARM for the CHIN address space. Hope this helps -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: EARmerc Roberts [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 10:18 AM To: [EMAIL PROTECTED] Subject: message CSQX558E - too many channels? Hello MQ persons, We are running MQ v 5.3 on OS/390 v2.10. Our qmgr reported message CSQX558E for a channel and the M&C guide said about this: "there might be too many channels current to be able to start it." The channel appeared to have no problem after a STOP and then a START were issued. What I want to do is make sure I am not restricting our growing MQ traffic with my current parameter settings. Is there a parameter that actually limits the number of active channels? Is there a DISPLAY command that can show that parameter value? I found parameter "CTHREAD=300" in the assembly JCL for CSQ6SYSP. Also, "IDBACK=20" was specified for non-TSO connections. The doc doesn't give a clear indication of what the parameters affect, but does state that a channel initiator can have more than one connection to a qmgr. Am I on the right track with this issue? should I alter those parameters upward? Thanx in advance? Ernest Roberts IT - Sr Sys Prog MBUSA, LLC Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Syncpoint question
I wish IBM was that consistent... On Z/OS the shared queues require the use of DB2. Robert Sloper Data Center: Middleware Phone: (613) 837 9879 [EMAIL PROTECTED] Paul Clarke <[EMAIL PROTECTED] To:[EMAIL PROTECTED] COM> cc: Sent by: MQSeries Subject: Re: Syncpoint question List <[EMAIL PROTECTED] .AT> 08/21/03 01:41 PM Please respond to MQSeries List >I just can't resist asking - but isn't SYSTEM.CLUSTER.REPOSITORY.QUEUE just >a database of clustering info and SYSTEM.AUTH.DATA.QUEUE a database of >authorisation profiles? Tut tut :-) >Regards >John. >PS. Please don't move this info into UDB - I like it the way it is... John, It was a slightly tongue-in-cheek comment. However, there are very good reasons why we as MQ writers don't want to have any databases as prereqs for the product (we sorta figured that you customers just wouldn't like it) so we do tend to use our queues as repositories (not databases :-) ). However, in your application environments don't you have those database thingies all over the place anyway ? The key is that you already have one generally so you can use it. We on the other hand just wouldn't know which database to choose. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Syncpoint question
Does the information in those ' repositories' have to be persistent? Once the Qmgr has been recycled does MQ care what was there before? - R "Paul Clarke" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 08/21/2003 01:41 PM Please respond to "MQSeries List" To: [EMAIL PROTECTED] cc: Subject: Re: Syncpoint question >I just can't resist asking - but isn't SYSTEM.CLUSTER.REPOSITORY.QUEUE just >a database of clustering info and SYSTEM.AUTH.DATA.QUEUE a database of >authorisation profiles? Tut tut :-) >Regards >John. >PS. Please don't move this info into UDB - I like it the way it is... John, It was a slightly tongue-in-cheek comment. However, there are very good reasons why we as MQ writers don't want to have any databases as prereqs for the product (we sorta figured that you customers just wouldn't like it) so we do tend to use our queues as repositories (not databases :-) ). However, in your application environments don't you have those database thingies all over the place anyway ? The key is that you already have one generally so you can use it. We on the other hand just wouldn't know which database to choose. 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 The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
Re: Syncpoint question
>I just can't resist asking - but isn't SYSTEM.CLUSTER.REPOSITORY.QUEUE just >a database of clustering info and SYSTEM.AUTH.DATA.QUEUE a database of >authorisation profiles? Tut tut :-) >Regards >John. >PS. Please don't move this info into UDB - I like it the way it is... John, It was a slightly tongue-in-cheek comment. However, there are very good reasons why we as MQ writers don't want to have any databases as prereqs for the product (we sorta figured that you customers just wouldn't like it) so we do tend to use our queues as repositories (not databases :-) ). However, in your application environments don't you have those database thingies all over the place anyway ? The key is that you already have one generally so you can use it. We on the other hand just wouldn't know which database to choose. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Evaluation List for Monitoring
Title: RE: Evaluation List for Monitoring Greetings: I wanted to apologize for sending this last response to the list. I meant to send it to someone where I work and didn't change the "TO". Keith -Original Message- From: Hessong, Keith Sent: Thursday, August 21, 2003 12:39 PM To: 'MQSeries List' Subject: RE: Evaluation List for Monitoring Kyle, Thought you might like to see this list of items I received off of the MQ Forum I subscribe to. Keith -Original Message- From: Wmq Techie [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 21, 2003 12:27 PM To: [EMAIL PROTECTED] Subject: Re: Evaluation List for Monitoring Channel status (running, indoubt, retrying, and stopped) application queue depth (messages building on queue, current depth) and application getting messages (ipprocs > 0) Dead letter queue messages ( current depth message > 0) queue manager (active or inactive) .. just a few .. HTH, techie > I have one day to provide what is needed to monitor MQSeries so we can > begin evaluating the various products out there. Has anyone done this > before > and could you provide some guidelines for evaluating this type of software? > > 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: Evaluation List for Monitoring
Title: RE: Evaluation List for Monitoring Kyle, Thought you might like to see this list of items I received off of the MQ Forum I subscribe to. Keith -Original Message- From: Wmq Techie [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 21, 2003 12:27 PM To: [EMAIL PROTECTED] Subject: Re: Evaluation List for Monitoring Channel status (running, indoubt, retrying, and stopped) application queue depth (messages building on queue, current depth) and application getting messages (ipprocs > 0) Dead letter queue messages ( current depth message > 0) queue manager (active or inactive) .. just a few .. HTH, techie > I have one day to provide what is needed to monitor MQSeries so we can > begin evaluating the various products out there. Has anyone done this > before > and could you provide some guidelines for evaluating this type of software? > > 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: Evaluation List for Monitoring
Channel status (running, indoubt, retrying, and stopped) application queue depth (messages building on queue, current depth) and application getting messages (ipprocs > 0) Dead letter queue messages ( current depth message > 0) queue manager (active or inactive) .. just a few .. HTH, techie > I have one day to provide what is needed to monitor MQSeries so we can > begin evaluating the various products out there. Has anyone done this > before > and could you provide some guidelines for evaluating this type of software? > > 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
Evaluation List for Monitoring
I have one day to provide what is needed to monitor MQSeries so we can begin evaluating the various products out there. Has anyone done this before and could you provide some guidelines for evaluating this type of software? 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: mqver remotely? Maybe MO71?
does it run rm *? John Matoba <[EMAIL PROTECTED] To: [EMAIL PROTECTED] MUTUAL.COM> cc: Sent by: MQSeries List Subject: Re: mqver remotely? Maybe MO71? <[EMAIL PROTECTED] > 08/21/2003 12:03 PM Please respond to MQSeries List We created a script that is triggered by an MQ message and assumes the message body contains a unix command. When the script is triggered, it runs the unix command and returns the output in a reply message. From a hub queue manager, we can send an mqver command to all our queue managers and generate a report of all the version info on all our queue managers. Such a script is fairly simple to write and as you might imagine, is quite useful in centrally issuing other unix commands. John Matoba Information Systems Northwestern Mutual Life 414-665-4160 -Original Message- From: Peter.Potkay [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 10:02 AM To: MQSERIES Subject: Re: mqver remotely? Maybe MO71? Paul, I am forwarding your reply to my IBM rep Tom Kruczek. Maybe he can push this request over to Hursley officially. -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 10:50 AM To: [EMAIL PROTECTED] Subject: Re: mqver remotely? Maybe MO71? >Is there anyway to get the MQ version of a box without having to actually >log onto the box? MQExplorer? QPASA? MO71? >It is a pain having to log onto individual boxes just to run the mqver >command when you want to see what CSDs have been applied. >Paul, would there be anyway for MO71 to do this in a future version? MO71 pretty much only talks to the command server, this is so it doesn't require an agent running on the target machine. Consequently if you want MO71 to be able to tell you the CSD level it really means that we need a command server version of the MQVER command. It doesn't seem an unreasonable requirement to me to have one added but this isn't really my area. 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 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 BDY.RTF Description: RTF file
Re: mqver remotely? Maybe MO71?
Another server? Why can't the people at Hursley add a new attribute for the queue manager properties. We have "Command Level", why not add a new attribute called "CSD Level". later Roger... Quoting "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>: > Paul, I am forwarding your reply to my IBM rep Tom Kruczek. Maybe he can > push this request over to Hursley officially. > > > -Original Message- > From: Paul Clarke [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 21, 2003 10:50 AM > To: [EMAIL PROTECTED] > Subject: Re: mqver remotely? Maybe MO71? > > > >Is there anyway to get the MQ version of a box without having to actually > >log onto the box? MQExplorer? QPASA? MO71? > > >It is a pain having to log onto individual boxes just to run the mqver > >command when you want to see what CSDs have been applied. > > >Paul, would there be anyway for MO71 to do this in a future version? > > MO71 pretty much only talks to the command server, this is so it doesn't > require an agent running on the target machine. Consequently if you want > MO71 to be able to tell you the CSD level it really means that we need a > command server version of the MQVER command. It doesn't seem an > unreasonable requirement to me to have one added but this isn't really my > area. > > 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 > > > 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: mqver remotely? Maybe MO71?
BDY.RTF Description: RTF file
Re: Syncpoint question
Title: RE: Syncpoint question hhmm when I describe Queues as a 'safe' place for your data, often people respond: "ah, so it's a database!" :-) -Original Message- From: John Scott [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 21, 2003 6:58 PM To: [EMAIL PROTECTED] Subject: Re: Syncpoint question I just can't resist asking - but isn't SYSTEM.CLUSTER.REPOSITORY.QUEUE just a database of clustering info and SYSTEM.AUTH.DATA.QUEUE a database of authorisation profiles? Tut tut :-) Regards John. PS. Please don't move this info into UDB - I like it the way it is... -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED]] Sent: 21 August 2003 14:54 To: [EMAIL PROTECTED] Subject: Re: Syncpoint question Dave, Don't tell me you're using a queue as a database ? tsk tsk :-) Paul G Clarke WebSphere MQ Development IBM Hursley "David C. Partridge" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: RIMEUR.COM> Subject: Syncpoint question Sent by: MQSeries List <[EMAIL PROTECTED] .AC.AT> 21/08/2003 14:30 Please respond to MQSeries List A colleague of mine has raised a question which suggests there may be a problem with a particular use of syncpoint processing. Consider a queue containing a number of messages (say 3) each with a unique correlid. This queue is browsed by applications to extract certain information. There is also an update application. The update application does a destructive get of the old messages and then puts new messages all under a unit of work. When the last new message is put the whole UOW is committed. My colleague is pretty certain that in this case there will be a window in which a browsing application will not see a complete set of messages on the queue (either old set or new set) and may in fact see no messages. Is he correct? If he is correct, what is the best update strategy to ensure that a browsing application will see either: The old set of messages or The new set of messages He has proposed the following as solution: Do a sequential browse of all the existing messages (that are not control messages) and record the message ids as a persistent control message on the same queue using a correlid that won't occur in the messages of interest (we can do this). Put the new messages to the queue (either in or out of syncpoint) Under syncpoint loop doing a destructive get of any control messages and messages with message ids as specified in the data of the control message. Commit. Regards, David C. Partridge Security and MQ Products Manager Primeur Group Tel: +44 (0)1926 511058 Mobile: +44 (0)7713 880197 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 ** 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 confidential, and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you are not the intended addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using your reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail maybe accessed. ** 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 - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the fi
Re: as/400 xcom
would be nice to just lay the file down, right now there is no recovery when they lose a connection we do trigger on the orders when they come in, so that is an option Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] Everyone has a photographic memory Its just that some do not have film -- Rick Tsujimoto <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 08/21/2003 08:47 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: as/400 xcom Do you plan to trigger some app, or just lay the file down? Dave Adam <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ERVALU.COM> cc: Sent by: Subject: as/400 xcom MQSeries List <[EMAIL PROTECTED] en.AC.AT> 08/21/2003 09:10 AM Please respond to MQSeries List I did a presentation yesterday to about 50 people in the company had IBM explain MQ in the first 30 minutes, and then explained whet we did to stabilize the order system that is our only MQ application now the woodwork is closing in the best candidate for a second successful conversion looks like the as/400 to mainframe file transfers is there a support pac out there that could be used as an example to accomplish the simple movement of data from point a to point b (no response required with this message transfer) Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] Everyone has a photographic memory Its just that some do not have film -- 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: UNSUBSCRIBE
There is no automated provision for this. You will need to send an email to [EMAIL PROTECTED] This goes to the real humans who administer the list so write a letter instead of sending a "SIGNOFF" command. -- T.Rob -Original Message- From: Thomas Lane [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 10:34 AM To: [EMAIL PROTECTED] Subject: Re: UNSUBSCRIBE Rebecca, How do we sign off if our email address has changed. My email address went from [EMAIL PROTECTED] to [EMAIL PROTECTED] In order for me to post, I signed up to the list under my new email address. Now I get two emails for each post. I believe if I unsubscribe, I will be unsubscribing for my new email address and not my old email address. Thanks, Thomas Lane Senior Manager, Unix Development - Middleware Pershing Technology Group East Brunswick, NJ Phone: 732-565-8289 "Bullock, Rebecca (CSC)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: >Subject: Re: UNSUBSCRIBE Sent by: MQSeries List <[EMAIL PROTECTED] N.AC.AT> 08/21/2003 09:32 AM Please respond to MQSeries List Once again Here's what you need to do: You may leave the list at any time by sending a "SIGNOFF MQSERIES" command (no quotes and use this as the body of the message) to [EMAIL PROTECTED] Do NOT send this to [EMAIL PROTECTED]; that won't get you off this listserv, it'll only send your wish to do so to everyone on the list. -Original Message- From: Kinlen, Dan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 11:12 AM To: [EMAIL PROTECTED] Subject: UNSUBSCRIBE UNSUBSCRIBE RBC Dain Rauscher does not accept buy, sell or cancel orders by e-mail, or any instructions by e-mail that would require your signature. Information contained in this communication is not considered an official record of your account and does not supersede normal trade confirmations or statements. Any information provided has been prepared from sources believed to be reliable but is not guaranteed, does not represent all available data necessary for making investment decisions and is for informational purposes only. This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you receive this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Information received by or sent from this system is subject to review by supervisory personnel, is retained and may be produced to regulatory authorities or others with a legal right to the information. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: Syncpoint question
I just can't resist asking - but isn't SYSTEM.CLUSTER.REPOSITORY.QUEUE just a database of clustering info and SYSTEM.AUTH.DATA.QUEUE a database of authorisation profiles? Tut tut :-) Regards John. PS. Please don't move this info into UDB - I like it the way it is... -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: 21 August 2003 14:54 To: [EMAIL PROTECTED] Subject: Re: Syncpoint question Dave, Don't tell me you're using a queue as a database ? tsk tsk :-) Paul G Clarke WebSphere MQ Development IBM Hursley "David C. Partridge"To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: RIMEUR.COM> Subject: Syncpoint question Sent by: MQSeries List <[EMAIL PROTECTED] .AC.AT> 21/08/2003 14:30 Please respond to MQSeries List A colleague of mine has raised a question which suggests there may be a problem with a particular use of syncpoint processing. Consider a queue containing a number of messages (say 3) each with a unique correlid. This queue is browsed by applications to extract certain information.There is also an update application. The update application does a destructive get of the old messages and then puts new messages all under a unit of work. When the last new message is put the whole UOW is committed. My colleague is pretty certain that in this case there will be a window in which a browsing application will not see a complete set of messages on the queue (either old set or new set) and may in fact see no messages. Is he correct? If he is correct, what is the best update strategy to ensure that a browsing application will see either: The old set of messages or The new set of messages He has proposed the following as solution: Do a sequential browse of all the existing messages (that are not control messages) and record the message ids as a persistent control message on the same queue using a correlid that won't occur in the messages of interest (we can do this). Put the new messages to the queue (either in or out of syncpoint) Under syncpoint loop doing a destructive get of any control messages and messages with message ids as specified in the data of the control message. Commit. Regards, David C. Partridge Security and MQ Products Manager Primeur Group Tel: +44 (0)1926 511058 Mobile: +44 (0)7713 880197 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 ** 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 confidential, and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you are not the intended addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using your reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail maybe accessed. ** 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: UNSUBSCRIBE
Thanks Rebecca, Yep, I'm in East Brunswick and MQ'in. Thomas Lane Senior Manager, Unix Development - Middleware Pershing Technology Group East Brunswick, NJ Phone: 732-565-8289 "Bullock, Rebecca (CSC)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: >Subject: Re: UNSUBSCRIBE Sent by: MQSeries List <[EMAIL PROTECTED] n.AC.AT> 08/21/2003 11:23 AM Please respond to MQSeries List Hey! New Brunswick! Hello, fellow New Jerseyite. Some listservs send out probes that delete people if they get a bounce back. Maybe this one does, too (although I've never gotten a message that just said "probing"; but maybe they just delete you after x numbers of returned, addressee unknown messages?). If you look at the listserv manual (http://www.lsoft.com/manuals/1.8e/user/user.pdf), it tells you how to send an e-mail to the actual list owner. You could try that approach. HTH, Rebecca -Original Message- From: Thomas Lane [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 10:34 AM To: [EMAIL PROTECTED] Subject: Re: UNSUBSCRIBE Rebecca, How do we sign off if our email address has changed. My email address went from [EMAIL PROTECTED] to [EMAIL PROTECTED] In order for me to post, I signed up to the list under my new email address. Now I get two emails for each post. I believe if I unsubscribe, I will be unsubscribing for my new email address and not my old email address. Thanks, Thomas Lane Senior Manager, Unix Development - Middleware Pershing Technology Group East Brunswick, NJ Phone: 732-565-8289 "Bullock, Rebecca (CSC)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: >Subject: Re: UNSUBSCRIBE Sent by: MQSeries List <[EMAIL PROTECTED] N.AC.AT> 08/21/2003 09:32 AM Please respond to MQSeries List Once again Here's what you need to do: You may leave the list at any time by sending a "SIGNOFF MQSERIES" command (no quotes and use this as the body of the message) to [EMAIL PROTECTED] Do NOT send this to [EMAIL PROTECTED]; that won't get you off this listserv, it'll only send your wish to do so to everyone on the list. -Original Message- From: Kinlen, Dan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 11:12 AM To: [EMAIL PROTECTED] Subject: UNSUBSCRIBE UNSUBSCRIBE RBC Dain Rauscher does not accept buy, sell or cancel orders by e-mail, or any instructions by e-mail that would require your signature. Information contained in this communication is not considered an official record of your account and does not supersede normal trade confirmations or statements. Any information provided has been prepared from sources believed to be reliable but is not guaranteed, does not represent all available data necessary for making investment decisions and is for informational purposes only. This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you receive this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Information received by or sent from this system is subject to review by supervisory personnel, is retained and may be produced to regulatory authorities or others with a legal right to the information. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users
Re: Syncpoint question
Browse with a LOCK option bb From: "David C. Partridge" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Syncpoint question Date: Thu, 21 Aug 2003 14:30:37 +0100 A colleague of mine has raised a question which suggests there may be a problem with a particular use of syncpoint processing. Consider a queue containing a number of messages (say 3) each with a unique correlid. This queue is browsed by applications to extract certain information.There is also an update application. The update application does a destructive get of the old messages and then puts new messages all under a unit of work. When the last new message is put the whole UOW is committed. My colleague is pretty certain that in this case there will be a window in which a browsing application will not see a complete set of messages on the queue (either old set or new set) and may in fact see no messages. Is he correct? If he is correct, what is the best update strategy to ensure that a browsing application will see either: The old set of messages or The new set of messages He has proposed the following as solution: Do a sequential browse of all the existing messages (that are not control messages) and record the message ids as a persistent control message on the same queue using a correlid that won't occur in the messages of interest (we can do this). Put the new messages to the queue (either in or out of syncpoint) Under syncpoint loop doing a destructive get of any control messages and messages with message ids as specified in the data of the control message. Commit. Regards, David C. Partridge Security and MQ Products Manager Primeur Group Tel: +44 (0)1926 511058 Mobile: +44 (0)7713 880197 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ Get MSN 8 and enjoy automatic e-mail virus protection. http://join.msn.com/?page=features/virus 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: MSGID Char conversion
I was here till the w hours of the morning working on this (I am not a C code warrior). I have it almost done except for the loop when it gets to the 48th byte. It is overwriting memory and distroying my PMO. I issue an MQPUT after the convert and get a 2173 on the first PUT. IF I comment out the 8 line conversion routine it works perfect. If I change the loop to convert 46bytes it works..but I loose that last qualifing byte (unfortunatly this one is the tie breaker). BUTwith all that work...the file is coming out of a REXX script. the guy, who wasn't here last night, did a 5 min chnge and is handing me the field in it's origional 24 byte format/structure. NOWthe script was taking the HEX/DEC 24 byte MSGID/CORREL ID and inserting it in the front of the file in STRING format. In REXX and C++ the back and forth is easy. C on the other hand. So I reacquainted myself with C last night. (VERY LATE I might add!!!) But hey...one of my favorite sayings is "If you are busting your chops, you are doing it the wrong way!!" I should listen to myself bobbee From: Pavel Tolkachev <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: MSGID Char conversion Date: Thu, 21 Aug 2003 09:29:22 -0400 Hello Bobbie, What is 48 byte character format of MsgId? I thought it is always MQBYTE24. For that I would use memcpy(msgDesc.MsgId, newMsgId, MQ_MSG_ID_LENGTH); Pavel Robert Broderick <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OTMAIL.COM> cc: Sent by: MQSeries Subject: MSGID Char conversion List <[EMAIL PROTECTED] .AC.AT> 08/20/2003 06:26 PM Please respond to MQSeries List I have an extracted MSGID in 48 byte character format. I want to place it back in the MQMD_MSGID field. Can anybody supply the code statement??? stuck bobbee _ Get MSN 8 and enjoy automatic e-mail virus protection. http://join.msn.com/?page=features/virus 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 _ Get MSN 8 and enjoy automatic e-mail virus protection. http://join.msn.com/?page=features/virus 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: Syncpoint question
You mean like the OAM and the Cluster repository data :-) Yes, I plead guilty ... Any thoughts on the specific questions? Cheers Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Paul Clarke Sent: 21 August 2003 15:54 To: [EMAIL PROTECTED] Subject: Re: Syncpoint question Dave, Don't tell me you're using a queue as a database ? tsk tsk :-) Paul G Clarke WebSphere MQ Development IBM Hursley "David C. Partridge"To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: RIMEUR.COM> Subject: Syncpoint question Sent by: MQSeries List <[EMAIL PROTECTED] .AC.AT> 21/08/2003 14:30 Please respond to MQSeries List A colleague of mine has raised a question which suggests there may be a problem with a particular use of syncpoint processing. Consider a queue containing a number of messages (say 3) each with a unique correlid. This queue is browsed by applications to extract certain information.There is also an update application. The update application does a destructive get of the old messages and then puts new messages all under a unit of work. When the last new message is put the whole UOW is committed. My colleague is pretty certain that in this case there will be a window in which a browsing application will not see a complete set of messages on the queue (either old set or new set) and may in fact see no messages. Is he correct? If he is correct, what is the best update strategy to ensure that a browsing application will see either: The old set of messages or The new set of messages He has proposed the following as solution: Do a sequential browse of all the existing messages (that are not control messages) and record the message ids as a persistent control message on the same queue using a correlid that won't occur in the messages of interest (we can do this). Put the new messages to the queue (either in or out of syncpoint) Under syncpoint loop doing a destructive get of any control messages and messages with message ids as specified in the data of the control message. Commit. Regards, David C. Partridge Security and MQ Products Manager Primeur Group Tel: +44 (0)1926 511058 Mobile: +44 (0)7713 880197 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: UNSUBSCRIBE
You have to send an EMAIL to the LISTSERV Admin. From: Thomas Lane <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: UNSUBSCRIBE Date: Thu, 21 Aug 2003 10:34:05 -0400 Rebecca, How do we sign off if our email address has changed. My email address went from [EMAIL PROTECTED] to [EMAIL PROTECTED] In order for me to post, I signed up to the list under my new email address. Now I get two emails for each post. I believe if I unsubscribe, I will be unsubscribing for my new email address and not my old email address. Thanks, Thomas Lane Senior Manager, Unix Development - Middleware Pershing Technology Group East Brunswick, NJ Phone: 732-565-8289 "Bullock, Rebecca (CSC)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: >Subject: Re: UNSUBSCRIBE Sent by: MQSeries List <[EMAIL PROTECTED] N.AC.AT> 08/21/2003 09:32 AM Please respond to MQSeries List Once again Here's what you need to do: You may leave the list at any time by sending a "SIGNOFF MQSERIES" command (no quotes and use this as the body of the message) to [EMAIL PROTECTED] Do NOT send this to [EMAIL PROTECTED]; that won't get you off this listserv, it'll only send your wish to do so to everyone on the list. -Original Message- From: Kinlen, Dan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 11:12 AM To: [EMAIL PROTECTED] Subject: UNSUBSCRIBE UNSUBSCRIBE RBC Dain Rauscher does not accept buy, sell or cancel orders by e-mail, or any instructions by e-mail that would require your signature. Information contained in this communication is not considered an official record of your account and does not supersede normal trade confirmations or statements. Any information provided has been prepared from sources believed to be reliable but is not guaranteed, does not represent all available data necessary for making investment decisions and is for informational purposes only. This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you receive this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Information received by or sent from this system is subject to review by supervisory personnel, is retained and may be produced to regulatory authorities or others with a legal right to the information. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ Get MSN 8 and help protect your children with advanced parental controls. http://join.msn.com/?page=features/parental 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 CSQX558E - too many channels?
Robert, There are several parameters limiting the number of active channels. They are in CSQ6CHIP. See sample SCSQPROC(CSQ4X4PRM). Have a look at ACTCHL, CURRCHL, LU62CHL and TCPCHL. Cheers, Joep -Original Message- From: EARmerc Roberts [mailto:[EMAIL PROTECTED] Sent: donderdag 21 augustus 2003 16:18 To: [EMAIL PROTECTED] Subject: message CSQX558E - too many channels? Hello MQ persons, We are running MQ v 5.3 on OS/390 v2.10. Our qmgr reported message CSQX558E for a channel and the M&C guide said about this: "there might be too many channels current to be able to start it." The channel appeared to have no problem after a STOP and then a START were issued. What I want to do is make sure I am not restricting our growing MQ traffic with my current parameter settings. Is there a parameter that actually limits the number of active channels? Is there a DISPLAY command that can show that parameter value? I found parameter "CTHREAD=300" in the assembly JCL for CSQ6SYSP. Also, "IDBACK=20" was specified for non-TSO connections. The doc doesn't give a clear indication of what the parameters affect, but does state that a channel initiator can have more than one connection to a qmgr. Am I on the right track with this issue? should I alter those parameters upward? Thanx in advance? Ernest Roberts IT - Sr Sys Prog MBUSA, LLC 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 ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. ** 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: UNSUBSCRIBE
Hey! New Brunswick! Hello, fellow New Jerseyite. Some listservs send out probes that delete people if they get a bounce back. Maybe this one does, too (although I've never gotten a message that just said "probing"; but maybe they just delete you after x numbers of returned, addressee unknown messages?). If you look at the listserv manual (http://www.lsoft.com/manuals/1.8e/user/user.pdf), it tells you how to send an e-mail to the actual list owner. You could try that approach. HTH, Rebecca -Original Message- From: Thomas Lane [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 10:34 AM To: [EMAIL PROTECTED] Subject: Re: UNSUBSCRIBE Rebecca, How do we sign off if our email address has changed. My email address went from [EMAIL PROTECTED] to [EMAIL PROTECTED] In order for me to post, I signed up to the list under my new email address. Now I get two emails for each post. I believe if I unsubscribe, I will be unsubscribing for my new email address and not my old email address. Thanks, Thomas Lane Senior Manager, Unix Development - Middleware Pershing Technology Group East Brunswick, NJ Phone: 732-565-8289 "Bullock, Rebecca (CSC)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: >Subject: Re: UNSUBSCRIBE Sent by: MQSeries List <[EMAIL PROTECTED] N.AC.AT> 08/21/2003 09:32 AM Please respond to MQSeries List Once again Here's what you need to do: You may leave the list at any time by sending a "SIGNOFF MQSERIES" command (no quotes and use this as the body of the message) to [EMAIL PROTECTED] Do NOT send this to [EMAIL PROTECTED]; that won't get you off this listserv, it'll only send your wish to do so to everyone on the list. -Original Message- From: Kinlen, Dan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 11:12 AM To: [EMAIL PROTECTED] Subject: UNSUBSCRIBE UNSUBSCRIBE RBC Dain Rauscher does not accept buy, sell or cancel orders by e-mail, or any instructions by e-mail that would require your signature. Information contained in this communication is not considered an official record of your account and does not supersede normal trade confirmations or statements. Any information provided has been prepared from sources believed to be reliable but is not guaranteed, does not represent all available data necessary for making investment decisions and is for informational purposes only. This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you receive this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Information received by or sent from this system is subject to review by supervisory personnel, is retained and may be produced to regulatory authorities or others with a legal right to the information. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. Instructions for managing your mailing list subscription are provided in
Re: message CSQX558E - too many channels?
Hi, Ernest. Yes, there is a parameter that limits the number of active channels. It's in the CSQ6CHIP macro that you coded to create your XPARM for the CHIN address space. Hope this helps -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: EARmerc Roberts [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 10:18 AM To: [EMAIL PROTECTED] Subject: message CSQX558E - too many channels? Hello MQ persons, We are running MQ v 5.3 on OS/390 v2.10. Our qmgr reported message CSQX558E for a channel and the M&C guide said about this: "there might be too many channels current to be able to start it." The channel appeared to have no problem after a STOP and then a START were issued. What I want to do is make sure I am not restricting our growing MQ traffic with my current parameter settings. Is there a parameter that actually limits the number of active channels? Is there a DISPLAY command that can show that parameter value? I found parameter "CTHREAD=300" in the assembly JCL for CSQ6SYSP. Also, "IDBACK=20" was specified for non-TSO connections. The doc doesn't give a clear indication of what the parameters affect, but does state that a channel initiator can have more than one connection to a qmgr. Am I on the right track with this issue? should I alter those parameters upward? Thanx in advance? Ernest Roberts IT - Sr Sys Prog MBUSA, LLC Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: mqver remotely? Maybe MO71?
Paul, I am forwarding your reply to my IBM rep Tom Kruczek. Maybe he can push this request over to Hursley officially. -Original Message- From: Paul Clarke [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 10:50 AM To: [EMAIL PROTECTED] Subject: Re: mqver remotely? Maybe MO71? >Is there anyway to get the MQ version of a box without having to actually >log onto the box? MQExplorer? QPASA? MO71? >It is a pain having to log onto individual boxes just to run the mqver >command when you want to see what CSDs have been applied. >Paul, would there be anyway for MO71 to do this in a future version? MO71 pretty much only talks to the command server, this is so it doesn't require an agent running on the target machine. Consequently if you want MO71 to be able to tell you the CSD level it really means that we need a command server version of the MQVER command. It doesn't seem an unreasonable requirement to me to have one added but this isn't really my area. 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 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: Syncpoint question
Dave, Don't tell me you're using a queue as a database ? tsk tsk :-) Paul G Clarke WebSphere MQ Development IBM Hursley "David C. Partridge"To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: RIMEUR.COM> Subject: Syncpoint question Sent by: MQSeries List <[EMAIL PROTECTED] .AC.AT> 21/08/2003 14:30 Please respond to MQSeries List A colleague of mine has raised a question which suggests there may be a problem with a particular use of syncpoint processing. Consider a queue containing a number of messages (say 3) each with a unique correlid. This queue is browsed by applications to extract certain information.There is also an update application. The update application does a destructive get of the old messages and then puts new messages all under a unit of work. When the last new message is put the whole UOW is committed. My colleague is pretty certain that in this case there will be a window in which a browsing application will not see a complete set of messages on the queue (either old set or new set) and may in fact see no messages. Is he correct? If he is correct, what is the best update strategy to ensure that a browsing application will see either: The old set of messages or The new set of messages He has proposed the following as solution: Do a sequential browse of all the existing messages (that are not control messages) and record the message ids as a persistent control message on the same queue using a correlid that won't occur in the messages of interest (we can do this). Put the new messages to the queue (either in or out of syncpoint) Under syncpoint loop doing a destructive get of any control messages and messages with message ids as specified in the data of the control message. Commit. Regards, David C. Partridge Security and MQ Products Manager Primeur Group Tel: +44 (0)1926 511058 Mobile: +44 (0)7713 880197 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
AS/400 and Java
We looking for using Java on AS/400.Does anyone has any performance factors of Java on AS/400 Also please let me know if anyone faced any problems with this approach? We are also looking for what would be the best approach for calling java from RPG. Any help would be appreciated. Thanks Gaurav
message CSQX558E - too many channels?
Hello MQ persons, We are running MQ v 5.3 on OS/390 v2.10. Our qmgr reported message CSQX558E for a channel and the M&C guide said about this: "there might be too many channels current to be able to start it." The channel appeared to have no problem after a STOP and then a START were issued. What I want to do is make sure I am not restricting our growing MQ traffic with my current parameter settings. Is there a parameter that actually limits the number of active channels? Is there a DISPLAY command that can show that parameter value? I found parameter "CTHREAD=300" in the assembly JCL for CSQ6SYSP. Also, "IDBACK=20" was specified for non-TSO connections. The doc doesn't give a clear indication of what the parameters affect, but does state that a channel initiator can have more than one connection to a qmgr. Am I on the right track with this issue? should I alter those parameters upward? Thanx in advance? Ernest Roberts IT - Sr Sys Prog MBUSA, LLC 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: UNSUBSCRIBE
Rebecca, How do we sign off if our email address has changed. My email address went from [EMAIL PROTECTED] to [EMAIL PROTECTED] In order for me to post, I signed up to the list under my new email address. Now I get two emails for each post. I believe if I unsubscribe, I will be unsubscribing for my new email address and not my old email address. Thanks, Thomas Lane Senior Manager, Unix Development - Middleware Pershing Technology Group East Brunswick, NJ Phone: 732-565-8289 "Bullock, Rebecca (CSC)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: >Subject: Re: UNSUBSCRIBE Sent by: MQSeries List <[EMAIL PROTECTED] N.AC.AT> 08/21/2003 09:32 AM Please respond to MQSeries List Once again Here's what you need to do: You may leave the list at any time by sending a "SIGNOFF MQSERIES" command (no quotes and use this as the body of the message) to [EMAIL PROTECTED] Do NOT send this to [EMAIL PROTECTED]; that won't get you off this listserv, it'll only send your wish to do so to everyone on the list. -Original Message- From: Kinlen, Dan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 11:12 AM To: [EMAIL PROTECTED] Subject: UNSUBSCRIBE UNSUBSCRIBE RBC Dain Rauscher does not accept buy, sell or cancel orders by e-mail, or any instructions by e-mail that would require your signature. Information contained in this communication is not considered an official record of your account and does not supersede normal trade confirmations or statements. Any information provided has been prepared from sources believed to be reliable but is not guaranteed, does not represent all available data necessary for making investment decisions and is for informational purposes only. This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you receive this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Information received by or sent from this system is subject to review by supervisory personnel, is retained and may be produced to regulatory authorities or others with a legal right to the information. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: mqver remotely? Maybe MO71?
>Is there anyway to get the MQ version of a box without having to actually >log onto the box? MQExplorer? QPASA? MO71? >It is a pain having to log onto individual boxes just to run the mqver >command when you want to see what CSDs have been applied. >Paul, would there be anyway for MO71 to do this in a future version? MO71 pretty much only talks to the command server, this is so it doesn't require an agent running on the target machine. Consequently if you want MO71 to be able to tell you the CSD level it really means that we need a command server version of the MQVER command. It doesn't seem an unreasonable requirement to me to have one added but this isn't really my area. 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
Syncpoint question
A colleague of mine has raised a question which suggests there may be a problem with a particular use of syncpoint processing. Consider a queue containing a number of messages (say 3) each with a unique correlid. This queue is browsed by applications to extract certain information.There is also an update application. The update application does a destructive get of the old messages and then puts new messages all under a unit of work. When the last new message is put the whole UOW is committed. My colleague is pretty certain that in this case there will be a window in which a browsing application will not see a complete set of messages on the queue (either old set or new set) and may in fact see no messages. Is he correct? If he is correct, what is the best update strategy to ensure that a browsing application will see either: The old set of messages or The new set of messages He has proposed the following as solution: Do a sequential browse of all the existing messages (that are not control messages) and record the message ids as a persistent control message on the same queue using a correlid that won't occur in the messages of interest (we can do this). Put the new messages to the queue (either in or out of syncpoint) Under syncpoint loop doing a destructive get of any control messages and messages with message ids as specified in the data of the control message. Commit. Regards, David C. Partridge Security and MQ Products Manager Primeur Group Tel: +44 (0)1926 511058 Mobile: +44 (0)7713 880197 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: as/400 xcom
Do you plan to trigger some app, or just lay the file down? Dave Adam <[EMAIL PROTECTED] To: [EMAIL PROTECTED] ERVALU.COM> cc: Sent by: Subject: as/400 xcom MQSeries List <[EMAIL PROTECTED] en.AC.AT> 08/21/2003 09:10 AM Please respond to MQSeries List I did a presentation yesterday to about 50 people in the company had IBM explain MQ in the first 30 minutes, and then explained whet we did to stabilize the order system that is our only MQ application now the woodwork is closing in the best candidate for a second successful conversion looks like the as/400 to mainframe file transfers is there a support pac out there that could be used as an example to accomplish the simple movement of data from point a to point b (no response required with this message transfer) Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] Everyone has a photographic memory Its just that some do not have film -- 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: as/400 xcom
For a tool of little brain you could look at our free XSP solution: http://www.primeur.com/products/xsp/xsp.html If you need more intelligence in the tool you're looking for, we do other (more sophisticated) products which of course aren't free that add all sorts of capabilities such as acknowledgements, mailboxing, etc. etc. Dave
Re: UNSUBSCRIBE
Once again Here's what you need to do: You may leave the list at any time by sending a "SIGNOFF MQSERIES" command (no quotes and use this as the body of the message) to [EMAIL PROTECTED] Do NOT send this to [EMAIL PROTECTED]; that won't get you off this listserv, it'll only send your wish to do so to everyone on the list. -Original Message- From: Kinlen, Dan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 11:12 AM To: [EMAIL PROTECTED] Subject: UNSUBSCRIBE UNSUBSCRIBE RBC Dain Rauscher does not accept buy, sell or cancel orders by e-mail, or any instructions by e-mail that would require your signature. Information contained in this communication is not considered an official record of your account and does not supersede normal trade confirmations or statements. Any information provided has been prepared from sources believed to be reliable but is not guaranteed, does not represent all available data necessary for making investment decisions and is for informational purposes only. This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you receive this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Information received by or sent from this system is subject to review by supervisory personnel, is retained and may be produced to regulatory authorities or others with a legal right to the information. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MSGID Char conversion
Hello Bobbie, What is 48 byte character format of MsgId? I thought it is always MQBYTE24. For that I would use memcpy(msgDesc.MsgId, newMsgId, MQ_MSG_ID_LENGTH); Pavel Robert Broderick <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OTMAIL.COM> cc: Sent by: MQSeries Subject: MSGID Char conversion List <[EMAIL PROTECTED] .AC.AT> 08/20/2003 06:26 PM Please respond to MQSeries List I have an extracted MSGID in 48 byte character format. I want to place it back in the MQMD_MSGID field. Can anybody supply the code statement??? stuck bobbee _ Get MSN 8 and enjoy automatic e-mail virus protection. http://join.msn.com/?page=features/virus 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: mqver remotely? Maybe MO71?
On Unix or Windows, I would just use ssh :-) Pavel John Scott <[EMAIL PROTECTED]To: [EMAIL PROTECTED] .CO.UK> cc: Sent by: MQSeriesSubject: Re: mqver remotely? Maybe MO71? List <[EMAIL PROTECTED] n.AC.AT> 08/21/2003 10:00 AM Please respond to MQSeries List You can see the command level from the Queue Manager properties in MO71. This will be something like 520, 521, 530 etc. for the version numbers. However, it doesn't tell you which service pack you have installed. Regards John. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: 21 August 2003 12:44 To: [EMAIL PROTECTED] Subject: mqver remotely? Maybe MO71? Is there anyway to get the MQ version of a box without having to actually log onto the box? MQExplorer? QPASA? MO71? It is a pain having to log onto individual boxes just to run the mqver command when you want to see what CSDs have been applied. Paul, would there be anyway for MO71 to do this in a future version? Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified 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 ** 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 confidential, and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you are not the intended addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using your reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail maybe accessed. ** 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: mqver remotely? Maybe MO71?
You can see the command level from the Queue Manager properties in MO71. This will be something like 520, 521, 530 etc. for the version numbers. However, it doesn't tell you which service pack you have installed. Regards John. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: 21 August 2003 12:44 To: [EMAIL PROTECTED] Subject: mqver remotely? Maybe MO71? Is there anyway to get the MQ version of a box without having to actually log onto the box? MQExplorer? QPASA? MO71? It is a pain having to log onto individual boxes just to run the mqver command when you want to see what CSDs have been applied. Paul, would there be anyway for MO71 to do this in a future version? Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified 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 ** 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 confidential, and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you are not the intended addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using your reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail maybe accessed. ** 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
as/400 xcom
I did a presentation yesterday to about 50 people in the company had IBM explain MQ in the first 30 minutes, and then explained whet we did to stabilize the order system that is our only MQ application now the woodwork is closing in the best candidate for a second successful conversion looks like the as/400 to mainframe file transfers is there a support pac out there that could be used as an example to accomplish the simple movement of data from point a to point b (no response required with this message transfer) Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] Everyone has a photographic memory Its just that some do not have film --
mqver remotely? Maybe MO71?
Is there anyway to get the MQ version of a box without having to actually log onto the box? MQExplorer? QPASA? MO71? It is a pain having to log onto individual boxes just to run the mqver command when you want to see what CSDs have been applied. Paul, would there be anyway for MO71 to do this in a future version? Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified 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: Certified candidates but < 2 years exp - comments
And the noose gets bigger! From: JoE JK <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Certified candidates but < 2 years exp - comments Date: Wed, 20 Aug 2003 17:22:31 -0700 dont worry, i'm not from US. :) --- Robert Broderick <[EMAIL PROTECTED]> wrote: > AH. More US tax dollars and a job down the > drain. I'm sure there was no > one qualified in the US to fit the position!!! (Soon > that actually may be a > true statement). > > Some "KID" found out what I did for a living and > asked me the other day at a > Staten Island Yankees ball game if he should go to > college to take up > computers. He said he really liked them. I told him > it's becoming a dead > field and should steer clear of it if he wanted to > financially get anywhere > in the future. > > > > > > > >From: JoE JK <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: Certified candidates but < 2 years exp > - comments > >Date: Wed, 20 Aug 2003 09:03:32 -0700 > > > >Hi, > >Actually we already have ppl from a well known > vendor > >+ experienced to help with the project. Another > >candidate is required to help our team with other > >concurrent project. We got a lot of response from > >those offshore software co with resumes as I > mentioned > >earlier. It just happened some of the candidates > had > >the certification with less exp and some w/o cert > but > > > 2 years exp. > >After talked to them, those with exps are more > >convincing and knows what we're talking about(our > >requirements). I probably would go for this guy. > > > >Many thanks for valuable input. > > > >Joe, > > > > > >--- Roger Lacroix <[EMAIL PROTECTED]> > >wrote: > > > Hi, > > > > > > Joe's original question was about interviewing > > > people with less than 2 years of > > > experience but who have the WMQ Specialist > > > certificate. > > > Quote: "With those certification, are they > really > > > can perform?" > > > > > > I read his question as, "he is looking for > someone > > > capable", i.e. intermediate > > > level not junior or trainee. > > > > > > Hence when talking technical details with a > > > intermediate (or senior) level > > > person, an hour will fly right by. > > > > > > Regards, > > > Roger Lacroix > > > Capitalware Inc. > > > > > > > > > Quoting Benjamin Zhou <[EMAIL PROTECTED]>: > > > > > > > Well,..., Roger, don't be too harsh to the > junior > > > MQers. Everyone deserve a > > > > chance to do his /her best to excel. We were > all > > > junior MQers not many years > > > > ago. > > > > > > > > >>I prefer to have the candidate go through an > > > in-depth technical interview > > > > of at > > > > >>least 1 hour on the on the subject matter. > > > > > > > > Are you serious? this should be for someone > with > > > your lengths of experience. > > > > The most important is that the candidate have > true > > > understanding of the > > > > fundamental ideas and structure of the > middleware, > > > and possesses the > > > > enthusiasm to learn, to try, and enjoy it. The > > > technical details we now know > > > > can quickly become obsolate. Remember, the > > > knowledge we possess today can > > > > turn into obstacle for progress tomorrow if we > > > love it too much. > > > > > > > > cheers, > > > > Benjamin Zhou > > > > State Street Corp. > > > > > > > > > > > > > > > > -Original Message- > > > > From: Roger Lacroix > > > [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, August 20, 2003 10:18 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: Certified candidates but < 2 > years > > > exp - comments > > > > > > > > > > > > Hi, > > > > > > > > Certification is a great thing but should be > taken > > > with a grain of salt. (I > > > > have ever noticed the number of people who > have > > > requested the certification > > > > questions on the ListServer or > www.mqseries.net ?) > > > > > > > > I personally assign a value of 2-3 months of > > > equivalent work experience for > > > > a > > > > certificate (MQSeries, Java, or whatever). > i.e. > > > If someone says they have > > > > been > > > > doing MQAdmin work for 6 months and they have > the > > > WMQ Specialist certificate > > > > then I go with a total 9 months work > experience. > > > This may be harsh but I > > > > have > > > > met people with the WMQ Specialists > certificate > > > but cannot resolve a channel > > > > sequence number error. > > > > > > > > I prefer to have the candidate go through an > > > in-depth technical interview of > > > > at > > > > least 1 hour on the on the subject matter. Or > > > have the candidate do a > > > > technical exam from ReviewNet or someone else > but > > > it has to be controlled so > > > > that their buddy doesn t write the exam for > them. > > > > > > > > > > > Note: I do have all 3 WMQ certifications, so I > am > > > not disputing their value > > > > but > > > > you should remember it is only a piece of > paper. > > > It represents a
Migrating from WMQI 2.1 to WBI Message Broker 5.0
Hi, We're looking to upgrade our message broker from WMQI 2.1 CSD4 to WBI Message Broker 5.0. Has anyone actually done this? Any gotchas that we need to be aware of? Thanks in advance, Kulbir.
Managing a large MQSeries and WMQI infrastructure
Hi, We're looking into ways of managing our large Middleware infrastructure which will eventually consist of over 300 applications with MQSeries installed and configured to communicate with up to 10 WMQI message brokers. For the ongoing deployment and support we see that we really need a configuration tool that we can use to generate and hold our MQSeries and DB2 configurations for the entire infrastructure. Previously we had a bespoke configuration database tool that we used to generate our MQSeries and legacy broker (CAI TDM) configuration files and that worked a treat. We're looking for something similar except that our new environment will be a lot more complex as we're merging three messaging infrastructures into one, therefore we have numerous naming conventions that we still want to apply but using a single tool. Our merging activities have an objective which states that we cannot rename any MQSeries objects on the end-points. Are there any tools out there that might be able to assist us with this? Has anyone else been in a similar situation and what have you done about it? Any assistance would be much appreciated. Thanks, Kulbir.
Unsubscribe
Thanks and RegardsSourav DebnathSpecialistE Business Integration ServicesWeb Development Company Ltdwww.dvlp.comPh:// 91.33.357 5521 /25 /26 /27Fax 91.33.357 5524www.dvlp.com"{-®ç-ì~æjv x2¢êæj)b b²Û.nÇ+b¢v«zè¾'^v)í
ââ²Û ®ñêÚK ®Á®×½¨¥i¹^jØm¶ÿà %²írÈb½èm¶ÿ¾f¤§·óIêâzÆ«r¯
Re: Cannot Uninstall MQ 5.2.1 from Windows2000
Hi Peter, In the windows registry there is an entry which point to the place where mqseries.msi is located, or should be located. This entry is HKEY_CLASSES_ROOT\Installer\Products. In this folder you will find different entries which correspond to products installed with Microsoft Installer. One of these entries correspond to MQSeries, the productName in the folder should be MQSeries. If you expand that tree you will find a new folder called SourceList. In this folder there is an entry called LastUsedSource. Try to modify it to your directory where the mqseries.msi is. I hope this help you. > -Mensaje original- > De: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] > Enviado el: Wednesday, August 20, 2003 23:24 > Para: [EMAIL PROTECTED] > Asunto: Cannot Uninstall MQ 5.2.1 from Windows2000 > > I am trying to upgrade to 5.3 on a Windows 2000 server, and cannot because > I > cannot get rid of the old version. > > If I go to Control Panel...Add/Remove Programs and select MQSeries, the > uninstall procedure begins, but then an error box gets thrown up saying it > cannot find the MQSeries.msi file. > > So I instead went straight to the 5.3 Install procedure, which threw me > into > Upgrade mode. I clicked install, and it started to work, but again, the > error came up saying it could not find MQSeries.msi, and the installation > ended on me. > > I cannot find MQSeries.msi anywhere on this server. > > I tried to uninstall MA88 from Add/ Remove programs, and got the error > saying it could not find the " IBM MQSeries classes for Java and Java > Message Service.msi" file. And then the uninstall ended on me. I cannot > find > this .msi file anywhere either. > > I copied over the entire MA88 Install directory to a temp folder on this > machine, found the IBM MQSeries classes for Java and Java Message > Service.msi file, and then tried the MA88 uninstall again. This time when > the error came up saying it could not find the file, I manually pointed it > to the temp folder, and it worked. MA88 is uninstalled on this server. > > > So I tried the same trick for base MQ. I copied over the entire Install CD > for 5.2.1, and located the MQSeries.msi file. I tried uninstalling from > Add/ > Remove programs again, and then manually pointed the uninstall procedure > to > the temp folder. No luck. The uninstall ends with a Fatal Error. I tried > upgrading to 5.3. Fatal error encountered during the upgrade, presumably > where 5.2.1 is trying to be uninstalled. > > I cannot get rid of 5.2.1 on this server! I tried removing CSD05, and that > worked, but still the same problem with base 5.2.1. Thankfully, I can get > MQ > 5.2.1 running again, so the customer is OK, but I can't upgrade this guy. > > > > We suspect this is related to an automated failed SP3 install for WIN2000 > earlier in the week. It screwed up the ability to open MQExplorer or > MQServices from the start menu. We thought that is all it did. Looks like > it > botched up some other stuff. Below is a quote from the Sys Admin for the > server explaining THAT problem. Maybe it is related??? > > Quote> > I'd like to update you to the issues that have risen on the concentrators > since we began rolling out the MS security patch and W2K service pack 3. > As > you are aware we rolled both SP3 and MS03-026 to the CMS DEV and CTST > concentrators on 8/5 and 8/7 respectively without any issues, the same was > true for MQIDEV01 and MQIDEV02. We use a tool called Update Expert to do > the scheduling of this type of maintenance, it was used for the initial > machines as well as machines patched since Monday night. > > Now to the issues. Since Monday night the W2K service pack installs have > failed through Update Expert while the patch on the other hand hasn't, > this > has lead to some shortcuts which are fired off upon logon to become > corrupted. An indication of this problem would be a pop up message > indicating that the path to install the product can't be found. The > product(s) are in fact running, MQ Series and NAV are not affected . > > >End Quote > > > Peter Potkay > MQSeries Specialist > The Hartford Financial Services > [EMAIL PROTECTED] > x77906 > IBM MQSeries Certified > > > > > 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:/
