I would find your technique onerous to the system.
First there's the I/O of going from outside the qsys.lib system into the
qsys.lib system with both. Then there's the overhead of the merge. Then
there's the conversion of them back into the non qsys.lib system.
Then there's the temporary space to consider. If you have a 10GB stream
file being posted into your 200GB stream file and you copy them into DB2,
do the merge, and then put them back outside of the qsys.lib system it
really starts to add up.
This is why I often cringe when people want to do DSPOBJD to output files
and then massage that to no end when there's perfectly good APIs to use,
like open list of objects and whatnot.
Another thing to consider is that IBM often uses internals far past the
APIs that even many in the community consider stretching past their
comfort zone. For example, when I started thinking about some of the SQL
services and how I would do it using various APIs only to be told by IBM
that they shave off a bunch of the overhead by accessing the internals not
available to those APIs. For example, having to use the open list of
objects API followed by the retrieve object description API when IBM
really could do that with one less API by accessing the internals in the
Chuck often mentions these internals.
I like his explanation as to why IBM does not have *CMD object duplicates
of many of these qsh commands. I may not be totally happy with it as I
have a hang up with qsHell but that's my problem.