RE: File Encapsulation Quandary

Kurt,

You could, of course, go with Jeff's idea, but have two modules in the same
service program - one containing the update routines and one containing the
read-only routines. Additionally, since there could be a lot of duplicated
code, you could put chunks of it in (gasp!) copybooks.

Frankly, I normally agree with Eric that file encapsulation may not be
worth the effort, but that's more related to the type of work that I do and
the database that I work with. Although, FWIW, I've never seen a problem
(as Eric seems to) with having a generic 'get' which retrieves all the
fields. Even when I only need a subset of the fields, it's not like it's a *
problem* that they're all returned - I just use some and ignore others.

Rory
On Apr 4, 2012 8:38 AM, "Kurt Anderson" <kurt.anderson@xxxxxxxxxxxxxx>
wrote:

Rory,

Interesting idea on the dual F-specs for the same file. Similarly I'd
have to have two files per logical as well, although our files encapsulated
by service programs generally suffice on the keyed physical. I'll have to
think on that (and when I get time, play with coding it). I think two
files wouldn't be too bad to implement into one of our service programs for
testing since the newer ones already access a data structure with the Gets
and Sets procedures.

Jeff, I suppose that could be a consideration, although I think Rory's
idea of using two F-specs might reduce the duplication that 2 service
programs would create.

I appreciate the feedback and ideas.

Thanks,
Kurt