Author |
Message
|
khan_dada |
Posted: Tue Feb 14, 2006 3:42 pm Post subject: Redefines in copy book: |
|
|
Newbie
Joined: 27 May 2003 Posts: 7
|
Does repeat reference or repeat count work when imported copy book has redefines in it?
I am working with WMB5.0 (CSD2). Here is part of cobol copy book which worked fine when imported.
Code: |
01 MW-NOTIFICATION-SERVICE-REQUEST.
10 MW-NOTIFICATION-REQUEST.
15 MW-NOTIFY-DELIVERY-TYPE PIC X(5).
15 MW-NOTIFY-DELIVERY-ADDR PIC X(250).
10 MW-WBIPING-REQUEST REDEFINES MW-NOTIFICATION-REQUEST.
15 WBIPING PIC X(9) |
I need to have multiple addresses inside the message structure, so I changed copybook to have an addition variable for counting. Here is the modified copy book:
Code: |
01 MW-NOTIFICATION-SERVICE-REQUEST.
10 MW-NOTIFICATION-REQUEST.
//changed to have multiple addresses
15 MW-NOTIFY-ADDRESS-COUNT PIC 9(9).
15 MW-NOTIFY-ADDRESS OCCURS 100 TIMES.
20 MW-NOTIFY-DELIVERY-TYPE PIC X(5).
20 MW-NOTIFY-DELIVERY-ADDR PIC X(250).
10 MW-WBIPING-REQUEST REDEFINES MW-NOTIFICATION-REQUEST.
15 WBIPING PIC X(9) |
I have changed the logical poperties of MW-NOTIFY-ADDRESS to have minimum occurrences of 1 and maximum occurrence of 100. and the physical poperties of MW-NOTIFY-ADDRESS to have have repeat count of MW-NOTIFY-ADDRESS-COUNT.
The input message is not getting parsed when the repeat count is of variable length and getting parsed for a fixed number.
Is there anythingelse needs to be set?
Thanks,
Sagar |
|
Back to top |
|
 |
JT |
Posted: Tue Feb 14, 2006 5:07 pm Post subject: |
|
|
Padawan
Joined: 27 Mar 2003 Posts: 1564 Location: Hartford, CT.
|
If you append a DEPENDING ON to the OCCURS clause, then the Repeat Reference will be set automatically, but since you already imported the copybook, manually set the Repeat Reference to MW_NOTIFY_ADDRESS_COUNT element. |
|
Back to top |
|
 |
khan_dada |
Posted: Tue Feb 14, 2006 5:48 pm Post subject: |
|
|
Newbie
Joined: 27 May 2003 Posts: 7
|
Yes, I had set it manually to MW_NOTIFY_ADDRESS_COUNT. I am getting a parsing error when it is set to MW_NOTIFY_ADDRESS_COUNT. So I had set this value to 2 and passed two addresses it parsed correctly.
Earlier when there was no redefine in my copy book and address repeat reference was set to use MW_NOTIFY_ADDRESS_COUNT, the message parsed correctly.
Parsing error statrted only when I have added the redefine in the copy book. |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Feb 14, 2006 6:14 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
I believe the problem here is that we have a redefines without possibility to know in advance which of the definitions we should use....
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
khan_dada |
Posted: Wed Feb 15, 2006 7:24 am Post subject: |
|
|
Newbie
Joined: 27 May 2003 Posts: 7
|
I did n't understand what you meant. Can you please explain it further.
Here is on of the FAQs on the IBM site.
Technote (FAQ)
Problem
You want to know if COBOL records that contain redefines are handled correctly?
Solution
The message repository does not currently support fields with several different usages, so there is no exact way to model the COBOL REDEFINES construct.
When it finds a redefinition, the COBOL Importer creates a corresponding type for the redefinition, but does not insert an element corresponding to the redefining type into the parent type. No element corresponding to the redefining type is created.
Product Alias/Synonym
WMB / WBIMB / WMQI / MQSI
Does this mean repeat reference does n't work when you have redefines in the copy book?
Thanks,
Sagar |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Feb 15, 2006 7:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
The problem is that, without additional information, the broker is not able to determine which redefine should be used when parsing the message.
Take, for example, a record that could either start with an 8 character number and then two 10 character strings OR it could be an 8 character number followed by a single 20 character string.
How can broker possibly tell which is which? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
dilse |
Posted: Wed Feb 15, 2006 8:38 am Post subject: |
|
|
 Master
Joined: 24 Jun 2004 Posts: 270
|
Quote: |
When it finds a redefinition, the COBOL Importer creates a corresponding type for the redefinition, but does not insert an element corresponding to the redefining type into the parent type. No element corresponding to the redefining type is created. |
In your case,
When COBOL importer looks at these redefined elements(MW-WBIPING-REQUEST) it will create a Choice element(RedefinedElement_***) in your message definition file that includes all the redefined elements types in it including the original(MW-NOTIFICATION-REQUEST ) type from where you redefined all these type but it does not insert elements corresponding to the redefining type into the parent(MW-NOTIFICATION-SERVICE-REQUEST).
When you resolve Choice element to any one of the choices for redefines elements in your ESQL code then that will be your choice and you cannot revert back your decision. In other words, the Choice element takes the redefines element that was first accesssed as its choice. So you have to decide in your ESQL code to which redefines type you want to resolve.
Hope this helps. |
|
Back to top |
|
 |
kimbert |
Posted: Thu Feb 16, 2006 2:42 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
You've hit a restriction in the MRM parser. When it encounters a choice ( i.e. a REDEFINE) the MRM parser immediately attempts to calculate the length of the longest branch of that choice. In your case, this is impossible - because the length of the first branch depends on the repeat count.
You may be able to work around the problem by creating two message definitions - one for each branch of the REDEFINE. Then parse the message in the BLOB domain, work out which way to jump, and re-parse the message against the correct message definition. |
|
Back to top |
|
 |
khan_dada |
Posted: Thu Feb 16, 2006 11:46 am Post subject: |
|
|
Newbie
Joined: 27 May 2003 Posts: 7
|
Thanks, Kimbert. I will take this alternate approach. |
|
Back to top |
|
 |
|