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



Chuck,

It's interesting how DM maps the data for the format; I hadn't thought about how IDDU accomplishes it, but the MFLF mechanism would seem to apply, at least internally.

At some point in the process of either compilation (in the case of a MFLF) or runtime (in possibly some other cases), the RPG program should be able to know where there is an ambiguity. Only in those (rare?) cases should we be required to specify the format.

Are there any cases you can think of (for data files) that this would be problematic?

-mark

At 3/1/2011 12:58 PM, you wrote:
On 2/27/11 2:08 PM, M. Lazarus wrote:
> Is there any good technical (not historical) reason that we still
> have any opcodes that can't use record formats and file names, for
> data files, interchangeably? PF's can't contain multiple formats.
> Multi-format LF's are relatively rare nowadays. The only time it
> would require differentiation is if a MFLF is used.
>
> Is there a consideration to relax that requirement?

Just some thoughts which may or may not be relevant to that request,
so FWiW...

Overrides of a database file to another file [with multiple formats],
even to a device file may be an issue. The RPG language operates over
the Common Data Management for accessing Database and Device files,
versus defining the rules of data management. The record format is
/common/ across the file types, and thus the RcdFmt is reflected in the
Common Data Management interface to the database file, just as to the
various device file types. Consider that DSPFD of a Save File [device
file attribute SAVF] shows that the file has a format which is defined
in the ODP even though no actual internal *FMT object type exists; if
any extended type attribute of the *FILE object type had no use for a
format, that is surely one, but for reading and writing, the common DM
requires the format to be /common/ across the various file types.

The data management and database support multiple formats for a PF
via "redirection" to an external format; I know only of IDDU in this
capacity. I am not aware if there is any support via RPG for that
capability; i.e. access to a program-described file as though the file
were externally described, via redirection to the file and record format
definitions in the IDDU [*DTADCT] data dictionary. To the common data
management the difference between MFLF and MFPF is minor; i.e. they
operate effectively the same, in how the request is handed off to the
database, where both require a format name [though possibly defaulting
to *FIRST if unspecified] to operate properly.

Some interfaces such as OPNQRYF offer a special value *ONLY for the
RcdFmt such that a file being acted on, for which more than one format
exists, an error will be issued; e.g. CPD3104 for the FILE parameter.

Regards, Chuck


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.