Re: Database I/O Modernization

What if the plan were to make the generator proprietary and charge
customers for it?

that would be a dead product from the beginning.

Okay, but wouldn't the choice of interface be simply a matter of style or
personal preference?

having one entry point, you would have to add all parms of all procedures to your one parm list. This has the risc that parms are not used correctly. Adding another (exported) procedure later on would change your one and only parm list and all consuming programms would need a change. Adding another entrypoint could be strongly isolated from all using programms - a must have for a deployed open source libraries (you don't have controll over applications using your library.

With this interface, a change in the record format would require a
recompile of the I/O server, plus all programs that call it. Otherwise
invalid data could be and probably would be pushed into the record from
referenced program memory.

We've had a similar discussion in this list earlier. Think of the ds as a data type and a type will never change!!! If you want the DS as an external DS, you would start with PF CusmstV01 with an LF CUSTMST, adding a field, you will get a new Version => PF CUSMSTV02, the old LF CUSTMST is built unchanged and a new (additional) LF is added. Both I/O modules could share the main logic, the old version would act as a wrapper for the current version, nearly without any logic.

I'm not sure I follow. It appears that you may be referring to replacing
the RLA op codes with SQL?

yes!!! from this starting point redesign is happening. You get rid of RLA, replacing it by SQL without any changes in your business logic, winning more flexibility for redesign in your database. In reality these I/O modules have to be generated in the initial step.

Good point. This interface has a lot of repeated logic in every service
program instance - an aberration of the Don't Repeat Yourself principle.

making this generic is not as easy as it might look at the first place. You would need "multiple instances" at runtime, because these modules are statefull. Thinking about this, you would need this capability for the one module per file too (e.g. setll followed by a read loop: two programms in the call stack could need diffrent opens of the same file. This could be solved with dynamic storage allocation, but you would need an additional parm - a handle -to be passed in with every call of the I/O mod. (similar to my Open Source APILIST http://bender-dv.de/Snippets.html#APILIST )

D*B