Integration with vendor product..

[Coombs, Lawrence]

I am working on an integration project with a vendor product and they would like to send me 11 MB messages over a client channel over a WAN . The queue manager is at WMQ 7.5.0.2. I am trying my best to discourage them from doing this, but so far I have been unsuccessful. I have suggested message grouping but they have no idea what I am talking about.

What are some technical reasons I could use to dissuade them from doing this?

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Bob Juch]

What are your reasons for your objection?

Bob Juch



On Thu, Jun 19, 2014 at 3:03 PM, Coombs, Lawrence <
Lawrence.Coombs-***@public.gmane.org> wrote:

> I am working on an integration project with a vendor product and they
> would like to send me 11 MB messages over a client channel over a WAN . The
> queue manager is at WMQ 7.5.0.2. I am trying my best to discourage them
> from doing this, but so far I have been unsuccessful. I have suggested
> message grouping but they have no idea what I am talking about.
>
>
>
> What are some technical reasons I could use to dissuade them from doing
> this?
> This message, including any attachments, is the property of Sears
> Holdings Corporation and/or one of its subsidiaries. It is confidential and
> may contain proprietary or legally privileged information. If you are not
> the intended recipient, please delete it without reading the contents.
> Thank you.
>
> ------------------------------
> List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage
> Your List Settings
> <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
> Unsubscribe
> <LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> <http://www.lsoft.com/resources/manuals.asp>
>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Coombs, Lawrence]

Network.

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Bob Juch
Sent: Thursday, June 19, 2014 2:06 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Integration with vendor product..

What are your reasons for your objection?

Bob Juch


On Thu, Jun 19, 2014 at 3:03 PM, Coombs, Lawrence <***@searshc.com<mailto:***@searshc.com>> wrote:
I am working on an integration project with a vendor product and they would like to send me 11 MB messages over a client channel over a WAN . The queue manager is at WMQ 7.5.0.2. I am trying my best to discourage them from doing this, but so far I have been unsuccessful. I have suggested message grouping but they have no idea what I am talking about.

What are some technical reasons I could use to dissuade them from doing this?
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Roger Lacroix]

Hi Lawrence,

A message of 11MB over a WAN is not a big deal. How many messages
per minute do you expect? If it is 1 per minute then it is not a big
deal, whereas if it is 100 per minute then maybe you have a point.

Besides, if they broke the message into segments, what is your
preferred message size? 1MB or 500KB or 75KB.

Regards,
Roger Lacroix
Capitalware Inc.

At 06:24 PM 6/19/2014, you wrote:
>Network.
>
>From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On
>Behalf Of Bob Juch
>Sent: Thursday, June 19, 2014 2:06 PM
>To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
>Subject: Re: Integration with vendor product..
>
>What are your reasons for your objection?
>
>Bob Juch
>
>
>On Thu, Jun 19, 2014 at 3:03 PM, Coombs, Lawrence
><<mailto:Lawrence.Coombs-***@public.gmane.org>Lawrence.Coombs-***@public.gmane.org> wrote:
>I am working on an integration project with a vendor product and
>they would like to send me 11 MB messages over a client channel over
>a WAN . The queue manager is at WMQ 7.5.0.2. I am trying my best to
>discourage them from doing this, but so far I have been
>unsuccessful. I have suggested message grouping but they have no
>idea what I am talking about.
>
>What are some technical reasons I could use to dissuade them from doing this?
>This message, including any attachments, is the property of Sears
>Holdings Corporation and/or one of its subsidiaries. It is
>confidential and may contain proprietary or legally privileged
>information. If you are not the intended recipient, please delete it
>without reading the contents. Thank you.
>
>
>----------
><http://listserv.meduniwien.ac.at/archives/mqser-l.html>List Archive
>-
><http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1>Manage
>Your List Settings -
><mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>Unsubscribe
>
>
>Instructions for managing your mailing list subscription are
>provided in the Listserv General Users Guide available at
><http://www.lsoft.com/resources/manuals.asp>http://www.lsoft.com
>
>
>
>----------
><http://listserv.meduniwien.ac.at/archives/mqser-l.html>List Archive
>-
><http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1>Manage
>Your List Settings -
><mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>Unsubscribe
>
>
>Instructions for managing your mailing list subscription are
>provided in the Listserv General Users Guide available at
><http://www.lsoft.com/resources/manuals.asp>http://www.lsoft.com
>This message, including any attachments, is the property of Sears
>Holdings Corporation and/or one of its subsidiaries. It is
>confidential and may contain proprietary or legally privileged
>information. If you are not the intended recipient, please delete it
>without reading the contents. Thank you.
>
>
>----------
><http://listserv.meduniwien.ac.at/archives/mqser-l.html>List Archive
>-
><http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1>Manage
>Your List Settings -
><mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>Unsubscribe
>
>
>Instructions for managing your mailing list subscription are
>provided in the Listserv General Users Guide available at
><http://www.lsoft.com/resources/manuals.asp>http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Coombs, Lawrence]

