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.
I want to emphasize that this is *not* processing files as 'business
objects' - it really is a case of having a procedure called e.g.
Get_ItemMaster which retrieves a record from the Item Master file. IOW,
everything that some people say is wrong.
I know it's not for everyone, and there was some initial overhead with
setting it up, but it works extremely well, and we never have to code
explicit file handling in our application programs. We still have older
programs which access files directly, and it's a real drag to have to go
back in and process them. I'm looking forward to when we can finally get
rid of the final bits of inline file-handling code.
This mailing list archive is Copyright 1997-2019 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