|
midrange.com
That adds a level of complexity on the PC side. Although, if you are open
to that there are other possibilities where you could circumvent the
CPYFRMIMPF command all together--how about ODBC? About 6 or 7 years ago I
had an application that uploaded MS-Access records to the AS/400 via ODBC.
I don't believe that there were any issues with delimeter characters.
Dave Parnin
Nishikawa Standard Company
Topeka, IN 46571
daparnin@xxxxxxxxxxxxxxxxxx
Jim Franz
<franz400@xxxxxxxxxx To: Midrange Systems
Technical Discussion
om>
<midrange-l@xxxxxxxxxxxx>@SMTP@CTB
Sent by: cc: (bcc: David A
Parnin/Topeka/NISCO/SPCO)
midrange-l-bounces@m Subject: Re: IBM response on
my CPYFRMIMPF request
idrange.com
10/06/2004 03:11 PM
Please respond to
Midrange Systems
Technical Discussion
<midrange-l@midrange
.com>
any way to running this file thru Excel, outputting some other delimiter?
submit the pmr also..
jim
----- Original Message -----
From: <rob@xxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Wednesday, October 06, 2004 3:54 PM
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.
>
>
--
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.
As an Amazon Associate we earn from qualifying purchases.
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.
