Re: Database I/O Modernization

@open source: the link points to an example, tied to a special file module cusmstf. You would need an instance of this for every file. If someone would provide a programm, generating such modules, this might be called open source.
@interface: having one entry point with an parameter Action is not best practice of modularisation. Why not export insertCusmst, updateCusmst, SetllCusmst... with only those parms, which are needed. This would be more handy to use too, replacing the RLA Opcodes in the current programms with very similar calls. (BTW this should be done by a generic programm, generating the needed code.
@modernisation: such a programm could be a first step in the right direction, it decouples business logic from database IO, but there are follow ons needed:
- changing the table layout of the underlaying table, the change has to be made for the I/O module only. keeping the current version adding a new!!! now recompile orgies of business layer
- replacing the RLA in the I/O modules, where needed, would enable the possibility of instead triggers, giving new possibilities for database redesign steps.
- replacing rla by sql, multiple of these I/O modules could share same logic (diffrent order only)
- replacing rla by SQL, the modules could be enhanced by an exported subprocedure setOrderByCusmst (BTW: I'm using this as exercise in one of my workshops)
- replacing rla by SQL the setllCusmst could be enhanced by the possibility to use non key values for setll
- replacing rla by SQL the module could be enhanced by an exported procedure filterCusmst (setting a where clause)
@joining files: this should be done in most cases in the view layer anyway.

This might be a starting point, but at the moment, it's only making a diffrence in programms where I replace the RLA by calls to such an I/O module. As long as the implementation of the module simply reflects one to one the same RLA operations nothing has really changed.

D*B