CPYFRMIMPF and it's counterpart CPYTOIMPF are great tools, but not without there share of complexities. I've had my own (un-related) problems with the latest version due to several (unnecessary) changes in V5R3 that IBM is currently addressing. This is a bit of "sticky wicket" if you don't mind my saying so. In the example given, you essentially have 2 delimiters for the data, and I know this is fairly common, because I've run into it myself. If I remember correctly, we had a similar situation on a conversion and wound up manually fixing the "offenders" since it was just a handful and only a one-time deal. > 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,| I know the data is coming from another system/vendor, but I wonder why it's necessary to have the quote marks around some of the data when you already have commas. I would think that in executing CPYFRMIMPF, you simply specify String Delimiter (STRDLM) of *NONE and it would work, except that you would have some of the elements with the quote marks included as part of the data. Then couldn't you run an SQL update on the data to remove beginning/ending quote marks? I know it adds an extra step, but it's a workable solution. Ron Adams Information Technology Group Crane Valves 9200 New Trails Dr. Suite 200 The Woodlands, TX 77385 "John Brandt Sr." <pgmr@xxxxxxxxxxxxxxx> Sent by: midrange-l-bounces@xxxxxxxxxxxx 10/06/2004 01:24 PM Please respond to Midrange Systems Technical Discussion To: "'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx> cc: Fax to: Subject: RE: IBM response on my CPYFRMIMPF request I think you should send a Pizza to Kevin and tell him that his future Pizza's will be 15" something, but the type has been cut off because someone can't figure out to program inside a delimiter, or this is a delimiter. What a crock. Send it back. John Brandt -----Original Message----- From: michael@xxxxxxxxxxxxxxxxxx [mailto:michael@xxxxxxxxxxxxxxxxxx] Sent: Wednesday, October 06, 2004 1:11 PM To: Midrange Systems Technical Discussion Subject: RE: IBM response on my CPYFRMIMPF request What's on the pizza? > -------- Original Message -------- > Subject: IBM response on my CPYFRMIMPF request > From: "Jeff Crosby" <jlcrosby@xxxxxxxxxxxxxxxx> > Date: Wed, October 06, 2004 2:02 pm > To: "'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx> > > <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. > > > > -- > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.772 / Virus Database: 519 - Release Date: 10/1/04 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.772 / Virus Database: 519 - Release Date: 10/1/04 -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
This mailing list archive is Copyright 1997-2013 by MIDRANGE dot 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 here. If you have questions about this, please contact