This has been heavily debated several times before in this list, and I
would advise you to search the archives.
The idea is that by doing that, if and when a new field
is added to the file, you shouldn't have to recompile
existing programs, unless they require the new field.
If this is the problem you are trying to solve, consider another solution
someone else suggested: Define and create the physical file. No program
will ever reference the physical file; all native file access is via a
logical file. All logical files, when defined, have the fields
individually defined (vs. referencing only the physical's record format).
When you need to add a new field to the physical file, create new
logical(s), as needed, that have the new field added to the list of all of
the other fields. Logical files can share access paths, so if a new
logical is created to add just the new field, but has an identical access
path, there is no additional overhead.
This *could* be done with an existing physical file (used by "tons of
programs") as well, with no recompilation of programs necessary. The
physical file gets renamed, a new logical file is defined using the
original physical file's name and definition. (Again, all fields must be
individually defined in all of the logical files.) Doing this, the new
logical file will have the same record format ID as the physical file,
thereby avoiding level check errors. All of the existing logical files
will need to be modified to point to the renamed physical file, but again,
they should retain the same record format ID.
Additional consideration would be needed for certain processes that will
only work with physical files. For example, CPYF's TOFILE parameter will
not accept a logical file.
- Dan
midrange.com
