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



Oh, good, I can breathe again.

I was afraid, after Rob had not responded to the CPY*IMPF topic within 4 nanoseconds, that something might have happened to him.

So glad the world is OK again now. :)
++
Dennis
++
If all of life's a stage, then I want to operate the trap door.




Sent from my Galaxy tablet phone. Please excuse my brevity.
For any grammatic/spelling errors, there is no excuse.
++


rob@xxxxxxxxx wrote:

John,

The CPY...IMPF gets worse after V5R2. The only thing constant with
that
is change.


Rob Berendt
--
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: John Yeung <gallium.arsenide@xxxxxxxxx>
To: Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxx>,
Date: 11/10/2011 10:48 AM
Subject: Re: Upload excel sheet to DB2 file on AS400
Sent by: midrange-l-bounces@xxxxxxxxxxxx



On Thu, Nov 10, 2011 at 9:32 AM, Morgan, Paul <Paul.Morgan@xxxxxxxxxxx>

wrote:
If you use CPYFRMIMPF with the RCDDLM(*CRLF)
and FROMRCD(2) parameters you can skip the .txt
futzing in your process.

I think Pete was referring only to the very last CRLF (which could be
interpreted as signifying an empty record at the end; but I don't know
because I haven't used CPYFRMIMPF in ages; see below). Surely the
other ones have to stay in there. FROMRCD(2) is a nice tip for
skipping the header row.

Personally, I have had lots of problems (ranging from annoyances to
deal-breaking lack of functionality or incorrect functionality) with
all of CPYFRMIMPF, CPYTOIMPF, CPYFRMSTMF, and CPYTOSTMF. I'm on V5R2,
if that makes a difference, and I think it does.

1) Save from Excel (I prefer CSV format)

Normally, I would say CSV is less safe than tab-delimited (because
data is much more likely to contain commas than tabs), but in the case
of either type generated *by Excel*, I think I agree that CSV is
better. The reason for this is that even if you choose tab-delimited,
Excel STILL treats commas in your data as special characters, so your
import facility still has to know how to parse Excel CSV anyway. (And
CPYFRMIMPF on V5R2 certainly does not.)

Because of all the issues with IBM's commands, particularly when
interfacing with Excel, I don't use any of them directly anymore.
Some of them I've been able to create tolerable wrappers around (I
think CPYFRMSTMF and CPYTOIMPF). For anything that has to read or
write "heavy-duty" Excel data, I now leave the data in Excel binary
format and use iSeries Python and the xlwt and xlrd modules. (Regular
Python with xlwt and xlrd is a great option for working with Excel
files on Linux/Windows/Mac.)

Scott Klement's POI stuff is certainly an option, and Giovanni Perotti
(Easy400.net) provides a wrapper around that which should be even
easier. (In my opinion, neither of those is as easy or as capable as
xlwt and xlrd, though.)

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

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.