OK, you talked me down. We are talking about maybe < 50 per hour.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Roger Lacroix
Sent: Thursday, June 19, 2014 5:35 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Integration with vendor product..

Hi Lawrence,

A message of 11MB over a WAN is not a big deal. How many messages per minute do you expect? If it is 1 per minute then it is not a big deal, whereas if it is 100 per minute then maybe you have a point.

Besides, if they broke the message into segments, what is your preferred message size? 1MB or 500KB or 75KB.

Regards,
Roger Lacroix
Capitalware Inc.

At 06:24 PM 6/19/2014, you wrote:

Network.

From: MQSeries List [ mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Bob Juch
Sent: Thursday, June 19, 2014 2:06 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Integration with vendor product..

What are your reasons for your objection?

Bob Juch


On Thu, Jun 19, 2014 at 3:03 PM, Coombs, Lawrence < ***@searshc.com<mailto:Lawrence.Coombs-***@public.gmane.org>> wrote:
I am working on an integration project with a vendor product and they would like to send me 11 MB messages over a client channel over a WAN . The queue manager is at WMQ 7.5.0.2. I am trying my best to discourage them from doing this, but so far I have been unsuccessful. I have suggested message grouping but they have no idea what I am talking about.

What are some technical reasons I could use to dissuade them from doing this?
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Paul Clarke]

My concern with 11MB would just be the worry about what it might lead to. We all know that really large messages, eg 100MB, messages are bad, for all sorts of reasons. An 11MB message implies to me that the application is putting all it’s data in a single message. This therefore implies that the application has not been coded to send it’s data in chunks. So, the concern is that a request for 11MB today will be 22MB next year and 40MB in year after that.

In this day and age certainly 11MB is not a huge amount of data but it still causes MQ to do slightly unnatural things. Personally I would prefer it if the application sent 11 x 1MB messages. That way I would know that in 5 years time the application will still work just fine and they won’t start bitching to me that they can no longer fit all their data into a single 100MB message.

Cheers,
Paul.

Paul Clarke
www.mqgem.com

From: Coombs, Lawrence
Sent: Thursday, June 19, 2014 8:03 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Integration with vendor product..

I am working on an integration project with a vendor product and they would like to send me 11 MB messages over a client channel over a WAN . The queue manager is at WMQ 7.5.0.2. I am trying my best to discourage them from doing this, but so far I have been unsuccessful. I have suggested message grouping but they have no idea what I am talking about.



What are some technical reasons I could use to dissuade them from doing this?

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.



--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Potkay, Peter M (CTO Architecture + Engineering)]

“In this day and age certainly 11MB is not a huge amount of data but it still causes MQ to do slightly unnatural things.”

Do tell



Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Paul Clarke
Sent: Friday, June 20, 2014 2:09 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Integration with vendor product..

My concern with 11MB would just be the worry about what it might lead to. We all know that really large messages, eg 100MB, messages are bad, for all sorts of reasons. An 11MB message implies to me that the application is putting all it’s data in a single message. This therefore implies that the application has not been coded to send it’s data in chunks. So, the concern is that a request for 11MB today will be 22MB next year and 40MB in year after that.

In this day and age certainly 11MB is not a huge amount of data but it still causes MQ to do slightly unnatural things. Personally I would prefer it if the application sent 11 x 1MB messages. That way I would know that in 5 years time the application will still work just fine and they won’t start bitching to me that they can no longer fit all their data into a single 100MB message.

Cheers,
Paul.

Paul Clarke
www.mqgem.com<http://www.mqgem.com>

From: Coombs, Lawrence<mailto:***@SEARSHC.COM>
Sent: Thursday, June 19, 2014 8:03 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Integration with vendor product..

