| Author |
Message
|
| sksharma_r |
 Posted: Wed Dec 18, 2013 11:49 am Post subject: MRM and COBOL |
 |
|
Newbie
Joined: 23 Sep 2011
Posts: 2
|
This may be a no brainer that MRM parser is used for COBOL messages as input, and some times so called data normalization needs to be done manually atleast thats what i am facing now. The data fields in the input COBOL message have STRING type with numeric data, with right justification and padded zeroes to reach the length eg: '00000000001234'.
So when this is parsed by the broker the value is read as '1234' and we are suppose to insert this data into database which actually expects the complete length, the field type in database is again CHAR for numeric data, so is ESQL the only way to fix this?? is there a way other than checking the input length and manually adding zeroes?
The message flow
InputNode------>TryCatch--------->Compute
MRM for COBOL ----------------Database Insertion
Appreciate your reply in helping me with this issue. |
|
| Back to top |
|
 |
| JosephGramig |
| Posted: Wed Dec 18, 2013 12:25 pm Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Dec 18, 2013 12:27 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Look at the OVERLAY function.
However your requirement is a little strange but hey-ho, that's life.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Dec 18, 2013 1:08 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I would manually adjust the MRM model to be a character field instead of a numeric field.
And then if needed override the part of the model that treats the '0' as a blank. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Dec 18, 2013 1:41 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I agree with mqjeff. Your application clearly does not wish to treat this field as a number. It wants to treat it as a fixed-width CHAR field. So you should adjust your MRM model accordingly.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| NealM |
| Posted: Wed Dec 18, 2013 2:30 pm Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
So, all your COBOL numeric data is positive integers? All PIC 9's, no "S" or "V" in the formats? If so, Jeff's approach would work; Otherwise you need to read up on the CAST function.
Hint: CAST(source AS CHARACTER FORMAT pattern) |
|
| Back to top |
|
|
| ajodowd |
| Posted: Wed Dec 18, 2013 3:28 pm Post subject: |
|
|
Novice
Joined: 15 Dec 2013
Posts: 13
|
Hi sksharma_r,
All great advice above, and can I ask whether you considered the DFDL parser rather than MRM? Is it because you're not at version 8 or version 9?
DFDL has quite a few advantages over MRM, but I really wondered whether you considered it or not.
Thanks, Anthony. |
|
| Back to top |
|
|
| sksharma_r |
| Posted: Tue Dec 24, 2013 8:32 am Post subject: |
|
|
Newbie
Joined: 23 Sep 2011
Posts: 2
|
| ajodowd wrote: |
Hi sksharma_r,
All great advice above, and can I ask whether you considered the DFDL parser rather than MRM? Is it because you're not at version 8 or version 9?
DFDL has quite a few advantages over MRM, but I really wondered whether you considered it or not.
Thanks, Anthony. |
Anthony,
Yes you are right, i am stuck with Version 7 and DFDL would have been great for COBOL. 
Regards |
|
| Back to top |
|
|
|
|
