| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MRM V 7.0.0.2 problem |
« View previous topic :: View next topic » |
| Author |
Message
|
| fjb_saper |
 Posted: Thu Apr 07, 2011 8:02 pm Post subject: MRM V 7.0.0.2 problem |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Ran into something bizarre and wondered if any of you encountered the same?
AIX 5.3 (one of the latest patches, XLC route at recommended level for WMB 7.0.0.2)
WMQ 7.0.1.4
WMB 7.0.0.2 effective 7.0.0.2
Toolkit in Windows7
Checked out V6 message set and flow from the V7 Branch (svn copy to V7 branch + svn checkout)
Re-imported copy books without creating default values where this caused errors. (All fields are set to nillable.)
Everything checked out => deployed to V7 broker => deploy successful.
When processing messages it balks on the MQOutput node (while serializing?) The error log says something about not understanding 'MQSTR '...
The format of the message is set to MQFMT_STRING by an MQ V6 application and is not changed from the MQMD header from input to output...
Ran a user trace in debug, doesn't tell me more...
The transformation is from MRM - XML1 input to MRM - CWF1 cobol copybook....
Probably going to open a PMR tomorrow... 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Apr 08, 2011 7:18 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
O.K. it took me to read the user trace in something different from vi or more.
The reason for the trouble is the change in behavior of the COBOL importer.
V6
- Make enums out of 88 values (check)
- all fields nillable, null value = space (check)
- all fields default value, default value = space (check)
This gives you a clean import in V6....
In V7 the import shows problems: #1 is not compatible with #3...
Yes you can't have a default value that is not part of the 88 level value facet turned into enum...
Now you have a choice:
- Do not set the 88 level values as enum
Well this means that a bad value would be accepted and the message is no longer rejected
- Do not set default values for all fields
This means that if the value is set to null like in "SET field = expression evaluating to null" the field is not created, but neither is it created anymore during serialization (CWF1) with a default null value!!
Does not matter which choice you take you will have to either run the risk of passing bad data, or change the code to make sure you set the value of fields to null like "SET FIELD VALUE = expression evaluating to null"
Huge upgrade effort!!
Please can you tell us how to get the old behavior back??
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Sun Apr 10, 2011 1:51 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| fjb_saper wrote: |
| O.K. it took me to read the user trace in something different from vi or more. |
Out of curiousity, what is it about vi or more that makes it difficult to read a usertrace, and what is it that works better?
| fjb_saper wrote: |
In V7 the import shows problems: #1 is not compatible with #3...
Yes you can't have a default value that is not part of the 88 level value facet turned into enum... |
Does the problem occur when importing the message set, or during run-time? What error messages are generated?
| fjb_saper wrote: |
Huge upgrade effort!!
Please can you tell us how to get the old behavior back?? |
In the absence of a better suggestion, sometimes manually editing the mxsd (with vi or other external editor), or setting up a script (perl, sed, awk, ...) to post-process the mxsd can turn a huge upgrade effort into a more manageable workaround. Don't try this though, except as a last resort, as it can be ... tricky. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Apr 10, 2011 4:10 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| rekarm01 wrote: |
| fjb_saper wrote: |
| O.K. it took me to read the user trace in something different from vi or more. |
Out of curiousity, what is it about vi or more that makes it difficult to read a usertrace, and what is it that works better? |
It's a line wrapping thing. The trace is much more clear when looked at in winscp editor where the line is not being wrapped.... much more readable.
| rekarm01 wrote: |
| fjb_saper wrote: |
In V7 the import shows problems: #1 is not compatible with #3...
Yes you can't have a default value that is not part of the 88 level value facet turned into enum... |
Does the problem occur when importing the message set, or during run-time? What error messages are generated? |
The problem occurs when importing the copy book into the message set. You check all 3 boxes and your imported msxd will show up with a problem icon. You look up the problem and it tells you clearly that the default value cannot be outside of the enum created by the 88 level entries.
| rekarm01 wrote: |
| fjb_saper wrote: |
Huge upgrade effort!!
Please can you tell us how to get the old behavior back?? |
In the absence of a better suggestion, sometimes manually editing the mxsd (with vi or other external editor), or setting up a script (perl, sed, awk, ...) to post-process the mxsd can turn a huge upgrade effort into a more manageable workaround. Don't try this though, except as a last resort, as it can be ... tricky. |
The best solution I can think of is to change the esql map and make sure it is created with SET field VALUE = assignment value;... in the absence of a default value...
However this is not going to be easy, will require a lot of effort and a lot of testing....
So if somebody from Hursley knows of an easy trick to allow the old behavior back, I am interested (opened a PMR to that effect)
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Mon Apr 11, 2011 1:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| rekarm01 wrote: |
| Out of curiousity, what is it about vi or more that makes it difficult to read a usertrace ... ? |
| fjb_saper wrote: |
| It's a line wrapping thing. |
Fair enough. It's too bad that the mqsiformatlog command doesn't have an option for line wrapping. For those who really don't like horizontal scrollbars, another option that works reasonably well is to edit the resulting log file; search for every occurrence of ':' or '.' followed by white space, and replace the white space with <newline><tab>.
| fjb_saper wrote: |
| So if somebody from Hursley knows of an easy trick to allow the old behavior back, I am interested (opened a PMR to that effect) |
Good luck with that. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Apr 11, 2011 2:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| The problem occurs when importing the copy book into the message set. You check all 3 boxes and your imported msxd will show up with a problem icon. You look up the problem and it tells you clearly that the default value cannot be outside of the enum created by the 88 level entries. |
Which, pardon me, but actually sounds sensible. The enum 88's list all allowed values, so why shouldn't the NULL value be listed? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Apr 11, 2011 7:39 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
| fjb_saper wrote: |
| The problem occurs when importing the copy book into the message set. You check all 3 boxes and your imported msxd will show up with a problem icon. You look up the problem and it tells you clearly that the default value cannot be outside of the enum created by the 88 level entries. |
Which, pardon me, but actually sounds sensible. The enum 88's list all allowed values, so why shouldn't the NULL value be listed? |
Sorry but I don't know of a single COBOL programmer that would add the initial value to the 88 list.
The 88 list shows all allowed values in case the section is relevant. When it is not relevant it can have an initial value (space, hex 00 or low or high value) that most probably is not in the 88 level of the copy book.
One of the reasons is that COBOL does not enforce the 88 level, the other being that the check will never be done at field level at this point but may be done at the higher level (i.e. level 10 initial with field at level 15 and values at level 88 ).
I understand that the new rule might have been to make it behave more like XML but we are talking here about a custom wire format that has nothing to do with XML...
I'd like the 6.0 behavior back...
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
