× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Scott,

<snip>
LIKEREC defines a data structure to be like a record format. That
record format must have already been brought into your program via an
F-spec at the top of the program.

LIKEREC guarantees that the data structure is identical to the input or
output buffer that the RPG program will be using to interact with the
database, that's important when you want to read a raw record into the
structure (which is what happens when you list the DS in the result
field of a RPG I/O opcode, or if you use something like the _Rreadx() APIs.)
</snip>

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?

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.:

D FileDS E DS Extname(YELMCST00L)
...
/free
read(e) YELMCST00L;
/end-free

After the read, the FileDS data-structure contains the record data. You can
then copy the entire DS into a separate (qualified) data-structure if you
want. True, it's not as 'obvious' as coding a LIKEREC data-structure on the
READ opcode itself, but that's effectively what you've done...

One benefit of using EXTNAME is where you have a program which might want to
read a number of different files - you simply define a program-described
file in the F-specs (complete with the EXTFILE keyword), override to the
file you want, read the file into a generic data-structure and then copy
that data-structure into the EXTNAME'd data-structure.

I also make use of the ability to add additional fields and/or provide
overlays of exisitng fields, e.g.:

* Subfile record data-structure
D SFLRCDDS E DS Extname(YELMCST00L) Prefix(Z_)
D Z_CstID1 1A Overlay(Z_CstID:1)
D Z_CstInf47 47A Overlay(Z_CstInf:1)
D Z_CstInf48 3A Overlay(Z_CstInf:48)
D SflSel 1A
D Z_DspInf 50A

<snip>
Also, if a file has fields that are input-only or output-only, EXTNAME's
format might not match the layout of the record.
</snip>

With the exception of display file record formats, these aren't an issue
with the vast majority of files, are they?

Rory

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.