RE: File encapsulation

Actually that just made me think of the approach I decided to take when
I
went down the road you are going on. . . Only when a file became hard to
keep up, regarding changes to the structure, would I ever entertain the
idea
of putting a file I/O layer in. Doing an all or nothing is like trying
to
boil the ocean (which is the way I initially went but found my pot
wasn't
big enough ;-)

When deciding to do it all, you have to realize it's going to take a
while to convert all the files and the programs that touch them. Our
approach will be to adopt the philosophy and update things when it makes
sense.

>Typing "wkSOON = getSOON();" is no more onerous than "wkSOON = SOON;".
This is a good starting point for the discussion. What did you have to
do to
get to the above statement? A chain? A read? How were those sub
procedures
written that have the chain and read in them?

Or an SQL statement. What ever it takes to get the data you want. The
internals are important only during the design and implementation. The
object is to make the end-product reliable and easy to use. Plus, it's
not necessary to think of everything upfront. There's no need to code
for a data access method that's never used. If someone decides to use it
in the future, they just update the service program.  

>In my view, the only real consideration is the impact of repeated calls
to
setters and/or getters in a batch environment.
I wouldn't consider that as much of a problem as trying to keep all of
the
getters and setters service programs up to date and getting them
initially
written (a lot of man hours to consider there).  

Case tool

How do you plan on doing signatures for new sub procedures for one? 

I don't get your point.

A large set of applications can get into the thousands of tables (not
including indexes, views and other DB objects). Is it wise to write
applications I/O wrappers for each of those before you even know you
need them for each specific file? 

If the organizational philosophy is to encapsulate file access, the
question of "need" is mostly irrelevant. Obviously, common sense needs
to prevail; it would be idiotic to encapsulate a one off. 

I think the point you're making is that files used in a minimal number
of places need not be wrapped. The cost/benefit is wobbly. So, start at
the other end of the spectrum - those files you dare not modify because
200 programs would have to be recompiled. Still, if the philosophy is to
wrap files, then any new production file should get the treatment.

>...creating the service programs can be delegated to a case tool.
Are there any out there that do this job well?  

I write my own. A few years ago I wrote a case tool in Objective-C. That
was before free, which should be much easier. This time I'd do it C#.

I have to admit that none of
my RPG code is generated nor have I used a RPG code generator, so I
can't
speak to the tools usabilities whether they are good or not. I do
however
use a lot of Java code generators (i.e. Hibernate class builders for a
good
related example) and I must say that they are quite nice and save me a
ton
of time, but Java is a much different language than RPG and Java tools
are
much more abundant.

Good conversation, I think there is some good middle ground we can find
here
for encapsulating in RPG.
Aaron Bartell