| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Impact of increasing the MAXMSGL parm of a receiver channel |
« View previous topic :: View next topic » |
| Author |
Message
|
| JosephGramig |
 Posted: Mon Nov 03, 2014 6:54 am Post subject: |
 |
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| Andyh wrote: |
There's no need for a transaction to be contained within a single recovery log extent.
There's a suggestion earlier in this thread that the recovery log extent size should be at least MAXMSGL*BATCHSZ, what is the basis for this suggestion ?
Thanks
Andy. |
Andy,
You are correct that a UOW can span more than one log. The only point was to reduce the log file churn. With circular logs, you have a limited number and sizing them large allows flexibility later... The defaults are probably not what you want. |
|
| Back to top |
|
 |
| PaulClarke |
| Posted: Mon Nov 03, 2014 8:29 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Bruce,
I think one of the concerns about z/OS not supporting Message Segmentation is the need to know where your messages are going. Whether Distributed Systems are more constrained for storage than z/OS ones is not really the issue in my view and I suspect you could find people that will argue it both ways. On my laptop I can buy 8GB of RAM for very little money; however whenever the suggestion of using more RAM on a z/OS machine is mentioned people go white at the cost of the storage.
No, I think the issue is more along the lines of - how do I know who is consuming my messages?. If, as you suggest, big messages are palatable on z/OS does it make it reasonable to send 100MB messages around? I think not. Even if it doesn't cause any problems for z/OS, which I seriously doubt.....it will if you send it to the Distributed machines.
Likewise on a Distributed machine, am I free to send around segmented messages willy nilly? Well, sadly no. I have to be really careful and be certain that my messages are not going to end up on a z/OS machine where they will cause problems.
One of the key goals of MQ was to try and be the same everywhere. The idea of location transparency and that I can write my program on one platform and have it run just the same anywhere else. These differences always undermine that philosophy.
Cheer,
Paul
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Nov 04, 2014 2:39 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I wholeheartedly agree that application-oriented MQ facilities and features should be common across all platform types. I can only speculate as to the rationale that led to lack of support for message segmentation on MQ for z/OS.
what i can comment on is the general ho-hum lack of concern regarding message segmentation support with my mainframe clients.
mainframes remain the platform of choice for organizations which need to move BIG data for thousands of concurrent apps. Most/many have long ago figured ways to move data to/from midrange MQ without message segmentation.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
