FWIW, I've used exactly the sort of file encapsulation that Scott, Charles
and others seem to hate - essentially creating a service program with
multiple modules, each one containing Get and a Set procedures for each
file. Each procedure passes a data-structure of the entire record format.
Why do I do this?
1. Caching - in some cases, file data is loaded into an array within the
Get procedure and when the Get procedure is called, it first checks the
array, before reading from the file. This provided a
*significant*performance 'boost', compared to simply reading the
record every time. It
also avoids almost all record locks for commonly-accessed records (from
'control' files, for example)
2. Maintainability - although it is rare that file record formats change,
it does happen. Rather as with IBM API's, when we call a Get procedure, we
pass both the key and also a 'format' identifier (actually, just a version
number). The Get procedure checks which version number is being passed and
returns the correct version of the record format data-structure.
3. Overrides - it's very easy to pass in the name of an overriding file
and/or library and have the procedure do all the file open and close stuff.
4. Common error-handling - standard error-handling procedures are used
throughout, using a combination of *PSSR, INFSR, MONITOR etc., and perform
5. Extensibility - we can convert our processing to use SQL bit-by-bit,
with no impact to our application programs.