Re: Passing a file to a procedure

[Vernon Hamberg <vhamberg@xxxxxxxxxxx>]

Rory

The use of an internally defined file has a tremendous problem - 
handling NULL-capable fields - it will not do it - the program blows 
up. Julian Moneypenny's set of generic file handlers from the later 
90s does just that.

Regards
Vern

At 11:07 AM 11/27/2007, you wrote:

> Larry,
>
> Well you *could* code this in 'native' RPG - simply have an internally
> defined file defined with USROPN and EXTFILE. You have one procedure to
> 'load' the file which basically puts the file/library name into an array and
> returns an integer (the index in the array). You then pass this integer to
> your other procedures, which look up the array to get the file/library name,
> load the EXTFILE variable, open the file and do whatever they need to in
> terms of READ, CHAIN, WRITE etc. and then close the file. All the procedures
> only know the file handle (except, obviously, the first one, where you
> specify the file to be processed).
>
> I have a series of procedures which do this, which I originally wrote to use
> OVRDBF (since this was before the EXTFILE keyword existed). If you're
> continuously opening and closing a file, it can be slow, but if you're
> typically just doing something to the same file, you can keep track of the
> 'current' file and use that to determine whether to open/close it. Keyed
> operations are tricky, but not impossible.
>
> It's doable, but as you say, it's easier just to use either the _R* API's or
> just to write it in C.
>
> Rory
>
> On Nov 27, 2007 1:56 AM, Larry Ducie <Larry_Ducie@xxxxxxxxxxx> wrote:
>
> > ...You can't get the functionality you request in native RPG file I/O
> > code...
> > Larry Ducie