RE: IBM response on my CPYFRMIMPF request -- MIDRANGE-L

Understandable, and that's why in general I always shy away from using the 
comma. 
In fact, we never use the comma as a delimiter here because some of our 
part numbers (for some odd reasons) have commas in them.
Of course, when the customer supplies it this way, sometimes you just have 
program around it, unless you can persuade them to change their (sinful) 
ways.  <g>


Ron Adams
Information Technology Group
Crane Valves
9200 New Trails Dr. Suite 200
The Woodlands, TX 77385





rob@xxxxxxxxx
Sent by: midrange-l-bounces@xxxxxxxxxxxx
10/06/2004 02:54 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


Technically the comma alone is not necessary a good indicator.  For 
example:
1,"Vehicle, SUV, green", 5,"hi ya"
But it really boils down to because the customer supplies it that way.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





ron_adams@xxxxxxxxxxxxxx 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
10/06/2004 02:15 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Fax to

Subject
RE: IBM response on my CPYFRMIMPF request






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 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.