RE: Record name the same as the file name

["Bob cozzi" <cozzi@xxxxxxxxx>]

Hans,
The change could be to just allow any Qualified data structure as the target
rather than a short list of specific keywords used when declaring a data
structure.  What's the difference between LIKEREC and LIKEDS to the
Programmer? There should be no difference to the programmer. I could accept
a QUALIFIED limitation or no other limitation, but not a short list that
needs to be, (A) documented, (B) explained, (C) Taught, (D) Learned, and (E)
Comprehended.


Bob Cozzi
Cozzi Consulting
www.rpgiv.com


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Hans Boldt
Sent: Monday, August 25, 2003 8:35 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Record name the same as the file name

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


_______________________________________________
This is the RPG programming on the AS400 / 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.