× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.