Re: Database I/O Modernization

I'm just following up on the latest comments from Rob, Birgitta, and
Jonathan.

Each of your post delineated some of the rationale for "externalizing" I/O,
including the encapsulation of data validation, RI constraints, business
rules, and mapping data from "business objects" to database files - all of
which may be incidental to database I/O.

However the API referenced in my original post is not designed for that.
It's merely designed to be a procedural wrapper around RPG I/O op codes.
That is evident by the three (3) parameters passed (Action, Record Buffer,
and Key Buffer).

This interface rather relies on DB constraints and trigger programs to
perform the additional logic that might need to occur, which would be
incidental to record I/O. That is evident by the monitor and on-error
blocks, which merely percolate diagnostic and escape messages up one level
in the call stack. There's no transformation of messages into something
more user friendly, for example.