On Mon, Oct 1, 2012 at 2:24 PM, Stone, Joel <Joel.Stone@xxxxxxxxxx> wrote:
Agreed. I was hoping to do this without a second HLL pgm (I already
have one HLL pgm to do the ETL).
Not your fault, but as an aside, I really dislike "HLL" to mean
"either RPG or COBOL", which I guess is what you mean. This is
probably accepted terminology in IBM circles. There's plenty of other
IBM terminology I've not been happy with.
Ironically, RPG and COBOL are the *lowest*-level languages you are
likely to consider for problems like this, and indeed for most
day-to-day operations. But I digress.
There are 20 files, which means I would then have 40 pgms and 80
objects floating around for this ETL.
Are those 20 files all different formats? If they all have the same
record length, then overriding them (and funneling them all to the
same RPG) is perhaps the most straightforward way. (Yes, the CL code
will look really dumb and repetitive, but 20 isn't all that many, and
you can get it done pretty fast this way. If we were talking 200
files, then I would be more gung-ho about avoiding copy-paste coding.)
There must be a creative way to do this.
For tasks that are not blatantly SQL-friendly and RPG-unfriendly, I
find that the performance of RPG is so superior to anything else on
the i that it is worth it to just compile as necessary. For example,
I wasn't happy with CPYTOIMPF or CPYTOSTMF when it came to converting
PFs to CSVs, so I wrote my own using CL and RPG. One RPG is for
reading the DSPFFD output and the other RPG is dynamically recompiled
for each PF being copied.
So yeah, at worst (in terms of complexity) you could do a similar
thing for your task at hand.
John
midrange.com
