Re: CPF428A on a JDE Table

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.