I am working on an integration project with a vendor product and they would like to send me 11 MB messages over a client channel over a WAN . The queue manager is at WMQ 7.5.0.2. I am trying my best to discourage them from doing this, but so far I have been unsuccessful. I have suggested message grouping but they have no idea what I am talking about.

What are some technical reasons I could use to dissuade them from doing this?
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Paul Clarke]

Well it’s nothing terribly exciting but you can imagine yourself the kinds of things that go on. When an application connects to MQ the MQI layer has to make all sorts of ‘guesses’ about what it might do and what messages it might be processing. It ‘assumes’ that messages will be less than 11MB. So, if it comes across a larger message then it has to do things slightly differently, quite probably allocating slightly more memory.

As I said before I don’t think 11MB messages are too bad. In terms of just raw speed of a single application I wouldn’t be surprised if an 11MB message is slightly faster than 11 x 1MB messages. However, this may not be the case as the message gets bigger and bigger. And bear in mind that the message is your unit of recovery. If you are sending this message over a client link then it may well be advantageous to send each 1MB separately. Certainly you wouldn’t want to send 100MB in one go since a comms failure after 99MB would mean retransmitting the entire thing.

At the end of the day it is down to individual preference and experimentation. MQ wouldn’t support 100MB if it were a truly awful thing to do, they just don’t recommend it. Not least of which is because it’s a hard stop. I think it unlikely that MQ will ever support message sizes bigger than 100MB. I think there is a need for bulk data transfer via MQ, perhaps a little like MFT, but I doubt it would be strictly message based. As a consequence any application needing to send large bits of information should, in my view, bite the bullet now and just design the application so the data can be segmented. After all, it’s not exactly hard. Better that than needing to send 101MB and the application and all the down stream applications that have been built up around it being SOL.

Cheers,
Paul.

Paul Clarke
www.mqgem.com

From: Potkay, Peter M (CTO Architecture + Engineering)
Sent: Friday, June 20, 2014 1:05 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Integration with vendor product..

“In this day and age certainly 11MB is not a huge amount of data but it still causes MQ to do slightly unnatural things.”



Do tell






Peter Potkay



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Paul Clarke
Sent: Friday, June 20, 2014 2:09 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Integration with vendor product..



My concern with 11MB would just be the worry about what it might lead to. We all know that really large messages, eg 100MB, messages are bad, for all sorts of reasons. An 11MB message implies to me that the application is putting all it’s data in a single message. This therefore implies that the application has not been coded to send it’s data in chunks. So, the concern is that a request for 11MB today will be 22MB next year and 40MB in year after that.



In this day and age certainly 11MB is not a huge amount of data but it still causes MQ to do slightly unnatural things. Personally I would prefer it if the application sent 11 x 1MB messages. That way I would know that in 5 years time the application will still work just fine and they won’t start bitching to me that they can no longer fit all their data into a single 100MB message.



Cheers,
Paul.



Paul Clarke
www.mqgem.com



From: Coombs, Lawrence

Sent: Thursday, June 19, 2014 8:03 PM

To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org

Subject: Re: Integration with vendor product..



I am working on an integration project with a vendor product and they would like to send me 11 MB messages over a client channel over a WAN . The queue manager is at WMQ 7.5.0.2. I am trying my best to discourage them from doing this, but so far I have been unsuccessful. I have suggested message grouping but they have no idea what I am talking about.



What are some technical reasons I could use to dissuade them from doing this?

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.




--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com




--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

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



--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Peter D]

Agree whole heartily - I have a client who's mq-fte fails 99x per day - Even tho FTE handles the packaging and repackaging it's still on a 'Queue' with a definition of ###. I can't imagine what would happen if that were a user app trying to do that process?!

Precedent setting in IT is many times a good move in order to prevent future headaches.

As Paul suggests - if I'm built to add on railroad cars of a certain length each time - I just add more as needed ... If I need to reset my track for a new size ... well ... That's ongoing construction.

/Pete

