RE: i/o module

<snip>
But, if I have one inquiry program and one maintenance program both
accessing
the same file, having that file encapsulated into one service program
makes it easy to reuse.
</snip>
Why?

<snip>
Data conversion.
Some of our older files have fields that are zoned vs. packed. Why? I
don't know. So to make the interface not care if it's packed or zoned,
the getter procedure converts it.
</snip>
I use externally defined files. I never care.

<snip>
Shared Constants.
Let's say the file has a code field. If that code's only use is with
the data in the file, why not define those values in an associated copy
source (that already houses the prototypes). That way both the
encapsulated file service program and any module using that service
program can access constants without redefining them.
</snip>
Huh? You mean like changing 'IZ' to inactive record? Or do you mean
changing the item class code to the item class description? Sort of like
what a view, or a decent join logical would do?

<snip>
File specific business logic.
When we write a comment record, we're always incrementing the sequence.
Why should the every business logic service program that writes comments
to a certain file have to recode the increment logic? So it's embedded
in the write procedure within the file's service program.
</snip>
Initially I was thinking of an IDENTITY column, but typically the way an
application like yours would go is
order#, seq# where seq# starts over at 1 for each order# and thus an
identity column is not what you want.
Actually, what is probably better than a comment file is a clob field or a
nice varying length field. Then your application could determine how long
each line is based on what they are trying to fit it into, ie, data entry
screen vs report column, etc. Granted, coding a decent column this on a
5250 data entry screen is a boatload of work versus a better interface
like a simple "text" field in a web or client server interface. But if
you have to stick with a bad file layout that has the typical order#, seq#
layout then maybe externalizing it might make some sense. How would it
handle deleting a row out of the middle?

<snip>
Other examples of business logic: Error logging on the specific file.
</snip>
That might start to make more sense. When you start having to trap for
trigger errors, constraint errors and programmers assuming that every
write failure is because the key already exists and thus tries a
chain/update or some such animal...

<snip>
Open file initialization.
</snip>
Huh?


It took me a little while to believe file encapsulation was for me. It
was working in VARPG that really brought it to light. And while there's
the initial hit on time to create the service program, it has made my
life easier when working on other programs that use these file service
programs. (Note, the amount of time to create them gets a lot easier
when you have a utility to do it for you - we created one that works
great, adheres to our shop standards, and could use even more
enhancements. I see someone else has posted one too.)


Rob Berendt