Re: File encapsulation

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.

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?  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?


--
"Enter any 11-digit prime number to continue..."
"In Hebrew SQL, how do you use right() and left()?..." - Random Thought
"If all you have is a hammer, all your problems begin to look like nails"