> On Jun 20, 2014, at 9:06 AM, Paul Clarke <paul.clarke85-C2P5NI4ZpDVm9/***@public.gmane.org> wrote:
>
> Well it’s nothing terribly exciting but you can imagine yourself the kinds of things that go on. When an application connects to MQ the MQI layer has to make all sorts of ‘guesses’ about what it might do and what messages it might be processing. It ‘assumes’ that messages will be less than 11MB. So, if it comes across a larger message then it has to do things slightly differently, quite probably allocating slightly more memory.
>
> As I said before I don’t think 11MB messages are too bad. In terms of just raw speed of a single application I wouldn’t be surprised if an 11MB message is slightly faster than 11 x 1MB messages. However, this may not be the case as the message gets bigger and bigger. And bear in mind that the message is your unit of recovery. If you are sending this message over a client link then it may well be advantageous to send each 1MB separately. Certainly you wouldn’t want to send 100MB in one go since a comms failure after 99MB would mean retransmitting the entire thing.
>
> At the end of the day it is down to individual preference and experimentation. MQ wouldn’t support 100MB if it were a truly awful thing to do, they just don’t recommend it. Not least of which is because it’s a hard stop. I think it unlikely that MQ will ever support message sizes bigger than 100MB. I think there is a need for bulk data transfer via MQ, perhaps a little like MFT, but I doubt it would be strictly message based. As a consequence any application needing to send large bits of information should, in my view, bite the bullet now and just design the application so the data can be segmented. After all, it’s not exactly hard. Better that than needing to send 101MB and the application and all the down stream applications that have been built up around it being SOL.
>
> Cheers,
> Paul.
>
> Paul Clarke
> www.mqgem.com
>
> From: Potkay, Peter M (CTO Architecture + Engineering)
> Sent: Friday, June 20, 2014 1:05 PM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Integration with vendor product..
>
> “In this day and age certainly 11MB is not a huge amount of data but it still causes MQ to do slightly unnatural things.”
>
> Do tell

>
>
> Peter Potkay
>
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Paul Clarke
> Sent: Friday, June 20, 2014 2:09 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Integration with vendor product..
>
> My concern with 11MB would just be the worry about what it might lead to. We all know that really large messages, eg 100MB, messages are bad, for all sorts of reasons. An 11MB message implies to me that the application is putting all it’s data in a single message. This therefore implies that the application has not been coded to send it’s data in chunks. So, the concern is that a request for 11MB today will be 22MB next year and 40MB in year after that.
>
> In this day and age certainly 11MB is not a huge amount of data but it still causes MQ to do slightly unnatural things. Personally I would prefer it if the application sent 11 x 1MB messages. That way I would know that in 5 years time the application will still work just fine and they won’t start bitching to me that they can no longer fit all their data into a single 100MB message.
>
> Cheers,
> Paul.
>
> Paul Clarke
> www.mqgem.com
>
> From: Coombs, Lawrence
> Sent: Thursday, June 19, 2014 8:03 PM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Integration with vendor product..
>
> I am working on an integration project with a vendor product and they would like to send me 11 MB messages over a client channel over a WAN . The queue manager is at WMQ 7.5.0.2. I am trying my best to discourage them from doing this, but so far I have been unsuccessful. I have suggested message grouping but they have no idea what I am talking about.
>
> What are some technical reasons I could use to dissuade them from doing this?
> This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.
>
> List Archive - Manage Your List Settings - Unsubscribe
> Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
>
>
> List Archive - Manage Your List Settings - Unsubscribe
> Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
>
> ************************************************************
> This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
> ************************************************************
>
>
> List Archive - Manage Your List Settings - Unsubscribe
> Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
>
>
> List Archive - Manage Your List Settings - Unsubscribe
> Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Coombs, Lawrence]

Paul – Your concern is right on. Initially the maximum message size was supposed to be 1 MB, until they tried to send an 11MB message and the queue manager/channel/queue were defined with the default of 4MB. After a heart to heart conversation, their argument was that they discovered on the internet that MQ can handle 100 MB message and so 11 MB should not be a problem.

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Paul Clarke
Sent: Friday, June 20, 2014 1:09 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Integration with vendor product..

My concern with 11MB would just be the worry about what it might lead to. We all know that really large messages, eg 100MB, messages are bad, for all sorts of reasons. An 11MB message implies to me that the application is putting all it’s data in a single message. This therefore implies that the application has not been coded to send it’s data in chunks. So, the concern is that a request for 11MB today will be 22MB next year and 40MB in year after that.

In this day and age certainly 11MB is not a huge amount of data but it still causes MQ to do slightly unnatural things. Personally I would prefer it if the application sent 11 x 1MB messages. That way I would know that in 5 years time the application will still work just fine and they won’t start bitching to me that they can no longer fit all their data into a single 100MB message.

Cheers,
Paul.

Paul Clarke
www.mqgem.com<http://www.mqgem.com>

From: Coombs, Lawrence<mailto:***@SEARSHC.COM>
Sent: Thursday, June 19, 2014 8:03 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Integration with vendor product..

I am working on an integration project with a vendor product and they would like to send me 11 MB messages over a client channel over a WAN . The queue manager is at WMQ 7.5.0.2. I am trying my best to discourage them from doing this, but so far I have been unsuccessful. I have suggested message grouping but they have no idea what I am talking about.

What are some technical reasons I could use to dissuade them from doing this?
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Edenfield, Lee]

I regularly deal with large messages. There are issues, but as long as the volume is low it usually works ok. If they are using client bindings, make sure the developers know that the risk of failure on a put or get operation increases with large message size and they need to make sure they properly code for this.

From a network perspective, the amount of data transferred is slightly less with a single large message than with a bunch of small ones. The real issue is reliability. A message should ideally contain a single unit of work. I wonder about the design of an application where a single UOW contains a variable amount of data ranging from below 1MB to over 11MB.

Lee Edenfield, HagemeyerNA (843.745.2477)

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Coombs, Lawrence
Sent: Friday, June 20, 2014 8:29 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Integration with vendor product..

Paul – Your concern is right on. Initially the maximum message size was supposed to be 1 MB, until they tried to send an 11MB message and the queue manager/channel/queue were defined with the default of 4MB. After a heart to heart conversation, their argument was that they discovered on the internet that MQ can handle 100 MB message and so 11 MB should not be a problem.

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Paul Clarke
Sent: Friday, June 20, 2014 1:09 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Integration with vendor product..

My concern with 11MB would just be the worry about what it might lead to. We all know that really large messages, eg 100MB, messages are bad, for all sorts of reasons. An 11MB message implies to me that the application is putting all it’s data in a single message. This therefore implies that the application has not been coded to send it’s data in chunks. So, the concern is that a request for 11MB today will be 22MB next year and 40MB in year after that.

In this day and age certainly 11MB is not a huge amount of data but it still causes MQ to do slightly unnatural things. Personally I would prefer it if the application sent 11 x 1MB messages. That way I would know that in 5 years time the application will still work just fine and they won’t start bitching to me that they can no longer fit all their data into a single 100MB message.

Cheers,
Paul.

Paul Clarke
www.mqgem.com<http://www.mqgem.com>

From: Coombs, Lawrence<mailto:***@SEARSHC.COM>
Sent: Thursday, June 19, 2014 8:03 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Integration with vendor product..

I am working on an integration project with a vendor product and they would like to send me 11 MB messages over a client channel over a WAN . The queue manager is at WMQ 7.5.0.2. I am trying my best to discourage them from doing this, but so far I have been unsuccessful. I have suggested message grouping but they have no idea what I am talking about.

What are some technical reasons I could use to dissuade them from doing this?
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

______________________________________________________________________
CONFIDENTIALITY WARNING: This email may contain confidential or proprietary business information and is for the sole use of the intended recipient(s). Any unauthorized use or disclosure of this communication, including attachments, is strictly prohibited. If you believe that you have received this email in error, please notify the sender immediately and delete it from your system.
______________________________________________________________________


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Tim Zielke]

When you start introducing larger messages (and consequently longer running units of work), be aware of the impact it can have on your transaction log. You may need to increase it, and it is a good idea that you are proactively monitoring for log getting full messages.

Lawrence – Since this is a client app, unfortunately that would fall on your shoulders.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Edenfield, Lee
Sent: Friday, June 20, 2014 7:40 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Integration with vendor product..

I regularly deal with large messages. There are issues, but as long as the volume is low it usually works ok. If they are using client bindings, make sure the developers know that the risk of failure on a put or get operation increases with large message size and they need to make sure they properly code for this.

From a network perspective, the amount of data transferred is slightly less with a single large message than with a bunch of small ones. The real issue is reliability. A message should ideally contain a single unit of work. I wonder about the design of an application where a single UOW contains a variable amount of data ranging from below 1MB to over 11MB.

Lee Edenfield, HagemeyerNA (843.745.2477)

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Coombs, Lawrence
Sent: Friday, June 20, 2014 8:29 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Integration with vendor product..

Paul – Your concern is right on. Initially the maximum message size was supposed to be 1 MB, until they tried to send an 11MB message and the queue manager/channel/queue were defined with the default of 4MB. After a heart to heart conversation, their argument was that they discovered on the internet that MQ can handle 100 MB message and so 11 MB should not be a problem.

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Paul Clarke
Sent: Friday, June 20, 2014 1:09 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Integration with vendor product..

My concern with 11MB would just be the worry about what it might lead to. We all know that really large messages, eg 100MB, messages are bad, for all sorts of reasons. An 11MB message implies to me that the application is putting all it’s data in a single message. This therefore implies that the application has not been coded to send it’s data in chunks. So, the concern is that a request for 11MB today will be 22MB next year and 40MB in year after that.

In this day and age certainly 11MB is not a huge amount of data but it still causes MQ to do slightly unnatural things. Personally I would prefer it if the application sent 11 x 1MB messages. That way I would know that in 5 years time the application will still work just fine and they won’t start bitching to me that they can no longer fit all their data into a single 100MB message.

Cheers,
Paul.

Paul Clarke
www.mqgem.com<http://www.mqgem.com>

From: Coombs, Lawrence<mailto:***@SEARSHC.COM>
Sent: Thursday, June 19, 2014 8:03 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: Integration with vendor product..

I am working on an integration project with a vendor product and they would like to send me 11 MB messages over a client channel over a WAN . The queue manager is at WMQ 7.5.0.2. I am trying my best to discourage them from doing this, but so far I have been unsuccessful. I have suggested message grouping but they have no idea what I am talking about.

What are some technical reasons I could use to dissuade them from doing this?
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

______________________________________________________________________
CONFIDENTIALITY WARNING: This email may contain confidential or proprietary business information and is for the sole use of the intended recipient(s). Any unauthorized use or disclosure of this communication, including attachments, is strictly prohibited. If you believe that you have received this email in error, please notify the sender immediately and delete it from your system.
______________________________________________________________________

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Jefferson Lowrey]

Also, ask the vendor team what they'll do when the message reaches 101 MB.



Thank you,

Jeff Lowrey




From: Tim Zielke <***@AON.COM>
To: ***@listserv.meduniwien.ac.at
Date: 06/20/2014 08:39 AM
Subject: Re: [MQSERIES] Integration with vendor product..
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>



When you start introducing larger messages (and consequently longer
running units of work), be aware of the impact it can have on your
transaction log. You may need to increase it, and it is a good idea that
you are proactively monitoring for log getting full messages.

Lawrence – Since this is a client app, unfortunately that would fall on
your shoulders.

Thanks,
Tim

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Edenfield, Lee
Sent: Friday, June 20, 2014 7:40 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Integration with vendor product..

I regularly deal with large messages. There are issues, but as long as the
volume is low it usually works ok. If they are using client bindings, make
sure the developers know that the risk of failure on a put or get
operation increases with large message size and they need to make sure
they properly code for this.

From a network perspective, the amount of data transferred is slightly
less with a single large message than with a bunch of small ones. The real
issue is reliability. A message should ideally contain a single unit of
work. I wonder about the design of an application where a single UOW
contains a variable amount of data ranging from below 1MB to over 11MB.

Lee Edenfield, HagemeyerNA (843.745.2477)

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Coombs, Lawrence
Sent: Friday, June 20, 2014 8:29 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Integration with vendor product..

Paul – Your concern is right on. Initially the maximum message size was
supposed to be 1 MB, until they tried to send an 11MB message and the
queue manager/channel/queue were defined with the default of 4MB. After a
heart to heart conversation, their argument was that they discovered on
the internet that MQ can handle 100 MB message and so 11 MB should not be
a problem.

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Paul Clarke
Sent: Friday, June 20, 2014 1:09 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Integration with vendor product..

My concern with 11MB would just be the worry about what it might lead to.
We all know that really large messages, eg 100MB, messages are bad, for
all sorts of reasons. An 11MB message implies to me that the application
is putting all it’s data in a single message. This therefore implies that
the application has not been coded to send it’s data in chunks. So, the
concern is that a request for 11MB today will be 22MB next year and 40MB
in year after that.

In this day and age certainly 11MB is not a huge amount of data but it
still causes MQ to do slightly unnatural things. Personally I would prefer
it if the application sent 11 x 1MB messages. That way I would know that
in 5 years time the application will still work just fine and they won’t
start bitching to me that they can no longer fit all their data into a
single 100MB message.

Cheers,
Paul.

Paul Clarke
www.mqgem.com

From: Coombs, Lawrence
Sent: Thursday, June 19, 2014 8:03 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Integration with vendor product..

I am working on an integration project with a vendor product and they
would like to send me 11 MB messages over a client channel over a WAN .
The queue manager is at WMQ 7.5.0.2. I am trying my best to discourage
them from doing this, but so far I have been unsuccessful. I have
suggested message grouping but they have no idea what I am talking about.

What are some technical reasons I could use to dissuade them from doing
this?
This message, including any attachments, is the property of Sears Holdings
Corporation and/or one of its subsidiaries. It is confidential and may
contain proprietary or legally privileged information. If you are not the
intended recipient, please delete it without reading the contents. Thank
you.


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
This message, including any attachments, is the property of Sears Holdings
Corporation and/or one of its subsidiaries. It is confidential and may
contain proprietary or legally privileged information. If you are not the
intended recipient, please delete it without reading the contents. Thank
you.


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

______________________________________________________________________
CONFIDENTIALITY WARNING: This email may contain confidential or
proprietary business information and is for the sole use of the intended
recipient(s). Any unauthorized use or disclosure of this communication,
including attachments, is strictly prohibited. If you believe that you
have received this email in error, please notify the sender immediately
and delete it from your system.
______________________________________________________________________


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[David Awerbuch (BLOOMBERG/ 120 PARK)]

With this in mind, perhaps folks could share their anecdotes regarding WMQ and large messages? I have worked with multi-megabyte messages in the past without issues, but that was also in a low volume environment. Thanks, Dave

----- Original Message -----
From: ***@LISTSERV.MEDUNIWIEN.AC.AT
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
At: Jun 20 2014 08:05:58



“In this day and age certainly 11MB is not a huge amount of data but it still causes MQ to do slightly unnatural things.”

Do tell




Peter Potkay


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Paul Clarke
Sent: Friday, June 20, 2014 2:09 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Integration with vendor product..


My concern with 11MB would just be the worry about what it might lead to. We all know that really large messages, eg 100MB, messages are bad, for all sorts of reasons. An 11MB message implies to me that the application is putting all it’s data in a single message. This therefore implies that the application has not been coded to send it’s data in chunks. So, the concern is that a request for 11MB today will be 22MB next year and 40MB in year after that.



In this day and age certainly 11MB is not a huge amount of data but it still causes MQ to do slightly unnatural things. Personally I would prefer it if the application sent 11 x 1MB messages. That way I would know that in 5 years time the application will still work just fine and they won’t start bitching to me that they can no longer fit all their data into a single 100MB message.



Cheers,
Paul.



Paul Clarke
www.mqgem.com



From:Coombs, Lawrence

Sent: Thursday, June 19, 2014 8:03 PM

To:***@LISTSERV.MEDUNIWIEN.AC.AT

Subject: Re: Integration with vendor product..



I am working on an integration project with a vendor product and they would like to send me 11 MB messages over a client channel over a WAN . The queue manager is at WMQ 7.5.0.2. I am trying my best to discourage them from doing this, but so far I have been unsuccessful. I have suggested message grouping but they have no idea what I am talking about.

What are some technical reasons I could use to dissuade them from doing this?

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


<< "Once the game is over, the king and the pawn go back into the same box." - Anon >>

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Dominique Courtois]

Hi all,
I had this kind of discussion with customers or partners numerous times in the past.
My experience is that when you argue as a technician because you understand that WMQ is not used in the most efficient way you are likely to be eventually defeated.
WMQ uses system ressources efficiently and most of the resource comsumption seen by users comes from application code (business rules, DB access, I/O and so ...). Changing the way they use WMQ usually doesn't mean anything they can measure (technical resources or mere money). This turned very often to be a very dubious batlle.

What I did the last years was to ensure that reliability was good and that any possible problem would not be missed. So I did not fight much for what I thought was the "right way to go" but only tried to draw the attention on the possible risk or not optimal use.

Regards

Dominique

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES