I am thinking on the level of a whole new application. Everyone
knows that even a well planned application will need additional fields
added and changed as you go along.
...Every shop I've been in has had several changes to their database
files.
It's a way of life in our shops. Ubiquitous on System I machines are
generic field names, with often very important flags stored as
substrings in fields with names like BLANK5, BLANK7, CHAR50A, CHAR50B,
YOUNAMEIT, and the like. When you need another flag to tag along with
the customer master record, just find a substring for it. *IF* you can
find somewhere.
Not for nothing IBM gave us triggers, and a lot of shops use them, but I
think this could replace all the ways triggers are used, but with much
less overhead, plus more flexibility, like joining relevant
externally-acquired (off-platform) data, like Eric mentioned.
I have heard of one shop that started to go in this direction and
actually reverted, but to me the thing is that it may take some
significant organization and discipline necessary to pull it off, but
IMO it could well be worth it. And we have an example of someone who is
satisfied with it.
It seems like Chris has a setup like I had in mind. The subprocedures
can handle things like making sure a file is open (If not
%open(file)....Open File....Endif) that we put into our code..
Another benefit would be a one-stop set of validation-error logic
routines that feeds back to all the programs that try to write or update
to the file.
--Alan
midrange.com
