|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Import message set problem |
« View previous topic :: View next topic » |
Author |
Message
|
nevin |
Posted: Fri Dec 12, 2003 1:12 am Post subject: Import message set problem |
|
|
 Newbie
Joined: 16 Dec 2002 Posts: 9
|
Hi
I have some problems with message set import in WBIMB 5.0.2.
All my messages are defined in cobol. I found that I can create a new Message Definition File and select a cobol file as the source to create the message set, but this way, each Message Definition file would contain one message only. I cannot see an option to import more message definitions under the same Message Definition File except by creating them manually and inputting the fields one by one. Anyone have any clues? Thanks in advance.
Nev |
|
Back to top |
|
 |
kimbert |
Posted: Fri Dec 12, 2003 4:26 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
I think the only way would be to merge the copybooks manually, and then import the merged copybook. But you probably thought of that already. |
|
Back to top |
|
 |
nevin |
Posted: Fri Dec 12, 2003 5:35 pm Post subject: |
|
|
 Newbie
Joined: 16 Dec 2002 Posts: 9
|
Yes, merging copy books would be feasible initially, but when our message sets are being upgraded, we might have to add new messages to the existing message definition files. Those new messages would be defined in cobol (cause they are from host programs), and it is now impossible to add them to the existing message files except by typing them manually.
Another stupid solution is to delete the whole message definition file, prepare new merged cobol copy books, then add them to a new message definition file, but is it really the way to do this? There must be some better method, right?
Nev |
|
Back to top |
|
 |
kimbert |
Posted: Tue Dec 16, 2003 5:06 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
It looks as if merging the copybooks is the only option.
I don't think its as bad as you are suggesting, though. In your COBOL application, each message was defined in its own source file. When you import to the v5.0 tooling, each message is defined in its own source file. Why is that suddenly a problem? It seems to me that this is what most users will expect. |
|
Back to top |
|
 |
nevin |
Posted: Tue Dec 16, 2003 6:04 pm Post subject: |
|
|
 Newbie
Joined: 16 Dec 2002 Posts: 9
|
It is a bad option IF you have to use WBIMB's message set migration tool (from v2.1 to v5). The migration tool migrates all messages under a message set under one single message definition file. Problem is, you cannot achieve the same effect manually using cobol copy books.
Isn't it normal for me to expect multiple messages under one message set definition file the norm, when the migration tool is doing exactly this? If the message definition file is really intended for one message only, why would they let you add multiple messages to it?
It is going to be a problem for users upgrading from v2.1 to v5. Your existing message sets migrated from v2.1 will look different from new message sets added after the upgrade. I wonder what the message definition files are really for. Any one has any clue? |
|
Back to top |
|
 |
kimbert |
Posted: Wed Dec 17, 2003 2:12 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Quote: |
I wonder what the message definition files are really for. Any one has any clue? |
v2.1 did not provide any facility for splitting a message set into several source files. v5.0 provides this facility, and some users will find it really useful. It allows a huge message set to be divided up into manageable parts, and it allows a message set to be divided up along namespace boundaries.
All the importers, including the COBOL importer, the C importer and the XML schema importer will create exactly one message definition file per imported source file. If there are multiple global elements in an imported source file, multiple messages can be created within the resulting message definition file.
Quote: |
Isn't it normal for me to expect multiple messages under one message set definition file the norm, when the migration tool is doing exactly this? If the message definition file is really intended for one message only, why would they let you add multiple messages to it? |
IBM does not prescribe how many messages you put into a message definition file - its up to you. It is not true to say that a message definition file is intended for one message only (any more than a COBOL copybook is intended for one structure only). But in your case, the COBOL copybooks only define one structure, so they are producing message definition files containing only one message.
The migration tool (mqsimigratemsgsets) is not being deliberately different from the importers - it has no choice. The source data (from v2.1) is in a single file, so by default it is going to create one message definition file.
Note: mqsimigratemsgsets does have an option which splits the imported message set into a set of independent message definition files. However, it does not split by message - it uses a partitioning algorithm to identify independent sub-sections of the message model. Still, it might help you a little.
Quote: |
It is going to be a problem for users upgrading from v2.1 to v5. Your existing message sets migrated from v2.1 will look different from new message sets added after the upgrade. |
Only in your case, and for the reasons outlined above. Most users will not be faced with the same situation as you.[/b] |
|
Back to top |
|
 |
nevin |
Posted: Wed Dec 17, 2003 7:04 pm Post subject: |
|
|
 Newbie
Joined: 16 Dec 2002 Posts: 9
|
Quote: |
mqsimigratemsgsets does have an option which splits the imported message set into a set of independent message definition files. However, it does not split by message - it uses a partitioning algorithm to identify independent sub-sections of the message model. Still, it might help you a little. |
You mean the -part option? It splits the message set only if the number of messages, elements and compound types in the export file exceeds 1000 AND if the messages can be partitioned. So, not much help for the smaller message sets I have.
I don't see the reason you said only me but not other users would be affected by the migration, as there must be people out there who constructs their message sets by importing cobol, c or xml files. For my case, thought, I think it might be better to rebuild new message sets in v5 rather than using the migration tools. |
|
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
|
|
|
|