Re: Resume message receive

[Guy Shavitt]

My feeling is that this is an idea for a killer product or great feature in
the next MQSeries version. Any volunteers?  Maybe some IBM guys would like
to comment?
Regards,
Guy

From: "Miller, Dennis" <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Resume message receive
Date: Tue, 15 Jul 2003 13:01:47 -0700
Then I think you're stuck with building that functionality into your
application. The client connection flows MQI requests, not messages. If the
connection drops while an MQGET is in progress, the MQGET must be
re-issued.  There is no way to re-connect to the qmgr, re-open the queue,
and resume an abandonded MQGET.
> -Original Message-
> From: Guy Shavitt [SMTP:[EMAIL PROTECTED]
> Sent: Monday, July 14, 2003 10:54 PM
> To:   [EMAIL PROTECTED]
> Subject:   Re: Resume message receive
>
> Dennis,
>
> Yes it does. We use Server Connection and Client Connection channels to
> communicate
>
> Regards,
> Guy
>
>
> >From: "Miller, Dennis" <[EMAIL PROTECTED]>
> >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: Resume message receive
> >Date: Mon, 14 Jul 2003 08:36:31 -0700
> >
> >Does the receiving end point use a client connection?
> >
> > > -Original Message-
> > > From: Guy Shavitt [SMTP:[EMAIL PROTECTED]
> > > Sent: Monday, July 14, 2003 5:16 AM
> > > To:   [EMAIL PROTECTED]
> > > Subject:   Resume message receive
> > >
> > > Hello,
> > >
> > > We are sending large messages (more than 4MB each) over an Internet
> > > connection using MQSeries. The receiving end points are sometimes
> >connected
> > > with a simple Dial-Up connection.
> > >
> > > Is someone familiar with a way in MQSeries to resume a "receive" for
a
> > > message if the connection fails in the middle of the "receive"
process
> >and
> > > continue to load just the portion of the message that was not read
yet?
> > > Today, we need to receive the whole message all over again.
> > >
> > > Is there a product that supports this feature in MQSeries?
> > > Did someone encounter this problem and found a solution for it?
> > >
> > > Thanks for your help
> > > Guy
> > >
> > > _
> > > Protect your PC - get McAfee.com VirusScan Online
> > > 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
> >
> >Instructions for managing your mailing list subscription are provided
in
> >the Listserv General Users Guide available at http://www.lsoft.com
> >Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
> _
> The new MSN 8: advanced junk mail protection and 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive
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
_
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

FDC file - any manual to understand those errors?

[JoE JK]

Hi,
Is there any manual or documentation mentioned in
details about *.FDC file contents?  For eg what is
'Comment1' meant or 'Arith'?

Thanks,

Joe

__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: KeepAlive for Inactive Channels

[ZUO Limin]

Signoff


-Original Message-
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 4:14 AM
To: [EMAIL PROTECTED]
Subject: Re: KeepAlive for Inactive Channels

QM1 has a SNDR channel to QM2 call QM1.QM2.
QM2 has a RCVR channel called QM1.QM2.

Both of these channels have gone inactive due to no messages. At this point,
the SNDR channel is not even sending heartbeats. The channel is truly
inactive. There is no longer a TCP/IP connection for this particular socket,
so even KeepAlive does not come into play.

You take QM2 down.

Nothing will happen on the QM1 side because that SNDR channel is InActive
(deep sleep). It does not know or care what is happening on the other side.


Now while QM2 is still down, a message lands in QM1's XMIT queue to QM2, and
the QM1.QM2 SNDR channel is triggered. It immediately goes into retry state,
retrying over and over until either QM2 comes back up and the connection is
reestablished between QM1 and QM2, or your long retry count is used up, and
the channel goes to STOPPED.





-Original Message-
From: Wmq Techie [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 3:46 PM
To: [EMAIL PROTECTED]
Subject: Re: KeepAlive for Inactive Channels


Which version of the Intercommunications guide? My guide on page 85 talks
about
the convert parameter.


TIA
> No, it does NOT "wake" a sleeping channel.  See MQSeries
Intercommunication
> manual, page 85 for a fuller description.
>
> -Original Message-
> From: Wmq Techie [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 15, 2003 1:43 PM
> To: [EMAIL PROTECTED]
> Subject: Re: KeepAlive for Inactive Channels
>
>
> Douglas,
>
>   Are you saying that the heartbeat interval will wake the 'inactive'
> channel up and then the channel will realize that the partner queue
manager
> is not there and will go into a 'retry' state?
>
>
> TIA
> > I haven't used KeepAlive, but in a class I just attended, it was
> > strongly recommended that heartbeat be used, and then if desired
> > KeepAlive could also be activated.
> >
> > -Original Message-
> > From: Wmq Techie [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, July 15, 2003 1:09 PM
> > To: [EMAIL PROTECTED]
> > Subject: KeepAlive for Inactive Channels
> >
> >
> > MQ'ers
> >
> >   When a triggered channel has timed out due to inactivity, and while
> > the channel is 'inactive', the queue manager on the other side of the
> > channel is taken down, shouldn't the channel go into 'retry' when the
> > TCP KeepAlive interval is reached? Or does the channel have to go into
> > a 'running' state to detect that the partner queue manager is down and
> > then go into 'retry'?
> >
> >
> > TIA
> >
> > 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

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all
copies.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: UNSUBSCRIBE

[ZUO Limin]

UNSUBSCRIBE

-Original Message-
From: Kinlen, Dan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 11:12 PM
To: [EMAIL PROTECTED]
Subject: UNSUBSCRIBE

UNSUBSCRIBE


RBC Dain Rauscher does not accept buy, sell or cancel orders by e-mail, or
any instructions by e-mail that would require your signature.  Information
contained in this communication is not considered an official record of your
account and does not supersede normal trade confirmations or statements.
Any information provided has been prepared from sources believed to be
reliable but is not guaranteed, does not represent all available data
necessary for making investment decisions and is for informational purposes
only.

This e-mail may be privileged and/or confidential, and the sender does not
waive any related rights and obligations.  Any distribution, use or copying
of this e-mail or the information it contains by other than an intended
recipient is unauthorized.  If you receive this e-mail in error, please
advise me (by return e-mail or otherwise) immediately.

Information received by or sent from this system is subject to review by
supervisory personnel, is retained and may be produced to regulatory
authorities or others with a legal right to the information.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

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: KeepAlive for Inactive Channels

[Potkay, Peter M (PLC, IT)]

QM1 has a SNDR channel to QM2 call QM1.QM2.
QM2 has a RCVR channel called QM1.QM2.

Both of these channels have gone inactive due to no messages. At this point,
the SNDR channel is not even sending heartbeats. The channel is truly
inactive. There is no longer a TCP/IP connection for this particular socket,
so even KeepAlive does not come into play.

You take QM2 down.

Nothing will happen on the QM1 side because that SNDR channel is InActive
(deep sleep). It does not know or care what is happening on the other side.


Now while QM2 is still down, a message lands in QM1's XMIT queue to QM2, and
the QM1.QM2 SNDR channel is triggered. It immediately goes into retry state,
retrying over and over until either QM2 comes back up and the connection is
reestablished between QM1 and QM2, or your long retry count is used up, and
the channel goes to STOPPED.





-Original Message-
From: Wmq Techie [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 3:46 PM
To: [EMAIL PROTECTED]
Subject: Re: KeepAlive for Inactive Channels


Which version of the Intercommunications guide? My guide on page 85 talks
about
the convert parameter.


TIA
> No, it does NOT "wake" a sleeping channel.  See MQSeries
Intercommunication
> manual, page 85 for a fuller description.
>
> -Original Message-
> From: Wmq Techie [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 15, 2003 1:43 PM
> To: [EMAIL PROTECTED]
> Subject: Re: KeepAlive for Inactive Channels
>
>
> Douglas,
>
>   Are you saying that the heartbeat interval will wake the 'inactive'
> channel up and then the channel will realize that the partner queue
manager
> is not there and will go into a 'retry' state?
>
>
> TIA
> > I haven't used KeepAlive, but in a class I just attended, it was
> > strongly recommended that heartbeat be used, and then if desired
> > KeepAlive could also be activated.
> >
> > -Original Message-
> > From: Wmq Techie [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, July 15, 2003 1:09 PM
> > To: [EMAIL PROTECTED]
> > Subject: KeepAlive for Inactive Channels
> >
> >
> > MQ'ers
> >
> >   When a triggered channel has timed out due to inactivity, and while
> > the channel is 'inactive', the queue manager on the other side of the
> > channel is taken down, shouldn't the channel go into 'retry' when the
> > TCP KeepAlive interval is reached? Or does the channel have to go into
> > a 'running' state to detect that the partner queue manager is down and
> > then go into 'retry'?
> >
> >
> > TIA
> >
> > 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

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all copies.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Resume message receive

[Miller, Dennis]

Then I think you're stuck with building that functionality into your application. The 
client connection flows MQI requests, not messages. If the connection drops while an 
MQGET is in progress, the MQGET must be re-issued.  There is no way to re-connect to 
the qmgr, re-open the queue, and resume an abandonded MQGET.   

> -Original Message-
> From: Guy Shavitt [SMTP:[EMAIL PROTECTED]
> Sent: Monday, July 14, 2003 10:54 PM
> To:   [EMAIL PROTECTED]
> Subject:   Re: Resume message receive
> 
> Dennis,
> 
> Yes it does. We use Server Connection and Client Connection channels to
> communicate
> 
> Regards,
> Guy
> 
> 
> >From: "Miller, Dennis" <[EMAIL PROTECTED]>
> >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: Resume message receive
> >Date: Mon, 14 Jul 2003 08:36:31 -0700
> >
> >Does the receiving end point use a client connection?
> >
> > > -Original Message-
> > > From: Guy Shavitt [SMTP:[EMAIL PROTECTED]
> > > Sent: Monday, July 14, 2003 5:16 AM
> > > To:   [EMAIL PROTECTED]
> > > Subject:   Resume message receive
> > >
> > > Hello,
> > >
> > > We are sending large messages (more than 4MB each) over an Internet
> > > connection using MQSeries. The receiving end points are sometimes
> >connected
> > > with a simple Dial-Up connection.
> > >
> > > Is someone familiar with a way in MQSeries to resume a "receive" for a
> > > message if the connection fails in the middle of the "receive" process
> >and
> > > continue to load just the portion of the message that was not read yet?
> > > Today, we need to receive the whole message all over again.
> > >
> > > Is there a product that supports this feature in MQSeries?
> > > Did someone encounter this problem and found a solution for it?
> > >
> > > Thanks for your help
> > > Guy
> > >
> > > _
> > > Protect your PC - get McAfee.com VirusScan Online
> > > 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
> >
> >Instructions for managing your mailing list subscription are provided in
> >the Listserv General Users Guide available at http://www.lsoft.com
> >Archive: http://vm.akh-wien.ac.at/MQSeries.archive
> 
> _
> The new MSN 8: advanced junk mail protection and 2 months FREE*
> http://join.msn.com/?page=features/junkmail
> 
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive

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: KeepAlive for Inactive Channels

[Wmq Techie]

Which version of the Intercommunications guide? My guide on page 85 talks about
the convert parameter.


TIA
> No, it does NOT "wake" a sleeping channel.  See MQSeries Intercommunication
> manual, page 85 for a fuller description.
>
> -Original Message-
> From: Wmq Techie [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 15, 2003 1:43 PM
> To: [EMAIL PROTECTED]
> Subject: Re: KeepAlive for Inactive Channels
>
>
> Douglas,
>
>   Are you saying that the heartbeat interval will wake the 'inactive'
> channel up and then the channel will realize that the partner queue manager
> is not there and will go into a 'retry' state?
>
>
> TIA
> > I haven't used KeepAlive, but in a class I just attended, it was
> > strongly recommended that heartbeat be used, and then if desired
> > KeepAlive could also be activated.
> >
> > -Original Message-
> > From: Wmq Techie [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, July 15, 2003 1:09 PM
> > To: [EMAIL PROTECTED]
> > Subject: KeepAlive for Inactive Channels
> >
> >
> > MQ'ers
> >
> >   When a triggered channel has timed out due to inactivity, and while
> > the channel is 'inactive', the queue manager on the other side of the
> > channel is taken down, shouldn't the channel go into 'retry' when the
> > TCP KeepAlive interval is reached? Or does the channel have to go into
> > a 'running' state to detect that the partner queue manager is down and
> > then go into 'retry'?
> >
> >
> > TIA
> >
> > 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

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

MQOPEN ended with reason code 2189, CLUSTERS

[eai grp]

Hi 
I get a
MQOPEN ended with reason code 2189 when i try to  amqsput on a queue that is shared in a cluster.
I have just two QMGRs QM1 and QM2 in the cluster and iam doing a amqsput test QM2.
QM2 does not have test and test is in QM1  and is shared. QM1 is the repos.
Display clusqgr qmtype status, gives me the status as running ! what could be the problem
 
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

Re: KeepAlive for Inactive Channels

[Kanwischer, Douglas E.]

No, it does NOT "wake" a sleeping channel.  See MQSeries Intercommunication
manual, page 85 for a fuller description.

-Original Message-
From: Wmq Techie [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 1:43 PM
To: [EMAIL PROTECTED]
Subject: Re: KeepAlive for Inactive Channels


Douglas,

  Are you saying that the heartbeat interval will wake the 'inactive'
channel up and then the channel will realize that the partner queue manager
is not there and will go into a 'retry' state?


TIA
> I haven't used KeepAlive, but in a class I just attended, it was
> strongly recommended that heartbeat be used, and then if desired
> KeepAlive could also be activated.
>
> -Original Message-
> From: Wmq Techie [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 15, 2003 1:09 PM
> To: [EMAIL PROTECTED]
> Subject: KeepAlive for Inactive Channels
>
>
> MQ'ers
>
>   When a triggered channel has timed out due to inactivity, and while
> the channel is 'inactive', the queue manager on the other side of the
> channel is taken down, shouldn't the channel go into 'retry' when the
> TCP KeepAlive interval is reached? Or does the channel have to go into
> a 'running' state to detect that the partner queue manager is down and
> then go into 'retry'?
>
>
> TIA
>
> 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: CSD4 MQ v5.3 NT

[Potkay, Peter M (PLC, IT)]

The link is good. You need an IBMLink ID to get to it.


-Original Message-
From: EXT-Makhija, Arun [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 3:16 PM
To: [EMAIL PROTECTED]
Subject: Re: CSD4 MQ v5.3 NT


The link is in complete

Arun Makhija
Never argue with an idiot. They drag you down to their level and beat you
with experience


-Original Message-
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 12:03 PM
To: [EMAIL PROTECTED]
Subject: Re: CSD4 MQ v5.3 NT


I have it installed on several servers with no problems (yet).

This link will give you the readme for this CSD, which contains the info you
seek:

http://www6.software.ibm.com/dl/wsmqcsd/wsmqcsd-h?S_PKG=csd04&S_TACT=&S_CMP=

I had to sign in with my IBMLink ID to get to this page though.


-Original Message-
From: Nick Dilauro [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 2:52 PM
To: [EMAIL PROTECTED]
Subject: CSD4 MQ v5.3 NT


Hi,

I am planning to install the latest CSD04 for Windows NT MQ version 5.3.  I
noticed that there were no details listed for the CSD.   Is there a way to
find out what problems this CSD corrects?  I realize that it includes all
the previous fixes for CSD03 and previous CSDs, but I don't see any details
for CSD04.

BTW, has anyone installed this yet?  Any observations?

Nick

__

Nicholas DiLauro
MQSeries Administrator
QRS Corporation
1400 Marina Way South
Richmond, CA 94804
t: 510-231-6544
f: 510-621-6544
[EMAIL PROTECTED]

__

This message contains information that may be confidential or proprietary,
or protected by the attorney-client privilege or work product doctrine
intended solely for the use of the addressee(s) named above. Any review,
disclosure, distribution, copying or use of the information by others is
strictly prohibited. If you have received this message in error or without
authorization, please advise the sender by immediate reply and delete the
original message. All email sent to this address will be received by the QRS
corporate email system and is subject to archiving and review by someone
other than the recipient.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all
copies.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

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: CSD4 MQ v5.3 NT

[EXT-Makhija, Arun]

The link is in complete

Arun Makhija
Never argue with an idiot. They drag you down to their level and beat you with 
experience 


-Original Message-
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 12:03 PM
To: [EMAIL PROTECTED]
Subject: Re: CSD4 MQ v5.3 NT


I have it installed on several servers with no problems (yet).

This link will give you the readme for this CSD, which contains the info you
seek:

http://www6.software.ibm.com/dl/wsmqcsd/wsmqcsd-h?S_PKG=csd04&S_TACT=&S_CMP=

I had to sign in with my IBMLink ID to get to this page though.


-Original Message-
From: Nick Dilauro [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 2:52 PM
To: [EMAIL PROTECTED]
Subject: CSD4 MQ v5.3 NT


Hi,

I am planning to install the latest CSD04 for Windows NT MQ version 5.3.  I
noticed that there were no details listed for the CSD.   Is there a way to
find out what problems this CSD corrects?  I realize that it includes all
the previous fixes for CSD03 and previous CSDs, but I don't see any details
for CSD04.

BTW, has anyone installed this yet?  Any observations?

Nick

__

Nicholas DiLauro
MQSeries Administrator
QRS Corporation
1400 Marina Way South
Richmond, CA 94804
t: 510-231-6544
f: 510-621-6544
[EMAIL PROTECTED]

__

This message contains information that may be confidential or proprietary,
or protected by the attorney-client privilege or work product doctrine
intended solely for the use of the addressee(s) named above. Any review,
disclosure, distribution, copying or use of the information by others is
strictly prohibited. If you have received this message in error or without
authorization, please advise the sender by immediate reply and delete the
original message. All email sent to this address will be received by the QRS
corporate email system and is subject to archiving and review by someone
other than the recipient.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all copies.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: CSD4 MQ v5.3 NT

[Potkay, Peter M (PLC, IT)]

I have it installed on several servers with no problems (yet).

This link will give you the readme for this CSD, which contains the info you
seek:

http://www6.software.ibm.com/dl/wsmqcsd/wsmqcsd-h?S_PKG=csd04&S_TACT=&S_CMP=

I had to sign in with my IBMLink ID to get to this page though.


-Original Message-
From: Nick Dilauro [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 2:52 PM
To: [EMAIL PROTECTED]
Subject: CSD4 MQ v5.3 NT


Hi,

I am planning to install the latest CSD04 for Windows NT MQ version 5.3.  I
noticed that there were no details listed for the CSD.   Is there a way to
find out what problems this CSD corrects?  I realize that it includes all
the previous fixes for CSD03 and previous CSDs, but I don't see any details
for CSD04.

BTW, has anyone installed this yet?  Any observations?

Nick

__

Nicholas DiLauro
MQSeries Administrator
QRS Corporation
1400 Marina Way South
Richmond, CA 94804
t: 510-231-6544
f: 510-621-6544
[EMAIL PROTECTED]

__

This message contains information that may be confidential or proprietary,
or protected by the attorney-client privilege or work product doctrine
intended solely for the use of the addressee(s) named above. Any review,
disclosure, distribution, copying or use of the information by others is
strictly prohibited. If you have received this message in error or without
authorization, please advise the sender by immediate reply and delete the
original message. All email sent to this address will be received by the QRS
corporate email system and is subject to archiving and review by someone
other than the recipient.

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

CSD4 MQ v5.3 NT

[Nick Dilauro]

Hi,

I am planning to install the latest CSD04 for Windows NT MQ version 5.3.  I
noticed that there were no details listed for the CSD.   Is there a way to
find out what problems this CSD corrects?  I realize that it includes all
the previous fixes for CSD03 and previous CSDs, but I don't see any details
for CSD04.

BTW, has anyone installed this yet?  Any observations?

Nick

__

Nicholas DiLauro
MQSeries Administrator
QRS Corporation
1400 Marina Way South
Richmond, CA 94804
t: 510-231-6544
f: 510-621-6544
[EMAIL PROTECTED]

__

This message contains information that may be confidential or proprietary,
or protected by the attorney-client privilege or work product doctrine
intended solely for the use of the addressee(s) named above. Any review,
disclosure, distribution, copying or use of the information by others is
strictly prohibited. If you have received this message in error or without
authorization, please advise the sender by immediate reply and delete the
original message. All email sent to this address will be received by the QRS
corporate email system and is subject to archiving and review by someone
other than the recipient.

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: KeepAlive for Inactive Channels

[Wmq Techie]

Douglas,

  Are you saying that the heartbeat interval will wake the 'inactive' channel
up and then the channel will realize that the partner queue manager is not
there and will go into a 'retry' state?


TIA
> I haven't used KeepAlive, but in a class I just attended, it was strongly
> recommended that heartbeat be used, and then if desired KeepAlive could also
> be activated.
>
> -Original Message-
> From: Wmq Techie [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 15, 2003 1:09 PM
> To: [EMAIL PROTECTED]
> Subject: KeepAlive for Inactive Channels
>
>
> MQ'ers
>
>   When a triggered channel has timed out due to inactivity, and while the
> channel is 'inactive', the queue manager on the other side of the channel is
> taken down, shouldn't the channel go into 'retry' when the TCP KeepAlive
> interval is reached? Or does the channel have to go into a 'running' state
> to detect that the partner queue manager is down and then go into 'retry'?
>
>
> TIA
>
> 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: KeepAlive for Inactive Channels

[Kanwischer, Douglas E.]

I haven't used KeepAlive, but in a class I just attended, it was strongly
recommended that heartbeat be used, and then if desired KeepAlive could also
be activated.

-Original Message-
From: Wmq Techie [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 1:09 PM
To: [EMAIL PROTECTED]
Subject: KeepAlive for Inactive Channels


MQ'ers

  When a triggered channel has timed out due to inactivity, and while the
channel is 'inactive', the queue manager on the other side of the channel is
taken down, shouldn't the channel go into 'retry' when the TCP KeepAlive
interval is reached? Or does the channel have to go into a 'running' state
to detect that the partner queue manager is down and then go into 'retry'?


TIA

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: KeepAlive for Inactive Channels

[Glen Shubert]

No, the channel will not go into a retry while it is in an INACTIVE state.  TCP Keepalive is a TCP level function, not an MQ function.

Glen Shubert
[EMAIL PROTECTED]
Associate Director
TSYS - MQSeries Technical Support






Wmq Techie <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
07/15/2003 02:09 PM
Please respond to MQSeries List


        
        To:        [EMAIL PROTECTED]
        cc:        
        Subject:        KeepAlive for Inactive Channels
MQ'ers

  When a triggered channel has timed out due to inactivity, and while the
channel is 'inactive', the queue manager on the other side of the channel is
taken down, shouldn't the channel go into 'retry' when the TCP KeepAlive
interval is reached? Or does the channel have to go into a 'running' state to
detect that the partner queue manager is down and then go into 'retry'?


TIA

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive



The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed.  The information may also constitute a legally privileged confidential communication.  If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited.  If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.  Thank you

Upgrading to MQSI 5.0 from MQSI 2.1

[Kanwischer, Douglas E.]

So, we got the CDs a couple of weeks ago.  My AIX admin went to install the
Integrator today, and found the install app noted in their documentation
(setupaix) didn't have an execute flag for ANYONE (ugo)!  I've suggested
copying the whole disk to our hard drive and changing the flag and running
(which he'll do tomorrow), but I was just curious if anyone else's CD was
sent this way.

I haven't checked out our Windows CD yet, but will shortly.

Regards,


Doug Kanwischer
MQ and Integrator Administrator
Information Technology
Purdue University

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

KeepAlive for Inactive Channels

[Wmq Techie]

MQ'ers

  When a triggered channel has timed out due to inactivity, and while the
channel is 'inactive', the queue manager on the other side of the channel is
taken down, shouldn't the channel go into 'retry' when the TCP KeepAlive
interval is reached? Or does the channel have to go into a 'running' state to
detect that the partner queue manager is down and then go into 'retry'?


TIA

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: Questionable MQ infrastructure design

[Beinert, William]

I like the "business object" naming for queues.
So why not put the sending/receiving applicaton names in the Description?

Bill

-Original Message-
From: Robert Broderick [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 7:09 AM
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design


Try to debug a service oriented at 3:00AM when all you got is a queue name
to go on and your critical financial start-of-day application is getting a
bad data enima and your application SME has had enough of his/her crappy job
and busted the batteries out of their beeper.

I have been in these situations and what people take for granted when naming
"BUSINESS OBJECT" sort of eludes the actual person who is harpooned with the
process of figuring out what the problem. And also from experience it isn't
the MSTER of names that will take the heat for the application /
infrasturcture not working.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: UNSUBSCRIBE

[James Kingdon]

I wonder if we could get those two sentences appended to each mail sent
from the list. It would help people a lot more than the generic
reference to lsoft.com...
cc'd to list managers with eternal optimism.

Regards,
James.
Bullock, Rebecca (CSC) wrote:

Here's what you need to do:

You  may leave  the list  at  any time  by sending  a "SIGNOFF  MQSERIES"
command to  [EMAIL PROTECTED]
Do NOT send this to [EMAIL PROTECTED]; that won't get you off this
listserv, it'll only send your wish to do so to everyone on the list.
-Original Message-
From: Kinlen, Dan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 11:12 AM
To: [EMAIL PROTECTED]
Subject: UNSUBSCRIBE
UNSUBSCRIBE

RBC Dain Rauscher does not accept buy, sell or cancel orders by e-mail, or
any instructions by e-mail that would require your signature.  Information
contained in this communication is not considered an official record of your
account and does not supersede normal trade confirmations or statements.
Any information provided has been prepared from sources believed to be
reliable but is not guaranteed, does not represent all available data
necessary for making investment decisions and is for informational purposes
only.
This e-mail may be privileged and/or confidential, and the sender does not
waive any related rights and obligations.  Any distribution, use or copying
of this e-mail or the information it contains by other than an intended
recipient is unauthorized.  If you receive this e-mail in error, please
advise me (by return e-mail or otherwise) immediately.
Information received by or sent from this system is subject to review by
supervisory personnel, is retained and may be produced to regulatory
authorities or others with a legal right to the information.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


**
This e-mail and any files transmitted with it may contain privileged or
confidential information. It is solely for use by the individual for whom
it is intended, even if addressed incorrectly. If you received this e-mail
in error, please notify the sender; do not disclose, copy, distribute, or
take any action in reliance on the contents of this information; and delete
it from your system. Any other use of this e-mail is prohibited. Thank you
for your compliance.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive


Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Questionable MQ infrastructure design

[Robert Broderick]

The PC term is now PUREST!!! (hahahahahaha)


From: Rick Tsujimoto <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design
Date: Tue, 15 Jul 2003 12:17:14 -0400
tsk tsk tsk...just like a techie



  Robert Broderick
  <[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
  OTMAIL.COM>cc:
  Sent by: MQSeries  Subject: Re: Questionable
MQ infrastructure design
  List
  <[EMAIL PROTECTED]
  .AC.AT>
  07/15/2003 12:00
  PM
  Please respond to
  MQSeries List




Aliases!! YuckWhat a deplorable thing!!

>From: Rick Tsujimoto <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Questionable MQ infrastructure design
>Date: Tue, 15 Jul 2003 09:24:24 -0400
>
>Isn't that why we have QALIASes?  One for the programmers, and one for
us.
>
>
>
>
>   Robert Broderick
>   <[EMAIL PROTECTED] To:
>[EMAIL PROTECTED]
>   OTMAIL.COM>cc:
>   Sent by: MQSeries  Subject: Re:
Questionable
>MQ infrastructure design
>   List
>   <[EMAIL PROTECTED]
>   .AC.AT>
>
>
>   07/15/2003 07:09
>   AM
>   Please respond to
>   MQSeries List
>
>
>
>
>
>Try to debug a service oriented at 3:00AM when all you got is a queue
name
>to go on and your critical financial start-of-day application is getting
a
>bad data enima and your application SME has had enough of his/her crappy
>job
>and busted the batteries out of their beeper.
>
>I understand that in this age of OVER doing things and making everything
>nicey nice and looking like we all got degrees from MIT. BUT...what often
>is
>best is the KISS method.
>
>I have been in these situations and what people take for granted when
>naming
>"BUSINESS OBJECT" sort of eludes the actual person who is harpooned with
>the
>process of figuring out what the problem. And also from experience it
isn't
>the MSTER of names that will take the heat for the application /
>infrasturcture not working.
>
>We do a better job if we design and NAME system that are a little less
>abstract and a lot more realistic. I know that sometimes this is not
>possible but..:-)
>
> bee-oh-dubble-bee-dubble-egh
>
>
> >From: "Kelly, Steve" <[EMAIL PROTECTED]>
> >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: Questionable MQ infrastructure design
> >Date: Mon, 14 Jul 2003 17:26:01 -0400
> >
> >Interesting. Agree with channel names but queue names ? In a
> >service-oriented architecture don't you want your queue names to
identify
> >the shared service they drive. So, for example,
UPDATE.NAME.AND.ADDRESS,
> >CREDIT.MY.ACCOUNT etc. When we are all trying to maximise re-use do we
> >really care who the sending application is? Yes, you'll want to know if
> >something goes wrong, but do you need it in the queue name ?
> >
> >Steve.
> >
> >-Original Message-
> >From: Robert Broderick [mailto:[EMAIL PROTECTED]
> >Sent: 14 July 2003 12:15
> >To: [EMAIL PROTECTED]
> >Subject: Re: Questionable MQ infrastructure design
> >
> >
> >The Queue name I push when we a developing infrastructure is
> >SendingApp.ReceivingApp.AnythingYouWant
> >
> >Channels are generic-ly Sender.Receiver  with variations considered for
> >multiple QMGRS on the same box and testing cyclye (eg SandBox, Dev,
SIT,
> >UAT, QA, Prod, DR)
> >
> >
>bobbee
> >
> >
> > >From: [EMAIL PROTECTED]
> > >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> > >To: [EMAIL PROTECTED]
> > >Subject: Re: Questionable MQ infrastructure design
> > >Date: Sun, 13 Jul 2003 18:01:36 +1000
> > >
> > >Hi,
> > >
> > >We have a similar name scheme for channels except much shorter
> >SRC_DST
> > >and optionallyPROD_SRC_DST, not by application though.
> > >
> > >For queues,we normally use a qualifier on the end of the queue
>name/type
> > >for
> > >the type of data i.e.
> > >
> > >ie  app_type.pgp   (PGP encrypted data)
> > >app_type_subtype.xml
> > >
> > >etc
> > >
> > >Same goes for Transmission queues and initiation queues
> > >
> > >app_process.initq
> > >app_process.txq
> > >
> > >I think you can see the pattern..
> > >
> > >
> > >Sid
> > >
> > >
> > >
> > >-Original Message-
> > >From: Armand ten Dam [mailto:[EMAIL PROTECTED]
> > >Sent: Thursday, 10 July 2003 10:58 AM
> > >To: [EMAIL PROTECTED]
> > >Subject: Questionable MQ infrastructure design
> > >
> > >
> > >Hi all,
> > >For an integration project I have been asked to adop

Re: Questionable MQ infrastructure design

[Rick Tsujimoto]

tsk tsk tsk...just like a techie




  Robert Broderick
  <[EMAIL PROTECTED] To:  [EMAIL PROTECTED]
  OTMAIL.COM>cc:
  Sent by: MQSeries  Subject: Re: Questionable MQ 
infrastructure design
  List
  <[EMAIL PROTECTED]
  .AC.AT>


  07/15/2003 12:00
  PM
  Please respond to
  MQSeries List





Aliases!! YuckWhat a deplorable thing!!


>From: Rick Tsujimoto <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Questionable MQ infrastructure design
>Date: Tue, 15 Jul 2003 09:24:24 -0400
>
>Isn't that why we have QALIASes?  One for the programmers, and one for us.
>
>
>
>
>   Robert Broderick
>   <[EMAIL PROTECTED] To:
>[EMAIL PROTECTED]
>   OTMAIL.COM>cc:
>   Sent by: MQSeries  Subject: Re:
Questionable
>MQ infrastructure design
>   List
>   <[EMAIL PROTECTED]
>   .AC.AT>
>
>
>   07/15/2003 07:09
>   AM
>   Please respond to
>   MQSeries List
>
>
>
>
>
>Try to debug a service oriented at 3:00AM when all you got is a queue name
>to go on and your critical financial start-of-day application is getting a
>bad data enima and your application SME has had enough of his/her crappy
>job
>and busted the batteries out of their beeper.
>
>I understand that in this age of OVER doing things and making everything
>nicey nice and looking like we all got degrees from MIT. BUT...what often
>is
>best is the KISS method.
>
>I have been in these situations and what people take for granted when
>naming
>"BUSINESS OBJECT" sort of eludes the actual person who is harpooned with
>the
>process of figuring out what the problem. And also from experience it
isn't
>the MSTER of names that will take the heat for the application /
>infrasturcture not working.
>
>We do a better job if we design and NAME system that are a little less
>abstract and a lot more realistic. I know that sometimes this is not
>possible but..:-)
>
> bee-oh-dubble-bee-dubble-egh
>
>
> >From: "Kelly, Steve" <[EMAIL PROTECTED]>
> >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: Questionable MQ infrastructure design
> >Date: Mon, 14 Jul 2003 17:26:01 -0400
> >
> >Interesting. Agree with channel names but queue names ? In a
> >service-oriented architecture don't you want your queue names to
identify
> >the shared service they drive. So, for example, UPDATE.NAME.AND.ADDRESS,
> >CREDIT.MY.ACCOUNT etc. When we are all trying to maximise re-use do we
> >really care who the sending application is? Yes, you'll want to know if
> >something goes wrong, but do you need it in the queue name ?
> >
> >Steve.
> >
> >-Original Message-
> >From: Robert Broderick [mailto:[EMAIL PROTECTED]
> >Sent: 14 July 2003 12:15
> >To: [EMAIL PROTECTED]
> >Subject: Re: Questionable MQ infrastructure design
> >
> >
> >The Queue name I push when we a developing infrastructure is
> >SendingApp.ReceivingApp.AnythingYouWant
> >
> >Channels are generic-ly Sender.Receiver  with variations considered for
> >multiple QMGRS on the same box and testing cyclye (eg SandBox, Dev, SIT,
> >UAT, QA, Prod, DR)
> >
> >
>bobbee
> >
> >
> > >From: [EMAIL PROTECTED]
> > >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> > >To: [EMAIL PROTECTED]
> > >Subject: Re: Questionable MQ infrastructure design
> > >Date: Sun, 13 Jul 2003 18:01:36 +1000
> > >
> > >Hi,
> > >
> > >We have a similar name scheme for channels except much shorter
> >SRC_DST
> > >and optionallyPROD_SRC_DST, not by application though.
> > >
> > >For queues,we normally use a qualifier on the end of the queue
>name/type
> > >for
> > >the type of data i.e.
> > >
> > >ie  app_type.pgp   (PGP encrypted data)
> > >app_type_subtype.xml
> > >
> > >etc
> > >
> > >Same goes for Transmission queues and initiation queues
> > >
> > >app_process.initq
> > >app_process.txq
> > >
> > >I think you can see the pattern..
> > >
> > >
> > >Sid
> > >
> > >
> > >
> > >-Original Message-
> > >From: Armand ten Dam [mailto:[EMAIL PROTECTED]
> > >Sent: Thursday, 10 July 2003 10:58 AM
> > >To: [EMAIL PROTECTED]
> > >Subject: Questionable MQ infrastructure design
> > >
> > >
> > >Hi all,
> > >For an integration project I have been asked to adopt an MQ naming
> >standard
> > >that reflects a very unusual approach in MQ-based integration. I have
> >never
> > >seen this approach before and have serious concerns in adopting any of
> >it.
> > >
> > >Key in the design is the u

Re: Questionable MQ infrastructure design

[Robert Broderick]

Aliases!! YuckWhat a deplorable thing!!


From: Rick Tsujimoto <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design
Date: Tue, 15 Jul 2003 09:24:24 -0400
Isn't that why we have QALIASes?  One for the programmers, and one for us.



  Robert Broderick
  <[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
  OTMAIL.COM>cc:
  Sent by: MQSeries  Subject: Re: Questionable
MQ infrastructure design
  List
  <[EMAIL PROTECTED]
  .AC.AT>
  07/15/2003 07:09
  AM
  Please respond to
  MQSeries List




Try to debug a service oriented at 3:00AM when all you got is a queue name
to go on and your critical financial start-of-day application is getting a
bad data enima and your application SME has had enough of his/her crappy
job
and busted the batteries out of their beeper.
I understand that in this age of OVER doing things and making everything
nicey nice and looking like we all got degrees from MIT. BUT...what often
is
best is the KISS method.
I have been in these situations and what people take for granted when
naming
"BUSINESS OBJECT" sort of eludes the actual person who is harpooned with
the
process of figuring out what the problem. And also from experience it isn't
the MSTER of names that will take the heat for the application /
infrasturcture not working.
We do a better job if we design and NAME system that are a little less
abstract and a lot more realistic. I know that sometimes this is not
possible but..:-)
bee-oh-dubble-bee-dubble-egh

>From: "Kelly, Steve" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Questionable MQ infrastructure design
>Date: Mon, 14 Jul 2003 17:26:01 -0400
>
>Interesting. Agree with channel names but queue names ? In a
>service-oriented architecture don't you want your queue names to identify
>the shared service they drive. So, for example, UPDATE.NAME.AND.ADDRESS,
>CREDIT.MY.ACCOUNT etc. When we are all trying to maximise re-use do we
>really care who the sending application is? Yes, you'll want to know if
>something goes wrong, but do you need it in the queue name ?
>
>Steve.
>
>-Original Message-
>From: Robert Broderick [mailto:[EMAIL PROTECTED]
>Sent: 14 July 2003 12:15
>To: [EMAIL PROTECTED]
>Subject: Re: Questionable MQ infrastructure design
>
>
>The Queue name I push when we a developing infrastructure is
>SendingApp.ReceivingApp.AnythingYouWant
>
>Channels are generic-ly Sender.Receiver  with variations considered for
>multiple QMGRS on the same box and testing cyclye (eg SandBox, Dev, SIT,
>UAT, QA, Prod, DR)
>
>
bobbee
>
>
> >From: [EMAIL PROTECTED]
> >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: Questionable MQ infrastructure design
> >Date: Sun, 13 Jul 2003 18:01:36 +1000
> >
> >Hi,
> >
> >We have a similar name scheme for channels except much shorter
>SRC_DST
> >and optionallyPROD_SRC_DST, not by application though.
> >
> >For queues,we normally use a qualifier on the end of the queue
name/type
> >for
> >the type of data i.e.
> >
> >ie  app_type.pgp   (PGP encrypted data)
> >app_type_subtype.xml
> >
> >etc
> >
> >Same goes for Transmission queues and initiation queues
> >
> >app_process.initq
> >app_process.txq
> >
> >I think you can see the pattern..
> >
> >
> >Sid
> >
> >
> >
> >-Original Message-
> >From: Armand ten Dam [mailto:[EMAIL PROTECTED]
> >Sent: Thursday, 10 July 2003 10:58 AM
> >To: [EMAIL PROTECTED]
> >Subject: Questionable MQ infrastructure design
> >
> >
> >Hi all,
> >For an integration project I have been asked to adopt an MQ naming
>standard
> >that reflects a very unusual approach in MQ-based integration. I have
>never
> >seen this approach before and have serious concerns in adopting any of
>it.
> >
> >Key in the design is the use of separate queue managers for each
> >application
> >pair. E.g. if an application interfaces with eight different
distributed
> >applications this would result in eight separate queue managers on a
>single
> >system.
> >
> >Some examples:
> >Queue manager:
> >QMPROD.SOURCECOMPANY.SOURCEAPP.TARGETCOMPANY.TARGETAPP.SYSTEMNAME
> >Channel:
> >CHPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP
> >Transmission queue:
> >TXPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP
> >...
> >
> >Obviously this does not reflect best-practice, seriously impacts
> >scalability, makes support of the MQ infrastructure difficult etc.
> >
> >As it looks like it will be a bit of a political discussion to get this
>out
> >of the way,
> >I am looking to gather as much 'neutral' feedback to bac

Re: UNSUBSCRIBE

[Bullock, Rebecca (CSC)]

Here's what you need to do:

You  may leave  the list  at  any time  by sending  a "SIGNOFF  MQSERIES"
command to  [EMAIL PROTECTED]

Do NOT send this to [EMAIL PROTECTED]; that won't get you off this
listserv, it'll only send your wish to do so to everyone on the list.


-Original Message-
From: Kinlen, Dan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 11:12 AM
To: [EMAIL PROTECTED]
Subject: UNSUBSCRIBE


UNSUBSCRIBE


RBC Dain Rauscher does not accept buy, sell or cancel orders by e-mail, or
any instructions by e-mail that would require your signature.  Information
contained in this communication is not considered an official record of your
account and does not supersede normal trade confirmations or statements.
Any information provided has been prepared from sources believed to be
reliable but is not guaranteed, does not represent all available data
necessary for making investment decisions and is for informational purposes
only.

This e-mail may be privileged and/or confidential, and the sender does not
waive any related rights and obligations.  Any distribution, use or copying
of this e-mail or the information it contains by other than an intended
recipient is unauthorized.  If you receive this e-mail in error, please
advise me (by return e-mail or otherwise) immediately.

Information received by or sent from this system is subject to review by
supervisory personnel, is retained and may be produced to regulatory
authorities or others with a legal right to the information.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive



**
This e-mail and any files transmitted with it may contain privileged or
confidential information. It is solely for use by the individual for whom
it is intended, even if addressed incorrectly. If you received this e-mail
in error, please notify the sender; do not disclose, copy, distribute, or
take any action in reliance on the contents of this information; and delete
it from your system. Any other use of this e-mail is prohibited. Thank you
for your compliance.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

UNSUBSCRIBE

[Kinlen, Dan]

UNSUBSCRIBE


RBC Dain Rauscher does not accept buy, sell or cancel orders by e-mail, or any 
instructions by e-mail that would require your signature.  Information contained in 
this communication is not considered an official record of your account and does not 
supersede normal trade confirmations or statements.  Any information provided has been 
prepared from sources believed to be reliable but is not guaranteed, does not 
represent all available data necessary for making investment decisions and is for 
informational purposes only.

This e-mail may be privileged and/or confidential, and the sender does not waive any 
related rights and obligations.  Any distribution, use or copying of this e-mail or 
the information it contains by other than an intended recipient is unauthorized.  If 
you receive this e-mail in error, please advise me (by return e-mail or otherwise) 
immediately.

Information received by or sent from this system is subject to review by supervisory 
personnel, is retained and may be produced to regulatory authorities or others with a 
legal right to the information.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Questionable MQ infrastructure design

[Scott Gray]

We have very similar requirements...We decided on acquiring CommerceQuests
DataIntegrator product which gives us single file, full directory level
transfer, full PDS transfers, message to file, file to messages, etc...Its
also as scalable as your machines will allow and can accomodate as many
parallel xfers as you like.   We implemented a class of service type
configuration and we now do many thousands of files up to 100MB daily
without impacting our real time interfaces on the same QMs.

Scott

-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of
O'Keeffe, Michael
Sent: Tuesday, July 15, 2003 9:29 AM
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design


Thanks to everybody for the ideas on this - I wasn't aware that you could
use parallel channels and xmitqs.

The documents we are processing are similar to Jim's.  These are assorted
financing documents and images combined into a single PDF (depending on
whether you are say, Enron, or a little guy - hence the +70MB range,
although most are <5MB).  We didn't have much leeway with the back-end
system, the original design called for FTPing a directory of documents and
images to our server, however the assured delivery of MQ seemed like a good
fit since this was a fee based service and we didn't want to lose the order
nor the orderitems.  The receiving application is a WebSphere Commerce Suite
app, which handles the shopping cart details.

-Original Message-
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Monday, July 14, 2003 4:58 PM
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design


In our case, we need to store loan-related documents for 7 years.
These are things like HTML, TIFs, Word docs, etc., and can be as big
as 40M although most of them are substantially smaller. Our client
application is totally MQ-centric (the developers love the product),
and they use MQ to save the documents and to retrieve them when
needed.

I wasn't originally thrilled with using this method, but it's been as
successful as anything else would have been. The documents were
originally stored on a Windows file server. The Windows guys decided
it was too much work to manage all of the documents, and told the
developers they needed to go elsewhere with them. So they've been
stored as BLOBs in a RDBMS for the last year. This approach hasn't
been cost effective, so next month we'll be storing them on one of
EMC's mass storage products. Using MQ let us do all of this without
altering the client application, and that's a huge plus.

I agree with the others who said to have a second pair of channels and
XMITQs for the big messages. It prevents the 'normal' channels from
getting constipated, and lets you tune high service time, batch size,
etc.




  "Kelly, Steve"
  <[EMAIL PROTECTED]To:
[EMAIL PROTECTED]
  EQUEST.COM> cc:
  Sent by: MQSeries   Subject:  Re: Questionable
MQ infrastructure design
  List
  <[EMAIL PROTECTED]
  C.AT>


  07/14/2003 04:40 PM
  Please respond to
  MQSeries List






I wouldn't have separate queue managers but would use separate
channels for different class of service requirements.

One thing that always intrigues me is the size of messages some people
are moving around. I've always used MQ messages as the input that
drives a transaction / program. A bit like how terminal input will
drive a transaction. So a few K at most. So, what's in your (and
indeed anyone else with big messages) 70Meg ? And what application is
at the receiving end to process it ?

Steve.

-Original Message-
From: O'Keeffe, Michael [mailto:[EMAIL PROTECTED]
Sent: 14 July 2003 16:34
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design


Here's another twist to this QM subject: what about a system which
sends
varying messages over MQ?  Most messages are simple 2k request-reply,
but
when a customer requests a document the message will range up to 70MB
(!),
with average document(message) about 5MB.  The 2k messages need to
fast (web
interface), however the document messages are low priority (user can
check
back for their order).

What's the best way to handle this with MQ?  Separate Queue Managers
(with
separate channels) for the documents?  Use the same QM, but use MQ's
message
segmenting feature, and low priority for the document messages?

-Mike

-Original Message-
From: Vitaliy Ilyin [mailto:[EMAIL PROTECTED]
Sent: Friday, July 11, 2003 6:10 PM
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design


I've seen a lot of responses to thisone which is
actually very ineresting discusion topic.
Most of responses concentrate on
1) resource usage on the server running multiple QMgrs
2) 20char limit to the channel names
3) It desn't hav

UNSUBSCRIBE

[Peterson, Steven C.]

UNSUBSCRIBE

Re: Questionable MQ infrastructure design

[O'Keeffe, Michael]

Thanks to everybody for the ideas on this - I wasn't aware that you could
use parallel channels and xmitqs.

The documents we are processing are similar to Jim's.  These are assorted
financing documents and images combined into a single PDF (depending on
whether you are say, Enron, or a little guy - hence the +70MB range,
although most are <5MB).  We didn't have much leeway with the back-end
system, the original design called for FTPing a directory of documents and
images to our server, however the assured delivery of MQ seemed like a good
fit since this was a fee based service and we didn't want to lose the order
nor the orderitems.  The receiving application is a WebSphere Commerce Suite
app, which handles the shopping cart details.

-Original Message-
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Monday, July 14, 2003 4:58 PM
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design


In our case, we need to store loan-related documents for 7 years.
These are things like HTML, TIFs, Word docs, etc., and can be as big
as 40M although most of them are substantially smaller. Our client
application is totally MQ-centric (the developers love the product),
and they use MQ to save the documents and to retrieve them when
needed.

I wasn't originally thrilled with using this method, but it's been as
successful as anything else would have been. The documents were
originally stored on a Windows file server. The Windows guys decided
it was too much work to manage all of the documents, and told the
developers they needed to go elsewhere with them. So they've been
stored as BLOBs in a RDBMS for the last year. This approach hasn't
been cost effective, so next month we'll be storing them on one of
EMC's mass storage products. Using MQ let us do all of this without
altering the client application, and that's a huge plus.

I agree with the others who said to have a second pair of channels and
XMITQs for the big messages. It prevents the 'normal' channels from
getting constipated, and lets you tune high service time, batch size,
etc.




  "Kelly, Steve"
  <[EMAIL PROTECTED]To:
[EMAIL PROTECTED]
  EQUEST.COM> cc:
  Sent by: MQSeries   Subject:  Re: Questionable
MQ infrastructure design
  List
  <[EMAIL PROTECTED]
  C.AT>


  07/14/2003 04:40 PM
  Please respond to
  MQSeries List






I wouldn't have separate queue managers but would use separate
channels for different class of service requirements.

One thing that always intrigues me is the size of messages some people
are moving around. I've always used MQ messages as the input that
drives a transaction / program. A bit like how terminal input will
drive a transaction. So a few K at most. So, what's in your (and
indeed anyone else with big messages) 70Meg ? And what application is
at the receiving end to process it ?

Steve.

-Original Message-
From: O'Keeffe, Michael [mailto:[EMAIL PROTECTED]
Sent: 14 July 2003 16:34
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design


Here's another twist to this QM subject: what about a system which
sends
varying messages over MQ?  Most messages are simple 2k request-reply,
but
when a customer requests a document the message will range up to 70MB
(!),
with average document(message) about 5MB.  The 2k messages need to
fast (web
interface), however the document messages are low priority (user can
check
back for their order).

What's the best way to handle this with MQ?  Separate Queue Managers
(with
separate channels) for the documents?  Use the same QM, but use MQ's
message
segmenting feature, and low priority for the document messages?

-Mike

-Original Message-
From: Vitaliy Ilyin [mailto:[EMAIL PROTECTED]
Sent: Friday, July 11, 2003 6:10 PM
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design


I've seen a lot of responses to thisone which is
actually very ineresting discusion topic.
Most of responses concentrate on
1) resource usage on the server running multiple QMgrs
2) 20char limit to the channel names
3) It desn't have any sense to run multiple QMgrs on
the same server because whatever happens to that
server happens to all the QMgrs

Now, I'd like to through in couple considerations.
Let's say that your company provides services to
multiple external clients and you want to separate
these clients by SSL.
3) What happens if your single QMgr goes down? The
answer is that this event affects all of your
customers. You can argue that you don't have a single
QMgr but multiple may be even clustered QMgrs and your
MQ client apps can switch over from that failed QMgr
to the other. But the point is that ALL of your
customers will be affected.
What if one of your customers' message traffic
requirements just increased 10 times and

Re: Resume message receive

[Rick Tsujimoto]

I think the original poster was asking for something that requires a
checkpoint and restart capability.  AFAIK, nothing straight out of the box
can meet his/her requirement.  Perhaps there's a package out there that
does.




  "David C.
  Partridge" To:  [EMAIL PROTECTED]
  <[EMAIL PROTECTED] cc:
  RIMEUR.COM>Subject: Re: Resume message receive
  Sent by: MQSeries
  List
  <[EMAIL PROTECTED]
  .AC.AT>


  07/15/2003 04:23
  AM
  Please respond to
  MQSeries List





So long as this is application driven segmentation, and you restrict your
segments to the order of 28-30kB (I'd err on the low end) this should work.
Assuming TCP/IP transport the buffer used by the channel is 32kB, but you
need to add some space for the marshalled API parameters.

To avoid loss, you'd also need to investigate the use of syncpoint, and
have
the application keep track of what segments it has committed so far.

Dave

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: Questionable MQ infrastructure design

[Rick Tsujimoto]

Isn't that why we have QALIASes?  One for the programmers, and one for us.




  Robert Broderick
  <[EMAIL PROTECTED] To:  [EMAIL PROTECTED]
  OTMAIL.COM>cc:
  Sent by: MQSeries  Subject: Re: Questionable MQ 
infrastructure design
  List
  <[EMAIL PROTECTED]
  .AC.AT>


  07/15/2003 07:09
  AM
  Please respond to
  MQSeries List





Try to debug a service oriented at 3:00AM when all you got is a queue name
to go on and your critical financial start-of-day application is getting a
bad data enima and your application SME has had enough of his/her crappy
job
and busted the batteries out of their beeper.

I understand that in this age of OVER doing things and making everything
nicey nice and looking like we all got degrees from MIT. BUT...what often
is
best is the KISS method.

I have been in these situations and what people take for granted when
naming
"BUSINESS OBJECT" sort of eludes the actual person who is harpooned with
the
process of figuring out what the problem. And also from experience it isn't
the MSTER of names that will take the heat for the application /
infrasturcture not working.

We do a better job if we design and NAME system that are a little less
abstract and a lot more realistic. I know that sometimes this is not
possible but..:-)

bee-oh-dubble-bee-dubble-egh


>From: "Kelly, Steve" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Questionable MQ infrastructure design
>Date: Mon, 14 Jul 2003 17:26:01 -0400
>
>Interesting. Agree with channel names but queue names ? In a
>service-oriented architecture don't you want your queue names to identify
>the shared service they drive. So, for example, UPDATE.NAME.AND.ADDRESS,
>CREDIT.MY.ACCOUNT etc. When we are all trying to maximise re-use do we
>really care who the sending application is? Yes, you'll want to know if
>something goes wrong, but do you need it in the queue name ?
>
>Steve.
>
>-Original Message-
>From: Robert Broderick [mailto:[EMAIL PROTECTED]
>Sent: 14 July 2003 12:15
>To: [EMAIL PROTECTED]
>Subject: Re: Questionable MQ infrastructure design
>
>
>The Queue name I push when we a developing infrastructure is
>SendingApp.ReceivingApp.AnythingYouWant
>
>Channels are generic-ly Sender.Receiver  with variations considered for
>multiple QMGRS on the same box and testing cyclye (eg SandBox, Dev, SIT,
>UAT, QA, Prod, DR)
>
>bobbee
>
>
> >From: [EMAIL PROTECTED]
> >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: Questionable MQ infrastructure design
> >Date: Sun, 13 Jul 2003 18:01:36 +1000
> >
> >Hi,
> >
> >We have a similar name scheme for channels except much shorter
>SRC_DST
> >and optionallyPROD_SRC_DST, not by application though.
> >
> >For queues,we normally use a qualifier on the end of the queue name/type
> >for
> >the type of data i.e.
> >
> >ie  app_type.pgp   (PGP encrypted data)
> >app_type_subtype.xml
> >
> >etc
> >
> >Same goes for Transmission queues and initiation queues
> >
> >app_process.initq
> >app_process.txq
> >
> >I think you can see the pattern..
> >
> >
> >Sid
> >
> >
> >
> >-Original Message-
> >From: Armand ten Dam [mailto:[EMAIL PROTECTED]
> >Sent: Thursday, 10 July 2003 10:58 AM
> >To: [EMAIL PROTECTED]
> >Subject: Questionable MQ infrastructure design
> >
> >
> >Hi all,
> >For an integration project I have been asked to adopt an MQ naming
>standard
> >that reflects a very unusual approach in MQ-based integration. I have
>never
> >seen this approach before and have serious concerns in adopting any of
>it.
> >
> >Key in the design is the use of separate queue managers for each
> >application
> >pair. E.g. if an application interfaces with eight different distributed
> >applications this would result in eight separate queue managers on a
>single
> >system.
> >
> >Some examples:
> >Queue manager:
> >QMPROD.SOURCECOMPANY.SOURCEAPP.TARGETCOMPANY.TARGETAPP.SYSTEMNAME
> >Channel:
> >CHPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP
> >Transmission queue:
> >TXPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP
> >...
> >
> >Obviously this does not reflect best-practice, seriously impacts
> >scalability, makes support of the MQ infrastructure difficult etc.
> >
> >As it looks like it will be a bit of a political discussion to get this
>out
> >of the way,
> >I am looking to gather as much 'neutral' feedback to back me up. I would
> >appreciate it if some of you could shed some more light on the
>implications
> >of the above approach.
> >
> >Any insights much appreciated,
> >Thanks,
> >Armand
> 

Re: Questionable MQ infrastructure design

[Rick Tsujimoto]

I don't think you could attribute this frame of mind with being "
mainfram-ish".  On most m/f's you tend to see many address spaces, running
many instances of a subsystem, such as CICS.  From the IT perspective, you
could probably consolidate many of those subsystems into fewer ones, but
then you'd have many political battles to fight.  The customer is always
right, even if IT disagrees with them.

I think mind set you're alluding is more common with the distributed boxes,
where resources tend to be more limited.




  Vitaliy Ilyin
  <[EMAIL PROTECTED] To:  [EMAIL PROTECTED]
  AHOO.COM>cc:
  Sent by: Subject: Re: Questionable MQ 
infrastructure design
  MQSeries List
  <[EMAIL PROTECTED]
  en.AC.AT>


  07/14/2003 10:43
  PM
  Please respond
  to MQSeries List





I find it intriguing how similar people think and
what's even more intersting is that IT IS difficult to
think out of the box.
We MQ people seem to think from the MQ perspective. If
you take one step back (or aside) you would agree that
even though from MQ perspective it makes sense to send
small dissociated "fire and forget" messages, from the
application perspective MQSeries is just a transport.
Yes, reliable, robust, providing that "assured, once
and only once" message delivery but still only a
transport.
That's where you start getting requirements for large
messages whether they are ftp files, XML files or
such.

Now, going back to multiple QMgrs on the same box.
It's exactly the same reason that most of MQers go
bizark when they here "multiple QMgr on the same box".
It partially comes from the mainfram-ish mentality.
Nothing wrong with that. But you have to think and
consider other options.
I'll give you one example of the "strange behavior"
that I've seen at one of the clients: one application
was trying to connect to the database that was down
w/out releasing MQHCONNs after every connect. Very
soon QMgr ran out of max client conns and noone and I
mean NO ONE client app including EXplorers could
connect to it. That single stupid app affected
everyone who was connecting to that QMgr.
Now recall those apps that forget to close a
transaction and it becomes along -playing playing one
again affecting everybody else.
...
Thanks, Vitaliy

--- "Kelly, Steve" <[EMAIL PROTECTED]>
wrote:
> I wouldn't have separate queue managers but would
> use separate channels for different class of service
> requirements.
>
> One thing that always intrigues me is the size of
> messages some people are moving around. I've always
> used MQ messages as the input that drives a
> transaction / program. A bit like how terminal input
> will drive a transaction. So a few K at most. So,
> what's in your (and indeed anyone else with big
> messages) 70Meg ? And what application is at the
> receiving end to process it ?
>
> Steve.


=
Vitaliy Ilyin

Principal Middleware Architect
IBM Certified Solutions Expert  -   WMQ   (MQSeries v5.3)
  &  WMQI (WebSphereMQ
Integrator)
IBM Certified Specialist-   WMQ  (MQSeries v5.3)
  & WMQI  (WebSphereMQ
Integrator)
IBM Certified Developer   -  WMQI (MQSeries v5.2)
781-363-3474 http://www.ICnowledge.com

__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

UNSUBSCRIBE

[Kinlen, Dan]

RBC Dain Rauscher does not accept buy, sell or cancel orders by e-mail, or any 
instructions by e-mail that would require your signature.  Information contained in 
this communication is not considered an official record of your account and does not 
supersede normal trade confirmations or statements.  Any information provided has been 
prepared from sources believed to be reliable but is not guaranteed, does not 
represent all available data necessary for making investment decisions and is for 
informational purposes only.

This e-mail may be privileged and/or confidential, and the sender does not waive any 
related rights and obligations.  Any distribution, use or copying of this e-mail or 
the information it contains by other than an intended recipient is unauthorized.  If 
you receive this e-mail in error, please advise me (by return e-mail or otherwise) 
immediately.

Information received by or sent from this system is subject to review by supervisory 
personnel, is retained and may be produced to regulatory authorities or others with a 
legal right to the information.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: A double cluster to get 2 CLUSRCVR channels?

[Potkay, Peter M (PLC, IT)]

OK, so there are multiple MCAs (one for each dynamically created CLUSSNDR)
all servicing the one S.C.T.Q, and they should be able to do their work
independently, right?

I plan on testing this in my lab environment and posting the results when I
yank the cables from the server to the SAN. I just wanted to get a feel from
the list as to whether this was possible and worth testing. I'll see what
other posts come about today and tomorrow (Morag???  :-)) and then test
later in the week.





-Original Message-
From: Raabe, Stefan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 8:58 AM
To: [EMAIL PROTECTED]
Subject: AW: A double cluster to get 2 CLUSRCVR channels?


Peter, 

a message destigned for a "remote" cluster queue gets a target 
queue assinged and a cluster channel to use and is then put to
the SYSTEM.CLUSTER.TRANSMIT.QUEUE.
I assume, that every mca gets only the messages that are
assigned to its channel. On os/390, the correlid field holds
the channel name and the S.C.T.Q is indexed by correlid, it
is most likely that the mca does a get by correlid to pick 
up the proper messages.

You share the S.C.T.Q queue between the cluster channels,
so you share the storage, but i do not think that the P
and NP messages will be mixed over the channels because
the target queue is not known in the other cluster.

Regards
Stefan


-Ursprüngliche Nachricht-
Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 15. Juli 2003 14:29
An: [EMAIL PROTECTED]
Betreff: Re: A double cluster to get 2 CLUSRCVR channels?


I plan on separating the queues into the proper cluster.

Queues that deal only with NP messages will be in CLUSTER1, and queues that
deal with both P and NP messages will live in the other cluster.

The goal being that WITHOUT replacing the standard cluster workload exit, NP
messages destined for queues in CLUSTER1 will not be effected by channel
problems in CLUSTER2. These channel "problems" could be large messages
taking their time, or P messages holding up both P and NP messages while the
P message waits to be logged on the receiving side.

The only doubt I have is the fact that there is one common XMIT queue in
this case (SYSTEM.CLUSTER.TRANSMIT.QUEUE) being serviced by 2 or more
channels.



**
I got to think that one message at the head of the
SYSTEM.CLUSTER.TRANSMIT.QUEUE that is held up for whatever reason would not
impeded others behind it destined for other channels to other QMs in the
same cluster or other channels in other overlapping clusters.
**



-Original Message-
From: Neil Casey [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 12:30 AM
To: [EMAIL PROTECTED]
Subject: Re: A double cluster to get 2 CLUSRCVR channels?


Hi Peter,

you design pretty much pans out Ok. This is actually similar to the way we
set up our clusters here. Our reasons for separating out the cluster
channels are different (security rather than performance) but the result is
the same.

You might find that you need to use a cluster workload balancing exit to
force the correct choice of cluster.

If you are sending to a cluster queue (a request) and that queue is defined
in only one of the clusters, then you will be fine. If you want to make the
choice based not on the queue, but instead on the message size, then you
will need to open your queues with bind(notfixed) and use the cluster
workload exit to make the choice.

If you are sending a response, based on the replyToQ and replyToQMgr
fields, then either cluster is a valid choice, and the workload balancing
algorithm gets to make the choice. The IBM default algorithm may not be
able to make the choice that you want, in which case you will need to write
or buy a workload balancing exit. This can also happen in an environment
where the destination for a message is looked up in an external database
(like LDAP) and the target queue manager and queue are both specified.

Regards,

Neil Casey.


|-+-->
| |   "Potkay, Peter M   |
| |   (PLC, IT)" |
| |   <[EMAIL PROTECTED]|
| |   RTFORD.COM>|
| |   Sent by: MQSeries  |
| |   List   |
| |   <[EMAIL PROTECTED]|
| |   AC.AT> |
| |  |
| |  |
| |   15/07/2003 13:09   |
| |   Please respond to  |
| |   MQSeries List  |
| |  |
|-+-->

>---
---|
  |
|
  |   To:   [EMAIL PROTECTED]
|
  |   cc:
|
  |   Subject:  A double cluster to get 2 CLUSRCVR channels?
|

>---
---

Re: MQ Design Query # Repost

[Pavel Tolkachev]

Hello Vitaly,

I cannot answer everything, just some:

1. N/A :-)
2. I am not sure exactly what purposes you mean. You may look at 
http://enterprise.aim.com/docs/cms/ as an example of what they call "certificate 
management system". Also look at RSA ClearTrust family of products.
3. I am not aware of any difference except for a Java clients. On java clients, Sun's 
native JSSE only supports certificates stored in JKS (Java Key Store). But you can 
install 3rd paty security providers supporting other format (including the one from 
IBM that, I guess, supports CMS format -- but I could never get it working -- not that 
I tried too hard..).
4. I am not sure what do you mean -- CA software or CA itself (Verisign?) so I assume 
the former. IBM's iKeyman (iKeycmd) included with MQSeries is very slow but I could 
not yet find another one supporting that CMS format (maybe AOL's mentioned in 2. does, 
but I am not sure). Openssl seems to be a pretty decent (and fast!) command-line tool 
providing CA functionality for free. RSA offers Keon (some vendors incorporate it in 
their products). BTW, If you find any tool that can support CMS format required by MQ 
servers, please let me know.

Actually, iKeycmd allows me to do all I need for CA (well, almost), it is just too 
slow to play with. However, as soon as the infrastructure is established it may be 
quite acceptable.

Hopefully it will help a little bit.
Pavel





  Vitaliy Ilyin
  <[EMAIL PROTECTED]To:   [EMAIL PROTECTED]
  HOO.COM> cc:
  Sent by: MQSeriesSubject:  Re: MQ Design Query # Repost
  List
  <[EMAIL PROTECTED]
  n.AC.AT>


  07/14/2003 11:53
  PM
  Please respond to
  MQSeries List






Dear colleges,

HI

I have couple questions for you (after 3 Gin ad
Tonics);-), B-lo-o-o-be-e-e, you keep quite this time,
please.

1) Did anyone have any experiences with managing large
number of SSL certificates: both client-side and
server-side?
2) Is there any vendor's product(s) available for this
purpose?
3) What is the difference between server-side and
client-side certificate as far as MQ is concerned
(opposed to the web server vs web browser): both
technical and legal
4) Differences amongst CAs: Versing vs BSafe vs
etc

Thanks a lot,
Vitaliy



=
Vitaliy Ilyin

Principal Middleware Architect
IBM Certified Solutions Expert  -   WMQ   (MQSeries v5.3)
  &  WMQI (WebSphereMQ Integrator)
IBM Certified Specialist-   WMQ  (MQSeries v5.3)
  & WMQI  (WebSphereMQ Integrator)
IBM Certified Developer   -  WMQI (MQSeries v5.2)
781-363-3474 http://www.ICnowledge.com

__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive





--

This e-mail may contain confidential and/or privileged information. If you are not the 
intended recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

AW: A double cluster to get 2 CLUSRCVR channels?

[Raabe, Stefan]

Peter, 

a message destigned for a "remote" cluster queue gets a target 
queue assinged and a cluster channel to use and is then put to
the SYSTEM.CLUSTER.TRANSMIT.QUEUE.
I assume, that every mca gets only the messages that are
assigned to its channel. On os/390, the correlid field holds
the channel name and the S.C.T.Q is indexed by correlid, it
is most likely that the mca does a get by correlid to pick 
up the proper messages.

You share the S.C.T.Q queue between the cluster channels,
so you share the storage, but i do not think that the P
and NP messages will be mixed over the channels because
the target queue is not known in the other cluster.

Regards
Stefan


-Ursprüngliche Nachricht-
Von: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 15. Juli 2003 14:29
An: [EMAIL PROTECTED]
Betreff: Re: A double cluster to get 2 CLUSRCVR channels?


I plan on separating the queues into the proper cluster.

Queues that deal only with NP messages will be in CLUSTER1, and queues that
deal with both P and NP messages will live in the other cluster.

The goal being that WITHOUT replacing the standard cluster workload exit, NP
messages destined for queues in CLUSTER1 will not be effected by channel
problems in CLUSTER2. These channel "problems" could be large messages
taking their time, or P messages holding up both P and NP messages while the
P message waits to be logged on the receiving side.

The only doubt I have is the fact that there is one common XMIT queue in
this case (SYSTEM.CLUSTER.TRANSMIT.QUEUE) being serviced by 2 or more
channels.



**
I got to think that one message at the head of the
SYSTEM.CLUSTER.TRANSMIT.QUEUE that is held up for whatever reason would not
impeded others behind it destined for other channels to other QMs in the
same cluster or other channels in other overlapping clusters.
**



-Original Message-
From: Neil Casey [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 12:30 AM
To: [EMAIL PROTECTED]
Subject: Re: A double cluster to get 2 CLUSRCVR channels?


Hi Peter,

you design pretty much pans out Ok. This is actually similar to the way we
set up our clusters here. Our reasons for separating out the cluster
channels are different (security rather than performance) but the result is
the same.

You might find that you need to use a cluster workload balancing exit to
force the correct choice of cluster.

If you are sending to a cluster queue (a request) and that queue is defined
in only one of the clusters, then you will be fine. If you want to make the
choice based not on the queue, but instead on the message size, then you
will need to open your queues with bind(notfixed) and use the cluster
workload exit to make the choice.

If you are sending a response, based on the replyToQ and replyToQMgr
fields, then either cluster is a valid choice, and the workload balancing
algorithm gets to make the choice. The IBM default algorithm may not be
able to make the choice that you want, in which case you will need to write
or buy a workload balancing exit. This can also happen in an environment
where the destination for a message is looked up in an external database
(like LDAP) and the target queue manager and queue are both specified.

Regards,

Neil Casey.


|-+-->
| |   "Potkay, Peter M   |
| |   (PLC, IT)" |
| |   <[EMAIL PROTECTED]|
| |   RTFORD.COM>|
| |   Sent by: MQSeries  |
| |   List   |
| |   <[EMAIL PROTECTED]|
| |   AC.AT> |
| |  |
| |  |
| |   15/07/2003 13:09   |
| |   Please respond to  |
| |   MQSeries List  |
| |  |
|-+-->

>---
---|
  |
|
  |   To:   [EMAIL PROTECTED]
|
  |   cc:
|
  |   Subject:  A double cluster to get 2 CLUSRCVR channels?
|

>---
---|




3 QueueManagers (QMs) on 3 servers, QM1, QM2 and QMGateway.

QM1 has a CLUSRCVR called TO.QM1.CLUSTER1 which is in CLUSTER1. It also has
a CLUSRCVR called TO.QM1.CLUSTER2 which is in CLUSTER2.
QM1 is a full repository for a cluster name list called
CLUSTER1andCLUSTER2.

QM2 has a CLUSRCVR called TO.QM2.CLUSTER1 which is in CLUSTER1. It also has
a CLUSRCVR called TO.QM2.CLUSTER2 which is in CLUSTER2.
QM2 is a full repository for a cluster name list called
CLUSTER1andCLUSTER2.

QMGateway has a CLUSRCVR called TO.QMGateway.CLUSTER1 which is in CLUSTER1.
It also has a CLUSRCVR called TO.QMGateway.CLUSTER2 which is in CLUSTER2.


The point of all this 

Re: A double cluster to get 2 CLUSRCVR channels?

[Potkay, Peter M (PLC, IT)]

I plan on separating the queues into the proper cluster.

Queues that deal only with NP messages will be in CLUSTER1, and queues that
deal with both P and NP messages will live in the other cluster.

The goal being that WITHOUT replacing the standard cluster workload exit, NP
messages destined for queues in CLUSTER1 will not be effected by channel
problems in CLUSTER2. These channel "problems" could be large messages
taking their time, or P messages holding up both P and NP messages while the
P message waits to be logged on the receiving side.

The only doubt I have is the fact that there is one common XMIT queue in
this case (SYSTEM.CLUSTER.TRANSMIT.QUEUE) being serviced by 2 or more
channels.



**
I got to think that one message at the head of the
SYSTEM.CLUSTER.TRANSMIT.QUEUE that is held up for whatever reason would not
impeded others behind it destined for other channels to other QMs in the
same cluster or other channels in other overlapping clusters.
**



-Original Message-
From: Neil Casey [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 12:30 AM
To: [EMAIL PROTECTED]
Subject: Re: A double cluster to get 2 CLUSRCVR channels?


Hi Peter,

you design pretty much pans out Ok. This is actually similar to the way we
set up our clusters here. Our reasons for separating out the cluster
channels are different (security rather than performance) but the result is
the same.

You might find that you need to use a cluster workload balancing exit to
force the correct choice of cluster.

If you are sending to a cluster queue (a request) and that queue is defined
in only one of the clusters, then you will be fine. If you want to make the
choice based not on the queue, but instead on the message size, then you
will need to open your queues with bind(notfixed) and use the cluster
workload exit to make the choice.

If you are sending a response, based on the replyToQ and replyToQMgr
fields, then either cluster is a valid choice, and the workload balancing
algorithm gets to make the choice. The IBM default algorithm may not be
able to make the choice that you want, in which case you will need to write
or buy a workload balancing exit. This can also happen in an environment
where the destination for a message is looked up in an external database
(like LDAP) and the target queue manager and queue are both specified.

Regards,

Neil Casey.


|-+-->
| |   "Potkay, Peter M   |
| |   (PLC, IT)" |
| |   <[EMAIL PROTECTED]|
| |   RTFORD.COM>|
| |   Sent by: MQSeries  |
| |   List   |
| |   <[EMAIL PROTECTED]|
| |   AC.AT> |
| |  |
| |  |
| |   15/07/2003 13:09   |
| |   Please respond to  |
| |   MQSeries List  |
| |  |
|-+-->

>---
---|
  |
|
  |   To:   [EMAIL PROTECTED]
|
  |   cc:
|
  |   Subject:  A double cluster to get 2 CLUSRCVR channels?
|

>---
---|




3 QueueManagers (QMs) on 3 servers, QM1, QM2 and QMGateway.

QM1 has a CLUSRCVR called TO.QM1.CLUSTER1 which is in CLUSTER1. It also has
a CLUSRCVR called TO.QM1.CLUSTER2 which is in CLUSTER2.
QM1 is a full repository for a cluster name list called
CLUSTER1andCLUSTER2.

QM2 has a CLUSRCVR called TO.QM2.CLUSTER1 which is in CLUSTER1. It also has
a CLUSRCVR called TO.QM2.CLUSTER2 which is in CLUSTER2.
QM2 is a full repository for a cluster name list called
CLUSTER1andCLUSTER2.

QMGateway has a CLUSRCVR called TO.QMGateway.CLUSTER1 which is in CLUSTER1.
It also has a CLUSRCVR called TO.QMGateway.CLUSTER2 which is in CLUSTER2.


The point of all this is so I can have 2 different dynamically created
CLUSSNDR channels into each QM. I wish to do this for 2 reasons. First,
CLUSTER1 will only have queues and applications that deal with messages
greater than 50 MEG in size. CLUSTER2 will only deal with messages smaller
than 500 bytes in size (numbers have been exaggerated to make the point).
So
I would like to insure that the 50MEG lunkers do not block the 500 byte
peewees on the CLUSSNDRs as the big messages take their sweet time being
sent across.

Will my idea work? If I have 2 clusters, I should have 2 channels that
should not interfere with each other, correct? I wonder if the fact that
there is still only 1 SYSTEM.CLUSTER.TRANSMIT.QUEUE to be shared between
the
2 CLUSSNDRs will invalidate this concept (i.e. a message taking its sweet
time going down a CLUSSNDR in CLUSTER1 will prevent a little message
sitting
in the XMIT

Re: MQ Design Query # Repost

[Robert Broderick]

Before I zip up my lips are you eating Beet Borscht and watching TV
T?
ZPPP!


From: Vitaliy Ilyin <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: MQ Design Query # Repost
Date: Mon, 14 Jul 2003 20:53:11 -0700
Dear colleges,

HI

I have couple questions for you (after 3 Gin ad
Tonics);-), B-lo-o-o-be-e-e, you keep quite this time,
please.
1) Did anyone have any experiences with managing large
number of SSL certificates: both client-side and
server-side?
2) Is there any vendor's product(s) available for this
purpose?
3) What is the difference between server-side and
client-side certificate as far as MQ is concerned
(opposed to the web server vs web browser): both
technical and legal
4) Differences amongst CAs: Versing vs BSafe vs
etc
Thanks a lot,
Vitaliy


=
Vitaliy Ilyin

Principal Middleware Architect
IBM Certified Solutions Expert  -   WMQ   (MQSeries v5.3)
  &  WMQI (WebSphereMQ
Integrator)
IBM Certified Specialist-   WMQ  (MQSeries v5.3)
  & WMQI  (WebSphereMQ
Integrator)
IBM Certified Developer   -  WMQI (MQSeries v5.2)
781-363-3474 http://www.ICnowledge.com
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
_
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Re: Questionable MQ infrastructure design

[Robert Broderick]

Try to debug a service oriented at 3:00AM when all you got is a queue name
to go on and your critical financial start-of-day application is getting a
bad data enima and your application SME has had enough of his/her crappy job
and busted the batteries out of their beeper.
I understand that in this age of OVER doing things and making everything
nicey nice and looking like we all got degrees from MIT. BUT...what often is
best is the KISS method.
I have been in these situations and what people take for granted when naming
"BUSINESS OBJECT" sort of eludes the actual person who is harpooned with the
process of figuring out what the problem. And also from experience it isn't
the MSTER of names that will take the heat for the application /
infrasturcture not working.
We do a better job if we design and NAME system that are a little less
abstract and a lot more realistic. I know that sometimes this is not
possible but..:-)
   bee-oh-dubble-bee-dubble-egh


From: "Kelly, Steve" <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design
Date: Mon, 14 Jul 2003 17:26:01 -0400
Interesting. Agree with channel names but queue names ? In a
service-oriented architecture don't you want your queue names to identify
the shared service they drive. So, for example, UPDATE.NAME.AND.ADDRESS,
CREDIT.MY.ACCOUNT etc. When we are all trying to maximise re-use do we
really care who the sending application is? Yes, you'll want to know if
something goes wrong, but do you need it in the queue name ?
Steve.

-Original Message-
From: Robert Broderick [mailto:[EMAIL PROTECTED]
Sent: 14 July 2003 12:15
To: [EMAIL PROTECTED]
Subject: Re: Questionable MQ infrastructure design
The Queue name I push when we a developing infrastructure is
SendingApp.ReceivingApp.AnythingYouWant
Channels are generic-ly Sender.Receiver  with variations considered for
multiple QMGRS on the same box and testing cyclye (eg SandBox, Dev, SIT,
UAT, QA, Prod, DR)
   bobbee

>From: [EMAIL PROTECTED]
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Questionable MQ infrastructure design
>Date: Sun, 13 Jul 2003 18:01:36 +1000
>
>Hi,
>
>We have a similar name scheme for channels except much shorter
SRC_DST
>and optionallyPROD_SRC_DST, not by application though.
>
>For queues,we normally use a qualifier on the end of the queue name/type
>for
>the type of data i.e.
>
>ie  app_type.pgp   (PGP encrypted data)
>app_type_subtype.xml
>
>etc
>
>Same goes for Transmission queues and initiation queues
>
>app_process.initq
>app_process.txq
>
>I think you can see the pattern..
>
>
>Sid
>
>
>
>-Original Message-
>From: Armand ten Dam [mailto:[EMAIL PROTECTED]
>Sent: Thursday, 10 July 2003 10:58 AM
>To: [EMAIL PROTECTED]
>Subject: Questionable MQ infrastructure design
>
>
>Hi all,
>For an integration project I have been asked to adopt an MQ naming
standard
>that reflects a very unusual approach in MQ-based integration. I have
never
>seen this approach before and have serious concerns in adopting any of
it.
>
>Key in the design is the use of separate queue managers for each
>application
>pair. E.g. if an application interfaces with eight different distributed
>applications this would result in eight separate queue managers on a
single
>system.
>
>Some examples:
>Queue manager:
>QMPROD.SOURCECOMPANY.SOURCEAPP.TARGETCOMPANY.TARGETAPP.SYSTEMNAME
>Channel:
>CHPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP
>Transmission queue:
>TXPROD.SOURCECOMPANY.SOURCEAPP.TO.TARGETCOMPANY.TARGETAPP
>...
>
>Obviously this does not reflect best-practice, seriously impacts
>scalability, makes support of the MQ infrastructure difficult etc.
>
>As it looks like it will be a bit of a political discussion to get this
out
>of the way,
>I am looking to gather as much 'neutral' feedback to back me up. I would
>appreciate it if some of you could shed some more light on the
implications
>of the above approach.
>
>Any insights much appreciated,
>Thanks,
>Armand
>
>_
>Hot chart ringtones and polyphonics. Go to
>http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=174&referr
>al=Hotmail_taglines_plain&URL=http://ninemsn.com.au/mobilemania/default.asp
>
>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
_
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http:

Re: MQ Design Query # Repost

[David C. Partridge]

>you need a personal certificate (MQ does not seem to use Server type
>certificates at all).

Hmmm I accept that it will work with a Verisign Class 1 certificate.

The question is how much trust you are prepared to put in a certificate
where the process of identification is only "does the requestor have an
email address".   Personally I'd be more inclined to use Class 3
certificates for both MQI client and server, as the process is a bit
stronger.

Dave

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: Resume message receive

[David C. Partridge]

So long as this is application driven segmentation, and you restrict your
segments to the order of 28-30kB (I'd err on the low end) this should work.
Assuming TCP/IP transport the buffer used by the channel is 32kB, but you
need to add some space for the marshalled API parameters.

To avoid loss, you'd also need to investigate the use of syncpoint, and have
the application keep track of what segments it has committed so far.

Dave

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: Supported Versions

[Sony Varghese]

Hi Terry,

We are using the following but on AIX 5.1

WebSphere MQ V5.3
WebSphere Business Interchange Server V4.2 (Crossworlds)

Regards
Sony


-Original Message-
From: Terry Fors [mailto:[EMAIL PROTECTED]
Sent: 11 July 2003 16:46
To: [EMAIL PROTECTED]
Subject: Supported Versions


Is anyone using the following environment on AIX 5.2, or know if it is
supported?

WebSphere MQ V5.3
WebSphere Business Integration Broker V5.0
WebSphere Business Interchange Server V4.2 (Crossworlds)

Thanks

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

[Henttu Tuovi]

Title: Message