Janet Kubsh/Schneider is out of the office.
I will be out of the office starting 06/06/2003 and will not return until 06/16/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
MQ V5.1 CSD06 for Solaris
Peter: Thank you, thank you, thank you. You are a life saver. - Message from Peter Uranyi <[EMAIL PROTECTED]> on Sat, 31 May 2003 18:57:49 -0700 - Subject: Re: MQ V5.1 CSD06 for Solaris You can download it from here: ftp://ftp.software.ibm.com/software/mqseries/fixes/solaris51/U471246/ Peter I am in desperate need for CSD06 for V5.1 running on Solaris. Does anyone have a copy of this CSD that they could send to me? Thank You, John Haraburda Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
Didn't see your response before I sent mine. An MCA issues an I/O request to the OS. I do not believe that THAT MCA is brave enough to do other work asynchronously while the I/O is pending. All work with respect to that MCA stops, the CPU is thus freed to serve other MCA's that may not require disk. > -Original Message- > From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] > Sent: Friday, June 06, 2003 7:08 AM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi > stent messages > > An application is sending NP messages, priority 9. Another app sends P > messages, priority 1. Odds are both apps are sending messages somewhat > regularly. When things are fine, the NP messages jump to the head of the > line and zoom across. But sooner or later, those persistent messages are > going get their turn in line and be shipped. And if the other side is having > disk problems, what happens then? Are NP messages produced after this point > stuck waiting, because the MCA is busy with the persistent message, waiting > for a response? Or are you saying that they will pass the stuck persistent > message? > > Same question when everything is OK. If a 100MEG lunker is taking its time > to be shipped, are you saying that a higher priority message will somehow > jump over the big one? > > I gotta think that if the MCA is busy (either moving a big message or stuck > waiting for I/O), Priority will not help. > > -Original Message- > From: Stephan C. Moen [mailto:[EMAIL PROTECTED] > Sent: Friday, June 06, 2003 9:23 AM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / > non-persi stent messages > > > For those mixing non-persistent messages with persistent messages, if you > want to avoid this, simply raise the priority one level higher than your > persistent messages. The higher priority messages will be transmitted PRIOR > to the lower priority messages. This also eliminates response time problems > with VERY LARGE messages or a batch run of many messages, causing response > time delays to INTERACTIVE application that require more real-time > responses, and minimizes the disk I/O issues that this thread has been > talking about. This ASSUMES that queues are defined as PRIORITY versus > FIFO. > > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, > Dennis > Sent: Friday, May 30, 2003 5:41 PM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi > stent messages > > Here's my mindset. Assuming non-persistent messages do not require disk I/O, > then they should continue to flow even when your disk I/O sub-system is > temporarily unavailable. Since you experiencing something else, there must > be conditions under which NP messages are dependent on the disk. I was both > attempting to identify some of likely causes and, > somewhat-confusingly-in-the-same-breath, suggest that if the logs are on the > unavailable disk, you might be heading upstream with a broom stick for a > paddle. > > I stand by my first point, even if there are as few as two messages in a > batch. If one is persistent, then non-persistent msgs in the same batch > will be blocked until the logs are available. Similarly, the qmgr may at > times suspend all activity until it can access the logs. The lesson is to > put logs on high-performance, high-availability media--redundant, > hot-swapable raid or the like. Putting logs on media that is routinely > taken out of service is paramount to drilling holes in your broomstick. > > I am not necessarily an advocate for separate channels, but I do think it > could improve the odds that non-persistent messages will flow when the SAN > is unavailable. Generally, while one qmgr process waits for I/O, the others> > may be dispatched to make good use of the available time, including their > own disk I/O and, hopefully, network I/O for non-persistent messages that do > not require disk. Tasks waiting on I/O do not consume--they are overlapped > with those needing CPU, lest a staggering percentage of the CPU resource > would go to waste. The notion of being a CPU being "busy waiting" is > silly--faster machines don't wait at twice the speed! > > > Point #1. If a server is dealing with persistent and non persistent > messages, the persistent ones have to negatively effect the non > persistent > ones, at a hardware level (disk and CPU). It does not matter whether > you > have separate QMs on that server split between persistent and non > persistent. Both QMs share the CPU and disk. It does not matter > whether you > have separate channels or not. All MCAs share the same CPU and disk. > > Only true if there is contention for one of the resources: CPU, memory, or > I/O. If you can dedicate a task (either by separate Qmgrs or separate >
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
I agree with most of that, but as far as the original issues is concerned it only works up to a point. As soon as the channel hangs waiting for i/o on any persistent message, then it is blocked from moving NP messages that may appear the next instant. So unless the channel is so busy processing NP messages that it never has time for the persistent ones... > -Original Message- > From: Stephan C. Moen [SMTP:[EMAIL PROTECTED] > Sent: Friday, June 06, 2003 6:23 AM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi > stent messages > > For those mixing non-persistent messages with persistent messages, if you > want to avoid this, simply raise the priority one level higher than your > persistent messages. The higher priority messages will be transmitted PRIOR > to the lower priority messages. This also eliminates response time problems > with VERY LARGE messages or a batch run of many messages, causing response > time delays to INTERACTIVE application that require more real-time > responses, and minimizes the disk I/O issues that this thread has been > talking about. This ASSUMES that queues are defined as PRIORITY versus > FIFO. > > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, > Dennis > Sent: Friday, May 30, 2003 5:41 PM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi > stent messages > > Here's my mindset. Assuming non-persistent messages do not require disk I/O, > then they should continue to flow even when your disk I/O sub-system is > temporarily unavailable. Since you experiencing something else, there must > be conditions under which NP messages are dependent on the disk. I was both > attempting to identify some of likely causes and, > somewhat-confusingly-in-the-same-breath, suggest that if the logs are on the > unavailable disk, you might be heading upstream with a broom stick for a > paddle. > > I stand by my first point, even if there are as few as two messages in a > batch. If one is persistent, then non-persistent msgs in the same batch > will be blocked until the logs are available. Similarly, the qmgr may at > times suspend all activity until it can access the logs. The lesson is to > put logs on high-performance, high-availability media--redundant, > hot-swapable raid or the like. Putting logs on media that is routinely > taken out of service is paramount to drilling holes in your broomstick. > > I am not necessarily an advocate for separate channels, but I do think it > could improve the odds that non-persistent messages will flow when the SAN > is unavailable. Generally, while one qmgr process waits for I/O, the others > may be dispatched to make good use of the available time, including their > own disk I/O and, hopefully, network I/O for non-persistent messages that do > not require disk. Tasks waiting on I/O do not consume--they are overlapped > with those needing CPU, lest a staggering percentage of the CPU resource > would go to waste. The notion of being a CPU being "busy waiting" is > silly--faster machines don't wait at twice the speed! > > > Point #1. If a server is dealing with persistent and non persistent > messages, the persistent ones have to negatively effect the non > persistent > ones, at a hardware level (disk and CPU). It does not matter whether > you > have separate QMs on that server split between persistent and non > persistent. Both QMs share the CPU and disk. It does not matter > whether you > have separate channels or not. All MCAs share the same CPU and disk. > > Only true if there is contention for one of the resources: CPU, memory, or > I/O. If you can dedicate a task (either by separate Qmgrs or separate > channels) to non-persistent messages that are not dependent on disk I/O,> > then you do not have competion for that resource and there would not be an > adverse affect with respect to it. > > > Point #2. If the disk is temporarily unavailable, then persistent > messages > are effected, and due to point #1, non persistent ones are effected as well. > > I agree (in a contrary way): > > If tasks handling non-persistent messages are dependent on disk, then they > may be adversely affected by the unavailable disk. > > If tasks handling non-persistent messages are not dependent on disk, then > they may be favorably affected by the unavailable disk! This occurs because > other tasks waiting on disk are not competing for CPU. > > > > -Original Message- > > From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] > > Sent: Friday, May 30, 2003 1:01 PM > > To: [EMAIL PROTECTED] > > Subject: Re: How a MQSeries Hub does its thing with persistent / > non-persi stent messages > > > > Hi Dennis. > > > > I agree that non-persistent and persistent messages in a batch will be > >
Re: MQSeries in DMZ
Rob, Correct me if I am wrong but my understanding is that the firewall will only allow a specific IP address and port request outside (from the specific client) and then translate the address to connect to the MQ in DMZ. So the request is already filtered from the firewall and the LOCLADDR is not much use in this case (as it always coded to the 'translated' firewall address) unless you are protecting connections from other machines in the DMZ. Cheers, Ian -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Friday, 6 June 2003 4:00 AM To: [EMAIL PROTECTED] Subject: Re: MQSeries in DMZ Tim, Make sure you use MQ 5.3 in the DMZ. One of the new features is a channel attribute that binds the channel to a particular local IP address. Your DMZ will have two addresses we are concerned with - the IP address your trusted network sees, and the IP address the world sees. You will also have two categories of channel: customer-facing channels and internal-facing channels. By specifying the LOCLADDR, you can insure that your internal-facing channels are not hijacked by external users. For example, assume your DMZ server has a RCVR or RQSTR channel called APPSVR.DMZ with no exit. One of your customers could create a SDR or SVR channel called APPSVR.DMZ and try to start it. Without a LOCLADDR specified, the channel would bind to the external-facing IP and the firewall would allow the connection. On the other hand, if you set the LOCLADDR attribute to your internal-facing IP address, the external firewall will disallow the connection. There are a LOT of other considerations. For example, if the data is sensitive and encrypted, you don't want to store the keys on the DMZ. It would be better to have the messages signed/encrypted at either end and have them pass the DMZ unaltered. Also, IP filtering as provided at the firewall is strong but not 100% reliable. It is possible to spoof an IP address and it is possible that an intrusion attempt could come from a trusted business partner. If your listeners are running as mqm, they can potentially be hijacked. Better to run your listeners as low-privileged IDs. Use different listeners and ports for internal-facing and external-facing connections. In fact, use different listeners for each customer if you want to be really safe. Finally, consider the implications of multiple clients using the same QMgr. If one client can put messages onto another client's remote queue, your company may be partially liable for any damages that are caused. You can enforce isolation of each client's traffic if each client has its own listener, running under its own ID, listening on its own port; and each client has its own channel pair, its own UserID in the MCAUSER, and its own remote queues authorized to that UserID. This is just a quick review. If you really want to harden your DMZ (and I hope you do by now!) There are many additional options available in MQ configuration, exits, architecture, etc. It all depends on how valuable and sensitive the messages are and how far you want to go to protect them. -- T.Rob -Original Message- From: Madsen, Timothy [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: MQSeries in DMZ Hello, We have external partners who need to connect to our MQSeries. So, we could put an MQSeries server in our DMZ and let those external people connect to that MQ and then have the DMZ MQ connect to our internal MQ. We can configure our firewall (Cisco Pix) to only let MQ appropriate ports/protocols pass from the internet to the DMZ MQ server. However, we would still be allowing **anybody** on the internet to send messages to our MQSeries in our DMZ. We are working with a small list of partners - they are not anonymous. So - from this two questions: 1) Would this be considered a fairly secure configuration - from the standpoint of a hacker trying to get into our MQ box and crash it or access OS services? 2) What is a standard method whereby we could allow our external partners to send MQ messages - but not allow other people on the internet to send MQ messages to our DMZ MQ server? Thanks. Tim. Instructions for managing your mailing list 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
Bhapinder is out of the office.
I will be out of the office starting 05-Jun-2003 and will not return until 09-Jun-2003. I will respond to your message on my return. If you have an urgent enquiry, please call 07951 034441 Regards, Bhapinder Instructions for managing your mailing list 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: Invoking a CICS Program using JMS
Check out the book Designing and Programming CICS Applications: http://www.amazon.com/exec/obidos/tg/detail/-/B7FYDN/qid=1054832518/sr=1-1/ref=sr_1_1/103-4032391-8436628?v=glance&s=books The examples utilize MA88, but the overall concepts are the same. >>> [EMAIL PROTECTED] 06/05/03 08:56AM >>> Hi, >From the MQ documentation I can see that is possible to invoke a CICS program using MQSeries and the MQ CICS Bridge. I would like to know if it is possible to know if this is possible using MQ via JMS? Is anyone using it in production? Can you point me some documentation about this topic? Many thanks Paulo -- The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Instructions for managing your mailing list 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
Upgrading to 5.3 question- IGNORE
Please ignore my previous question with the subject line "Upgrading to 5.3 question"... I know the answer to my question... Thanks, Ruzi Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: How a MQSeries Hub does its thing with persistent / non-persistent messages
A sound case here for two different channels and TQs both connecting the two QMs. One for NP messages with NPMSPEED(FAST), and the other for persistent. Needs a bit of management of QR definitions, and make sure that different dest QR are use for NP versus P messages but that's an MQ administrator's daily life ... Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Potkay, Peter M (PLC, IT) Sent: 06 June 2003 15:08 To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages An application is sending NP messages, priority 9. Another app sends P messages, priority 1. Odds are both apps are sending messages somewhat regularly. When things are fine, the NP messages jump to the head of the line and zoom across. But sooner or later, those persistent messages are going get their turn in line and be shipped. And if the other side is having disk problems, what happens then? Are NP messages produced after this point stuck waiting, because the MCA is busy with the persistent message, waiting for a response? Or are you saying that they will pass the stuck persistent message? Same question when everything is OK. If a 100MEG lunker is taking its time to be shipped, are you saying that a higher priority message will somehow jump over the big one? I gotta think that if the MCA is busy (either moving a big message or stuck waiting for I/O), Priority will not help. -Original Message- From: Stephan C. Moen [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 9:23 AM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages For those mixing non-persistent messages with persistent messages, if you want to avoid this, simply raise the priority one level higher than your persistent messages. The higher priority messages will be transmitted PRIOR to the lower priority messages. This also eliminates response time problems with VERY LARGE messages or a batch run of many messages, causing response time delays to INTERACTIVE application that require more real-time responses, and minimizes the disk I/O issues that this thread has been talking about. This ASSUMES that queues are defined as PRIORITY versus FIFO. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, Dennis Sent: Friday, May 30, 2003 5:41 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Here's my mindset. Assuming non-persistent messages do not require disk I/O, then they should continue to flow even when your disk I/O sub-system is temporarily unavailable. Since you experiencing something else, there must be conditions under which NP messages are dependent on the disk. I was both attempting to identify some of likely causes and, somewhat-confusingly-in-the-same-breath, suggest that if the logs are on the unavailable disk, you might be heading upstream with a broom stick for a paddle. I stand by my first point, even if there are as few as two messages in a batch. If one is persistent, then non-persistent msgs in the same batch will be blocked until the logs are available. Similarly, the qmgr may at times suspend all activity until it can access the logs. The lesson is to put logs on high-performance, high-availability media--redundant, hot-swapable raid or the like. Putting logs on media that is routinely taken out of service is paramount to drilling holes in your broomstick. I am not necessarily an advocate for separate channels, but I do think it could improve the odds that non-persistent messages will flow when the SAN is unavailable. Generally, while one qmgr process waits for I/O, the others may be dispatched to make good use of the available time, including their own disk I/O and, hopefully, network I/O for non-persistent messages that do not require disk. Tasks waiting on I/O do not consume--they are overlapped with those needing CPU, lest a staggering percentage of the CPU resource would go to waste. The notion of being a CPU being "busy waiting" is silly--faster machines don't wait at twice the speed! Point #1. If a server is dealing with persistent and non persistent messages, the persistent ones have to negatively effect the non persistent ones, at a hardware level (disk and CPU). It does not matter whether you have separate QMs on that server split between persistent and non persistent. Both QMs share the CPU and disk. It does not matter whether you have separate channels or not. All MCAs share the same CPU and disk. Only true if there is contention for one of the resources: CPU, memory, or I/O. If you can dedicate a task (either by separate Qmgrs or separate channels) to non-persistent messages that are not dependent on disk I/O, then you do not have competion for that resource and there would not be an adverse affect with respect to it.
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
An application is sending NP messages, priority 9. Another app sends P messages, priority 1. Odds are both apps are sending messages somewhat regularly. When things are fine, the NP messages jump to the head of the line and zoom across. But sooner or later, those persistent messages are going get their turn in line and be shipped. And if the other side is having disk problems, what happens then? Are NP messages produced after this point stuck waiting, because the MCA is busy with the persistent message, waiting for a response? Or are you saying that they will pass the stuck persistent message? Same question when everything is OK. If a 100MEG lunker is taking its time to be shipped, are you saying that a higher priority message will somehow jump over the big one? I gotta think that if the MCA is busy (either moving a big message or stuck waiting for I/O), Priority will not help. -Original Message- From: Stephan C. Moen [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 9:23 AM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages For those mixing non-persistent messages with persistent messages, if you want to avoid this, simply raise the priority one level higher than your persistent messages. The higher priority messages will be transmitted PRIOR to the lower priority messages. This also eliminates response time problems with VERY LARGE messages or a batch run of many messages, causing response time delays to INTERACTIVE application that require more real-time responses, and minimizes the disk I/O issues that this thread has been talking about. This ASSUMES that queues are defined as PRIORITY versus FIFO. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, Dennis Sent: Friday, May 30, 2003 5:41 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Here's my mindset. Assuming non-persistent messages do not require disk I/O, then they should continue to flow even when your disk I/O sub-system is temporarily unavailable. Since you experiencing something else, there must be conditions under which NP messages are dependent on the disk. I was both attempting to identify some of likely causes and, somewhat-confusingly-in-the-same-breath, suggest that if the logs are on the unavailable disk, you might be heading upstream with a broom stick for a paddle. I stand by my first point, even if there are as few as two messages in a batch. If one is persistent, then non-persistent msgs in the same batch will be blocked until the logs are available. Similarly, the qmgr may at times suspend all activity until it can access the logs. The lesson is to put logs on high-performance, high-availability media--redundant, hot-swapable raid or the like. Putting logs on media that is routinely taken out of service is paramount to drilling holes in your broomstick. I am not necessarily an advocate for separate channels, but I do think it could improve the odds that non-persistent messages will flow when the SAN is unavailable. Generally, while one qmgr process waits for I/O, the others may be dispatched to make good use of the available time, including their own disk I/O and, hopefully, network I/O for non-persistent messages that do not require disk. Tasks waiting on I/O do not consume--they are overlapped with those needing CPU, lest a staggering percentage of the CPU resource would go to waste. The notion of being a CPU being "busy waiting" is silly--faster machines don't wait at twice the speed! Point #1. If a server is dealing with persistent and non persistent messages, the persistent ones have to negatively effect the non persistent ones, at a hardware level (disk and CPU). It does not matter whether you have separate QMs on that server split between persistent and non persistent. Both QMs share the CPU and disk. It does not matter whether you have separate channels or not. All MCAs share the same CPU and disk. Only true if there is contention for one of the resources: CPU, memory, or I/O. If you can dedicate a task (either by separate Qmgrs or separate channels) to non-persistent messages that are not dependent on disk I/O, then you do not have competion for that resource and there would not be an adverse affect with respect to it. Point #2. If the disk is temporarily unavailable, then persistent messages are effected, and due to point #1, non persistent ones are effected as well. I agree (in a contrary way): If tasks handling non-persistent messages are dependent on disk, then they may be adversely affected by the unavailable disk. If tasks handling non-persistent messages are not dependent on disk, then they may be favorably affected by the unavailable disk! This occurs because other tasks waiting on disk are not competing for CPU. > -Original Message- > From: Potkay,
Re: MQMD.PutApplName (was Re: MQMD)
There goes Brian thinking outside the box again! -Original Message- From: Brian T. Shelden [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 4:37 PM To: [EMAIL PROTECTED] Subject: Re: MQMD.PutApplName (was Re: MQMD) > does anyone know how I can set the Application name in the > MQMD header. I have tried setting it using md.PutApplName = > "MyName" but the MQ Client always takes the name of the of > where the location of the application is and overwrites my > value. Is there a flag I need to set as well?? mv prog MyName ? move prog.exe MyName.exe? :-) (Or use SET_ALL_CONTEXT options, and appropriate permissions, as others suggested.) -- --Brian T. Shelden [EMAIL PROTECTED] Shelden & Associates, Inc. New York, NY 10280 Certified MQSeries Specialists (212) 786-0175 Instructions for managing your mailing list 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: MQSeries in DMZ
David, To expand a little further, the ideal situation is that encryption/signing of messages occurs at the endpoints whereas connections need to be authenticated point-to-point. So you are right that some kind of app-to-app encryption is best here. SSL only authenticates or encrypts from point-to-point and only on the wire. The messages are in plaintext on the queue making them vulnerable as they hop through the DMZ. However, firewall IP filtering does not qualify as authentication. SSL between the DMZ and the client site hardens that communication path so I still believe SSL is appropriate here. Of course, I work for a bank and take a pretty conservative approach to external connections. As far as storing keys in the DMZ, my objection is that no processing or manipulation of the messages should occur in the DMZ. They should just pass through. Keys for point-to-point authentication (SSL for example) are necessary, of course. But as far as manipulating the messages, the whole point of the DMZ is that you don't trust it, right? If you did, you wouldn't need a DMZ, you'd just put your app server right next to the external firewall and forget about it. So if we don't trust the DMZ, the last thing we want to do is store the keys to the castle in it. But as I said, my employer requires me to take a rather conservative view of these things. Your mileage may vary. -- T.Rob -Original Message- From: David C. Partridge [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 5:39 AM To: [EMAIL PROTECTED] Subject: Re: MQSeries in DMZ Nice summary. SSL is (probably) not appropriate here for encryption purposes, and an application to application encryption product such as Primeur DSMQ E2E (preferred by me anyway, but then I'm biased, as I designed it), Candle MQSecure, or Tivoli AMBI is more appropriate. Alternatives to SSL could also be considered such as channel exit based solutions (strange we do that too!). As far as the issue of storing keys on the DMZ machine is concerned, I wouldn't be worried if the keys were stored in an HSM. Cheers Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Wyatt, T. Rob Sent: 05 June 2003 19:00 To: [EMAIL PROTECTED] Subject: Re: MQSeries in DMZ Tim, Make sure you use MQ 5.3 in the DMZ. One of the new features is a channel attribute that binds the channel to a particular local IP address. Your DMZ will have two addresses we are concerned with - the IP address your trusted network sees, and the IP address the world sees. You will also have two categories of channel: customer-facing channels and internal-facing channels. By specifying the LOCLADDR, you can insure that your internal-facing channels are not hijacked by external users. For example, assume your DMZ server has a RCVR or RQSTR channel called APPSVR.DMZ with no exit. One of your customers could create a SDR or SVR channel called APPSVR.DMZ and try to start it. Without a LOCLADDR specified, the channel would bind to the external-facing IP and the firewall would allow the connection. On the other hand, if you set the LOCLADDR attribute to your internal-facing IP address, the external firewall will disallow the connection. There are a LOT of other considerations. For example, if the data is sensitive and encrypted, you don't want to store the keys on the DMZ. It would be better to have the messages signed/encrypted at either end and have them pass the DMZ unaltered. Also, IP filtering as provided at the firewall is strong but not 100% reliable. It is possible to spoof an IP address and it is possible that an intrusion attempt could come from a trusted business partner. If your listeners are running as mqm, they can potentially be hijacked. Better to run your listeners as low-privileged IDs. Use different listeners and ports for internal-facing and external-facing connections. In fact, use different listeners for each customer if you want to be really safe. Finally, consider the implications of multiple clients using the same QMgr. If one client can put messages onto another client's remote queue, your company may be partially liable for any damages that are caused. You can enforce isolation of each client's traffic if each client has its own listener, running under its own ID, listening on its own port; and each client has its own channel pair, its own UserID in the MCAUSER, and its own remote queues authorized to that UserID. This is just a quick review. If you really want to harden your DMZ (and I hope you do by now!) There are many additional options available in MQ configuration, exits, architecture, etc. It all depends on how valuable and sensitive the messages are and how far you want to go to protect them. -- T.Rob -Original Message- From: Madsen, Timothy [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: MQSeries in DMZ Hello, We have external partners who need to connect
Re: MQSeries in DMZ
Ian, My suggestion to use LOCLADDR was not intended to augment firewall filtering at all. Remember, LOCLADDR has nothing to do with the incoming IP address. In a multi-homed environment, LOCLADDR specifies which of the available local IP addresses the channel will bind to. The reason to use LOCLADDR in a DMZ is that, given a choice, your external-facing channel may bind to the internal-facing NIC instead of the external-facing NIC. If this happens the firewall will refuse to let the channel connect to your customer. In MQ 5.2 and earlier, where LOCLADDR was not available, a working interface would suddenly stop working when the MCA decided to pick a different IP address. Now, chances are the MCA will bind to the correct IP address anyway and you'd never really notice. The problem with this is that, in the absence of LOCLADDR, your RCVR/RQSTR channels can be started by internal or external users. So if you have external-facing channels DMZ.TO.CLIENT/CLIENT.TO.DMZ, and internal-facing channels APP.TO.DMZ/DMZ.TO.APP, a client could define a SDR called APP.TO.DMZ and start it. Hopefully, there is an exit in place to authenticate the connection. But even if you have an exit, LOCLADDR is quite effective at binding a channel to a specific interface which eliminates this vulnerability. And, of course, it solves the occasional problem of the MCA choosing the wrong address which is what it was intended for anyway. -- T.Rob -Original Message- From: Chan, Ian M [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 8:06 PM To: [EMAIL PROTECTED] Subject: Re: MQSeries in DMZ Rob, Correct me if I am wrong but my understanding is that the firewall will only allow a specific IP address and port request outside (from the specific client) and then translate the address to connect to the MQ in DMZ. So the request is already filtered from the firewall and the LOCLADDR is not much use in this case (as it always coded to the 'translated' firewall address) unless you are protecting connections from other machines in the DMZ. Cheers, Ian -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Friday, 6 June 2003 4:00 AM To: [EMAIL PROTECTED] Subject: Re: MQSeries in DMZ Tim, Make sure you use MQ 5.3 in the DMZ. One of the new features is a channel attribute that binds the channel to a particular local IP address. Your DMZ will have two addresses we are concerned with - the IP address your trusted network sees, and the IP address the world sees. You will also have two categories of channel: customer-facing channels and internal-facing channels. By specifying the LOCLADDR, you can insure that your internal-facing channels are not hijacked by external users. For example, assume your DMZ server has a RCVR or RQSTR channel called APPSVR.DMZ with no exit. One of your customers could create a SDR or SVR channel called APPSVR.DMZ and try to start it. Without a LOCLADDR specified, the channel would bind to the external-facing IP and the firewall would allow the connection. On the other hand, if you set the LOCLADDR attribute to your internal-facing IP address, the external firewall will disallow the connection. There are a LOT of other considerations. For example, if the data is sensitive and encrypted, you don't want to store the keys on the DMZ. It would be better to have the messages signed/encrypted at either end and have them pass the DMZ unaltered. Also, IP filtering as provided at the firewall is strong but not 100% reliable. It is possible to spoof an IP address and it is possible that an intrusion attempt could come from a trusted business partner. If your listeners are running as mqm, they can potentially be hijacked. Better to run your listeners as low-privileged IDs. Use different listeners and ports for internal-facing and external-facing connections. In fact, use different listeners for each customer if you want to be really safe. Finally, consider the implications of multiple clients using the same QMgr. If one client can put messages onto another client's remote queue, your company may be partially liable for any damages that are caused. You can enforce isolation of each client's traffic if each client has its own listener, running under its own ID, listening on its own port; and each client has its own channel pair, its own UserID in the MCAUSER, and its own remote queues authorized to that UserID. This is just a quick review. If you really want to harden your DMZ (and I hope you do by now!) There are many additional options available in MQ configuration, exits, architecture, etc. It all depends on how valuable and sensitive the messages are and how far you want to go to protect them. -- T.Rob -Original Message- From: Madsen, Timothy [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: MQSeries in DMZ Hello, We have external partners who need to connect to our MQSeries. So, we could put an M
Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages
For those mixing non-persistent messages with persistent messages, if you want to avoid this, simply raise the priority one level higher than your persistent messages. The higher priority messages will be transmitted PRIOR to the lower priority messages. This also eliminates response time problems with VERY LARGE messages or a batch run of many messages, causing response time delays to INTERACTIVE application that require more real-time responses, and minimizes the disk I/O issues that this thread has been talking about. This ASSUMES that queues are defined as PRIORITY versus FIFO. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, Dennis Sent: Friday, May 30, 2003 5:41 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Here's my mindset. Assuming non-persistent messages do not require disk I/O, then they should continue to flow even when your disk I/O sub-system is temporarily unavailable. Since you experiencing something else, there must be conditions under which NP messages are dependent on the disk. I was both attempting to identify some of likely causes and, somewhat-confusingly-in-the-same-breath, suggest that if the logs are on the unavailable disk, you might be heading upstream with a broom stick for a paddle. I stand by my first point, even if there are as few as two messages in a batch. If one is persistent, then non-persistent msgs in the same batch will be blocked until the logs are available. Similarly, the qmgr may at times suspend all activity until it can access the logs. The lesson is to put logs on high-performance, high-availability media--redundant, hot-swapable raid or the like. Putting logs on media that is routinely taken out of service is paramount to drilling holes in your broomstick. I am not necessarily an advocate for separate channels, but I do think it could improve the odds that non-persistent messages will flow when the SAN is unavailable. Generally, while one qmgr process waits for I/O, the others may be dispatched to make good use of the available time, including their own disk I/O and, hopefully, network I/O for non-persistent messages that do not require disk. Tasks waiting on I/O do not consume--they are overlapped with those needing CPU, lest a staggering percentage of the CPU resource would go to waste. The notion of being a CPU being "busy waiting" is silly--faster machines don't wait at twice the speed! Point #1. If a server is dealing with persistent and non persistent messages, the persistent ones have to negatively effect the non persistent ones, at a hardware level (disk and CPU). It does not matter whether you have separate QMs on that server split between persistent and non persistent. Both QMs share the CPU and disk. It does not matter whether you have separate channels or not. All MCAs share the same CPU and disk. Only true if there is contention for one of the resources: CPU, memory, or I/O. If you can dedicate a task (either by separate Qmgrs or separate channels) to non-persistent messages that are not dependent on disk I/O, then you do not have competion for that resource and there would not be an adverse affect with respect to it. Point #2. If the disk is temporarily unavailable, then persistent messages are effected, and due to point #1, non persistent ones are effected as well. I agree (in a contrary way): If tasks handling non-persistent messages are dependent on disk, then they may be adversely affected by the unavailable disk. If tasks handling non-persistent messages are not dependent on disk, then they may be favorably affected by the unavailable disk! This occurs because other tasks waiting on disk are not competing for CPU. > -Original Message- > From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] > Sent: Friday, May 30, 2003 1:01 PM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages > > Hi Dennis. > > I agree that non-persistent and persistent messages in a batch will be > available at the same time. But my batches are of 1 or 2 messages. Since my > BATCHINT is zero, and the channel can keep the XMIT queue at zero, I doubt I > am incurring any performance hit. 1 or 2 messages are sent across, mybe > message #1 is a nonpersistent that is held back until the batch completes, > but the batch completes almost immediately, since no more message have yet > arrived and the BATCHINT expires. At this point I am still not convinced, in > my scenario, that this setting has an effect for the above reason.> > > It has also been mentioned more than once to make a separate channel for > persistent vs. non-persistent messages. I don't see how that makes a > difference. So I make 2 separate channels from SPOKEQM1 to HUBQM. As far as > the hub and its receiving MCAs are concern
Re: MQMD.PutApplName (was Re: MQMD)
does anyone know how I can set the Application name in the MQMD header. I have tried setting it using md.PutApplName = "MyName" but the MQ Client always takes the name of the of where the location of the application is and overwrites my value. Is there a flag I need to set as well?? mv prog MyName ? move prog.exe MyName.exe? :-) (Or use SET_ALL_CONTEXT options, and appropriate permissions, as others suggested.) -- --Brian T. Shelden [EMAIL PROTECTED] Shelden & Associates, Inc. New York, NY 10280 Certified MQSeries Specialists (212) 786-0175 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: AW: Cluster---AMQ4514
Stefan- Thanks for your help. Yes, I was using MQ Explorer... Ruzi --- "Raabe, Stefan" <[EMAIL PROTECTED]> wrote: > Ruzi, > > this sounds somehow familiar to me. > are you using the mq explorer? i remember of > similiar error messages telling me that > the qmgr is not in the cluster when working with > cluster objects, at least the definition worked > and the qmgr was member of the cluster, it was > just the mq explorer that was telling me silly > messages. > > if you are using the mq explorer, try something > else (e.g. remote runmqsc or mo71 supportpac) to > create the definitions and check if the > errors occur again. > > the mq explorer sometimes seems to be a bit > confused > > regards > > stefan > > > > > > > -Urspr|ngliche Nachricht- > Von: Ruzi R [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 5. Juni 2003 15:07 > An: [EMAIL PROTECTED] > Betreff: Cluster---AMQ4514 > > > I created a cluster with QM1 and QM2 > full-repositories. QM3 is a member of the cluster > (not a full repository). The cluster queue Q1 is > defined on QM2 and QM3. > > Q1: When I want to define Q1 on QM1 I get an error > message AMQ4514 which basically says as the queue > manager is not a member of the cluster, the queue > cannot be defined as cluster. But the queue manager > (QM1) is the full-repository. I have refreshed the > cluster. > > Q2: When defining the cluster queue I expected to > see > the cluster name in the drop-down menu of the > cluster tab --- it was just blank. Is this a > normal > behavior? I manually specified the cluster name for > creating cluster queue Q1 on QM2 and QM3, and it > worked. > > Thanks, > > Ruzi > > Instructions for managing your mailing list > 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: MQSeries in DMZ
Tim, Make sure you use MQ 5.3 in the DMZ. One of the new features is a channel attribute that binds the channel to a particular local IP address. Your DMZ will have two addresses we are concerned with - the IP address your trusted network sees, and the IP address the world sees. You will also have two categories of channel: customer-facing channels and internal-facing channels. By specifying the LOCLADDR, you can insure that your internal-facing channels are not hijacked by external users. For example, assume your DMZ server has a RCVR or RQSTR channel called APPSVR.DMZ with no exit. One of your customers could create a SDR or SVR channel called APPSVR.DMZ and try to start it. Without a LOCLADDR specified, the channel would bind to the external-facing IP and the firewall would allow the connection. On the other hand, if you set the LOCLADDR attribute to your internal-facing IP address, the external firewall will disallow the connection. There are a LOT of other considerations. For example, if the data is sensitive and encrypted, you don't want to store the keys on the DMZ. It would be better to have the messages signed/encrypted at either end and have them pass the DMZ unaltered. Also, IP filtering as provided at the firewall is strong but not 100% reliable. It is possible to spoof an IP address and it is possible that an intrusion attempt could come from a trusted business partner. If your listeners are running as mqm, they can potentially be hijacked. Better to run your listeners as low-privileged IDs. Use different listeners and ports for internal-facing and external-facing connections. In fact, use different listeners for each customer if you want to be really safe. Finally, consider the implications of multiple clients using the same QMgr. If one client can put messages onto another client's remote queue, your company may be partially liable for any damages that are caused. You can enforce isolation of each client's traffic if each client has its own listener, running under its own ID, listening on its own port; and each client has its own channel pair, its own UserID in the MCAUSER, and its own remote queues authorized to that UserID. This is just a quick review. If you really want to harden your DMZ (and I hope you do by now!) There are many additional options available in MQ configuration, exits, architecture, etc. It all depends on how valuable and sensitive the messages are and how far you want to go to protect them. -- T.Rob -Original Message- From: Madsen, Timothy [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: MQSeries in DMZ Hello, We have external partners who need to connect to our MQSeries. So, we could put an MQSeries server in our DMZ and let those external people connect to that MQ and then have the DMZ MQ connect to our internal MQ. We can configure our firewall (Cisco Pix) to only let MQ appropriate ports/protocols pass from the internet to the DMZ MQ server. However, we would still be allowing **anybody** on the internet to send messages to our MQSeries in our DMZ. We are working with a small list of partners - they are not anonymous. So - from this two questions: 1) Would this be considered a fairly secure configuration - from the standpoint of a hacker trying to get into our MQ box and crash it or access OS services? 2) What is a standard method whereby we could allow our external partners to send MQ messages - but not allow other people on the internet to send MQ messages to our DMZ MQ server? Thanks. Tim. Instructions for managing your mailing list 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
AW: How to be cheap and safe: 2 QMs on 1 Server
Hello Peter, there is a support pac MC74. It is designed for MSCS, to move QM files to separate volumes, in order to run them on different machines. In case of fail-over, these QM run on the same machine, but with different volumes for the QMs. This support pac should do it without MSCS too. Regards Hubert Kleinmanns -Ursprüngliche Nachricht- Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 5. Juni 2003 17:08 An: [EMAIL PROTECTED] Betreff: How to be cheap and safe: 2 QMs on 1 Server If I have a WIN2000 server that I want to install 2 Queue managers on (1 for DEV testing and 1 for QA testing), what are the things I can do to make the possibility of one environment effecting the other one as slim as possible? I plan on having the C drive used for O/S stuff, the E drive will be for DEV and the F drive will be for QA. I know I can easily choose what the log paths should be at QM creation time, so I can keep QA and DEV logs separate. But what about all the other files? At install time, you have to choose where to keep all this stuff, so the DEV and QA files would all be on the same drive. Is this an issue? Any way to separate them? Peter 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: MQSeries in DMZ
Nice summary. SSL is (probably) not appropriate here for encryption purposes, and an application to application encryption product such as Primeur DSMQ E2E (preferred by me anyway, but then I'm biased, as I designed it), Candle MQSecure, or Tivoli AMBI is more appropriate. Alternatives to SSL could also be considered such as channel exit based solutions (strange we do that too!). As far as the issue of storing keys on the DMZ machine is concerned, I wouldn't be worried if the keys were stored in an HSM. Cheers Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Wyatt, T. Rob Sent: 05 June 2003 19:00 To: [EMAIL PROTECTED] Subject: Re: MQSeries in DMZ Tim, Make sure you use MQ 5.3 in the DMZ. One of the new features is a channel attribute that binds the channel to a particular local IP address. Your DMZ will have two addresses we are concerned with - the IP address your trusted network sees, and the IP address the world sees. You will also have two categories of channel: customer-facing channels and internal-facing channels. By specifying the LOCLADDR, you can insure that your internal-facing channels are not hijacked by external users. For example, assume your DMZ server has a RCVR or RQSTR channel called APPSVR.DMZ with no exit. One of your customers could create a SDR or SVR channel called APPSVR.DMZ and try to start it. Without a LOCLADDR specified, the channel would bind to the external-facing IP and the firewall would allow the connection. On the other hand, if you set the LOCLADDR attribute to your internal-facing IP address, the external firewall will disallow the connection. There are a LOT of other considerations. For example, if the data is sensitive and encrypted, you don't want to store the keys on the DMZ. It would be better to have the messages signed/encrypted at either end and have them pass the DMZ unaltered. Also, IP filtering as provided at the firewall is strong but not 100% reliable. It is possible to spoof an IP address and it is possible that an intrusion attempt could come from a trusted business partner. If your listeners are running as mqm, they can potentially be hijacked. Better to run your listeners as low-privileged IDs. Use different listeners and ports for internal-facing and external-facing connections. In fact, use different listeners for each customer if you want to be really safe. Finally, consider the implications of multiple clients using the same QMgr. If one client can put messages onto another client's remote queue, your company may be partially liable for any damages that are caused. You can enforce isolation of each client's traffic if each client has its own listener, running under its own ID, listening on its own port; and each client has its own channel pair, its own UserID in the MCAUSER, and its own remote queues authorized to that UserID. This is just a quick review. If you really want to harden your DMZ (and I hope you do by now!) There are many additional options available in MQ configuration, exits, architecture, etc. It all depends on how valuable and sensitive the messages are and how far you want to go to protect them. -- T.Rob -Original Message- From: Madsen, Timothy [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: MQSeries in DMZ Hello, We have external partners who need to connect to our MQSeries. So, we could put an MQSeries server in our DMZ and let those external people connect to that MQ and then have the DMZ MQ connect to our internal MQ. We can configure our firewall (Cisco Pix) to only let MQ appropriate ports/protocols pass from the internet to the DMZ MQ server. However, we would still be allowing **anybody** on the internet to send messages to our MQSeries in our DMZ. We are working with a small list of partners - they are not anonymous. So - from this two questions: 1) Would this be considered a fairly secure configuration - from the standpoint of a hacker trying to get into our MQ box and crash it or access OS services? 2) What is a standard method whereby we could allow our external partners to send MQ messages - but not allow other people on the internet to send MQ messages to our DMZ MQ server? Thanks. Tim. Instructions for managing your mailing list 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: mqsi - esql coding techniques?
Hi, Another idea... After your MQInput node, insert a compute node and promote it's computeExpression property. Before deploy operation, you can update the promoted property, like SET OutputRoot = InputRoot; SET Environment.Variables.v1 = '0001'; SET Environment.Variables.v2 = '0002'; and change your ESQL in IF (txncode = Environment.Variables.v1) or (txncode = Environment.Variables.v2) then set accno = 99; END IF; Isn't a perfect solution, but works and you can change the parameters without ESQL code modifications. Best Regards, = Zudor Sándor vezetõ tanácsadó/senior consultant - T-Logic KFT. Certified Solution Expert/Developer IBM WebSphere MQ & MQ Integrator e-mail: [EMAIL PROTECTED] tel: +36-1-424.06.01 mobil: +36-20-956.97.70 fax: +36-1-227.57.16 url: www.t-logic.hu Mike Krueger <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 2003-06-05 17:08 Please respond to [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject Re: mqsi - esql coding techniques? Take a look at the "MQSI get environment variables plug-in" Support Pack: http://www-3.ibm.com/software/integration/support/supportpacs/individual /ia06.html -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of JoE JK Sent: Thursday, June 05, 2003 5:07 AM To: [EMAIL PROTECTED] Subject: mqsi - esql coding techniques? hi, I have the following code in one of the flow done by our SI team(one of those thousand lines). IF (txncode = '0001') or (txncode = '0002') then set accno = 99; END IF; - Is there anyway that i can improve further the above code? Instead of hardcode the value inside, can I define any variables or parameter outside the esql which is modular or easy for me for future enhancement requirements. Any input & idea are greatly appreciated. Thanks, Joe __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: mqsi - esql coding techniques?
Take a look at the "MQSI get environment variables plug-in" Support Pack: http://www-3.ibm.com/software/integration/support/supportpacs/individual /ia06.html -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of JoE JK Sent: Thursday, June 05, 2003 5:07 AM To: [EMAIL PROTECTED] Subject: mqsi - esql coding techniques? hi, I have the following code in one of the flow done by our SI team(one of those thousand lines). IF (txncode = '0001') or (txncode = '0002') then set accno = 99; END IF; - Is there anyway that i can improve further the above code? Instead of hardcode the value inside, can I define any variables or parameter outside the esql which is modular or easy for me for future enhancement requirements. Any input & idea are greatly appreciated. Thanks, Joe __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
How to be cheap and safe: 2 QMs on 1 Server
If I have a WIN2000 server that I want to install 2 Queue managers on (1 for DEV testing and 1 for QA testing), what are the things I can do to make the possibility of one environment effecting the other one as slim as possible? I plan on having the C drive used for O/S stuff, the E drive will be for DEV and the F drive will be for QA. I know I can easily choose what the log paths should be at QM creation time, so I can keep QA and DEV logs separate. But what about all the other files? At install time, you have to choose where to keep all this stuff, so the DEV and QA files would all be on the same drive. Is this an issue? Any way to separate them? Peter 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: MQseries installation
Maybe someday, but not right now. Spread a little thin these days, but then aren't we all? Brandon has an MQSeries FAQ section over at http://www.mqseries.net. If anyone has Q & A that they'd like to see in a FAQ, I'd suggest they post it there. The signal-to-noise in that part of the forum is a little low to be a true FAQ, but with everyone collaborating it would be a good collection point from which a clean and comprehensive FAQ could be assembled. -- T.Rob -Original Message- From: Jan van Kemenade [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 10:19 AM To: [EMAIL PROTECTED] Subject: Re: MQseries installation > You are sure giving us all a good workout! If we collect all your > questions, we would have a pretty good MQSeries FAQ. ;-) Is that an offer to start one ? Cheers, Jan. -/ /&Jan van Kemenade \&www.cressida.info -\ Instructions for managing your mailing list 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
AW: unattended (silent) install of CSD's?
Hi Stefan, try the following trick: create a script like this #!/bin/ksh YOUR_PKG_PATH="insert your path" YOUR_CSD="mqm-something.img" pkgadd -a $YOUR_PKG_PATH/adminfile -d $YOUR_PKG_PATH/$YOUR_CSD > $2 2>&1
Re: Invoking a CICS Program using JMS
AAAGGG!! Now your streaching my brain!!! And that is not hard these days. There is a RED BOOK. And I believe it has to with JAVA CICS on OpenEdition. I have one manual I will send it to you off line so as not to piss off the people on the LIST who are technology disadvantaged (who said I'm not PC!!). When I was fooling with this stuff at s.h.i.t.t.y.bank I was looking at CORBA for legacy services implementation. Some of the information may ALSO be in RED Books with that in the title. bobbee From: "Moreira, Paulo" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Invoking a CICS Program using JMS Date: Thu, 5 Jun 2003 14:56:53 +0200 Hi, From the MQ documentation I can see that is possible to invoke a CICS program using MQSeries and the MQ CICS Bridge. I would like to know if it is possible to know if this is possible using MQ via JMS? Is anyone using it in production? Can you point me some documentation about this topic? Many thanks Paulo -- The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: CLUSTERed MQM's in MVS & Distributed Platforms in a DRP
I can agree with that and I considered that scenario for Hot Site. But, my concern are dynamic CHANNELS. If IBM keeps previously built DYNAMIC CHANNELs to other CLUSTERed MQM's in, say one of the SYSTEM.CLUSTER.? or in SYSTEM.CHANNEL.SYNCQ queues, then data could flow to or from the Hote Site. So maybe the issue is - When are DYNAMIC CLUSTER CHANNELS built? 1)At MQM startup 2) or when CLUSTER's are defined to the MQM. If it's #2, then I see problems for data traffic to production at the Hot Site TEST. Regards Jason "Beinert, William" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: OM> Subject: Re: CLUSTERed MQM's in MVS & Distributed Sent by: Platforms in a DRP "MQSeries List" <[EMAIL PROTECTED] N.AC.AT> 06/05/2003 08:59 AM Please respond to "MQSeries List" If you have TCP connectivity between your DR and Production sites, your network people will have done a lot of work changing IP addresses of every host at DR. You will need to do the same - change the CONNAME address of every SENDER channel, clustered and non-clustered. Clustering is not really the issue here, as I see it. Bill -Original Message- From: Jason Andersen [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 2:49 PM To: [EMAIL PROTECTED] Subject: CLUSTERed MQM's in MVS & Distributed Platforms in a DRP What kind of problems will I have given this scenario: 1) DRP Hot Site Test 2) MVS and Distributed MQM's recovered 3) MQM's have CLUSTERs on both platforms 4) Shared Queues in the CLUSTER 5) Stand alone CLUSTER queues (not shared) 6) Now the BIGGY, Open TCPIP Network between Hot Site and Production Enterprise I see some doom and gloom here. Dynamic CHANNELS being created between MQM's running on the Hot Site and Production Site where messages could flow from DRP to Production or vice-versa. Not to mention MQM's with the same names. What can I do to put a fence around the DRP Hot Site for MQSeries CLUSTER's to stop any message exchange between Production/Test and the Hot Site? Remember this is only a Test. Instructions for managing your mailing list 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: MQMD
yes, but if I remember correctly you have to specifically set an option to set the context. This was talked about on the LIST a while back. The allmqi doesn't do the trick. bobbee From: Jay Jayatissa <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: MQMD Date: Thu, 5 Jun 2003 13:29:27 +0100 I have setmqaut for this user on the Queue with the param of +allmqi is this the command you mean? "Robert Broderick" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 05-Jun-2003 12:27 Please respond to "MQSeries List" <[EMAIL PROTECTED]> To: MQSERIES cc: Subject:Re: MQMD You need to use the MQSETAUTH to grant your user the authorazation to perform this. >From: Jay Jayatissa <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: MQMD >Date: Thu, 5 Jun 2003 11:12:23 +0100 > >I have set MQOO_SET_ALL_CONTEXT option in the MQOPEN call and >MQPUT_SET_ALL_CONTEXT in the MQPUT call but Iam still >getting "2035" error. The userid that the application is running under >does have authority to set this option on the queue. > >Can anyone help? > >Jay > > > > >"Bruce Giordano" <[EMAIL PROTECTED]> > >Sent by: "MQSeries List" <[EMAIL PROTECTED]> >04-Jun-2003 16:46 >Please respond to "MQSeries List" <[EMAIL PROTECTED]> > > > > > To: MQSERIES > > cc: > Subject:Re: MQMD > > >You need to specify the SET_ALL_CONTEXT option when you open the queue. >Note that the id this is running under would also need the authority to >set >this option on the queue. > - Bruce Giordano > > > > Jay Jayatissa > <[EMAIL PROTECTED]> To: >[EMAIL PROTECTED] > cc: > Sent by: MQSeries List Subject: MQMD > <[EMAIL PROTECTED]> > > > > Wednesday June 4, 2003 11:18 AM > Please respond to MQSeries List > > > > > > >Hi all, >does anyone know how I can set the Application name in the MQMD header. > I have tried setting it using md.PutApplName = "MyName" but the MQ Client >always takes the name of the of where the location of the application is >and >overwrites my value. Is there a flag I need to set as well?? > > > cheers, >Jay >(See attached file: C.htm) > > > > ><< C.htm >> _ MSN 8 with e-mail virus protection service: 2 months FREE* 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 _ MSN 8 with e-mail virus protection service: 2 months FREE* 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: MQS 5.2 & 5.3
Wow, deja vu! Current and prior releases of MQ, at least as far back as v2 anyway, all look for executables in /opt/mqm/bin. Therefore it would be impossible to have two versions running at the same time. -- T.Rob -Original Message- From: Darius Parvaneh [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 10:00 AM To: [EMAIL PROTECTED] Subject: MQS 5.2 & 5.3 Hi all, Is it possible to have two different MQSeries version, for ex 5.2 and 5.3, on the same unix box ? Thanks in advance, Darius. Instructions for managing your mailing list 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: Invoking a CICS Program using JMS
Haven't done it, but why not? Check out the "Mapping JMS to a Native MQSeries Application" section of the Java Manual. Make sure to suppress the RFH2 header by invoking the destination.setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ) method. > -Original Message- > From: Moreira, Paulo [SMTP:[EMAIL PROTECTED] > Sent: Thursday, June 05, 2003 5:57 AM > To: [EMAIL PROTECTED] > Subject: Invoking a CICS Program using JMS > > Hi, > > From the MQ documentation I can see that is possible to invoke a CICS > program using MQSeries and the MQ CICS Bridge. I would like to know if it is > possible to know if this is possible using MQ via JMS? Is anyone using it in > production? Can you point me some documentation about this topic? > > Many thanks > > Paulo > > > > -- > The contents of this e-mail are intended for the named addressee only. It > contains information that may be confidential. Unless you are the named > addressee or an authorized designee, you may not copy or use it, or disclose > it to anyone else. If you received it in error please notify us immediately > and then destroy it. > > Instructions for managing your mailing list 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: MQSeries in DMZ
There are 2 questions here: 1. The concrete Madsen's question about allowing anybody to send data to MQSeries in DMZ. Using SSL channel is a decent (but not 100%) way to prevent anyone but legal users from connecting to your server, and no one can read or write data without having a connection. 2. What does DMZ protect you from? Mostly from breaking into one of the servers on your intranet, getting some user's priviliges there and compromising your network. To Bobbee: Yes, DMZ is essentially a router, but of a special kind (if configured properly). Hosts in DMZ are usually not allowed to initiate any connections as a policy matter. The main reason is that if the machine in DMZ is completely compromised by the attacker, s/he will have some troubles in using it as a bridgehead to expand the attack on the Intranet. This is of course only a basic concept and somewhat old-fashioned DMZ design. Current DMZ configurations have more than 2 firewalls with different rules for every zone. One MQSeries strong point for implementation in DMZ is having many types of channels to select from. So, for example, for getting data from an outside client, you can use "receiver" and "server" ends on QM in DMZ, Requester on QM on your intranet (and sender on your partner's QM). Hope this will answer the original question, Pavel Robert Broderick <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OTMAIL.COM> cc: Sent by: MQSeries Subject: Re: MQSeries in DMZ List <[EMAIL PROTECTED] .AC.AT> 06/05/2003 07:12 AM Please respond to MQSeries List Just a question. As the DMZ is just a router. And unless the receiver or sender is down. There normally would not be any data on the DMZ box. I would think the exposure to people snooping on the DMZ is a moote point. The server inside your intranet is another story. bobbee >From: Tim Armstrong <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: MQSeries in DMZ >Date: Thu, 5 Jun 2003 11:33:29 +1000 > >Sid, > >But if only certain ports on the DMZ machine are open and the listener >running against the MQ port goes through an SSL validation process for >anyone connecting to it then aren't we protected? > >Regards >Tim A > > > > [EMAIL PROTECTED] > .AU To: >[EMAIL PROTECTED] > Sent by: MQSeriescc: > List Subject: Re: MQSeries in >DMZ > <[EMAIL PROTECTED] > N.AC.AT> > > > 05/06/2003 10:53 > Please respond to > MQSeries List > > > > > >Tim, > >SSL wont protect the data sitting on the server Is that where the risk >really is ?.. In my case it is.. Yours may be different. > >But SSL from server-server is also a good choice. > >Sid > >-Original Message- >From: Tim Armstrong [mailto:[EMAIL PROTECTED] >Sent: Thursday, 5 June 2003 9:56 AM >To: [EMAIL PROTECTED] >Subject: Re: MQSeries in DMZ > > >Or you can use the SSL features that became available in V5.3. > >Regards >Tim A > > > > "Potkay, Peter M > (PLC, IT)" To: >[EMAIL PROTECTED] > <[EMAIL PROTECTED]cc: > RTFORD.COM>Subject: Re: MQSeries in >DMZ > Sent by: MQSeries > List > <[EMAIL PROTECTED] > AC.AT> > > > 05/06/2003 01:17 > Please respond to > MQSeries List > > > > > >See support pac MS81 >http://www-3.ibm.com/software/integration/support/supportpacs/individual/ms8 > > >1.html > >It has what you need. It is the MQSeries Internet Pass Thru (MQIPT). > > >-Original Message- >From: Madsen, Timothy [mailto:[EMAIL PROTECTED] >Sent: Wednesday, June 04, 2003 11:06 AM >To: [EMAIL PROTECTED] >Subject: MQSeries in DMZ > > >Hello, >We have external partners who need to connect to our MQSeries. So, we >could >put an MQSeries server in our DMZ and let those external people connect to >that MQ and then have the DMZ MQ connect to our internal MQ. We can >configure our firewall (Cisco Pix) to only let MQ appropriate >ports/protocols pass from the internet to the DMZ MQ server. > >However, we would still be allowing **anybody** on the internet to send >messages to our MQSeries in our DMZ. We are working with a small list of >partners - they are not anonymous. > >So - from this two questions: > >1) Would this be conside
AMQ7605
Hi all, I seem to get the following error very frequently , env : MQSeries 5.2 CSD06 and Oracle: AMQ7605: The XA resource manager Oracle xadbptr has returned an unexpected return code -3, when called for xa_close. Any ideas? Emile Kearns MQSeries Administrator SCMB > Technology Infrastructure Group > Information Technology Department > Standard Corporate and Merchant Bank > > E-mail: [EMAIL PROTECTED] > *Phone: +27-11-636-3336 SCMB, P.O. Box 61344, Marshalltown, > 2107, Gauteng, RSA > *Fax: +27-11-636-5713 2nd Floor, Entrance 6, 3 Simmonds > Street, JHB > > > For information about the Standard Bank group visit our web site www.standardbank.co.za Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of the 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 reached you and do not read, disclose or use the content in any way. Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. II Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
AW: Cluster---AMQ4514
Ruzi, this sounds somehow familiar to me. are you using the mq explorer? i remember of similiar error messages telling me that the qmgr is not in the cluster when working with cluster objects, at least the definition worked and the qmgr was member of the cluster, it was just the mq explorer that was telling me silly messages. if you are using the mq explorer, try something else (e.g. remote runmqsc or mo71 supportpac) to create the definitions and check if the errors occur again. the mq explorer sometimes seems to be a bit confused regards stefan -Ursprüngliche Nachricht- Von: Ruzi R [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 5. Juni 2003 15:07 An: [EMAIL PROTECTED] Betreff: Cluster---AMQ4514 I created a cluster with QM1 and QM2 full-repositories. QM3 is a member of the cluster (not a full repository). The cluster queue Q1 is defined on QM2 and QM3. Q1: When I want to define Q1 on QM1 I get an error message AMQ4514 which basically says as the queue manager is not a member of the cluster, the queue cannot be defined as cluster. But the queue manager (QM1) is the full-repository. I have refreshed the cluster. Q2: When defining the cluster queue I expected to see the cluster name in the drop-down menu of the cluster tab --- it was just blank. Is this a normal behavior? I manually specified the cluster name for creating cluster queue Q1 on QM2 and QM3, and it worked. Thanks, Ruzi Instructions for managing your mailing list 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: MQMD
Thanks Tom! that works now Jay "Tom Schneider" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 05-Jun-2003 12:48 Please respond to "MQSeries List" <[EMAIL PROTECTED]> To: MQSERIES cc: Subject: Re: MQMD Jay, If this is on a distributed queue manager, in the OAM the userid running the program needs setall authority to both the queue and the queue manager. -Tom == Tom Schneider / IBM Global Services (513) 274-4034 [EMAIL PROTECTED] == Jay Jayatissa <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 06/05/2003 06:12 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: MQMD I have set MQOO_SET_ALL_CONTEXT option in the MQOPEN call and MQPUT_SET_ALL_CONTEXT in the MQPUT call but Iam still getting "2035" error. The userid that the application is running under does have authority to set this option on the queue. Can anyone help? Jay "Bruce Giordano" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 04-Jun-2003 16:46 Please respond to "MQSeries List" <[EMAIL PROTECTED]> To: MQSERIES cc: Subject: Re: MQMD You need to specify the SET_ALL_CONTEXT option when you open the queue. Note that the id this is running under would also need the authority to set this option on the queue. - Bruce Giordano Jay Jayatissa <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Sent by: MQSeries List Subject: MQMD <[EMAIL PROTECTED]> Wednesday June 4, 2003 11:18 AM Please respond to MQSeries List Hi all, does anyone know how I can set the Application name in the MQMD header. I have tried setting it using md.PutApplName = "MyName" but the MQ Client always takes the name of the of where the location of the application is and overwrites my value. Is there a flag I need to set as well?? cheers, Jay (See attached file: C.htm) C.htm has been removed from this note on June 05, 2003 by Tom Schneider Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
SOAP
Title: SOAP I was wondering if there are users who have implemented the following: Use MQ to send SOAP messages asynchronously over a queue. Any pointers or help would be very useful. In appreciation Subhajit Maitra This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna
Re: PubSub Broker
I have 10 clients connecting, but each of them are going after a different subscription. So I would expect the IPPROCS to show a 1 for 1 relationship. -- Jay H. Lang Chief Technologist Distributed Computing Professionals Inc. IBM Certified Specialist - MQSeries 303 277-1873 - Office 303 807-9700 - Cell "David C. Partridge" wrote: > Maybe I'm being dense, but surely if you have 10 clients connecting and > reading messages from the same subscription queue, then the IPPROCS on that > queue will be 10? > > David > > Instructions for managing your mailing list 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
