Rory Hewitt wrote:
This has always puzzled me - if you need to have defined a LIKEREC's
file in an F-spec, why would you want to use the _R* API's to access
the file, rather than RPG's built-in file I/O opcodes?
Always? For how long?
I dunno... that was just what popped into my mind when I was writing the
e-mail. You can use the _R* APIs with EXTNAME or with no external
definition at all.. whatever floats your boat.
As far as reading into a data-structure, one thing that lots of
people seem to forget (or just be unaware of!) is that if you specify
an unqualified, unprefixed EXTNAME data-structure, every file
read/chain will *automatically * populate it, e.g.:
That's true, but it'll be populated in a different manner. If you read
directly into the DS (i.e. put the DS in the result field of the
operation) the record will be read as a whole block -- just a block
memory copy from the database to the data structure.
When you don't use it as a result field, the program will go through the
fields, one-by-one, and copy them from the database to the program's
variables.
There are pros and cons to each approach:
a) Block memory copy performs better.
b) Block memory copy won't get decimal data errors (allowing you to
detect them later via MONITOR, etc.)
c) Using the result field means you can specify a DS that's defined
locally to a procedure, instead of a global one.
d) Using a result field means you can have different DSes for different
records, and that makes it a little easier to have values from multiple
records loaded in memory at once.
e) Individual fields means that the data type doesn't have to match
precisely, thus letting you have zoned in the file, and packed in the
program, or vice-versa. That's a must when you have the same fieldnames
defined in your database and your display file.
f) Individual fields lets the system optimize things by only reading the
fields you use in your program.
So, although it'll read into the DS when the fieldnames match those of
the filenames (i.e. you don't use a result field, but do use EXTNAME),
it works differently, and may have a different effect in your code.
With the exception of display file record formats, these aren't an
issue with the vast majority of files, are they?
I guess that depends on how you define your files? For example, we
have some (admittedly, legacy) files where a logical file substrings out
pieces of other fields in the file. We can then key the file by those
substrings, which is useful to chain to particular records, or have the
file in a particlar sort order.
Those substring fields are input-only, however.
Then, of course, display files (as you pointed out) traditionally have a
lot of output-only fields.
Anyway -- I didn't design the thing. I'm just telling you the logic
that an IBMer told me about why LIKEREC and EXTNAME evolved the way they
did. You don't have to agree with IBM's decision to do things that way
if you don't want to -- but that's what they did. (Personally, I think
LIKEREC was totally unnecessary, and wish they had just extended EXTNAME
in the first place.)
midrange.com
