RE: Externalizing I/O

<Justin>
I'm not sure how using LF's for RLA would help with table layout changes.

I'm trying to solve the problem of changing existing columns, not adding new columns.

</justin>

let us assume you have an existing table named foo.
then you would have an E DS (external datastructure) named foo too, containing the complete record.
You would write a SRVPGM FOODAO as Data access Object (DAO) doing all I/O operations with foo, having some getters and setters, getFoo() and setFoo() and maybe sure some others. All I/O is done only by this SRVPGM, all other programms have to use this SRVPGM, if they want to talk to the database to get or modify the underlaying table foo.
Now you are making some changes to foo, adding fields, or alter dimensions of a field. As long as you could provide the getters and setters from FOODAO, the only Module seeing this changes FOODAO, this would be the only part of your application needing any change. The old layout of foo would be only a LF and doesn't change its name, so E DS FOO wouldn't change.
The new PF or LF doesn't make much diffrence, would get another name, let us assume foo2, The new E DS named FOO2 will have the new layout. To bring the new layout to your application, you would add additional getters and setters, including getFoo2() and setFoo2() and for sure some others.
All programms needing the new fields or enhanced dimensions need a change anyway and the are altered to use the new getters and setters.
The benefit of this is, you could first change your database and afterwards only touch, what needs a change.
Using SQL for database access instead of RLA, you could hide even changes in the design of your database, for example moving a column from one table to another, or working on normalisation of your database - that's the real benefit of SQL, compared to RLA.

Dieter