| Author |
Message
|
| CuriCAT |
 Posted: Tue Jun 30, 2009 4:15 pm Post subject: FileOutput with Record is delimited issue [0D0A] |
 |
|
Voyager
Joined: 26 Sep 2006
Posts: 82
|
I create file using FileOutput node with record definition option as "record is delimited" and delimited as [0D0A].
When the file is produced, some of the data also contains same hexa decimal as record delimited 0D0A (in other words some of the data has same hexa value as line feed )
When target application parse the file, even records are getting splited into peaces when application see record delimted hexa value in the data. I see this as a common issue, 0D0A or 0A hexa value is used commonly in many file processing as line feed and carriage return.
How can I address this problem, is there any work around for this ?
I appriciate your help. |
|
| Back to top |
|
 |
| harish_td |
| Posted: Tue Jun 30, 2009 5:02 pm Post subject: |
|
|
Master
Joined: 13 Feb 2006
Posts: 236
|
Why would 0D0A be in the data? 0D is Carriage return and 0A is Line Feed/Start of Message [0D0A : Windows New Line Character].
The application generating the business data should not generate these values within the business data.
If you cannot change that, then applications downstream including your message flow need to change the record delimiter to a hex value other than 0D0A, Say ##. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Jun 30, 2009 9:40 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Ah the old 15,12 problem (octal representation of hex od,oa for those not old envough to have worked on an octal based system, eg PDP-11's). Yes some O/S use the presence of BOTH as the record terminator
Could the incoming message already have these terminators embedded?
If so then perhaps changing your message termination string might work.
_________________
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 |
|
|
| zpat |
| Posted: Tue Jun 30, 2009 10:11 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Remove the message data's ODOA in a compute node or change it to something else if you don't want it output.
Not exactly rocket science! |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jul 01, 2009 4:43 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| How can I address this problem |
Design your multi-record format with *all* of the requirements in mind. Using 0x0D0A as the delimiter is looking like a bad design decision. If you made that decision, either change the decision or do what zpat suggested. Otherwise, find the person who made the decision and explain the problem. |
|
| Back to top |
|
|
| CuriCAT |
| Posted: Wed Jul 01, 2009 7:13 am Post subject: |
|
|
Voyager
Joined: 26 Sep 2006
Posts: 82
|
| Quote: |
| Why would 0D be in the data? 0D is Carriage return and 0A is Line Feed/Start of Message [0D0A : Windows New Line Character]. |
When -10.00 get converted in EBSIDIC format with signed over punch the resultant binary data is 0000000100D. there is a 0D in the data area. |
|
| Back to top |
|
|
| CuriCAT |
| Posted: Wed Jul 01, 2009 7:21 am Post subject: |
|
|
Voyager
Joined: 26 Sep 2006
Posts: 82
|
Output message definition i create it from following COBOL copy book field definition.
10 AMOUNT PIC S9(09)V9(2) COMP-3 VALUE 0.
and I have to use 0D0A as a record delimiter since target system uses this as a record delimiter.
As I said before When -10.00 get converted in EBSIDIC format with signed over punch the resultant binary data is 0000000100D. there is a 0D in the data area. which creates the problem. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 01, 2009 1:49 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| CuriCAT wrote: |
10 AMOUNT PIC S9(09)V9(2) COMP-3 VALUE 0.
|
As you correctly point out, this is a packed decimal format. You're going to get problems representing that in a text format.
Speak to the guy sending the data, have it sent in character.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
