Re: File encapsulation

On Mon, 2005-11-28 at 13:12 -0800, Tony Carolla wrote:
> On 11/25/05, Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> wrote:
> >
> > Personally, I've found that what makes it the most valuable is to have it
> > so that the module does MORE than just database access.  Instead, have it
> > do some business logic as well as simply loading the record.
> > --
> >
> 
> I am working on a new application that will encapsulate the act of adding
> new records to the database.  The accounts file has many constraints, as
> well as other business rules that need to be enforced.  Also, there is a
> unique identifier assigned to each new account, and this is handled by the
> record creation service program.
> 
> This serves many purposes:
> 1)  Provide a detailed response when a file constraint is violated, so that
> the calling program can avoid checking some of these constraints, and rely
> on the service program
> 2)  Enforce business rules that are not easily set up as PF constraints
> 3)  handle unique account identifier generation logic
> 4)  handle fields such as "Date Record added", "User who created", etc.
This is a reasonable example of encapsulation - encapsulation of
business logic.  What's really great is that you can call it from a
green screen, a web app, or in batch.  It is harder to screw things up. 

Course a database trigger could keep folks out of the file, while using
a procedure is merely optional. 

> 
> I have looked at what would be involved for encapsulating READs, CHAINs,
> etc, and I have decided to limit the encapsulation to this.  I couldn't see
> how it would make sense to do this for file input.  Who knows what key
> fields a program might need to use in the future?  What do you do, build an
> LF for every possible combination of fields, and have the service program
> decide which logical to use?
I think it's fairly unworkable, though I suppose SQL could work.  Let
the service program caller specify a 'where' clause.  The SQL optimizer
is supposed to work out which logical(s) to use.  You could even
register a 'record received' callback in the application with a
procedure pointer and have the procedure invoke the callback whenever a
record is read.

>   Or would you simply restrict the READer to
> primary keys, and force multiple reads?  Also, what about blocking?  How do
> you better serve the report program that is going to read almost every
> record in the file, vs the interactive READer who just wants a few records?
I don't think you do.  Any sorts of READs are probably fine.  It's the
updates/adds/deletes that I generally want to protect in some kind of
framework.