Re: CPF428A on a JDE Table

Yeah, once you use the C functions, you have to use them all. That's fine, if it's needed.

My mention of a generic file-handler was only parenthetical - not to suggest a generic handler for this situation.

The generic handler I mentioned made use of an program-described file - and those cannot process null-capable fields, so it is very likely to run into problems with more modern practices, especially with output of SQL to a temp table, for example. That handler also did not properly work with varying-length fields.

OK, it was old - some day, when I get the gumption, I may do something similar to handle current structures and protocols.

Later
Vern

On 12/21/2013 6:31 PM, CRPence 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.