Re: JAVA client and reason code 2085 (unknown object)
We are using BMC Patrol for Websphere MQ for monitoring and administration. Janet Dye Infrastructure Systems Engineer - Middleware UMB Bank, n.a. 1008 Oak Street - Mailstop 1170305 Kansas City, MO. 64106 office: 816-860-1109 cell : 816-686-1544 -Original Message- From: Christopher Warneke [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 12:31 PM To: [EMAIL PROTECTED] Subject: Re: JAVA client and reason code 2085 (unknown object) What do you use for administration tools? --- MQ Mailbox <[EMAIL PROTECTED]> wrote: > We have several JAVA client applications running in > our production > environment. Every once in awhile I receive a MQ > event for 2085, > unknown object, with the object name as blank and > the application as > 'MQSeries Client for Java'. Other events that I > have seen for a client > app would have a name of an executable instead of > 'MQSeries Client for > Java'. Nowhere on the event record is there a > username or something > else that would help me to determine where that > client is coming from. > Looking in the AMQERR01.LOG files in > /var/mqm/errors, > /var/mqm/qmgr/@SYSTEM/errors and > /var/mqm/qmgr/QMNAME, I don't see > anything. As far as the connected SVRCONN channels, > I don't see any > that look suspicious. I don't know if an production application is > having an occasional problem, or if someone is > playing in production. > Anyone have any ideas on how to determine the origin > of this client. > > Thanks > > Janet Dye > Infrastructure Systems Engineer - Middleware > UMB Bank, n.a. > 1008 Oak Street - Mailstop 1170305 > Kansas City, MO. 64106 > office: 816-860-1109 > cell : 816-686-1544 > > Instructions for managing your mailing list > 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
Unsubscribe
= Esta mensagem pode conter informação confidencial e/ou privilegiada. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, não deverá utilizar, copiar, alterar, divulgar a informação nela contida ou tomar qualquer ação baseada nessas informações. Se você recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperação. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, change, take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. =
A backup/recovery solution for WebSphere MQ for z/OS using a volu me flash copy
Hello, I am working on a backup/recovery solution for WebSphere MQ for z/OS. At our shop we are already doing a volume (DASD) flash copy backup. The DB2 system programmers use the SUSPEND, RESUME commands before and after the flash copy to allow in-flight transactions to commit and to block any new transaction to access DB2. Are there similar commands for MQ, which will suspend any I/O operation to the PAGESETS or to MQ as a whole until the flash copy is ended? I know there is the ARCHIVE LOG command, but this command seems to deal only the MQ active log data sets. Thanks,... Mohamed This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message.
iSeries AS/400 OS/400. What does ENDCCTJOB(*YES) on ENDMQM do?
On the AS/400. What does ENDCCTJOB(*YES) on ENDMQM do? The iSeries Admin Guide gives examples using it but does not tell what it does. I found a few APARs that describe bug fixes to the option. Script (MQSC) Command Reference does not mention it. I cannot find where the option ENDCCTJOB is decsribed. Maybe somebody has an info APAR? _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
FW: iSeries AS/400 OS/400. What does ENDCCTJOB(*YES) on ENDMQM do ?
Title: FW: iSeries AS/400 OS/400. What does ENDCCTJOB(*YES) on ENDMQM do? Specifies whether or not all processes connected to the queue manager are forcibly terminated. The possible values are: *NO The queue manager or queue managers will be ended but no further action is taken. *YES The following steps are taken for each queue manager to be ended: All channels (except Receiver, Client-connection and Cluster-receiver channels) defined for the queue manager are stopped. Media images for all objects defined for the queue manager are recorded. The queue manager is ended in the appropriate manner (*CNTRLD, *WAIT, or *IMMED). Any processes still connected to the queue manager are terminated. All shared memory and semaphores used by the queue manager are deleted. If MQMNAME(*ALL) was specified and all queue managers are in an INACTIVE state, global shared memory and semaphores are deleted. -Original Message- From: Larry Hendersen [mailto:[EMAIL PROTECTED]] Sent: Friday, September 03, 2004 10:01 AM To: [EMAIL PROTECTED] Subject: iSeries AS/400 OS/400. What does ENDCCTJOB(*YES) on ENDMQM do? On the AS/400. What does ENDCCTJOB(*YES) on ENDMQM do? The iSeries Admin Guide gives examples using it but does not tell what it does. I found a few APARs that describe bug fixes to the option. Script (MQSC) Command Reference does not mention it. I cannot find where the option ENDCCTJOB is decsribed. Maybe somebody has an info APAR? _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ Instructions for managing your mailing list 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: A backup/recovery solution for WebSphere MQ for z/OS using a volu me flash copy
Look at the ARCHIVE LOG MODE(QUIESCE) command. "It creates a system-wide point of consistency..." Middleware Group Mailbox <[EMAIL PROTECTED] To > [EMAIL PROTECTED] Sent by: MQSeries cc List <[EMAIL PROTECTED] Subject n.AC.AT> A backup/recovery solution for WebSphere MQ for z/OS using a volu me flash copy 09/03/2004 09:45 AM Please respond to MQSeries List <[EMAIL PROTECTED] n.AC.AT> Hello, I am working on a backup/recovery solution for WebSphere MQ for z/OS. At our shop we are already doing a volume (DASD) flash copy backup. The DB2 system programmers use the SUSPEND, RESUME commands before and after the flash copy to allow in-flight transactions to commit and to block any new transaction to access DB2. Are there similar commands for MQ, which will suspend any I/O operation to the PAGESETS or to MQ as a whole until the flash copy is ended? I know there is the ARCHIVE LOG command, but this command seems to deal only the MQ active log data sets. Thanks,... Mohamed This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Large message size support on MQSeries
Hi All, >From what I read, that MQ supports upto 100mb for single message. It seems there is option for segmentation, Does that mean it supports over 100mb if using the segmatation option? Thank you very much!! Yan 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
Re: Connecting to more than one queue managers on solaris, linux
Thanks eugene, Probably, not in 5.3. This is the error we are getting on Solaris: 2103( MQRC_ANOTHER_Q_MGR_CONNECTED) Child processes would be one option -- but it was decided against it for non-MQ-related reasons. Thanks, Pavel eugene rosenberg <[EMAIL PROTECTED]To: [EMAIL PROTECTED] .COM>cc: Sent by: MQSeriesSubject: Re: Connecting to more than one queue managers on solaris, linux List <[EMAIL PROTECTED] n.AC.AT> 09/02/2004 08:46 PM Please respond to MQSeries List Pavel, It was always possible to have connections to various queue managers from UNIX child processes (still one connection per child process) and I did it myself. In the best of my knowledge starting with V5.2 it became possible to have the same type of connections from threads. Even I did not try it myself I am using products that are multithreaded and each thread has it is own connection. In some cases the number of threads is directly defined by the number of local queue managers. Eugene --- Pavel Tolkachev <[EMAIL PROTECTED]> wrote: > Well, for a loopback interface (I mean, when client > connects to localhost or 127.0.0.1), it should not > call real network drivers. I think it uses some > platform-specific IPCs (on solaris, probably streams > -- I believe both pipes and local sockets use same > underlying mechanisms, on very old Unices it were > mbufs) -- and should not be really heavy... > Although, the latency will increase due to the agent > and some overhead will still be there.. Even when > real IP is used, smart TCP stack must not hit the > network for local connections. > > Just thinking aloud.. I have never really tested it > with MQ but I did some performance testing with > locally bound TCP sockets -- as long as all socket > options were set right (especially TCP_NDELAY), the > overhead became negligible. Hopefully, IBM got it > right :-). > > Just my 2c > Pavel > > > > > "Miller, Dennis" > <[EMAIL PROTECTED]To: > [EMAIL PROTECTED] > OM> cc: > Sent by: MQSeries > Subject: Re: Connecting to more than one queue > managers on solaris, linux > List > <[EMAIL PROTECTED] > n.AC.AT> > > > 09/01/2004 02:39 > PM > Please respond to > MQSeries List > > > > > > > The client connection has a performance > disadvantage, mostly because of > network overhead. After all, every API request (and > any messages it > conveys) must pass over the network to get between > the MQ client and the > qmgr. The server channel agent, acting on behalf of > the client, uses > local bindings and should experience about the same > performance as the > application using local bindings. But the exchange > of API requests > between the MQ client and the server channel agent > is extra work. > > I am not in a position to quantify it, though, and I > expect it would > depend greatly on your network configuration. > > > -Original Message- > From: Gurney, Matthew > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 01, 2004 12:48 AM > To: [EMAIL PROTECTED] > Subject: Re: Connecting to more than one queue > managers on solaris, > linux > > > What would the performance difference of using > MQClient connections to > connect to a local Queue manager on the same Unix > host, compared to > using a local bindings direct connection to the > local Queue manager. I > understand that for Pavel's situation, this be be > irrelevant, but I am > concerned with the general case? > > Matt. > > -Original Message- > From: MQSeries List > [mailto:[EMAIL PROTECTED] Behalf Of Miller, > Dennis > Sent: 01 September 2004 01:13 > To: [EMAIL PROTECTED] > Subject: Re: Connecting to more than one queue > managers on solaris, > linux > > > I understand your hesitance to use MQ client for > such an app. But think > about what you are really asking. An app on one > server with MQM > credentials for other servers? An app on one server > with access to MQM > internals on another server? Hmmm... > > I'm sure you know that without MQ-Client, you cannot > even connect to a > single QMgr across servers, much less multitudes of > them. So, if your > thinking about monitoring even one qmgr by an app > running on a different > system, you are talking about some sort of client > model, by definition. > > But it needn't necessarily be the MQ client. You > could for example, > write a monitoring agent and run it locally on each > qmgr. The user > interface for your monitoring app is then a client > to these agents, >
Re: Large message size support on MQSeries
Yes, a single message segment can be 100mb. Using segmentation only your receiving program would be the limiting factor in message size. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Yan Sent: Friday, September 03, 2004 9:31 AM To: [EMAIL PROTECTED] Subject: Large message size support on MQSeries Hi All, >From what I read, that MQ supports upto 100mb for single message. It seems there is option for segmentation, Does that mean it supports over 100mb if using the segmatation option? Thank you very much!! Yan 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: Large message size support on MQSeries
Yes, but MQ on 390 doesn't support segmentation (though MQ 5.3 390 does support message grouping which can just about achieve a similar function) Also consider the impact on the system that very large messages may have especially when going between QMs over channels (may need to have separate xmit queues and channels just for large messages so you don't block the small ones). Also what will the storage use be for the MCA (CHIN) when handling messages this size. Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Zhang, Yan Sent: 03 September 2004 15:31 To: [EMAIL PROTECTED] Subject: Large message size support on MQSeries Hi All, >From what I read, that MQ supports upto 100mb for single message. It seems there is option for segmentation, Does that mean it supports over 100mb if using the segmatation option? Thank you very much!! Yan 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: Large message size support on MQSeries
Alan , thanks ! Does MQ support straming on solaris? If it does, sending program could steaming in to the queue and The receiving program could steaming out to disk. That way the limit is the disk. Am I right? Yan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bender, Alan Sent: Friday, September 03, 2004 10:41 AM To: [EMAIL PROTECTED] Subject: Re: Large message size support on MQSeries Yes, a single message segment can be 100mb. Using segmentation only your receiving program would be the limiting factor in message size. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Yan Sent: Friday, September 03, 2004 9:31 AM To: [EMAIL PROTECTED] Subject: Large message size support on MQSeries Hi All, >From what I read, that MQ supports upto 100mb for single message. It seems there is option for segmentation, Does that mean it supports over 100mb if using the segmatation option? Thank you very much!! Yan 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 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
Derick Browne/CanWest/IBM is out of the office.
I will be out of the office starting 09/03/2004 and will not return until 09/23/2004. I will respond to your message when I return.Backup persons are Joan Barton 790-5389 Robert Frei 790-5136 Lyle Mack 790-5375 Gord Thomson 790-5148 Jason Carroll 790-5131 ISM HelpDesk 781-8488 Instructions for managing your mailing list 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: Large message size support on MQSeries
Yan,
Just to add a bit more to that, prior to 5.1 (I think) there was a 4MB limit
to the size of a message. With 5.1 the possibility was introduced to
segment messages. You can pass a single buffer into WMQ of what ever size,
and WMQ will automatically split the message into segments to the limit of
the message size. You can then also get the receiving programme to wait
until all segments of the message have been delivered and then re-assemble
the multiple messages into a single message buffer on MQGET. Alternatively
you can get you application to read a large buffer in record chunks and
write each of those chunks as a separate message.
You can also to an equivalent by using application groups of messages, with
the receiver waiting until all messages in the group have arrived, reading
each message in the group in the right order (and ignoring any other
messages that might lie in between individual members of the group) and
signal which message is the last message in the group.
The challenge with very large messages is load on the transaction log. The
latter mechanism can support messages being send one message per transaction
or using transaction processing with periodic commits of a sub-set of
messages (though all groups must use the same transaction model), reducing
the impact on the maximum size of the log containing uncommitted records.
Its actually all quite will documented in the programmers guide /
programmers reference, so write a little hello world to try the techniques
out.
Nick
-Original Message-
From: Zhang, Yan [mailto:[EMAIL PROTECTED]
Sent: 03 September 2004 15:31
To: [EMAIL PROTECTED]
Subject: Large message size support on MQSeries
Hi All,
>From what I read, that MQ supports upto 100mb for single message. It seems
there is option for segmentation,
Does that mean it supports over 100mb if using the segmatation option?
Thank you very much!!
Yan
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
*
This message contains privileged and confidential information intended
only for the use of the recipient named above. Its contents do not
constitute a commitment by Strategic Thought Limited ("Strategic
Thought") unless separately endorsed by an authorised representative
of Strategic Thought.
Any use, dissemination, distribution, reproduction or unauthorised
disclosure of this message is prohibited. If you receive this message
in error, please notify the sender immediately and delete it from your
computer systems.
Any views expressed in this message are those of the individual sender
and may not necessarily reflect those of Strategic Thought.
Strategic Thought believes this e-mail and any attachments to be virus
free. However, the recipient is responsible for ensuring it is virus
free and Strategic Thought do not accept any responsibility for any
loss or damage howsoever caused from use of this e-mail, attachments
or contents.
*
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
assigning a port when creating a broker
Hello everyone. I'm a newbie here (with MQSeries anyway). When creating a new broker (our environment is on AIX), when do you assign the port that the broker will use? The command we use goes like this: mqsicreatebroker -i -a -q -n -u -p I don't see where the port is specified. Thanks, -Patrick. Instructions for managing your mailing list 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: assigning a port when creating a broker
The port is assigned to the queue manager that the broker is attached to.. Thanks, Dennis Bryngelson Phone: (763) 765-4224 Fax: (763) 765-3820 mailto:[EMAIL PROTECTED] |-+> | | Patrick Reeder | | | <[EMAIL PROTECTED]| | | RG> | | | Sent by: MQSeries| | | List | | | <[EMAIL PROTECTED]| | | N.AC.AT> | | || | || | | 09/03/2004 10:15 | | | AM | | | Please respond to| | | MQSeries List| | || |-+> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: assigning a port when creating a broker | >--| Hello everyone. I'm a newbie here (with MQSeries anyway). When creating a new broker (our environment is on AIX), when do you assign the port that the broker will use? The command we use goes like this: mqsicreatebroker -i -a -q -n -u -p I don't see where the port is specified. Thanks, -Patrick. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive * PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/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 e-mail, 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: Large message size support on MQSeries
Thank you so much!
I will write a client to test this out. We are using MQ5.3 on Solaris.
The potential customer's data is up to 400mb and is compressed. They are
using FTP right now, and often times out. They want try MQ.
Thanks,
Yan
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Nick
Denning
Sent: Friday, September 03, 2004 11:04 AM
To: [EMAIL PROTECTED]
Subject: Re: Large message size support on MQSeries
Yan,
Just to add a bit more to that, prior to 5.1 (I think) there was a 4MB limit
to the size of a message. With 5.1 the possibility was introduced to
segment messages. You can pass a single buffer into WMQ of what ever size,
and WMQ will automatically split the message into segments to the limit of
the message size. You can then also get the receiving programme to wait
until all segments of the message have been delivered and then re-assemble
the multiple messages into a single message buffer on MQGET. Alternatively
you can get you application to read a large buffer in record chunks and
write each of those chunks as a separate message.
You can also to an equivalent by using application groups of messages, with
the receiver waiting until all messages in the group have arrived, reading
each message in the group in the right order (and ignoring any other
messages that might lie in between individual members of the group) and
signal which message is the last message in the group.
The challenge with very large messages is load on the transaction log. The
latter mechanism can support messages being send one message per transaction
or using transaction processing with periodic commits of a sub-set of
messages (though all groups must use the same transaction model), reducing
the impact on the maximum size of the log containing uncommitted records.
Its actually all quite will documented in the programmers guide /
programmers reference, so write a little hello world to try the techniques
out.
Nick
-Original Message-
From: Zhang, Yan [mailto:[EMAIL PROTECTED]
Sent: 03 September 2004 15:31
To: [EMAIL PROTECTED]
Subject: Large message size support on MQSeries
Hi All,
>From what I read, that MQ supports upto 100mb for single message. It seems
there is option for segmentation, Does that mean it supports over 100mb if
using the segmatation option?
Thank you very much!!
Yan
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
*
This message contains privileged and confidential information intended only
for the use of the recipient named above. Its contents do not constitute a
commitment by Strategic Thought Limited ("Strategic
Thought") unless separately endorsed by an authorised representative of
Strategic Thought.
Any use, dissemination, distribution, reproduction or unauthorised
disclosure of this message is prohibited. If you receive this message in
error, please notify the sender immediately and delete it from your computer
systems.
Any views expressed in this message are those of the individual sender and
may not necessarily reflect those of Strategic Thought.
Strategic Thought believes this e-mail and any attachments to be virus free.
However, the recipient is responsible for ensuring it is virus free and
Strategic Thought do not accept any responsibility for any loss or damage
howsoever caused from use of this e-mail, attachments or contents.
*
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
The 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
Re: Large message size support on MQSeries
Yan, With MQ you get all of the message or none of the message so streaming data is not an option. As others have pointed out the documentation on this is very good. And there seem to be some very good people who have lots more experience with MQ than I do, I'd listen to them first. Personally I find many smaller messages process faster and better than one very LARGE message. But that's just me. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Yan Sent: Friday, September 03, 2004 9:55 AM To: [EMAIL PROTECTED] Subject: Re: Large message size support on MQSeries Alan , thanks ! Does MQ support straming on solaris? If it does, sending program could steaming in to the queue and The receiving program could steaming out to disk. That way the limit is the disk. Am I right? Yan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bender, Alan Sent: Friday, September 03, 2004 10:41 AM To: [EMAIL PROTECTED] Subject: Re: Large message size support on MQSeries Yes, a single message segment can be 100mb. Using segmentation only your receiving program would be the limiting factor in message size. Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Yan Sent: Friday, September 03, 2004 9:31 AM To: [EMAIL PROTECTED] Subject: Large message size support on MQSeries Hi All, >From what I read, that MQ supports upto 100mb for single message. It seems there is option for segmentation, Does that mean it supports over 100mb if using the segmatation option? Thank you very much!! Yan 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 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: assigning a port when creating a broker
Patrick, the port is assigned to the queue manager vs the broker. Since mq is handling the traffic, and is using the server connection, it has no need to worry about which port is used.That is something you manage in the queue manager setup Glen Larson Zurich NA Patrick Reeder <[EMAIL PROTECTED]>@AKH-Wien.AC.AT> on 09/03/2004 10:15:34 AM Please respond to MQSeries List <[EMAIL PROTECTED]> Sent by:MQSeries List <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:assigning a port when creating a broker Hello everyone. I'm a newbie here (with MQSeries anyway). When creating a new broker (our environment is on AIX), when do you assign the port that the broker will use? The command we use goes like this: mqsicreatebroker -i -a -q -n -u -p I don't see where the port is specified. Thanks, -Patrick. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. Instructions for managing your mailing list 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: JAVA client and reason code 2085 (unknown object)
Thanks, I am looking into those exits. Janet Dye Infrastructure Systems Engineer - Middleware UMB Bank, n.a. 1008 Oak Street - Mailstop 1170305 Kansas City, MO. 64106 office: 816-860-1109 cell : 816-686-1544 -Original Message- From: Wyatt, T Rob [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 8:19 AM To: [EMAIL PROTECTED] Subject: Re: JAVA client and reason code 2085 (unknown object) Janet, You might want to look at the BlockIP2 or LogIP channel exits. They can tell you where your SVRCONN channels are originating. That might help you correlate the events with the specific clients causing them. See: http://www.mrmq.dk/index.htm?BlockIP.htm -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of MQ Mailbox Sent: Wednesday, September 01, 2004 4:48 PM To: [EMAIL PROTECTED] Subject: JAVA client and reason code 2085 (unknown object) We have several JAVA client applications running in our production environment. Every once in awhile I receive a MQ event for 2085, unknown object, with the object name as blank and the application as 'MQSeries Client for Java'. Other events that I have seen for a client app would have a name of an executable instead of 'MQSeries Client for Java'. Nowhere on the event record is there a username or something else that would help me to determine where that client is coming from. Looking in the AMQERR01.LOG files in /var/mqm/errors, /var/mqm/qmgr/@SYSTEM/errors and /var/mqm/qmgr/QMNAME, I don't see anything. As far as the connected SVRCONN channels, I don't see any that look suspicious. I don't know if an production application is having an occasional problem, or if someone is playing in production. Anyone have any ideas on how to determine the origin of this client. Thanks Janet Dye Infrastructure Systems Engineer - Middleware UMB Bank, n.a. 1008 Oak Street - Mailstop 1170305 Kansas City, MO. 64106 office: 816-860-1109 cell : 816-686-1544 Instructions for managing your mailing list 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: FW: iSeries AS/400 OS/400. What does ENDCCTJOB(*YES) on ENDMQM do ?
Thanks for the info. I do appreciate it. Where did you find it? From: "Kinnaird, John" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: FW: iSeries AS/400 OS/400. What does ENDCCTJOB(*YES) on ENDMQM do ? Date: Fri, 3 Sep 2004 10:13:08 -0400 Specifies whether or not all processes connected to the queue manager are forcibly terminated. The possible values are: *NO The queue manager or queue managers will be ended but no further action is taken. *YES The following steps are taken for each queue manager to be ended: All channels (except Receiver, Client-connection and Cluster-receiver channels) defined for the queue manager are stopped. Media images for all objects defined for the queue manager are recorded. The queue manager is ended in the appropriate manner (*CNTRLD, *WAIT, or *IMMED). Any processes still connected to the queue manager are terminated. All shared memory and semaphores used by the queue manager are deleted. If MQMNAME(*ALL) was specified and all queue managers are in an INACTIVE state, global shared memory and semaphores are deleted. -Original Message- From: Larry Hendersen [mailto:[EMAIL PROTECTED] Sent: Friday, September 03, 2004 10:01 AM To: [EMAIL PROTECTED] Subject: iSeries AS/400 OS/400. What does ENDCCTJOB(*YES) on ENDMQM do? On the AS/400. What does ENDCCTJOB(*YES) on ENDMQM do? The iSeries Admin Guide gives examples using it but does not tell what it does. I found a few APARs that describe bug fixes to the option. Script (MQSC) Command Reference does not mention it. I cannot find where the option ENDCCTJOB is decsribed. Maybe somebody has an info APAR? _ Is your PC infected? Get a FREE online computer virus scan from McAfee. Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Unsubscribe
unsubscribe = Esta mensagem pode conter informação confidencial e/ou privilegiada. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, não deverá utilizar, copiar, alterar, divulgar a informação nela contida ou tomar qualquer ação baseada nessas informações. Se você recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperação. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, change, take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. =
Re: FW: iSeries AS/400 OS/400. What does ENDCCTJOB(*YES) on ENDMQ M do ?
Title: RE: FW: iSeries AS/400 OS/400. What does ENDCCTJOB(*YES) on ENDMQM do ? I just typed the command, did F4 to prompt, then tabbed to the ENDCCTJOB field, and hit F1 for Help. Every command on the iSeries (AS/400) has help behind the commands to explain the different parameters, sometimes not too well, but most of the time, it's sufficient. ;>) John. -Original Message- From: Larry Hendersen [mailto:[EMAIL PROTECTED]] Sent: Friday, September 03, 2004 2:43 PM To: [EMAIL PROTECTED] Subject: Re: FW: iSeries AS/400 OS/400. What does ENDCCTJOB(*YES) on ENDMQM do ? Thanks for the info. I do appreciate it. Where did you find it? >From: "Kinnaird, John" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: FW: iSeries AS/400 OS/400. What does ENDCCTJOB(*YES) on ENDMQM do > ? >Date: Fri, 3 Sep 2004 10:13:08 -0400 > >Specifies whether or not all processes connected to the queue manager >are forcibly terminated. > >The possible values are: > >*NO > The queue manager or queue managers will be ended but no further > action is taken. > >*YES > The following steps are taken for each queue manager to be > ended: > > All channels (except Receiver, Client-connection and > Cluster-receiver channels) defined for the queue manager are > stopped. > > Media images for all objects defined for the queue manager > are recorded. > > The queue manager is ended in the appropriate manner > (*CNTRLD, *WAIT, or *IMMED). > > Any processes still connected to the queue manager are > terminated. > > All shared memory and semaphores used by the queue manager > are deleted. > > If MQMNAME(*ALL) was specified and all queue managers are in > an INACTIVE state, global shared memory and semaphores are > deleted. > >-Original Message- >From: Larry Hendersen [mailto:[EMAIL PROTECTED]] >Sent: Friday, September 03, 2004 10:01 AM >To: [EMAIL PROTECTED] >Subject: iSeries AS/400 OS/400. What does ENDCCTJOB(*YES) on ENDMQM do? > > >On the AS/400. What does ENDCCTJOB(*YES) on ENDMQM do? The iSeries >Admin Guide gives examples using it but does not tell what it does. I >found a few APARs that describe bug fixes to the option. Script (MQSC) >Command Reference does not mention it. > >I cannot find where the option ENDCCTJOB is decsribed. Maybe somebody >has an info APAR? > _ Is your PC infected? Get a FREE online computer virus scan from McAfee. Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 Instructions for managing your mailing list 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: Connecting to more than one queue managers on solaris, linux
But I understood the question was restricted to an application writing to a local queue using local bindings vrs client bindings (i.e., no transmission queue involved). In that case, I think local bindings would always have a performance advantage. The situation for a distributed environment would be much different. And, yes, yes, really tricky. You'd more-often-than-not need to take measurements to know for sure. -Original Message- From: eugene rosenberg [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 5:57 PM To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux Dennis, It is really tricky to compare client/server performance with server/server performance. I agree that each application MQ client call would lose in performance compare with application MQ server call but I believe that the total throughput is better with the client/server communication because the number of I/O is low. The message is going directly to destination queue within client/server without be placed and retrieve on/from transmission queue. Eugene --- "Miller, Dennis" <[EMAIL PROTECTED]> wrote: > The client connection has a performance > disadvantage, mostly because of > network overhead. After all, every API request (and > any messages it > conveys) must pass over the network to get between > the MQ client and the > qmgr. The server channel agent, acting on behalf of > the client, uses > local bindings and should experience about the same performance as the > application using local bindings. But the exchange > of API requests > between the MQ client and the server channel agent > is extra work. > > I am not in a position to quantify it, though, and I > expect it would > depend greatly on your network configuration. > > > -Original Message- > From: Gurney, Matthew > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 01, 2004 12:48 AM > To: [EMAIL PROTECTED] > Subject: Re: Connecting to more than one queue > managers on solaris, > linux > > > What would the performance difference of using > MQClient connections to > connect to a local Queue manager on the same Unix > host, compared to > using a local bindings direct connection to the > local Queue manager. I > understand that for Pavel's situation, this be be > irrelevant, but I am > concerned with the general case? > > Matt. > > -Original Message- > From: MQSeries List > [mailto:[EMAIL PROTECTED] Behalf Of Miller, > Dennis > Sent: 01 September 2004 01:13 > To: [EMAIL PROTECTED] > Subject: Re: Connecting to more than one queue > managers on solaris, > linux > > > I understand your hesitance to use MQ client for > such an app. But think > about what you are really asking. An app on one > server with MQM > credentials for other servers? An app on one server > with access to MQM > internals on another server? Hmmm... > > I'm sure you know that without MQ-Client, you cannot > even connect to a > single QMgr across servers, much less multitudes of > them. So, if your > thinking about monitoring even one qmgr by an app > running on a different > system, you are talking about some sort of client > model, by definition. > > But it needn't necessarily be the MQ client. You > could for example, > write a monitoring agent and run it locally on each > qmgr. The user > interface for your monitoring app is then a client > to these agents, > requesting services and receiving replies from them. > If you are > so-inclined, you can even conduct the request/reply > exchanges using > local connections and MQ messages (although, > depending on what you are > doing, one might question the wisdom of running a > monitoring application > in-band like that). > > It is somewhat analagous to how the command server > works, only > customized to your specific requirements. > > > > > -Original Message- > From: Pavel Tolkachev > [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 31, 2004 1:31 PM > To: [EMAIL PROTECTED] > Subject: Re: Connecting to more than one queue > managers on solaris, > linux > > > Thanks Dennis, > > This is a low-level monitoring application > (requiring mqm credentials, > by the way). Making it an MQ client makes running > listener or configured > a pre-requisite to operate the app even if there is > no business purpose > for them to be there and creates a whole number of > security issues with > the too-far-going implications of their possible > solutions. I will have > to either live with these consequences or go for > running several > instances of the app instead (which is not ideal for > my cause, > either..). > > Pavel > > > > > > "Miller, Dennis" > <[EMAIL PROTECTED]To: > [EMAIL PROTECTED] > OM> cc: > Sent by: MQSeries > Subject: Re: Connecting > to more than one queue managers on solaris, linux > List > <[EMAIL PROTECTED
Re: Connecting to more than one queue managers on solaris, linux
Agree --- "Miller, Dennis" <[EMAIL PROTECTED]> wrote: > But I understood the question was restricted to an > application writing > to a local queue using local bindings vrs client > bindings (i.e., no > transmission queue involved). In that case, I think > local bindings would > always have a performance advantage. The situation > for a distributed > environment would be much different. And, yes, yes, > really tricky. You'd > more-often-than-not need to take measurements to > know for sure. > > -Original Message- > From: eugene rosenberg [mailto:[EMAIL PROTECTED] > > Sent: Thursday, September 02, 2004 5:57 PM > To: [EMAIL PROTECTED] > Subject: Re: Connecting to more than one queue > managers on solaris, > linux > > > Dennis, > It is really tricky to compare client/server > performance with server/server performance. I agree > that each application MQ client call would lose in > performance compare with application MQ server call > but I believe that the total throughput is better > with > the client/server communication because the number > of > I/O is low. The message is going directly to > destination queue within client/server without be > placed and retrieve on/from transmission queue. > > Eugene > > --- "Miller, Dennis" <[EMAIL PROTECTED]> wrote: > > > The client connection has a performance > > disadvantage, mostly because of > > network overhead. After all, every API request > (and > > any messages it > > conveys) must pass over the network to get between > > the MQ client and the > > qmgr. The server channel agent, acting on behalf > of > > the client, uses > > local bindings and should experience about the > same performance as the > > application using local bindings. But the exchange > > of API requests > > between the MQ client and the server channel agent > > is extra work. > > > > I am not in a position to quantify it, though, and > I > > expect it would > > depend greatly on your network configuration. > > > > > > -Original Message- > > From: Gurney, Matthew > > [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, September 01, 2004 12:48 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Connecting to more than one queue > > managers on solaris, > > linux > > > > > > What would the performance difference of using > > MQClient connections to > > connect to a local Queue manager on the same Unix > > host, compared to > > using a local bindings direct connection to the > > local Queue manager. I > > understand that for Pavel's situation, this be be > > irrelevant, but I am > > concerned with the general case? > > > > Matt. > > > > -Original Message- > > From: MQSeries List > > [mailto:[EMAIL PROTECTED] Behalf Of > Miller, > > Dennis > > Sent: 01 September 2004 01:13 > > To: [EMAIL PROTECTED] > > Subject: Re: Connecting to more than one queue > > managers on solaris, > > linux > > > > > > I understand your hesitance to use MQ client for > > such an app. But think > > about what you are really asking. An app on one > > server with MQM > > credentials for other servers? An app on one > server > > with access to MQM > > internals on another server? Hmmm... > > > > I'm sure you know that without MQ-Client, you > cannot > > even connect to a > > single QMgr across servers, much less multitudes > of > > them. So, if your > > thinking about monitoring even one qmgr by an app > > running on a different > > system, you are talking about some sort of client > > model, by definition. > > > > But it needn't necessarily be the MQ client. You > > could for example, > > write a monitoring agent and run it locally on > each > > qmgr. The user > > interface for your monitoring app is then a client > > to these agents, > > requesting services and receiving replies from > them. > > If you are > > so-inclined, you can even conduct the > request/reply > > exchanges using > > local connections and MQ messages (although, > > depending on what you are > > doing, one might question the wisdom of running a > > monitoring application > > in-band like that). > > > > It is somewhat analagous to how the command server > > works, only > > customized to your specific requirements. > > > > > > > > > > -Original Message- > > From: Pavel Tolkachev > > [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, August 31, 2004 1:31 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Connecting to more than one queue > > managers on solaris, > > linux > > > > > > Thanks Dennis, > > > > This is a low-level monitoring application > > (requiring mqm credentials, > > by the way). Making it an MQ client makes running > > listener or configured > > a pre-requisite to operate the app even if there > is > > no business purpose > > for them to be there and creates a whole number of > > security issues with > > the too-far-going implications of their possible > > solutions. I will have > > to either live with these consequences or go for > > running several > > instances of the app instead (which is not ideal > for > > my cause, > > e
Re: Connecting to more than one queue managers on solaris, linux
Pavel, I will do some research next week. I assume it should work in 5.3. I mentioned product that I am currently using. It is MQ system management product. Several components of it are multithreaded and are keeping connections to all active local queue managers. And I am using it in multithreaded mode on several platforms including SUN Solaris. Eugene --- Pavel Tolkachev <[EMAIL PROTECTED]> wrote: > Thanks eugene, > > Probably, not in 5.3. This is the error we are > getting on Solaris: > 2103( MQRC_ANOTHER_Q_MGR_CONNECTED) > > Child processes would be one option -- but it was > decided against it for non-MQ-related reasons. > > Thanks, > Pavel > > > > > > eugene rosenberg > <[EMAIL PROTECTED]To: > [EMAIL PROTECTED] > .COM>cc: > Sent by: MQSeries > Subject: Re: Connecting to more than one queue > managers on solaris, linux > List > <[EMAIL PROTECTED] > n.AC.AT> > > > 09/02/2004 08:46 > PM > Please respond to > MQSeries List > > > > > > > Pavel, > It was always possible to have connections to > various > queue managers from UNIX child processes (still one > connection per child process) and I did it myself. > In > the best of my knowledge starting with V5.2 it > became > possible to have the same type of connections from > threads. Even I did not try it myself I am using > products that are multithreaded and each thread has > it > is own connection. In some cases the number of > threads > is directly defined by the number of local queue > managers. > > Eugene > > --- Pavel Tolkachev <[EMAIL PROTECTED]> wrote: > > > Well, for a loopback interface (I mean, when > client > > connects to localhost or 127.0.0.1), it should not > > call real network drivers. I think it uses some > > platform-specific IPCs (on solaris, probably > streams > > -- I believe both pipes and local sockets use same > > underlying mechanisms, on very old Unices it were > > mbufs) -- and should not be really heavy... > > Although, the latency will increase due to the > agent > > and some overhead will still be there.. Even when > > real IP is used, smart TCP stack must not hit the > > network for local connections. > > > > Just thinking aloud.. I have never really tested > it > > with MQ but I did some performance testing with > > locally bound TCP sockets -- as long as all socket > > options were set right (especially TCP_NDELAY), > the > > overhead became negligible. Hopefully, IBM got it > > right :-). > > > > Just my 2c > > Pavel > > > > > > > > > > "Miller, Dennis" > > <[EMAIL PROTECTED]To: > > [EMAIL PROTECTED] > > OM> cc: > > Sent by: MQSeries > > Subject: Re: Connecting to more than one queue > > managers on solaris, linux > > List > > <[EMAIL PROTECTED] > > n.AC.AT> > > > > > > 09/01/2004 02:39 > > PM > > Please respond to > > MQSeries List > > > > > > > > > > > > > > The client connection has a performance > > disadvantage, mostly because of > > network overhead. After all, every API request > (and > > any messages it > > conveys) must pass over the network to get between > > the MQ client and the > > qmgr. The server channel agent, acting on behalf > of > > the client, uses > > local bindings and should experience about the > same > > performance as the > > application using local bindings. But the exchange > > of API requests > > between the MQ client and the server channel agent > > is extra work. > > > > I am not in a position to quantify it, though, and > I > > expect it would > > depend greatly on your network configuration. > > > > > > -Original Message- > > From: Gurney, Matthew > > [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, September 01, 2004 12:48 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Connecting to more than one queue > > managers on solaris, > > linux > > > > > > What would the performance difference of using > > MQClient connections to > > connect to a local Queue manager on the same Unix > > host, compared to > > using a local bindings direct connection to the > > local Queue manager. I > > understand that for Pavel's situation, this be be > > irrelevant, but I am > > concerned with the general case? > > > > Matt. > > > > -Original Message- > > From: MQSeries List > > [mailto:[EMAIL PROTECTED] Behalf Of > Miller, > > Dennis > > Sent: 01 September 2004 01:13 > > To: [EMAIL PROTECTED] > > Subject: Re: Connecting to more than one queue > > managers on solaris, > > linux > > > > > > I understand your hesitance to use MQ client for > > such an a
Re: Connecting to more than one queue managers on solaris, linux
Yes, the question was about a local app. Pavel "Miller, Dennis" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] OM> cc: Sent by: MQSeriesSubject: Re: Connecting to more than one queue managers on solaris, linux List <[EMAIL PROTECTED] n.AC.AT> 09/03/2004 05:11 PM Please respond to MQSeries List But I understood the question was restricted to an application writing to a local queue using local bindings vrs client bindings (i.e., no transmission queue involved). In that case, I think local bindings would always have a performance advantage. The situation for a distributed environment would be much different. And, yes, yes, really tricky. You'd more-often-than-not need to take measurements to know for sure. -Original Message- From: eugene rosenberg [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 5:57 PM To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux Dennis, It is really tricky to compare client/server performance with server/server performance. I agree that each application MQ client call would lose in performance compare with application MQ server call but I believe that the total throughput is better with the client/server communication because the number of I/O is low. The message is going directly to destination queue within client/server without be placed and retrieve on/from transmission queue. Eugene --- "Miller, Dennis" <[EMAIL PROTECTED]> wrote: > The client connection has a performance > disadvantage, mostly because of > network overhead. After all, every API request (and > any messages it > conveys) must pass over the network to get between > the MQ client and the > qmgr. The server channel agent, acting on behalf of > the client, uses > local bindings and should experience about the same performance as the > application using local bindings. But the exchange > of API requests > between the MQ client and the server channel agent > is extra work. > > I am not in a position to quantify it, though, and I > expect it would > depend greatly on your network configuration. > > > -Original Message- > From: Gurney, Matthew > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 01, 2004 12:48 AM > To: [EMAIL PROTECTED] > Subject: Re: Connecting to more than one queue > managers on solaris, > linux > > > What would the performance difference of using > MQClient connections to > connect to a local Queue manager on the same Unix > host, compared to > using a local bindings direct connection to the > local Queue manager. I > understand that for Pavel's situation, this be be > irrelevant, but I am > concerned with the general case? > > Matt. > > -Original Message- > From: MQSeries List > [mailto:[EMAIL PROTECTED] Behalf Of Miller, > Dennis > Sent: 01 September 2004 01:13 > To: [EMAIL PROTECTED] > Subject: Re: Connecting to more than one queue > managers on solaris, > linux > > > I understand your hesitance to use MQ client for > such an app. But think > about what you are really asking. An app on one > server with MQM > credentials for other servers? An app on one server > with access to MQM > internals on another server? Hmmm... > > I'm sure you know that without MQ-Client, you cannot > even connect to a > single QMgr across servers, much less multitudes of > them. So, if your > thinking about monitoring even one qmgr by an app > running on a different > system, you are talking about some sort of client > model, by definition. > > But it needn't necessarily be the MQ client. You > could for example, > write a monitoring agent and run it locally on each > qmgr. The user > interface for your monitoring app is then a client > to these agents, > requesting services and receiving replies from them. > If you are > so-inclined, you can even conduct the request/reply > exchanges using > local connections and MQ messages (although, > depending on what you are > doing, one might question the wisdom of running a > monitoring application > in-band like that). > > It is somewhat analagous to how the command server > works, only > customized to your specific requirements. > > > > > -Original Message- > From: Pavel Tolkachev > [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 31, 2004 1:31 PM > To: [EMAIL PROTECTED] > Subject: Re: Connecting to more than one queue > managers on solaris, > linux > > > Thanks Dennis, > > This is a low-level monitoring application > (requiring mqm credentials, > by the way). Making it an MQ client makes running > listener or configured > a pre-requisite to operate the app even if there is > no business purpose > for them to be there and creates a whole number of > security issues with > the too-far-going i
Re: Connecting to more than one queue managers on solaris, linux
Thanks Eugene, Yes, please let us know your findings. For system management, you may either use the client (the way I do not like), or connect/disconnect each time (the one we have now), or spawn multiple processes or connect to a single QM (you can use dedicated admin qm for that -- another way I kind of fond of) and use intercommunications for others. The options are plenty which by itself tells that no one of them is perfect... Pavel eugene rosenberg <[EMAIL PROTECTED]To: [EMAIL PROTECTED] .COM>cc: Sent by: MQSeriesSubject: Re: Connecting to more than one queue managers on solaris, linux List <[EMAIL PROTECTED] n.AC.AT> 09/03/2004 06:21 PM Please respond to MQSeries List Pavel, I will do some research next week. I assume it should work in 5.3. I mentioned product that I am currently using. It is MQ system management product. Several components of it are multithreaded and are keeping connections to all active local queue managers. And I am using it in multithreaded mode on several platforms including SUN Solaris. Eugene --- Pavel Tolkachev <[EMAIL PROTECTED]> wrote: > Thanks eugene, > > Probably, not in 5.3. This is the error we are > getting on Solaris: > 2103( MQRC_ANOTHER_Q_MGR_CONNECTED) > > Child processes would be one option -- but it was > decided against it for non-MQ-related reasons. > > Thanks, > Pavel > > > > > > eugene rosenberg > <[EMAIL PROTECTED]To: > [EMAIL PROTECTED] > .COM>cc: > Sent by: MQSeries > Subject: Re: Connecting to more than one queue > managers on solaris, linux > List > <[EMAIL PROTECTED] > n.AC.AT> > > > 09/02/2004 08:46 > PM > Please respond to > MQSeries List > > > > > > > Pavel, > It was always possible to have connections to > various > queue managers from UNIX child processes (still one > connection per child process) and I did it myself. > In > the best of my knowledge starting with V5.2 it > became > possible to have the same type of connections from > threads. Even I did not try it myself I am using > products that are multithreaded and each thread has > it > is own connection. In some cases the number of > threads > is directly defined by the number of local queue > managers. > > Eugene > > --- Pavel Tolkachev <[EMAIL PROTECTED]> wrote: > > > Well, for a loopback interface (I mean, when > client > > connects to localhost or 127.0.0.1), it should not > > call real network drivers. I think it uses some > > platform-specific IPCs (on solaris, probably > streams > > -- I believe both pipes and local sockets use same > > underlying mechanisms, on very old Unices it were > > mbufs) -- and should not be really heavy... > > Although, the latency will increase due to the > agent > > and some overhead will still be there.. Even when > > real IP is used, smart TCP stack must not hit the > > network for local connections. > > > > Just thinking aloud.. I have never really tested > it > > with MQ but I did some performance testing with > > locally bound TCP sockets -- as long as all socket > > options were set right (especially TCP_NDELAY), > the > > overhead became negligible. Hopefully, IBM got it > > right :-). > > > > Just my 2c > > Pavel > > > > > > > > > > "Miller, Dennis" > > <[EMAIL PROTECTED]To: > > [EMAIL PROTECTED] > > OM> cc: > > Sent by: MQSeries > > Subject: Re: Connecting to more than one queue > > managers on solaris, linux > > List > > <[EMAIL PROTECTED] > > n.AC.AT> > > > > > > 09/01/2004 02:39 > > PM > > Please respond to > > MQSeries List > > > > > > > > > > > > > > The client connection has a performance > > disadvantage, mostly because of > > network overhead. After all, every API request > (and > > any messages it > > conveys) must pass over the network to get between > > the MQ client and the > > qmgr. The server channel agent, acting on behalf > of > > the client, uses > > local bindings and should experience about the > same > > performance as the > > application using local bindings. But the exchange > > of API requests > > between the MQ client and the server channel agent > > is extra work. > > > > I am not in a position to quantify it, though, and > I > > expect it would > > depend greatly on your networ
