On Wed, Nov 16, 2011 at 9:26 AM, Vern Hamberg <vhamberg@xxxxxxxxxxx> wrote:
But I think, John, that you should look again at
CPYFRMIMPF - yes, there have been problems;
yes, it doesn't handle everything, but what does
when it's a general-purpose command?
Tell me, what good does it do if CPYFRMIMPF has not changed for me?
If it didn't work for me before, and it's the same as it was the last
time I tried it, how is it going to be any different now? When my
company upgrades, I will take a look at it again.
The several parameters on the command that do not
appear at first give you a lot of control. You get
to set the various delimiters.
I've played with the parameters. Until there is a parameter that lets
you choose to enact parsing of Excel-style CSVs, there is really not
much point for me. And even if IBM already put Excel-CSV parsing into
recent versions of this command, how would I use it? Is there such a
thing as a PTF just for CPYFRMIMPF? And would it work on V5R2? (I
don't mean to be mocking; if the answer is "yes, it exists, and it
would work", then maybe I actually have some chance of getting this
onto our machine.)
I think throwing it out of your armory completely leaves
you without a tool that is useful 90% of the time, and
you know ways to handle the others.
First, it's not out of my armory. I am still aware of its existence,
and I have no problem using it when the data is in a form that is
understood by the command.
Second, at *my workplace* it is useful at most 10% of the time. We
simply don't receive data that is understood by CPYFRMIMPF. We do,
however, receive Excel-generated CSVs by the truckload.
So we make our choices of what to use - you may have
a lock-down method that has no problems with delimited
files - I hope so - and if you do, maybe you'll share it on
the midrange code archive?
I haven't developed a method that lives on the i. You are right that
we make our choices, and my choice is to rely mostly on preprocessing
the data with tools that live outside the i, because I personally find
it more convenient. However, I have toyed with the idea of creating
an import-everything (including native Excel workbooks) program in
iSeries Python. Python has an included CSV module that handles Excel
as well as non-Excel styles of delimited files, and there are
third-party modules for .xls and .xlsx files. So it's feasible. But
so far I have not done it. (And there is the complication that on
versions of OS/400 before V5R3, the only iSeries Python available is
missing the XML support that is normally included with Python, which
means .xlsx is much harder.)
Of course, I don't completely trust Microsoft - with Excel,
especially, they try to "help" me far too much.
It's true MS applications tend to be overzealous, but this is mostly a
problem when providing data to be used *in* Excel, not when receiving
data coming out of Excel. While many people would argue that MS chose
poor conventions for their CSVs, the fact is that they *do* follow
conventions, and these are perfectly predictable and programmable. If
IBM wanted, they certainly could incorporate this set of conventions
into CPYFRMIMPF as a selectable (not necessarily default) behavior.
John Y.
midrange.com
