Re: RQD disappears [Deutsche Boerse Systems: Virus checked]
Dmitry, did you check CSQINP2 of the queuemanager for a DELETE QREMOTE(...) statement? Do you have any cleanup Jobs started by automation after MQ shutdown / before MQ restart? Or maybe you coded a delete with a define afterwards (CSQINP2, jobs, ...but the define fails for some reason? Is the queuemanager member of a queue sharing group, and maybe the remotequeue is a group entry in an other queuemanager and the local copy is purged because there is something wrong with the group entry (a message for the deletion should be in the mstr log in this case). If you are at Version 5.3, you could switch on configuration events and check for the queue deletion in the event queue. You could also check right after the shutdown and right before the restart with csqutil and SDEFS if the object definition is still there, so maybe this helps to identify the time the definition is lost... Just some guesses Regards, Stefan |+-+--+| || Dmitry| || || [EMAIL PROTECTED] | To: [EMAIL PROTECTED] || || | cc: (bcc: Stefan Raabe/DBS/GDB)^|| || 15.10.2003 08:12 | Subject: RQD disappears [Deutsche || || Please respond to | Boerse Systems: Virus checked] || || MQSeries List | || || | || |+-+--+| Hi! We use MQS on OS390 and recently have faced one strange fact. We created Remote Queue Definition in our Queue Manager, during several weeks it had been working succesfully. But when we restarted and again started the subsystem, it disappeared! We created RQD again and tried this trick one more time - and got the same result - it disappeared! Though all the 'normal', i.e. local queues, were present... Does someone can tell me the reason of this disappearence? Best regards, Dmitry Nevsky Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Question on message groups
A sending application uses message groups. It sends a large number of messages (1000+) in each group. The receiving application reads each message from the group and does a MQCMIT every message. For some reason, the receiving application cannot wait for the entire group to do the commit. What happens if the receiving application fails for some reason when it is half way through the group? It has committed many of the messages so they do not exist on the queue anymore. When the receiving app starts back up, will it begin reading the rest of the messages or will there be some problem. Instructions for managing your mailing list 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: queue manager does not exist error
If the restore found files under /var/mqm/qmgrsyourqmgr but yourqmgr was not listed in the mqs.ini file, then your MQ installation got out of synch at some point. Not sure what to suggest at this point. You might want to try renaming /var/mqm/qmgrsyourqmgr to something else and using crtmqm to create a new yourqmgr. Then copy the saved files over top of the new /var/mqm/qmgrsyourqmgr. This will make the correct entries in the mqs.ini file for you and then restore the old QMgr structure. Alternatively, you could edit the mqs.ini file directly to add the entries or search your older archives for an intact installation. Good luck! -- T.Rob -Original Message- From: Prithwiraj Basu [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 14, 2003 4:07 PM To: [EMAIL PROTECTED] Subject: Re: queue manager does not exist error That's odd because after doing the restore on the WHOLE tree (i.e. /var/mqm) my /var/mqm/mqs.ini does not have any queue manager names entries in it. In fact here are the contents (pasted below). Is this ini file in order? Thanks. Prits ## #* *# #* START_COPYRIGHT*# #* Licensed Materials - Property of IBM *# #* *# #* 63H9336 *# #* (C) Copyright IBM Corporation 1994, 2000 *# #* *# #* END_COPYRIGHT *# #* *# ## #***# #* Module Name: mqs.ini*# #* Type : MQSeries Machine-wide Configuration File *# #* Function : Define MQSeries resources for an entire machine*# #* *# #***# #* Notes :*# #* 1) This is the installation time default configuration *# #* *# #***# AllQueueManagers: ## #* The path to the qmgrs directory, below which queue manager data *# #* is stored*# ## DefaultPrefix=/var/mqm ClientExitPath: ExitsDefaultPath=/var/mqm/exits LogDefaults: LogPrimaryFiles=3 LogSecondaryFiles=2 LogFilePages=1024 LogType=CIRCULAR LogBufferPages=17 LogDefaultPath=/var/mqm/log Wyatt, T. Rob [EMAIL PROTECTED] OFAMERICA.COM To Sent by: MQSeries [EMAIL PROTECTED] List cc [EMAIL PROTECTED] n.AC.AT Subject Re: queue manager does not exist error 10/14/2003 03:20 PM Please respond to MQSeries List [EMAIL PROTECTED] n.AC.AT Yes. Ideally, the correct file will be from the same date as the /var/mqm/qmgrs/yourqmgr tree that was previously restored. My recommendation to restore all of /var/mqm at once was to insure that all files would be in synch. Restoring just mqs.ini will probably work if your MQ environment is fairly stable. -- T.Rob -Original Message- From: Prithwiraj Basu [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 14, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: Re: queue manager does not exist error Thanks for the responses. If the correct /var/mqm/mqs.ini is restored, then will there be an entry in it with my queue manager name (i.e. the one that is missing)? Thanks. Prits Wyatt, T. Rob [EMAIL PROTECTED] OFAMERICA.COM To Sent by: MQSeries [EMAIL PROTECTED] List cc [EMAIL PROTECTED] n.AC.AT Subject Re: queue manager does not exist error
Question about OS Upgrade and MQSeries
Hi All, We have upgraded our Unix OS from Sun Solaris 8 to Sun Solaris 9. While doing so, the IT team blew away the old MQSeries objects. My question is: Can this be avoided? I.e. can the OS be upgraded without blowing away the MQSeries objects as that would help us in future? Thanks. Prits Instructions for managing your mailing list 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: Penetrating an outbound firewall
Title: Penetrating an outbound firewall
T.Rob
wrote:
"Every
time I bring this up, people always reply that you can accomplish the same thing
with an exit or MCAUSER. My answer to that is that you cannot restrict
traffic to a specific channel. For example, if you define XYZ.RCVR with
MCAUSER('xyz'), there is nothing to prevent ABC Corp from connecting to
it."
If ABC
corp connects to XYZ.RCVR, and XYZ.RCVR has a MCA USer Identifier set to 'xyz',
then all the messages coming across this channelwill have xyz, even ABC's
messages. How is that different than if the ABC got to XYZ.RCVR through another
listner / port? If ABC connects XYZ.RCVR overport , where a listener
is running as def, aren't the messages still put as xyz, not def, xyz is in the
MCAUSER?
Also,
you mentioned "we also delete all SYSTEM.DEF* objects". I tried deleting
SYSTEM.DEFAULT.LOCAL.QUEUE on a dummy QM, and now I cant create any queues,
which I suppose is the goal. But does that meaning that from this point forward,
I can never create any more local queues on this QM?
-Original Message-From: Wyatt, T. Rob
[mailto:[EMAIL PROTECTED]Sent: Friday, September 05,
2003 4:44 PMTo: [EMAIL PROTECTED]Subject: Re:
Penetrating an outbound firewall
Peter,
I've
not used MQIPT so I don't know what security concerns it addresses - or
introduces. Since I work for a bank, I always start with the assumption
that my DMZ servers are targets of attack and Itry to nail them down as
tight as possible. In my shop we would do that last paragraph regardless
of any assumed security provided by MQIPT, our firewall or private
circuits.
And
that's just the beginning. In the DMZ we also delete all SYSTEM.DEF*
objects, set up LOCALADDR to bind the internal-facing channels to
internal-facing NICs and run security exits (or SSL where available). We
also never use a SVR channel in the DMZ or define a SVRCONN for external
use. As a rule, the Command Server and Trigger Monitor are turned off
unless specifically required. If we do run a trigger monitor,
itruns under a low-privileged ID. All channels use MCAUSER set to
a low-privileged ID. The QMgr runs under an ID other than mqm and mqm is
removed from the mqm group. UserIDs in the DMZ are never authorized to
SET*. All of these configurations address one or more specific
vulnerabilities and when you apply all of them in combination, it is VERY
difficult to get admin access to the QMgr from outside or to hijack queues and
channels for other than their intended use.
Incidentally, you mentioned a dedicated QMgr "for outbound messaging
(to other companies)" and I notice that's plural. Are you hosting
interfaces tomore than one company on the same QMgr? In that case,
I would DEFINITELY want to lock down each interface under a separate ID.
Can you imagine the fallout if company A used your MQ interface to maliciously
attack Company B? If your naming standards make it easy to guess channel
names and queue names based on customer name or ID, hijacking someone else's
channel or queue is not so farfetched. Hell, you might even do it by
accident when copying MQSC scripts from one customer to another and miss the
RNAME in a QREMOTE or something. If you made this mistake with the
listener running as mqm, nothing would stop the messages from going to the
wrong queue or out to the wrong customer.
--
T.Rob
-Original Message-From: Potkay, Peter M (PLC, IT)
[mailto:[EMAIL PROTECTED]Sent: Friday, September 05,
2003 3:59 PMTo: [EMAIL PROTECTED]Subject: Re:
Penetrating an outbound firewall
T.Rob, in regards to your last paragraph, is that still necessary if
A.
Your queue manager is a dedicated one just for outbound messaging (to other
companies)sitting in the DMZ
and
B.
MQIPT sits between your DMZ queue manager and any outside
companies?
(There are very specific firewall rules between the DMZ queue manager
and the internal queue manager inside of the internal firewall that it
connects to.)
-Original Message-From: Wyatt, T. Rob
[mailto:[EMAIL PROTECTED]Sent: Friday, September
05, 2003 12:19 PMTo: [EMAIL PROTECTED]Subject:
Re: Penetrating an outbound firewall
Doug,
We are using direct MQ connections with firewall rules as specified
in MA86
(http://www-3.ibm.com/software/integration/support/supportpacs/individual/supportpacs/ma86.pdf).
This has been working fine for us except that servers with dual
NICs or virtual IP addresses (our Veritas clusters), the socket would
sometimes bind to a different address under MQpre-5.3 and be blocked
by the firewall. Prior to 5.3 we had to set up rules for the
physical AND virtual addresses since the binding was unspecified.
The LOCALADDR field has really simplified things. We have tried
Peter Gersak/Slovenia/IBM is out of the office.
I will be out of the office starting October 15, 2003 and will not return until October 16, 2003. Instructions for managing your mailing list 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: Penetrating an outbound firewall
Title: Message T.Rob, What do you think of just stopping the command server? My thinking is if they have access to the box to start the command server locally, they can just as easily use runmqsc to create the queue. True, it is an extra step, but does it buy us anything really to delete the command queue on top of stopping the command server? As a side note, does anyone know of an MQ class just for security. I am writing up a doc for Security for MQ at our company, and man, this is a subject unto itself! -Original Message-From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED]Sent: Wednesday, September 10, 2003 8:27 AMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall You can't. Without going into too much detail, you would need an agent that doesn't rely on the command server, a command server that used a different queue, or you would have to define the queue and start thecommand server each time. These options may seem like a royal pain but then the whole purpose is to make it hard to administer the QMgr by building significant hurdles for a malicious user to overcome. With appropriate automation, none of these are particularly burdensome for the legitimate admin team. -- T.Rob -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]Sent: Tuesday, September 09, 2003 8:47 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.Rob, If you delete the SYSTEM.ADMIN.COMMAND.QUEUE how do you send command messages ?... sorry if this appears to bea stupid question. Sid -Original Message-From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Saturday, 6 September 2003 6:44 AMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Peter, I've not used MQIPT so I don't know what security concerns it addresses - or introduces. Since I work for a bank, I always start with the assumption that my DMZ servers are targets of attack and Itry to nail them down as tight as possible. In my shop we would do that last paragraph regardless of any assumed security provided by MQIPT, our firewall or private circuits. And that's just the beginning. In the DMZ we also delete all SYSTEM.DEF* objects, set up LOCALADDR to bind the internal-facing channels to internal-facing NICs and run security exits (or SSL where available). We also never use a SVR channel in the DMZ or define a SVRCONN for external use. As a rule, the Command Server and Trigger Monitor are turned off unless specifically required. If we do run a trigger monitor, itruns under a low-privileged ID. All channels use MCAUSER set to a low-privileged ID. The QMgr runs under an ID other than mqm and mqm is removed from the mqm group. UserIDs in the DMZ are never authorized to SET*. All of these configurations address one or more specific vulnerabilities and when you apply all of them in combination, it is VERY difficult to get admin access to the QMgr from outside or to hijack queues and channels for other than their intended use. Incidentally, you mentioned a dedicated QMgr "for outbound messaging (to other companies)" and I notice that's plural. Are you hosting interfaces tomore than one company on the same QMgr? In that case, I would DEFINITELY want to lock down each interface under a separate ID. Can you imagine the fallout if company A used your MQ interface to maliciously attack Company B? If your naming standards make it easy to guess channel names and queue names based on customer name or ID, hijacking someone else's channel or queue is not so farfetched. Hell, you might even do it by accident when copying MQSC scripts from one customer to another and miss the RNAME in a QREMOTE or something. If you made this mistake with the listener running as mqm, nothing would stop the messages from going to the wrong queue or out to the wrong customer. -- T.Rob -Original Message-From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]Sent: Friday, September 05, 2003 3:59 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.Rob, in regards to your last paragraph, is that still necessary if A. Your queue manager is a dedicated one just for outbound messaging (to other companies)sitting in the DMZ and B. MQIPT sits between your DMZ queue manager and any outside companies? (There are very specific firewall rules between the DMZ queue manager and the internal queue manager inside of the internal firewall that it connects to.)
Re: Penetrating an outbound firewall
I think you should be able to create queues using the
LIKE parameter.
Sam
--- Potkay, Peter M (PLC, IT)
[EMAIL PROTECTED] wrote: T.Rob wrote:
Every time I bring this up, people always reply
that you can accomplish the
same thing with an exit or MCAUSER. My answer to
that is that you cannot
restrict traffic to a specific channel. For
example, if you define XYZ.RCVR
with MCAUSER('xyz'), there is nothing to prevent ABC
Corp from connecting to
it.
If ABC corp connects to XYZ.RCVR, and XYZ.RCVR has a
MCA USer Identifier set
to 'xyz', then all the messages coming across this
channel will have xyz,
even ABC's messages. How is that different than if
the ABC got to XYZ.RCVR
through another listner / port? If ABC connects
XYZ.RCVR over port ,
where a listener is running as def, aren't the
messages still put as xyz,
not def, xyz is in the MCAUSER?
Also, you mentioned we also delete all SYSTEM.DEF*
objects. I tried
deleting SYSTEM.DEFAULT.LOCAL.QUEUE on a dummy QM,
and now I cant create any
queues, which I suppose is the goal. But does that
meaning that from this
point forward, I can never create any more local
queues on this QM?
-Original Message-
From: Wyatt, T. Rob
[mailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2003 4:44 PM
To: [EMAIL PROTECTED]
Subject: Re: Penetrating an outbound firewall
Peter,
I've not used MQIPT so I don't know what security
concerns it addresses - or
introduces. Since I work for a bank, I always start
with the assumption
that my DMZ servers are targets of attack and I try
to nail them down as
tight as possible. In my shop we would do that last
paragraph regardless of
any assumed security provided by MQIPT, our firewall
or private circuits.
And that's just the beginning. In the DMZ we also
delete all SYSTEM.DEF*
objects, set up LOCALADDR to bind the
internal-facing channels to
internal-facing NICs and run security exits (or SSL
where available). We
also never use a SVR channel in the DMZ or define a
SVRCONN for external
use. As a rule, the Command Server and Trigger
Monitor are turned off
unless specifically required. If we do run a
trigger monitor, it runs under
a low-privileged ID. All channels use MCAUSER set
to a low-privileged ID.
The QMgr runs under an ID other than mqm and mqm is
removed from the mqm
group. UserIDs in the DMZ are never authorized to
SET*. All of these
configurations address one or more specific
vulnerabilities and when you
apply all of them in combination, it is VERY
difficult to get admin access
to the QMgr from outside or to hijack queues and
channels for other than
their intended use.
Incidentally, you mentioned a dedicated QMgr for
outbound messaging (to
other companies) and I notice that's plural. Are
you hosting interfaces to
more than one company on the same QMgr? In that
case, I would DEFINITELY
want to lock down each interface under a separate
ID. Can you imagine the
fallout if company A used your MQ interface to
maliciously attack Company B?
If your naming standards make it easy to guess
channel names and queue names
based on customer name or ID, hijacking someone
else's channel or queue is
not so farfetched. Hell, you might even do it by
accident when copying MQSC
scripts from one customer to another and miss the
RNAME in a QREMOTE or
something. If you made this mistake with the
listener running as mqm,
nothing would stop the messages from going to the
wrong queue or out to the
wrong customer.
-- T.Rob
-Original Message-
From: Potkay, Peter M (PLC, IT)
[mailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2003 3:59 PM
To: [EMAIL PROTECTED]
Subject: Re: Penetrating an outbound firewall
T.Rob, in regards to your last paragraph, is that
still necessary if
A. Your queue manager is a dedicated one just for
outbound messaging (to
other companies) sitting in the DMZ
and
B. MQIPT sits between your DMZ queue manager and any
outside companies?
(There are very specific firewall rules between the
DMZ queue manager and
the internal queue manager inside of the internal
firewall that it connects
to.)
-Original Message-
From: Wyatt, T. Rob
[mailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2003 12:19 PM
To: [EMAIL PROTECTED]
Subject: Re: Penetrating an outbound firewall
Doug,
We are using direct MQ connections with firewall
rules as specified in MA86
(
http://www-3.ibm.com/software/integration/support/supportpacs/individual/sup
portpacs/ma86.pdf
http://www-3.ibm.com/software/integration/support/supportpacs/individual/su
pportpacs/ma86.pdf ).
This has been working fine for us except that
servers with dual NICs or
virtual IP addresses (our Veritas clusters), the
socket would sometimes bind
to a different address under MQ pre-5.3 and be
blocked by the firewall.
Prior to 5.3 we had to set up rules for the physical
AND virtual addresses
since the binding was
Re: Penetrating an outbound firewall
Try http://www.sjg-enterpriseintegration.com/oamsecurity.asp and http://www.sjg-enterpriseintegration.com/closingmqholes.asp --- Potkay, Peter M (PLC, IT) [EMAIL PROTECTED] wrote: T.Rob, What do you think of just stopping the command server? My thinking is if they have access to the box to start the command server locally, they can just as easily use runmqsc to create the queue. True, it is an extra step, but does it buy us anything really to delete the command queue on top of stopping the command server? As a side note, does anyone know of an MQ class just for security. I am writing up a doc for Security for MQ at our company, and man, this is a subject unto itself! -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 10, 2003 8:27 AM To: [EMAIL PROTECTED] Subject: Re: Penetrating an outbound firewall You can't. Without going into too much detail, you would need an agent that doesn't rely on the command server, a command server that used a different queue, or you would have to define the queue and start the command server each time. These options may seem like a royal pain but then the whole purpose is to make it hard to administer the QMgr by building significant hurdles for a malicious user to overcome. With appropriate automation, none of these are particularly burdensome for the legitimate admin team. -- T.Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 09, 2003 8:47 PM To: [EMAIL PROTECTED] Subject: Re: Penetrating an outbound firewall T.Rob, If you delete the SYSTEM.ADMIN.COMMAND.QUEUE how do you send command messages ?... sorry if this appears to be a stupid question. Sid -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Saturday, 6 September 2003 6:44 AM To: [EMAIL PROTECTED] Subject: Re: Penetrating an outbound firewall Peter, I've not used MQIPT so I don't know what security concerns it addresses - or introduces. Since I work for a bank, I always start with the assumption that my DMZ servers are targets of attack and I try to nail them down as tight as possible. In my shop we would do that last paragraph regardless of any assumed security provided by MQIPT, our firewall or private circuits. And that's just the beginning. In the DMZ we also delete all SYSTEM.DEF* objects, set up LOCALADDR to bind the internal-facing channels to internal-facing NICs and run security exits (or SSL where available). We also never use a SVR channel in the DMZ or define a SVRCONN for external use. As a rule, the Command Server and Trigger Monitor are turned off unless specifically required. If we do run a trigger monitor, it runs under a low-privileged ID. All channels use MCAUSER set to a low-privileged ID. The QMgr runs under an ID other than mqm and mqm is removed from the mqm group. UserIDs in the DMZ are never authorized to SET*. All of these configurations address one or more specific vulnerabilities and when you apply all of them in combination, it is VERY difficult to get admin access to the QMgr from outside or to hijack queues and channels for other than their intended use. Incidentally, you mentioned a dedicated QMgr for outbound messaging (to other companies) and I notice that's plural. Are you hosting interfaces to more than one company on the same QMgr? In that case, I would DEFINITELY want to lock down each interface under a separate ID. Can you imagine the fallout if company A used your MQ interface to maliciously attack Company B? If your naming standards make it easy to guess channel names and queue names based on customer name or ID, hijacking someone else's channel or queue is not so farfetched. Hell, you might even do it by accident when copying MQSC scripts from one customer to another and miss the RNAME in a QREMOTE or something. If you made this mistake with the listener running as mqm, nothing would stop the messages from going to the wrong queue or out to the wrong customer. -- T.Rob -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2003 3:59 PM To: [EMAIL PROTECTED] Subject: Re: Penetrating an outbound firewall T.Rob, in regards to your last paragraph, is that still necessary if A. Your queue manager is a dedicated one just for outbound messaging (to other companies) sitting in the DMZ and B. MQIPT sits between your DMZ queue manager and any outside companies? (There are very specific firewall rules between the DMZ queue manager and the internal queue manager inside of the internal firewall that it connects to.) -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2003 12:19 PM To: [EMAIL PROTECTED] Subject: Re: Penetrating an outbound firewall Doug, We are
MQ Series Segmentation
Greetings, Have anyone used MQ segmentation ? Is it possible to activate MQ segmentation in a client server scenario ? I mean between MQ client and MQ server. This is what i am doing, say i have 3 segments, MQPUT PMO MQPMO_LOGICAL_ORDER MD MQMF_SEGMENT (all 3 segments) MQMF_LAST_SEGMENT (last segment ) MQGET GMO MQGMO_COMPLETE_MSG MD No options set Also the Version number for MQMD to MQMD_VERSION_2. Now when i put a message it segments it right, but when i do a MQGET it gets only the first segment, not the whole message. :(. The documentation i was reading says that QM upon receiving the segments reassembles it when an MQGET is issued.. . Does this mean that the segments cannot be re-assembled if the receiving application is an MQ client ? There is a work around that i can keep checking the for the mdDescriptor.MsgFlags = MQMF_LAST_SEGMENT i think... didn't try this yet but might work. Any information is appreciated. Thanks in advance Usha
Re: Penetrating an outbound firewall
Thanks I have seen these very informative docs. They don't address T.Rob's suggestion of deleting the queue altogether. I am curious if it is a benificial extra step or not. -Original Message- From: Sam Garforth [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 11:48 AM To: [EMAIL PROTECTED] Subject: Re: Penetrating an outbound firewall Try http://www.sjg-enterpriseintegration.com/oamsecurity.asp and http://www.sjg-enterpriseintegration.com/closingmqholes.asp --- Potkay, Peter M (PLC, IT) [EMAIL PROTECTED] wrote: T.Rob, What do you think of just stopping the command server? My thinking is if they have access to the box to start the command server locally, they can just as easily use runmqsc to create the queue. True, it is an extra step, but does it buy us anything really to delete the command queue on top of stopping the command server? As a side note, does anyone know of an MQ class just for security. I am writing up a doc for Security for MQ at our company, and man, this is a subject unto itself! -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 10, 2003 8:27 AM To: [EMAIL PROTECTED] Subject: Re: Penetrating an outbound firewall You can't. Without going into too much detail, you would need an agent that doesn't rely on the command server, a command server that used a different queue, or you would have to define the queue and start the command server each time. These options may seem like a royal pain but then the whole purpose is to make it hard to administer the QMgr by building significant hurdles for a malicious user to overcome. With appropriate automation, none of these are particularly burdensome for the legitimate admin team. -- T.Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 09, 2003 8:47 PM To: [EMAIL PROTECTED] Subject: Re: Penetrating an outbound firewall T.Rob, If you delete the SYSTEM.ADMIN.COMMAND.QUEUE how do you send command messages ?... sorry if this appears to be a stupid question. Sid -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Saturday, 6 September 2003 6:44 AM To: [EMAIL PROTECTED] Subject: Re: Penetrating an outbound firewall Peter, I've not used MQIPT so I don't know what security concerns it addresses - or introduces. Since I work for a bank, I always start with the assumption that my DMZ servers are targets of attack and I try to nail them down as tight as possible. In my shop we would do that last paragraph regardless of any assumed security provided by MQIPT, our firewall or private circuits. And that's just the beginning. In the DMZ we also delete all SYSTEM.DEF* objects, set up LOCALADDR to bind the internal-facing channels to internal-facing NICs and run security exits (or SSL where available). We also never use a SVR channel in the DMZ or define a SVRCONN for external use. As a rule, the Command Server and Trigger Monitor are turned off unless specifically required. If we do run a trigger monitor, it runs under a low-privileged ID. All channels use MCAUSER set to a low-privileged ID. The QMgr runs under an ID other than mqm and mqm is removed from the mqm group. UserIDs in the DMZ are never authorized to SET*. All of these configurations address one or more specific vulnerabilities and when you apply all of them in combination, it is VERY difficult to get admin access to the QMgr from outside or to hijack queues and channels for other than their intended use. Incidentally, you mentioned a dedicated QMgr for outbound messaging (to other companies) and I notice that's plural. Are you hosting interfaces to more than one company on the same QMgr? In that case, I would DEFINITELY want to lock down each interface under a separate ID. Can you imagine the fallout if company A used your MQ interface to maliciously attack Company B? If your naming standards make it easy to guess channel names and queue names based on customer name or ID, hijacking someone else's channel or queue is not so farfetched. Hell, you might even do it by accident when copying MQSC scripts from one customer to another and miss the RNAME in a QREMOTE or something. If you made this mistake with the listener running as mqm, nothing would stop the messages from going to the wrong queue or out to the wrong customer. -- T.Rob -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2003 3:59 PM To: [EMAIL PROTECTED] Subject: Re: Penetrating an outbound firewall T.Rob, in regards to your last paragraph, is that still necessary if A. Your queue manager is a dedicated one just for outbound messaging (to other companies) sitting in the DMZ and B. MQIPT sits between your DMZ queue manager and any outside companies? (There
Re: Penetrating an outbound firewall
Thanks Sam.
That did it.
-Original Message-
From: Sam Garforth [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 11:08 AM
To: [EMAIL PROTECTED]
Subject: Re: Penetrating an outbound firewall
I think you should be able to create queues using the
LIKE parameter.
Sam
--- Potkay, Peter M (PLC, IT)
[EMAIL PROTECTED] wrote: T.Rob wrote:
Every time I bring this up, people always reply
that you can accomplish the
same thing with an exit or MCAUSER. My answer to
that is that you cannot
restrict traffic to a specific channel. For
example, if you define XYZ.RCVR
with MCAUSER('xyz'), there is nothing to prevent ABC
Corp from connecting to
it.
If ABC corp connects to XYZ.RCVR, and XYZ.RCVR has a
MCA USer Identifier set
to 'xyz', then all the messages coming across this
channel will have xyz,
even ABC's messages. How is that different than if
the ABC got to XYZ.RCVR
through another listner / port? If ABC connects
XYZ.RCVR over port ,
where a listener is running as def, aren't the
messages still put as xyz,
not def, xyz is in the MCAUSER?
Also, you mentioned we also delete all SYSTEM.DEF*
objects. I tried
deleting SYSTEM.DEFAULT.LOCAL.QUEUE on a dummy QM,
and now I cant create any
queues, which I suppose is the goal. But does that
meaning that from this
point forward, I can never create any more local
queues on this QM?
-Original Message-
From: Wyatt, T. Rob
[mailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2003 4:44 PM
To: [EMAIL PROTECTED]
Subject: Re: Penetrating an outbound firewall
Peter,
I've not used MQIPT so I don't know what security
concerns it addresses - or
introduces. Since I work for a bank, I always start
with the assumption
that my DMZ servers are targets of attack and I try
to nail them down as
tight as possible. In my shop we would do that last
paragraph regardless of
any assumed security provided by MQIPT, our firewall
or private circuits.
And that's just the beginning. In the DMZ we also
delete all SYSTEM.DEF*
objects, set up LOCALADDR to bind the
internal-facing channels to
internal-facing NICs and run security exits (or SSL
where available). We
also never use a SVR channel in the DMZ or define a
SVRCONN for external
use. As a rule, the Command Server and Trigger
Monitor are turned off
unless specifically required. If we do run a
trigger monitor, it runs under
a low-privileged ID. All channels use MCAUSER set
to a low-privileged ID.
The QMgr runs under an ID other than mqm and mqm is
removed from the mqm
group. UserIDs in the DMZ are never authorized to
SET*. All of these
configurations address one or more specific
vulnerabilities and when you
apply all of them in combination, it is VERY
difficult to get admin access
to the QMgr from outside or to hijack queues and
channels for other than
their intended use.
Incidentally, you mentioned a dedicated QMgr for
outbound messaging (to
other companies) and I notice that's plural. Are
you hosting interfaces to
more than one company on the same QMgr? In that
case, I would DEFINITELY
want to lock down each interface under a separate
ID. Can you imagine the
fallout if company A used your MQ interface to
maliciously attack Company B?
If your naming standards make it easy to guess
channel names and queue names
based on customer name or ID, hijacking someone
else's channel or queue is
not so farfetched. Hell, you might even do it by
accident when copying MQSC
scripts from one customer to another and miss the
RNAME in a QREMOTE or
something. If you made this mistake with the
listener running as mqm,
nothing would stop the messages from going to the
wrong queue or out to the
wrong customer.
-- T.Rob
-Original Message-
From: Potkay, Peter M (PLC, IT)
[mailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2003 3:59 PM
To: [EMAIL PROTECTED]
Subject: Re: Penetrating an outbound firewall
T.Rob, in regards to your last paragraph, is that
still necessary if
A. Your queue manager is a dedicated one just for
outbound messaging (to
other companies) sitting in the DMZ
and
B. MQIPT sits between your DMZ queue manager and any
outside companies?
(There are very specific firewall rules between the
DMZ queue manager and
the internal queue manager inside of the internal
firewall that it connects
to.)
-Original Message-
From: Wyatt, T. Rob
[mailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2003 12:19 PM
To: [EMAIL PROTECTED]
Subject: Re: Penetrating an outbound firewall
Doug,
We are using direct MQ connections with firewall
rules as specified in MA86
(
http://www-3.ibm.com/software/integration/support/supportpacs/individual/sup
portpacs/ma86.pdf
http://www-3.ibm.com/software/integration/support/supportpacs/individual/su
pportpacs/ma86.pdf ).
This has been working fine for us except that
servers with dual NICs or
virtual IP addresses (our Veritas
Re: Penetrating an outbound firewall
T.Rob, What do you think of just stopping the command server? My thinking is if they have access to the box to start the command server locally, they can just as easily use runmqsc to create the queue. True, it is an extra step, but does it buy us anything really to delete the command queue on top of stopping the command server? As a side note, does anyone know of an MQ class just for security. I am writing up a doc for Security for MQ at our company, and man, this is a subject unto itself! Hi, I have done extensive testing about security, hacking and so on, on Queue Managers hosted on Windows and Unix boxes. If you want to protect your QM from external attacks, throught channels, the answer is SSL. Definitively. You can play with MCAUSER, channels exits, firewalls, but ... After applying the CSD, MQ5.3 SSL support works pretty well and is able to secure in a decent way your QM from externam attacks. If you want more (in-queue encryption), have a look at MQ Extended Security Edition 5.3, who includes Policy Director. HTH, Luc-Michel -- Luc-Michel Demey - Freelance EAI Consultant Paris / France Tel. : +33 6 08 755 655 http://consulting.demey.org/ - lmd at demey dot org Instructions for managing your mailing list 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: Penetrating an outbound firewall
SSL will protect you from people you don't know from breaking in. You are always sure of who the other side is with SSL. I does nothing when the trusted guy on the other side decides to behave badly. That is where all the other tricks come into play. SSL in combination with all the other methods is the way to go I suppose. -Original Message- From: Luc-Michel Demey [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 12:17 PM To: [EMAIL PROTECTED] Subject: Re: Penetrating an outbound firewall T.Rob, What do you think of just stopping the command server? My thinking is if they have access to the box to start the command server locally, they can just as easily use runmqsc to create the queue. True, it is an extra step, but does it buy us anything really to delete the command queue on top of stopping the command server? As a side note, does anyone know of an MQ class just for security. I am writing up a doc for Security for MQ at our company, and man, this is a subject unto itself! Hi, I have done extensive testing about security, hacking and so on, on Queue Managers hosted on Windows and Unix boxes. If you want to protect your QM from external attacks, throught channels, the answer is SSL. Definitively. You can play with MCAUSER, channels exits, firewalls, but ... After applying the CSD, MQ5.3 SSL support works pretty well and is able to secure in a decent way your QM from externam attacks. If you want more (in-queue encryption), have a look at MQ Extended Security Edition 5.3, who includes Policy Director. HTH, Luc-Michel -- Luc-Michel Demey - Freelance EAI Consultant Paris / France Tel. : +33 6 08 755 655 http://consulting.demey.org/ - lmd at demey dot org Instructions for managing your mailing list 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
MQ Problem - Advice Needed
We have periodic pauses on some of our Solaris servers. CPU usage drops down to nothing for a couple of minutes, then things begin to function normally again. Many of our MQ apps on Solaris were written in the last two years, and maintain exhaustive audit trails, Those audit trails showed that their applications were waiting on an MQPUT for the entire time. Everything on the machine pauses, by the way, but it's these MQ apps that keep the audit trail. So I did some investigation, and eventually discovered that the pauses seemed to coincide with something our storage administrator was running. It is a series of commands - issued on the mainframe - which causes our SAN to replicate to our hotsite. I ran the Unix iostat command during the pauses, and sure enough, the disk service times had gone way up, then back to a couple milliseconds after. So I told the storage team about it (2 months ago!). They claim not to see any problems, and have now decided that it's an MQ problem. They want to meet with me, and have me explain what the MQPUT command is, and how it works. It seems pretty obvious that they don't intend to work on this, and are in the process of putting up a stonewall by shooting the messenger. It's much like dealing with a difficult vendor, except the fact that we work for the same company in some ways makes it even more difficult. I'd be tempted to raise hell with a vendor, but that could be a career limiting move in this case. So... I'm interested if anyone has seen a similar problem. And I'm also interested in any advice on how to get the SAN team to do the right thing and take ownership of the problem. Instructions for managing your mailing list 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: Penetrating an outbound firewall
I like to make my own templets that incorporate any non default object
attributes. For instance, I have a template called TEMPLATE.XMIT.QUEUE that
is all set up to be a triggered transmit queue. When I want a transmit
queue (and all of mine are triggered) in the script I say DEFINE QLOCAL(Q
NAME) LIKE(TEMPLATE.XMIT.QUEUE) and I have a triggered transmit queue. Now
I can have the folks in ops build the definitions, and they don't have to
know anything about triggering a transmit queue.
It works well
Bill Anderson
Senior Systems Analyst
SITA Atlanta, GA
770-303-3503 (office)
404-915-3190 (cell)
[EMAIL PROTECTED]
http://www.mconnect.aero/
Potkay, Peter M
(PLC, IT) To: [EMAIL PROTECTED]
[EMAIL PROTECTED]cc:
RTFORD.COMSubject: Re: Penetrating an outbound
firewall
Sent by: MQSeries
List
[EMAIL PROTECTED]
AC.AT
10/15/2003 12:37 PM
Please respond to
MQSeries List
Thanks T.Rob.
What about the channel question I had below. Am I missing something there?
-Original Message-
From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 12:23 PM
To: [EMAIL PROTECTED]
Subject: Re: Penetrating an outbound firewall
No, it just means you need to specify all the parameters. If you run
a saveqmgr it prints out runmqsc commands suitable for use on a QMgr
with no SYSTEM.DEF* objects. Use these as templates for your queue
definitions if you need to add or change anything. Make sure you run
saveqmgr on the same server or at least one with a matching version
of MQ.
-- T.Rob
-Original Message-
From: Potkay, Peter M (PLC, IT)
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 10:08 AM
To: [EMAIL PROTECTED]
Subject: Re: Penetrating an outbound firewall
T.Rob wrote:
Every time I bring this up, people always reply that you can
accomplish the same thing with an exit or MCAUSER. My answer
to that is that you cannot restrict traffic to a specific
channel. For example, if you define XYZ.RCVR with MCAUSER
('xyz'), there is nothing to prevent ABC Corp from connecting
to it.
If ABC corp connects to XYZ.RCVR, and XYZ.RCVR has a MCA USer
Identifier set to 'xyz', then all the messages coming across
this channel will have xyz, even ABC's messages. How is that
different than if the ABC got to XYZ.RCVR through another
listner / port? If ABC connects XYZ.RCVR over port , where
a listener is running as def, aren't the messages still put as
xyz, not def, xyz is in the MCAUSER?
Also, you mentioned we also delete all SYSTEM.DEF* objects. I
tried deleting SYSTEM.DEFAULT.LOCAL.QUEUE on a dummy QM, and
now I cant create any queues, which I suppose is the goal. But
does that meaning that from this point forward, I can never
create any more local queues on this QM?
-Original Message-
From: Wyatt, T. Rob
[mailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2003 4:44 PM
To: [EMAIL PROTECTED]
Subject: Re: Penetrating an outbound firewall
Peter,
I've not used MQIPT so I don't know what security
concerns it addresses - or introduces. Since I work for
a bank, I always start with the assumption that my DMZ
servers are targets of attack and I try to nail them down
as tight as possible. In my shop we would do that last
paragraph regardless of any assumed security provided by
MQIPT, our firewall or private circuits.
And that's just the beginning. In the DMZ we also delete
all SYSTEM.DEF* objects, set up LOCALADDR to bind the
internal-facing channels to internal-facing NICs and run
security exits (or SSL where available). We also never
use a SVR channel in the DMZ or define a SVRCONN for
external use. As a rule, the Command Server and Trigger
Monitor are turned off unless specifically required. If
we do run a trigger monitor, it runs under a
low-privileged ID. All channels use MCAUSER set to a
low-privileged ID. The QMgr runs under an ID other than
mqm and mqm is removed from the
Re: MQ Series Segmentation
Hi Arun, Thanks for the info, are you saying that i *have* to loop through till i get all the segments ?? I was under an impression that issuing one MQGET should reassemble all the segments and give me one single final message.. - Usha At 10:05 AM 10/15/2003 -0700, you wrote: HI Usha I have used segmentation but only in Server to Server to scenario. MQPUT PMO MQPMO_LOGICAL_ORDER MD MQMF_SEGMENT (all 3 segments) MQMF_LAST_SEGMENT (last segment ) MQGET 1. Instead of GMO MQGMO_COMPLETE_MSG I have used following options GMO MQGMO_LOGICAL_ORDER + MQGMO_ALL_SEGMENTS_AVAILABLE + MQGMO_WAIT; 2. MD No options set: In this case if You have to re-set msg-id and correl id , when you loop through all the segments in the queue to receive all the segments. messageId = MQMI_NONE; correlationId = MQCI_NONE; This worked for me in Server to Server case. try it with client-server and let us know how it works. Arun Makhija Never argue with an idiot. They drag you down to their level and beat you with experience -Original Message- From: Usha Suryadevara [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 15, 2003 8:57 AM To: [EMAIL PROTECTED] Subject: MQ Series Segmentation Greetings, Have anyone used MQ segmentation ? Is it possible to activate MQ segmentation in a client server scenario ? I mean between MQ client and MQ server. This is what i am doing, say i have 3 segments, MQPUT PMO MQPMO_LOGICAL_ORDER MD MQMF_SEGMENT (all 3 segments) MQMF_LAST_SEGMENT (last segment ) MQGET GMO MQGMO_COMPLETE_MSG MD No options set Also the Version number for MQMD to MQMD_VERSION_2. Now when i put a message it segments it right, but when i do a MQGET it gets only the first segment, not the whole message. :(. The documentation i was reading says that QM upon receiving the segments reassembles it when an MQGET is issued.. . Does this mean that the segments cannot be re-assembled if the receiving application is an MQ client ? There is a work around that i can keep checking the for the mdDescriptor.MsgFlags = MQMF_LAST_SEGMENT i think... didn't try this yet but might work. Any information is appreciated. Thanks in advance Usha
Re: MQ Problem - Advice Needed
Jim, When you sit down the SAN people ask them to run a little test with you. Suggest to them a schedule of when they will run these replications over the next week or two. During that time be sure to collect and maintain the application audit logs. After the test period you should be able to use the audit logs of the applications to show that at no other time does this problem occur. It sounds like that during these 'pauses' there is no disk i/o going on at all. If there are applications other than MQ related apps, see if you can get some information showing these 'pauses' are also affecting them. Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: Jim Ford [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 2:34 PM To: [EMAIL PROTECTED] Subject: MQ Problem - Advice Needed We have periodic pauses on some of our Solaris servers. CPU usage drops down to nothing for a couple of minutes, then things begin to function normally again. Many of our MQ apps on Solaris were written in the last two years, and maintain exhaustive audit trails, Those audit trails showed that their applications were waiting on an MQPUT for the entire time. Everything on the machine pauses, by the way, but it's these MQ apps that keep the audit trail. So I did some investigation, and eventually discovered that the pauses seemed to coincide with something our storage administrator was running. It is a series of commands - issued on the mainframe - which causes our SAN to replicate to our hotsite. I ran the Unix iostat command during the pauses, and sure enough, the disk service times had gone way up, then back to a couple milliseconds after. So I told the storage team about it (2 months ago!). They claim not to see any problems, and have now decided that it's an MQ problem. They want to meet with me, and have me explain what the MQPUT command is, and how it works. It seems pretty obvious that they don't intend to work on this, and are in the process of putting up a stonewall by shooting the messenger. It's much like dealing with a difficult vendor, except the fact that we work for the same company in some ways makes it even more difficult. I'd be tempted to raise hell with a vendor, but that could be a career limiting move in this case. So... I'm interested if anyone has seen a similar problem. And I'm also interested in any advice on how to get the SAN team to do the right thing and take ownership of the problem. Instructions for managing your mailing list 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: MQ Problem - Advice Needed
Jim, If they're willing, have them turn off replication. Show them the audit numbers from your apps. Turn on replication and show them the audit numbers again. Jim Ford [EMAIL PROTECTED] To: [EMAIL PROTECTED] OM cc: Sent by: Subject: MQ Problem - Advice Needed MQSeries List [EMAIL PROTECTED] en.AC.AT 10/15/2003 02:34 PM Please respond to MQSeries List We have periodic pauses on some of our Solaris servers. CPU usage drops down to nothing for a couple of minutes, then things begin to function normally again. Many of our MQ apps on Solaris were written in the last two years, and maintain exhaustive audit trails, Those audit trails showed that their applications were waiting on an MQPUT for the entire time. Everything on the machine pauses, by the way, but it's these MQ apps that keep the audit trail. So I did some investigation, and eventually discovered that the pauses seemed to coincide with something our storage administrator was running. It is a series of commands - issued on the mainframe - which causes our SAN to replicate to our hotsite. I ran the Unix iostat command during the pauses, and sure enough, the disk service times had gone way up, then back to a couple milliseconds after. So I told the storage team about it (2 months ago!). They claim not to see any problems, and have now decided that it's an MQ problem. They want to meet with me, and have me explain what the MQPUT command is, and how it works. It seems pretty obvious that they don't intend to work on this, and are in the process of putting up a stonewall by shooting the messenger. It's much like dealing with a difficult vendor, except the fact that we work for the same company in some ways makes it even more difficult. I'd be tempted to raise hell with a vendor, but that could be a career limiting move in this case. So... I'm interested if anyone has seen a similar problem. And I'm also interested in any advice on how to get the SAN team to do the right thing and take ownership of the problem. Instructions for managing your mailing list 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: MQ Problem - Advice Needed
Actually, they agreed to do that. The pauses stopped. But they can't see where it can be their fault, though, so now I'm required to defend MQSeries in general, and MQPUT in particular. Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: MQ Problem - Advice Needed [EMAIL PROTECTED] 10/15/2003 02:08 PM Please respond to MQSeries List Jim, If they're willing, have them turn off replication. Show them the audit numbers from your apps. Turn on replication and show them the audit numbers again. Jim Ford [EMAIL PROTECTED] To: [EMAIL PROTECTED] OM cc: Sent by: Subject: MQ Problem - Advice Needed MQSeries List [EMAIL PROTECTED] en.AC.AT 10/15/2003 02:34 PM Please respond to MQSeries List We have periodic pauses on some of our Solaris servers. CPU usage drops down to nothing for a couple of minutes, then things begin to function normally again. Many of our MQ apps on Solaris were written in the last two years, and maintain exhaustive audit trails, Those audit trails showed that their applications were waiting on an MQPUT for the entire time. Everything on the machine pauses, by the way, but it's these MQ apps that keep the audit trail. So I did some investigation, and eventually discovered that the pauses seemed to coincide with something our storage administrator was running. It is a series of commands - issued on the mainframe - which causes our SAN to replicate to our hotsite. I ran the Unix iostat command during the pauses, and sure enough, the disk service times had gone way up, then back to a couple milliseconds after. So I told the storage team about it (2 months ago!). They claim not to see any problems, and have now decided that it's an MQ problem. They want to meet with me, and have me explain what the MQPUT command is, and how it works. It seems pretty obvious that they don't intend to work on this, and are in the process of putting up a stonewall by shooting the messenger. It's much like dealing with a difficult vendor, except the fact that we work for the same company in some ways makes it even more difficult. I'd be tempted to raise hell with a vendor, but that could be a career limiting move in this case. So... I'm interested if anyone has seen a similar problem. And I'm also interested in any advice on how to get the SAN team to do the right thing and take ownership of the problem. Instructions for managing your mailing list 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: MQ Problem - Advice Needed
Doctor, doctor, it hurts when I do this. Well, don't do that anymore. But seriously, try to find other applications that are experiencing these pause also, then they would look rather foolish asking everyone to defend their apps. It's pretty apparent that whatever they are doing is hogging all of the disk i/o, and the MQPUT is definitely a disk intensive operation. Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: Jim Ford [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 3:20 PM To: [EMAIL PROTECTED] Subject: Re: MQ Problem - Advice Needed Actually, they agreed to do that. The pauses stopped. But they can't see where it can be their fault, though, so now I'm required to defend MQSeries in general, and MQPUT in particular. Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: MQ Problem - Advice Needed [EMAIL PROTECTED] 10/15/2003 02:08 PM Please respond to MQSeries List Jim, If they're willing, have them turn off replication. Show them the audit numbers from your apps. Turn on replication and show them the audit numbers again. Jim Ford [EMAIL PROTECTED] To: [EMAIL PROTECTED] OM cc: Sent by: Subject: MQ Problem - Advice Needed MQSeries List [EMAIL PROTECTED] en.AC.AT 10/15/2003 02:34 PM Please respond to MQSeries List We have periodic pauses on some of our Solaris servers. CPU usage drops down to nothing for a couple of minutes, then things begin to function normally again. Many of our MQ apps on Solaris were written in the last two years, and maintain exhaustive audit trails, Those audit trails showed that their applications were waiting on an MQPUT for the entire time. Everything on the machine pauses, by the way, but it's these MQ apps that keep the audit trail. So I did some investigation, and eventually discovered that the pauses seemed to coincide with something our storage administrator was running. It is a series of commands - issued on the mainframe - which causes our SAN to replicate to our hotsite. I ran the Unix iostat command during the pauses, and sure enough, the disk service times had gone way up, then back to a couple milliseconds after. So I told the storage team about it (2 months ago!). They claim not to see any problems, and have now decided that it's an MQ problem. They want to meet with me, and have me explain what the MQPUT command is, and how it works. It seems pretty obvious that they don't intend to work on this, and are in the process of putting up a stonewall by shooting the messenger. It's much like dealing with a difficult vendor, except the fact that we work for the same company in some ways makes it even more difficult. I'd be tempted to raise hell with a vendor, but that could be a career limiting move in this case. So... I'm interested if anyone has seen a similar problem. And I'm also interested in any advice on how to get the SAN team to do the right thing and take ownership of the problem. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQ Problem - Advice Needed
These puts are persistent messages? If so, MQ has to write to the log. If the log is on the SAN, MQ needs it available. If it is temporarily out, MQ waits. I dealt with the same thing with my HUB a few weeks ago. Remember the thread about fast and normal channels and persistent and non persistent messages? Even though my message were non persistent, the normal channels needed to write to disk on each side. When the SAN guys were doing an upgrade, the HUB had to wait, because the MCAs could not write to the channel sync queue. We solved the problem by making a cluster with all channels set to FAST and only allowing non persistent messages to go into this cluster. Anytime the SAN gets updated, and MQ has persistent messages to deal with, we wait. Fortunately, our blips are only a second or 2 long, so most applications don't know the difference. -Original Message- From: Jim Ford [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 3:20 PM To: [EMAIL PROTECTED] Subject: Re: MQ Problem - Advice Needed Actually, they agreed to do that. The pauses stopped. But they can't see where it can be their fault, though, so now I'm required to defend MQSeries in general, and MQPUT in particular. Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: MQ Problem - Advice Needed [EMAIL PROTECTED] 10/15/2003 02:08 PM Please respond to MQSeries List Jim, If they're willing, have them turn off replication. Show them the audit numbers from your apps. Turn on replication and show them the audit numbers again. Jim Ford [EMAIL PROTECTED] To: [EMAIL PROTECTED] OM cc: Sent by: Subject: MQ Problem - Advice Needed MQSeries List [EMAIL PROTECTED] en.AC.AT 10/15/2003 02:34 PM Please respond to MQSeries List We have periodic pauses on some of our Solaris servers. CPU usage drops down to nothing for a couple of minutes, then things begin to function normally again. Many of our MQ apps on Solaris were written in the last two years, and maintain exhaustive audit trails, Those audit trails showed that their applications were waiting on an MQPUT for the entire time. Everything on the machine pauses, by the way, but it's these MQ apps that keep the audit trail. So I did some investigation, and eventually discovered that the pauses seemed to coincide with something our storage administrator was running. It is a series of commands - issued on the mainframe - which causes our SAN to replicate to our hotsite. I ran the Unix iostat command during the pauses, and sure enough, the disk service times had gone way up, then back to a couple milliseconds after. So I told the storage team about it (2 months ago!). They claim not to see any problems, and have now decided that it's an MQ problem. They want to meet with me, and have me explain what the MQPUT command is, and how it works. It seems pretty obvious that they don't intend to work on this, and are in the process of putting up a stonewall by shooting the messenger. It's much like dealing with a difficult vendor, except the fact that we work for the same company in some ways makes it even more difficult. I'd be tempted to raise hell with a vendor, but that could be a career limiting move in this case. So... I'm interested if anyone has seen a similar problem. And I'm also interested in any advice on how to get the SAN team to do the right thing and take ownership of the problem. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list
Re: MQ Problem - Advice Needed
That would be a solution. It seems unnecessary for me to have to do any further legwork on this, just to get them to take ownership of something that's so obviously their problem. Maybe I just need to vent. Arrrgh!!! There. That's better. Thomas, Don [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: MQ Problem - Advice Needed List [EMAIL PROTECTED] N.AC.AT 10/15/2003 02:30 PM Please respond to MQSeries List Doctor, doctor, it hurts when I do this. Well, don't do that anymore. But seriously, try to find other applications that are experiencing these pause also, then they would look rather foolish asking everyone to defend their apps. It's pretty apparent that whatever they are doing is hogging all of the disk i/o, and the MQPUT is definitely a disk intensive operation. Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: Jim Ford [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 3:20 PM To: [EMAIL PROTECTED] Subject: Re: MQ Problem - Advice Needed Actually, they agreed to do that. The pauses stopped. But they can't see where it can be their fault, though, so now I'm required to defend MQSeries in general, and MQPUT in particular. Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: MQ Problem - Advice Needed [EMAIL PROTECTED] 10/15/2003 02:08 PM Please respond to MQSeries List Jim, If they're willing, have them turn off replication. Show them the audit numbers from your apps. Turn on replication and show them the audit numbers again. Jim Ford [EMAIL PROTECTED] To: [EMAIL PROTECTED] OM cc: Sent by: Subject: MQ Problem - Advice Needed MQSeries List [EMAIL PROTECTED] en.AC.AT 10/15/2003 02:34 PM Please respond to MQSeries List We have periodic pauses on some of our Solaris servers. CPU usage drops down to nothing for a couple of minutes, then things begin to function normally again. Many of our MQ apps on Solaris were written in the last two years, and maintain exhaustive audit trails, Those audit trails showed that their applications were waiting on an MQPUT for the entire time. Everything on the machine pauses, by the way, but it's these MQ apps that keep the audit trail. So I did some investigation, and eventually discovered that the pauses seemed to coincide with something our storage administrator was running. It is a series of commands - issued on the mainframe - which causes our SAN to replicate to our hotsite. I ran the Unix iostat command during the pauses, and sure enough, the disk service times had gone way up, then back to a couple milliseconds after. So I told the storage team about it (2 months ago!). They claim not to see any problems, and have now decided that it's an MQ problem. They want to meet with me, and have me explain what the MQPUT command is, and how it works. It seems pretty obvious that they don't intend to work on this, and are in the process of putting up a stonewall by shooting the messenger. It's much like dealing with a difficult vendor, except the fact that we work for the same company in some ways makes it even more difficult. I'd be tempted to raise hell with a vendor, but that could be a career limiting move in this case. So... I'm interested if anyone has seen a similar problem. And I'm also interested in any advice on how to get the SAN team to do the right thing and take ownership of the problem. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at
Re: MQ Problem - Advice Needed
Well, with the exception of what Peter said about persistent messages and your logs (possibly) being on a SAN, an MQPUT returns rather quickly. If it is possible to narrow down a time frame when this happens, you might be able to do a trace of the MQ layer and determine what is going on. I get the feeling though that you are unable to predict when this happens, or re-create it at will. Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Jim Ford [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: Sent by: MQSeriesSubject: Re: MQ Problem - Advice Needed List [EMAIL PROTECTED] N.AC.AT 10/15/2003 03:20 PM Please respond to MQSeries List Actually, they agreed to do that. The pauses stopped. But they can't see where it can be their fault, though, so now I'm required to defend MQSeries in general, and MQPUT in particular. Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: MQ Problem - Advice Needed [EMAIL PROTECTED] 10/15/2003 02:08 PM Please respond to MQSeries List Jim, If they're willing, have them turn off replication. Show them the audit numbers from your apps. Turn on replication and show them the audit numbers again. Jim Ford [EMAIL PROTECTED] To: [EMAIL PROTECTED] OM cc: Sent by: Subject: MQ Problem - Advice Needed MQSeries List [EMAIL PROTECTED] en.AC.AT 10/15/2003 02:34 PM Please respond to MQSeries List We have periodic pauses on some of our Solaris servers. CPU usage drops down to nothing for a couple of minutes, then things begin to function normally again. Many of our MQ apps on Solaris were written in the last two years, and maintain exhaustive audit trails, Those audit trails showed that their applications were waiting on an MQPUT for the entire time. Everything on the machine pauses, by the way, but it's these MQ apps that keep the audit trail. So I did some investigation, and eventually discovered that the pauses seemed to coincide with something our storage administrator was running. It is a series of commands - issued on the mainframe - which causes our SAN to replicate to our hotsite. I ran the Unix iostat command during the pauses, and sure enough, the disk service times had gone way up, then back to a couple milliseconds after. So I told the storage team about it (2 months ago!). They claim not to see any problems, and have now decided that it's an MQ problem. They want to meet with me, and have me explain what the MQPUT command is, and how it works. It seems pretty obvious that they don't intend to work on this, and are in the process of putting up a stonewall by shooting the messenger. It's much like dealing with a difficult vendor, except the fact that we work for the same company in some ways makes it even more difficult. I'd be tempted to raise hell with a vendor, but that could be a career limiting move in this case. So... I'm interested if anyone has seen a similar problem. And I'm also interested in any advice on how to get the SAN team to do the right thing and take ownership of the problem. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQ Problem - Advice Needed
I had a similar problem. It was even harder to detect because the bottleneck that time was SRDF link and iowait does not show you anything meaningful when all these low level buffers are full. To investigate, it took writing a very simple C application. In pseudocode: 1. In a tight loop forever 1.0. print write started + timestamp. 1.1. Write 100M of some garbage (it better to be random) into file A. 1.2. Close file A 1.3. Delete file A 1.4. Output write finished + timestamp. Then capture the output for a period of 24 hours and find out if this simple program gives you same problems (like 2-minute delays). If your description is correct, it will. Then give it to your storage team and ask them for a cure. No MQ involved. Hopefully this will help, Pavel Jim Ford [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: Sent by: MQSeriesSubject: Re: MQ Problem - Advice Needed List [EMAIL PROTECTED] n.AC.AT 10/15/2003 03:56 PM Please respond to MQSeries List That would be a solution. It seems unnecessary for me to have to do any further legwork on this, just to get them to take ownership of something that's so obviously their problem. Maybe I just need to vent. Arrrgh!!! There. That's better. Thomas, Don [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: MQ Problem - Advice Needed List [EMAIL PROTECTED] N.AC.AT 10/15/2003 02:30 PM Please respond to MQSeries List Doctor, doctor, it hurts when I do this. Well, don't do that anymore. But seriously, try to find other applications that are experiencing these pause also, then they would look rather foolish asking everyone to defend their apps. It's pretty apparent that whatever they are doing is hogging all of the disk i/o, and the MQPUT is definitely a disk intensive operation. Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: Jim Ford [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 3:20 PM To: [EMAIL PROTECTED] Subject: Re: MQ Problem - Advice Needed Actually, they agreed to do that. The pauses stopped. But they can't see where it can be their fault, though, so now I'm required to defend MQSeries in general, and MQPUT in particular. Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: MQ Problem - Advice Needed [EMAIL PROTECTED] 10/15/2003 02:08 PM Please respond to MQSeries List Jim, If they're willing, have them turn off replication. Show them the audit numbers from your apps. Turn on replication and show them the audit numbers again. Jim Ford [EMAIL PROTECTED] To: [EMAIL PROTECTED] OM cc: Sent by: Subject: MQ Problem - Advice Needed MQSeries List [EMAIL PROTECTED] en.AC.AT 10/15/2003 02:34 PM Please respond to MQSeries List We have periodic pauses on some of our Solaris servers. CPU usage drops down to nothing for a couple of minutes, then things begin to function normally again. Many of our MQ apps on Solaris were written in the last two years, and maintain exhaustive audit trails, Those audit trails showed that their applications were waiting on an MQPUT for the entire time. Everything on the machine pauses, by the way, but it's these MQ apps that keep the audit trail. So I did some investigation, and eventually discovered that the pauses seemed to coincide with something our storage administrator was running. It is a series of commands - issued on the mainframe - which causes our SAN to replicate to our hotsite. I ran the Unix iostat command during the pauses, and sure enough, the disk service times had gone way up, then back to a couple milliseconds after. So I told the storage team about it (2 months ago!). They claim not to see any problems, and have now decided that it's an MQ problem. They want to meet with me, and have me explain what the MQPUT command is, and
Re: Penetrating an outbound firewall
Title: Penetrating an outbound firewall
Sorry,
I thought that was part of my quote at first glance.Yes, if the
channels are not protected anyone can connect to any inbound channel. The
total solution is to use an exit or SSL to restrict the inbound connections to
the appropriate channel, AND the MCAUSER to enforce the ID restrictions.
Using one or the other doesn't work.
It
bears noting that the exit or SSL used must be placedon the protected
internalchannels and is optional on the external facing channel if you
only have one. A common mistake is placing theexiton the
external-facing channel andleaving the internal-facing ones
unprotected.
--
T.Rob
-Original Message-From: Potkay, Peter M (PLC, IT)
[mailto:[EMAIL PROTECTED]Sent: Wednesday, October 15,
2003 12:37 PMTo: [EMAIL PROTECTED]Subject: Re:
Penetrating an outbound firewall
Thanks T.Rob.
What
about the channel question I had below. Am I missing something
there?
-Original Message-From: Wyatt, T. Rob
[mailto:[EMAIL PROTECTED]Sent: Wednesday, October
15, 2003 12:23 PMTo: [EMAIL PROTECTED]Subject:
Re: Penetrating an outbound firewall
No, it just means you need to specify all the parameters. If
you run a saveqmgr it prints out runmqsc commands suitable for use on a QMgr
with no SYSTEM.DEF* objects. Use these as templates for your queue
definitions if you need to add or change anything. Make sure you run
saveqmgr on the same server or at least one with a matching version of
MQ.
--
T.Rob
-Original Message-From: Potkay, Peter M (PLC,
IT) [mailto:[EMAIL PROTECTED]Sent: Wednesday,
October 15, 2003 10:08 AMTo:
[EMAIL PROTECTED]Subject: Re: Penetrating an outbound
firewall
T.Rob wrote:
"Every time I bring this up, people always reply that you can
accomplish the same thing with an exit or MCAUSER. My answer to that
is that you cannot restrict traffic to a specific channel. For
example, if you define XYZ.RCVR with MCAUSER('xyz'), there is nothing to
prevent ABC Corp from connecting to it."
If ABC corp connects to XYZ.RCVR, and XYZ.RCVR has a MCA USer
Identifier set to 'xyz', then all the messages coming across this
channelwill have xyz, even ABC's messages. How is that different
than if the ABC got to XYZ.RCVR through another listner / port? If ABC
connects XYZ.RCVR overport , where a listener is running as def,
aren't the messages still put as xyz, not def, xyz is in the
MCAUSER?
Also, you mentioned "we also delete all SYSTEM.DEF* objects". I
tried deleting SYSTEM.DEFAULT.LOCAL.QUEUE on a dummy QM, and now I cant
create any queues, which I suppose is the goal. But does that meaning that
from this point forward, I can never create any more local queues on this
QM?
-Original Message-From: Wyatt, T. Rob
[mailto:[EMAIL PROTECTED]Sent: Friday, September
05, 2003 4:44 PMTo:
[EMAIL PROTECTED]Subject: Re: Penetrating an outbound
firewall
Peter,
I've not used MQIPT so I don't know what security concerns it
addresses - or introduces. Since I work for a bank, I always start
with the assumption that my DMZ servers are targets of attack and
Itry to nail them down as tight as possible. In my shop we
would do that last paragraph regardless of any assumed security provided
by MQIPT, our firewall or private circuits.
And that's just the beginning. In the DMZ we also delete
all SYSTEM.DEF* objects, set up LOCALADDR to bind the internal-facing
channels to internal-facing NICs and run security exits (or SSL where
available). We also never use a SVR channel in the DMZ or define a
SVRCONN for external use. As a rule, the Command Server and
Trigger Monitor are turned off unless specifically required. If we
do run a trigger monitor, itruns under a low-privileged ID.
All channels use MCAUSER set to a low-privileged ID. The QMgr runs
under an ID other than mqm and mqm is removed from the mqm group.
UserIDs in the DMZ are never authorized to SET*. All of these
configurations address one or more specific vulnerabilities and when you
apply all of them in combination, it is VERY difficult to get admin
access to the QMgr from outside or to hijack queues and channels for
other than their intended use.
Incidentally, you mentioned a dedicated QMgr "for outbound
messaging (to other companies)" and I notice that's plural. Are
you hosting interfaces tomore than one company on the same
QMgr? In that case, I would DEFINITELY want to lock down each
interface under a separate ID. Can you imagine the
Building an API exit on Solaris
I am trying to get MQ to run my API exit, written in C++ (it's a hacked version of the sample amqsaxe0.c). It works fine under Windows. I am using the following to build the .so file: CC -mt mqAPIExit.cpp -G -o mqAPIExit.so -lmqmzf -lmqm -lmqmcs -lmqmzse and no errors are generated, and the output is generated. I have added the following to qm.ini: ApiExitLocal: Sequence=100 Function=EntryPoint Module=/var/mqm/exits/mqAPIExit.so Name=mqAPIExit Data=16 But when I try to start the qmgr I get the following: [EMAIL PROTECTED]:/var/mqm/trace]$ strmqm TEST AMQ7214: The module '/var/mqm/exits/mqAPIExit.so' for Api Exit 'mqAPIExit' could not be loaded for reason xecU_S_LOAD_FAILED. I have tried running an early trace, but all the trace files give me is the same return code info, so I am suspecting that my build is not good. Any help/comments appreciated, Regards, 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
Re: MQ Problem - Advice Needed
There's SRDF involved here too. What was the problem? I think I will take your advice and write a tiny C program like you recommend. We could probably find one of our non-MQ applications that encountered the problem. But all of our applications will have something besides basic file access involved, like network, Oracle, etc. The SAN people would be sure to use that as an excuse to not take over the problem. Simpler is better. Pavel Tolkachev pavel.tolkachev@To: [EMAIL PROTECTED] DB.COM cc: Sent by: MQSeriesSubject: Re: MQ Problem - Advice Needed List [EMAIL PROTECTED] N.AC.AT 10/15/2003 03:47 PM Please respond to MQSeries List I had a similar problem. It was even harder to detect because the bottleneck that time was SRDF link and iowait does not show you anything meaningful when all these low level buffers are full. To investigate, it took writing a very simple C application. In pseudocode: 1. In a tight loop forever 1.0. print write started + timestamp. 1.1. Write 100M of some garbage (it better to be random) into file A. 1.2. Close file A 1.3. Delete file A 1.4. Output write finished + timestamp. Then capture the output for a period of 24 hours and find out if this simple program gives you same problems (like 2-minute delays). If your description is correct, it will. Then give it to your storage team and ask them for a cure. No MQ involved. Hopefully this will help, Pavel Jim Ford [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: Sent by: MQSeriesSubject: Re: MQ Problem - Advice Needed List [EMAIL PROTECTED] n.AC.AT 10/15/2003 03:56 PM Please respond to MQSeries List That would be a solution. It seems unnecessary for me to have to do any further legwork on this, just to get them to take ownership of something that's so obviously their problem. Maybe I just need to vent. Arrrgh!!! There. That's better. Thomas, Don [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: MQ Problem - Advice Needed List [EMAIL PROTECTED] N.AC.AT 10/15/2003 02:30 PM Please respond to MQSeries List Doctor, doctor, it hurts when I do this. Well, don't do that anymore. But seriously, try to find other applications that are experiencing these pause also, then they would look rather foolish asking everyone to defend their apps. It's pretty apparent that whatever they are doing is hogging all of the disk i/o, and the MQPUT is definitely a disk intensive operation. Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] -Original Message- From: Jim Ford [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 3:20 PM To: [EMAIL PROTECTED] Subject: Re: MQ Problem - Advice Needed Actually, they agreed to do that. The pauses stopped. But they can't see where it can be their fault, though, so now I'm required to defend MQSeries in general, and MQPUT in particular. Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: MQ Problem - Advice Needed [EMAIL PROTECTED] 10/15/2003 02:08 PM Please respond to MQSeries List Jim, If they're willing, have them turn off replication. Show them the audit numbers from your apps. Turn on replication and show them the audit numbers again. Jim Ford [EMAIL PROTECTED] To: [EMAIL PROTECTED] OM cc: Sent by: Subject: MQ Problem - Advice Needed MQSeries List [EMAIL PROTECTED] en.AC.AT 10/15/2003 02:34 PM Please respond to MQSeries List We have periodic pauses on some of our Solaris servers. CPU usage drops down to nothing for a couple of minutes, then things begin to function normally
Clustering not working
Howdy all, I am trying to get two linux MQ server working as a cluster but I am having odd rersults The 2 machines are called MQMDEV and QMLMQM2 and both are full repositories, the cluster is called MQLINK. I have two channels defined between the two machines: on MQMDEV define channel(LINK_TO_MQMDEV) chltype(CLUSRCVR) trptype(TCP) conname(mqmdev.qml.com.au) cluster(MQLINK) define channel(LINK_TO_QMLMQM2) chltype(CLUSSDR) trptype(TCP) conname(qmlmqm2.qml.com.au) cluster(MQLINK) on QMLMQM2 define channel(LINK_TO_QMLMQM2) chltype(CLUSRCVR) trptype(TCP) conname(qmlmqm2.qml.com.au) cluster(MQLINK) define channel(LINK_TO_MQMDEV) chltype(CLUSSDR) trptype(TCP) conname(mqmdev.qml.com.au) cluster(MQLINK) I have a SRVCONN channel called qml on each. I have 2 test queues: sid.test.queue on QMLMQM2 and sid.test.dev on MQMDEV (both have MQLINK in the cluster name) Now When I open up a client session on a Win2K workstation with a server connection channel to each machine and get and put from the queue hosted on the machine I can get and put without error. If I put to a queue hosted on the other machine I get the following: C:\MQClient\binset MQSERVER=qml/TCP/qmlmqm2.qml.com.au C:\MQClient\binamqsputc sid.test.dev Sample AMQSPUT0 start target queue is sid.test.dev MQOPEN ended with reason code 2085 unable to open queue for output Sample AMQSPUT0 end Any thoughts anyoneplease! Sid Young Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
