ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » MRM Data Type Conversion Problem

Post new topic  Reply to topic
 MRM Data Type Conversion Problem « View previous topic :: View next topic » 
Author Message
goffinf
PostPosted: Mon Dec 12, 2011 7:34 am    Post subject: MRM Data Type Conversion Problem Reply with quote

Chevalier

Joined: 05 Nov 2005
Posts: 401

Version: 6.1.0.3

I have a Message Set that uses the following Cobol field :-

027100 10 MILEAGE-READING PIC 9(0007).

Unfortunately the data that is being sent doesn't always contain data for this field and is coming thru as 7 SPACES. When the message is parsed I get the follwoing exception message in the user trace ;-

2011-12-12 14:43:58.163192 2916 ConversionException BIP5505E: A data conversion failed because the data was invalid.
Type of data being read: 'string'
Data: '.......' (note: I put the full-stops here since when posting they were removed ! - the actual usertrace has 7 spaces (honest)

Perfectly reasonable of Broker, but is there anything I can do to prevent the exception ?

I did try setting the4 Default value in Message Set to 0 but that didn't work (I guess because there *is* data coming thru albeit invalid).

Is there anything else I can try, or do I need to go back to the sender.

Many thanks

Fraser
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Dec 12, 2011 7:40 am    Post subject: Re: MRM Data Type Conversion Problem Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

goffinf wrote:
Is there anything else I can try, or do I need to go back to the sender.


You need to go back to the sender. That picture doesn't permit spaces (though I know a number of COBOL variants that turn a blind eye unless you actually reference the field).

What you could do (or the sender could do) is edit the copybook so that the field in question is REDEFINED as a PIC X(7). You could then test the PIC X field in WMB and if it's non-blank reference the PIC 9 field to get the number.

If kimbert is somewhere close he can probably explain how to get the choice into the message set without reimporting the copybook.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
kimbert
PostPosted: Mon Dec 12, 2011 8:17 am    Post subject: Reply with quote

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

The MRM parser has explicit support for your scenario. The '7 spaces' version of the input is called a 'null value'. It's not valid for the data type, but the MRM parser can detect it and put it into the message tree with the value 'NULL'. That's not the string 'NULL' - it's a real value that is distinct from the normal range of element values, and is testable using the ESQL operator 'IS NULL'.

Note : You *must* set the 'Nillable' property on the element to '

Check the info center docs for 'CWF null handling'. I expect you'll find it easiest to use 'Null Pad Fill' and set the pad character to <SP>.
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Dec 12, 2011 8:21 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

Told you!

All Hail The God Of Parsing!!


_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
goffinf
PostPosted: Mon Dec 12, 2011 9:34 am    Post subject: Reply with quote

Chevalier

Joined: 05 Nov 2005
Posts: 401

Thanks Victor/Kimbert.

I tried what you suggested but still no joy (same error).

Actually I using TDS rather than CWF, but I note that the same options are available as descriobed in the Info Centre.

To be sure I haven't missed some vital step, here's what I did :-

1. Positioned on the MILEAGE_READING element in the message set editor
2. Selected the properties tab.
3. In the Logical Properties/Local Element. I Checked the box 'Nillable'
4. In the Physical Properties/Text1/Local Element, Encoding Null property, I selected 'NullPadFill' from the dropdown.
5. Recompiled, re-deployed.
6. Rebuilt the flow that uses this Message Set, and redeployed.
7. Re-ran the test ... bah humbug

Have I missed something important ?

Fraser.
Back to top
View user's profile Send private message
goffinf
PostPosted: Mon Dec 12, 2011 9:46 am    Post subject: Reply with quote

Chevalier

Joined: 05 Nov 2005
Posts: 401

Ah ha, forgot to change the Padding Character to SPACE. That worked.

On to the next one.

First time using message sets for non-trivial stuff. Really enjoying it (frustrating as hell though
Back to top
View user's profile Send private message
kimbert
PostPosted: Mon Dec 12, 2011 3:03 pm    Post subject: Reply with quote

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

Quote:
First time using message sets for non-trivial stuff. Really enjoying it (frustrating as hell though
Just wait until you get your hands on the DFDL technology built into the v8 toolkit. Even more power, and quite a lot less frustration.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » MRM Data Type Conversion Problem
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.