Re: CPF428A on a JDE Table

To followup on this general discussion, the Control Language for Files
(CLF) product is based on CL commands with RPG CPPs which utilize the C _R*
functions. Referring to http://www.powercl.com/clf/clfcommands and looking
at OPNFCLF (in particular the help text for keyword ALWEXNDTA) you will
find support for opening/using a file containing extended data types (such
as LOBs).

And as Chuck suggested, it was a whole lot of fun to write -- for me, much
more fun than doing the whole thing directly with C CPPs :)

Bruce


On Sat, Dec 21, 2013 at 6:31 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 21-Dec-2013 15:31 -0800, Vernon Hamberg wrote:

On 12/21/2013 2:44 PM, CRPence wrote:

-snip-

The C language has a capability to effect an open using the
"process large object fields specified in the program" for the
UFCB. That is of no help directly to the RPG unless the same
capability is exposed via the RPG as well, because a shared open
would still fail, just like the full open, but with the error msg
CPF417C RC6 instead of the CPF428A. And deferring the work to the C
vs to the SQL is probably not necessarily any better as a solution.
And obviously, if the capability is [were to be] exposed via the
RPG, then no reason to defer to the C [for its _Ropen lobptrs=Y
capability].
http://archive.midrange.com/c400-l/201111/msg00013.html
-snip-

Just as a wild toss - since almost all the C functions can be run in
RPG, they could be used for RLA instead of F-specs. That is something
I was considering to update an old utility by a fellow named
Monypenny for generic file handling - his stuff didn't handle
null-capability, etc.

Granted, C-level RLA is not as much fun as native RPG, but it does
work. And I'd like to think we can call those routines in RPG, just
as we can for everything else we can do.

I am unaware of any reason one could not invoke the C routines to
effect the RLA; I've seen prototypes for the C functions. Sadly, I may
have even done so, but I have no _clear_ recollection; I might be
remembering use of actual C source code... though given my distaste for
that language...?.? ;-) Irrespective the use of directly prototyped,
use of wrappers, or use of a [service] program that is purely C code,
the deferral is still to the C. That is, the C routines will not create
an ODP for the RPG, against which the RPG program could then start
issuing READ\READE requests. Nor can the ODP created by the C [or
OPNDBF] using the "allow\ignore LOB" feature, be shared by the RPG.

Limiting myself to just the necessary database I/O via the direct
function calls to the C via the RPG, would be IMO, way more /fun/ than
having to write a program in C to do the same :-)

There is probably sufficient prototype information that can be culled
from the web for _Ropen and _Rlocate such that writing an RPG solution
for the specific scenario as described in the OP [i.e. not a more
/generic file handling/ solution], probably would be fairly
straightforward... if the chosen resolution via the SQL UPDATE is not as
desirable as using /native/ RLA.

--
Regards, Chuck
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.