Re: Record name the same as the file name

[Hans Boldt <boldt@xxxxxxxxxx>]

Bob cozzi wrote:
> Even more so that local files, I'd like to see the ability to share the I/O
> buffer of a file between modules. 
> For example:  Declare file CUSTMAST in MODA and do a READ to that file
> somewhere in the main-line calcs or a subproc in MODA, then call a proc in
> MODB and have that proc in MODB be able to see the input fields from the
> read in MODA.
> I can do this today with smoke, magic and mirrors, but it should be easier.
> To make it easy, we'd only need the EXPORT and IMPORT keywords at the FILE
> level, and Toronto to do the work under the covers. <g>

Even with IMPORT and EXPORT on the F-Spec, "smoke, magic and 
mirrors" would still be an apt description, and perhaps even more 
so. IMPORT and EXPORT under any circumstances still allow you to 
define "hidden" interfaces between modules, and so generally are to 
be avoided in practice. The problem is that you'd be sharing 
variable storage, not the I/O buffers.

If you need to communicate whole records between modules, a better 
approach would be to code data structure results on the I/O 
operations (new to V5R2), and pass the DS as a parameter between the 
procedures. Granted, the current support is a bit restrictive in 
that only LIKEREC data structures are allowed, but we are looking at 
ways to relax the rules. And this approach still doesn't give you as 
much as a "file pointer" since you still wouldn't be able to read in 
one module and update in another. (Not that you'd necessarily want 
to do that, eh?)

(Actually, we've been flip-flopping a bit on exactly how loose to 
make the rules on result DS on external-described I/O.  But now 
we're settling in on requiring the DS to be a LIKEREC DS like the 
specified record, an EDS defined like the specified record, or a DS 
defined using LIKEDS like either of the first two, with some 
additional flexibility for read by file name. The change is now 
planned for V5R3.)

I suppose the bottom line is that there are indeed lots of ways to 
improve the I/O model in RPG, and we are not unaware of them.

Cheers! Hans