| Author |
Message
|
| deecee |
 Posted: Wed Mar 23, 2016 11:44 am Post subject: FileInput node with ASCII enabled IIB9 |
 |
|
Acolyte
Joined: 11 Sep 2014
Posts: 51
|
Hello,
The scenario I have in IIB 9 is,
Fileinput -> compute -> httprequest
The input file is a SOD file from legacy which needs ASCII transfer mode.
I have created a DFDL file for parsing the SOD file.
This scenario works fine in IIB 10.
But as my production system is in IIB 9, when I move the same scenario to IIB 9, it fails with parsing errors.
As the DFDL contains discriminators and it wasn't getting parsed initially, I changed the parse timing to Complete and tried the same scenario with a file that I could pick using Binary transfer mode and it worked fine.
So the issue is only coming with ASCII mode transfer.
How do I solve this issue? |
|
| Back to top |
|
 |
| timber |
| Posted: Wed Mar 23, 2016 1:05 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Quote: |
| How do I solve this issue? |
Well, quoting the error message would be a good start. That way, we would have at least some chance of understanding what is going wrong 
In DFDL, you can declare what character encoding you want to use. What value of dfdl:encoding does your DFDL model use?
Finally, please explain more clearly why you changed Parse Timing to Complete. That should have exactly zero effect on parser behaviour ( except to delay parsing until it is unavoidable ). |
|
| Back to top |
|
|
| deecee |
| Posted: Thu Mar 24, 2016 6:20 am Post subject: |
|
|
Acolyte
Joined: 11 Sep 2014
Posts: 51
|
the error i get,
| Quote: |
| An error occurred in parser ''Root'' while parsing the field named ''DFDL'' on behalf of the node or component '.File Input'. The data being parsed was ''Stream Based Page Buffer [0,23644] |
dfdl encoding, UTF-8
I set parsing to complete, because I saw in one of the threads how IIB9 DFDL has a bug in parsing complex DFDL's which involve discriminators. And it was failing for me in IIB9 while it was perfectly working in IIB10. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Mar 24, 2016 6:49 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
There is a world of difference between ASCII and UTF-8
ASCII (American Society for Compute Information Interchange) was mostly 7-bit (1 + parity bit) and is this a mere dot in the ocean when it comes to the range of charaters usable in UTF-8.
Do you really mean ASCII? It is so... well 1970's or early 1980's. It was superceded by ISO-8859-x range of character sets in the 1980's which in turn gave way to UTF as the preferred encoding for non EBICIDIC data.
Just interested to know why something is demanding ASCII these days.
_________________
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 |
|
|
| deecee |
| Posted: Thu Mar 24, 2016 7:18 am Post subject: |
|
|
Acolyte
Joined: 11 Sep 2014
Posts: 51
|
smdavies99
The file is coming from legacy, may be that's why  , i am not sure.
Would the encoding value in the DFDL setting make the difference in this case? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Mar 24, 2016 8:07 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| deecee wrote: |
smdavies99
The file is coming from legacy, may be that's why , i am not sure.
Would the encoding value in the DFDL setting make the difference in this case? |
You can check with the testing view of the DFDL perspective... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| timber |
| Posted: Thu Mar 24, 2016 12:52 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
smdavies99 said:
| Quote: |
| Just interested to know why something is demanding ASCII these days |
I agree that it doesn't make a lot of sense technically, but there are dozens of legacy data formats that require ASCII. ISO8583 and HL7, to name a couple. And they're not minority sports either. One is a major financial data format, the other one is widely used in most hospitals in developed countries.
deecee said:
| Quote: |
| Would the encoding value in the DFDL setting make the difference in this case? |
You have asked DFDL to read your data. Does it matter if you tell DFDL to use the wrong character encoding?
Have you not read this excellent article? The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) |
|
| Back to top |
|
|
|
|
