Re: Database I/O Modernization

Some people think externalizing I/O like this is the best.
I've actually used software like this 30+ years ago on a Wang 2200 running
TOM (The Office Manager) software. It worked pretty good.

However I don't think this is the way to go with a database system like
Db2. This implies that all access is limited to only from these APIs. I
feel that people will eventually fight their way around this. For example
I need a report that joins this file to that file and so on. Do I talk to
the Db2 administrator and have him write an externalizer or do I just do
my own joiner? Or do I limit my code to RPG mentality which limits me to
read this file (call it's externalizer) then read this other file (call
it's externalizer) and so on.
Also, the externalizer crowd frowns on things like putting things into the
database itself such as check constraints, RI constraints and so on. They
normally feel that all this should be in the externalizer. This, I have a
real issue with. Again, people will find that they always have this
excuse to bypass the externalizer, such a mass conversion, etc. Or this
"one shot" deal which they could simply do with an SQL statement but now
they have to call a plethora of stored procedures.


Rob Berendt