RE: Using CPYFRMIMPF

If it were properly escaped, it would be a non-issue. However, most any printable character could be possible in the "real" data. That's why I prefer *TAB delimited or fixed width. It's pretty hard to screw those up.

Yes, I agree the middleware translation is at fault here.



-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of John Yeung
Sent: Friday, June 4, 2021 7:28 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Using CPYFRMIMPF

On Fri, Jun 4, 2021 at 4:56 AM Patrik Schindler <poc@xxxxxxxxxx> wrote:

My conclusion is, the middleware is faulty with its export function.

Signs are pointing that way, but regardless of whether it's faulty or
not, Roger did say he asked to get the data before being processed by
the middleware, to no avail.

Maybe this flaw can be partly blamed to IBM, interpreting a double quote being set not on field boundary (aka, beginning of line, end of line or immediately preceded or followed by the field separating comma) as delimiter instead of leaving it alone.

Well, I don't think that is what the CPYFRMIMPF command is doing, but
I'm not 100% sure, because I stopped using it long ago and haven't
rigorously tested it since.

I will say that recent versions of the command are vastly improved
over what it was when I first started playing with "import files"
on... I guess it was AS/400 back then.

My opinion is, that ambiguities must be avoided on the exporting side. So, a " as part of field data should be escaped. But it's easy to forget such corner cases in actual code.

This is why people should stop rolling their own already. (This
includes makers of custom middleware.)

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FComma-separated_values&amp;data=04%7C01%7C%7C06e20f936f684425c81b08d927650a0b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637584137174397792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Gv32fV62dRvgwh%2F3gGyBxTKMyMLxV0w1Kvwgu27kn1w%3D&amp;reserved=0 says:

[...] without additional information (such as whether RFC 4180 is honored), a file claimed simply to be in "CSV" format is not fully specified.

Absolutely correct. However, I will say that in my personal
experience, Excel has essentially "won". Indeed, RFC 4180 pretty much
describes what Excel does. Unless you control both ends of the data
exchange or have specific information to the contrary from whoever
controls the other end, the most practical thing to do is (1) assume
an Excel-compatible CSV, and (2) use an established library that
handles Excel CSVs.

John Y.