| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Copybook versus manual message definition |
« View previous topic :: View next topic » |
| Author |
Message
|
| LazyBoy |
 Posted: Mon Jun 01, 2009 11:16 am Post subject: Copybook versus manual message definition |
 |
|
Voyager
Joined: 04 May 2006
Posts: 78
|
Hi,
I have imported copybooks to my toolkit, and the field names are very long and with many REDEFINE fields there are lot of groups(even the group name are long) of type choice.
Is it advantagous to use copybooks than manual definition of fields?
The only advantage I see in using copybook is faster devlopment, but Is it reasonable to use it at the expense of Memory. I am assuming fields with long names consume more memory.
Please shower your inputs folks.
Thanks, |
|
| Back to top |
|
 |
| kimbert |
| Posted: Mon Jun 01, 2009 11:36 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Thanks, I already showered my inputs after I biked into work today. 
I wouldn't worry about the length of the names - the memory used by the names is not the main consumer of system memory in a message flow.
On the other hand, long names might well be a maintenance problem, because they make the ESQL/Java hard to read. Feel free to edit the result of the import to make them shorter. |
|
| Back to top |
|
|
| LazyBoy |
| Posted: Mon Jun 01, 2009 12:59 pm Post subject: |
|
|
Voyager
Joined: 04 May 2006
Posts: 78
|
Hi kimbert,
Thank you for your reply. So, my assumption abt long names consuming memory was correct.
The copybooks I have are generic message types which can be reused by many different interfaces. How Can I resuse this message type in another message set?
But if I have to create message definition from datasets there are very less fields and is specific to a particular interface.
Since Message broker doesn't default unsed fields with padding character(too many fields are unused in copybook generic message type), I think it is better to build message definition manually, because there will be less esql statements which will set the value to padding character. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Jun 01, 2009 1:41 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| So, my assumption abt long names consuming memory was correct |
Well, partly correct. I doubt whether using short names will show any real reduction in memory usage.
| Quote: |
| Since Message broker doesn't default unsed fields with padding character(too many fields are unused in copybook generic message type), I think it is better to build message definition manually, because there will be less esql statements which will set the value to padding character. |
Possibly true. This might be a valid reason for manually creating the message set. Length of names would not be. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
