Re: Compiling after file changes

["Lennon_s_j@xxxxxxxxxxx" <lennon_s_j@xxxxxxxxxxx>]

Here is something else to throw into the mix:
http://www.mcpressonline.com/programming/rpg/use-a-logical-file-layer-to-minimize-recompiles-from-field-additions.html

The essence is that you use LF's that explicitly include the fields that 
are needed for the particular application, instead of all the fields in 
the underlying physical.  It is a concept somewhat similar to using SQL 
views, but is more comfortable if a shop isn't into SQL.

Note that there is some effort required to retrofit it to an existing 
system, but once done it can make the next change a whole lot simpler.

I'd also like to support Charles Wilt's suggestion to abstract business 
logic into callable routines.  Makes changes so much easier.

Sam


On 5/28/2010 5:59 AM, David FOXWELL wrote:
> Hello all,
>
> I have some thoughts on binding that I hope you will be able to help with.
>
> If a widely used file gets modified, it means probably recompiling everthing on the system, as all our modules are bound to programs by copy. This is such a pain, especially on development machines.
>
> Management now wants a separate i/o module for a file. I used an article form iSeries News by Scott on MVC to come up with a proposition. I no longer have the article so if anyone tell me which issue that was, I'd be grateful.
>
> Scott used getters, I believe, for each field of the file. Management doesn't like the look of all those getters, though. Now, if in place of the getters, a program could call a procedure in the i/o module that simply returned the file record in a DS....
>
> <crunching noise as brains engages first gear>
> 1. Situation today : any file change means recompile all programs because of level, file is referenced in almost all programs.
> 2. Put the i/o module in a service program. Am I right in saying that now, DSPPGMREF will no longer find the file?
> 2a. If the procedure in the i/o module returned the file record in a DS, all callers will still need to be recompiled to change the DS in the caller?
> 2b. If a getter is used for each field instead, there would be no reason to recompile the callers that did not use the field that changed in the file?
>
> Thanks