|
midrange.com
<what I submitted>
Abstract:
CPYFRMIMPF command
.
System Type: 9406
System Serial Number: 10-589ZM
Operating System: i5/OS V5R3
Product Group: OS/400 - General, Other
.
Environment:
V5R3, latest c-u-m, database, and hipers applied
.
Problem:
Question regarding CPYFRMIMPF command when the data has an
embedded " character. We receive files regularly from the State of
Indiana in .csv format. Recently a file contained the following
record:
FDP,COM,"BP11","Freezer","72/5.5oz por.","15" Ital. Pizza","15"
Italian Pizza",0,0,26,24.75,9.97,0,28,07/28/2004,|
Note that there are 2 places in this record where the " (STRDLM
character) appears within the data as opposed to being a string
delimiter. When I use CPYFRMIMPF to get the date to a PF-DTA file,
this is not handled properly. The data ends up fubar'ed from an
application viewpoint. If I open the received .csv file with MS
Excel, it is handled properly.
I wouldn't want it to get out that MS has more intelligent software
than IBM <g>.
Seriously, I have no idea what the 'standards' say for such a
situation. It could be that:
1) Excel should actually not open the file properly, MS is
notorious for not following standards.
2) Or it could be that when the State of Indiana created the file,
they should have doubled up the character so that the field read
like this: "15"" Ital. Pizza".
3)Or it could be that CPYFRMIMPF should have looked at the next
character and since it (the next character) wasn't a comma (the
FLDDLM character), then the " should have not been treated as the
STRDLM character.
In any case, there needs to be some resolution.
</what I submitted>
<IBM Response>
________________________ 04/10/04-10:48--CR ____________________________
S7> COMPID= 5722SS100
Customer Rep: Jeffrey
Action Taken: q to DB
Action Plan: Rq to NETRSP with response-Thank you
________________________ 04/10/04-11:18--CT ____________________________
NO CONTACT IS REQUIRED
________________________ 04/10/04-11:59--CR ____________________________
S7> COMPID= 5722SS100
Customer: Jeffrey
Problem: CPYFRMIMPF is not handling string delimiter " within string
delimiters in a comma field delimited file.
Action Taken: Investigate
Action Plan: REQ to DBWK04 with Delay to investigate and respond.
________________________ 04/10/06-12:24--CR ____________________________
S7> COMPID= 5722SS100
Action Taken:
Jeffrey -
I investigated and contacted development and there currently is no
support to handle a single string delimiter that is used within the same
string delimiters. The processing fails because the code can attempt to
find a 2nd matching string delimiter and therefore can go past the end
of field delimiter, into the next field.
I believe a circumvention for
you would be to use a different string delimiter such as '~' or
something other than a '"' which is being used as an inch symbol as
well as string delimiter in your example. Unfortuneately the CPYFRMIMPF
does not handle string delimiters within the same string delimiter as
sometimes expected.
The other option for you beyond the circumvention would be to submit a
design change request so our development could consider a change for a
future release. If you would like to this let me know and I can make
sure you get a DCR form.
I hope this is of help for you. Let know if I can close this PMR, or
what you would like to do....
Thanks, Kevin.
Action Plan: Await reponse from Jeffrey
________________________ 04/10/06-12:27--CC ____________________________
Customer Rep: Jeffrey
Action Taken: Notified customer PMR has been updated
Action Plan: Email-fup
</IBM Response>
<My response>
It's the State of Indiana and they send this file to other businesses, not
just us. They are not going to change the delimiter(s) due to this
deficiency. I would like a DCR.
</My response>
--
Jeff Crosby
Dilgard Frozen Foods, Inc.
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.
