Re: SetLL *start

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